From nobody Tue Jan 2 08:19:04 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 0B48612D77D for ; Tue, 2 Jan 2018 08:19:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mailforce.net header.b=N0LEeMYB; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=IwFyWXEe 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 oXqBqcg48830 for ; Tue, 2 Jan 2018 08:19:00 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C359B12D7E2 for ; Tue, 2 Jan 2018 08:19:00 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 39AAE20AC6; Tue, 2 Jan 2018 11:19:00 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Tue, 02 Jan 2018 11:19:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailforce.net; h=cc:content-transfer-encoding:content-type:date:from :in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=g38HT1ujKQG3nciFp dZtL4yXNSFO9BRH9i0BHj6Vlbs=; b=N0LEeMYBvFp1eqYmCiG7/ZCCyi8PCsfFb icGTrbrnYS4WBtwQGIKFCKnx8GJkGFfA+JWrScAvJSie4cgWYJSeVIErh3QprjGQ RKGEEgqsAHMALH9v+1pKFbX6gGEein0WZ8BzN0TkEPmkWieCecUQRmgVTKI2zF4j TmHT1oqBA63yoR9A15GEop6tM78odFdFR8YX/YSqRpfI1Ujl1Tamhvf1ETlRCUMo uNQxN+3FNpITJsnbMvdmVya4QS0f3UWUJ4H9lGD3pupoRailyv0DcdCezEgXgrUY ypfUfNuoNgW130jpx1fgIujgT/lGDEyfWMbJc88hcFiW2yRWljAsw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=g38HT1 ujKQG3nciFpdZtL4yXNSFO9BRH9i0BHj6Vlbs=; b=IwFyWXEeBCj7/r8L4Gy1k8 h3uvgsLNHNqTpHS5BWvCekcrWmlwg/7eipJdLKKzxs9W2GNrXbSUGIcBqHZ2bZdP GPs/6re5CyFstj0v2qCJJU/k2GU69mq7W5Pax2JiYsFHsTQfGmqrcs6/LPmuVdmY LNE8H0abgLeaFurU/8gYOyth0YULKNgtbccDXMfXJrUrM/cEN1f5QPWbuheXQ8F1 TYp0yFLhdmpoB8yeKLVS+p0apU1mzlFZLVaqPbGwSovNskQ5KwmEIJhx/3r+5FpC z9TJGn3b6DYmXLryiDJdANMHhmSrB9qSSMLCGXBAk8dyIumczEkF3Y14jJHBaSFg == X-ME-Sender: Received: from [192.168.1.71] (108-84-31-27.lightspeed.tukrga.sbcglobal.net [108.84.31.27]) by mail.messagingengine.com (Postfix) with ESMTPA id DAD127E353; Tue, 2 Jan 2018 11:18:59 -0500 (EST) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-813AAB74-E841-4D0E-AA9E-BE304B04BC89 Message-Id: <2C837E60-BEAF-4098-9482-758FDB660B72@glyphein.mailforce.net> Cc: Seth Blank , dmarc@ietf.org X-Mailer: iPhone Mail (13G36) From: Stan Kalisch Date: Tue, 2 Jan 2018 11:18:54 -0500 To: "Murray S. Kucherawy" Archived-At: Subject: Re: [dmarc-ietf] ARC draft-10 protocol elements section and question about reducing section 8 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, 02 Jan 2018 16:19:03 -0000 --Apple-Mail-813AAB74-E841-4D0E-AA9E-BE304B04BC89 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On Dec 29, 2017, at 12:29 PM, Murray S. Kucherawy wr= ote: >=20 > Chairs, should we start using the WG's issue tracker for this stuff? Speaking as an observer, I personally would find that helpful. Thanks, Stan >> On Thu, Dec 28, 2017 at 4:44 PM, Seth Blank wrote: >> Sections 4.7 and 4.8 from my proposal (https://mailarchive.ietf.org/arch/= msg/dmarc/yl1HWdNbmQR1wHlCvG3eRl9ph5E) were not moved into the protocol elem= ents section of the latest draft (https://tools.ietf.org/html/draft-ietf-dma= rc-arc-protocol-10#section-4) >>=20 >> I spoke with Kurt, and this appears to have been an oversight. >>=20 >> To be clear about the protocol elements section, I've cribbed it from DKI= M and proposed it to: >> a) provide context for the entire ARC Chain >> b) define protocol components that are not specific to only sealing or va= lidating the chain >>=20 >> As such, I believe both the concept of chain validation status and the or= dering of hops belong in protocol elements. >=20 > +1. >=20 >> This also opens the question of where Section 8 (https://tools.ietf.org/h= tml/draft-ietf-dmarc-arc-protocol-10#section-8) belongs. This section now fe= els more like a kitchen sink and implementation guidance. >>=20 >> I would suggest: >>=20 >> 8.1 be stricken as it's a normative modification of DKIM, or replaced wit= h language to the effect of "ARC MUST be the last signer of the message; oth= erwise it cannot be validated on receipt." which can go in signer actions >>=20 >> 8.2 should be moved to protocol elements >>=20 >> 8.3 to signer actions >>=20 >> 8.4 to verifier actions >=20 > +1 to all of those. >=20 >> 8.5 should be stricken (this is bad advice that could result in backscatt= er, and I'm unsure where it came from, I can find no working group conversat= ion around this) >=20 > It is a reasonable choice, however. That is: If you're going to give an S= MTP reply, this is the right one to use, but maybe warn that backscatter (an= d provide or reference a definition of that term) can result. >=20 > -MSK >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc --Apple-Mail-813AAB74-E841-4D0E-AA9E-BE304B04BC89 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Dec 29, 2= 017, at 12:29 PM, Murray S. Kucherawy <superuser@gmail.com> wrote:

Chairs, should we start using the WG's issue tracke= r for this stuff?

Speaking as an o= bserver, I personally would find that helpful.


=
Thanks,
Stan

On T= hu, Dec 28, 2017 at 4:44 PM, Seth Blank <seth@sethblank.com> w= rote:
Sections 4.7 an= d 4.8 from my proposal (https://mailarchive.ietf.o= rg/arch/msg/dmarc/yl1HWdNbmQR1wHlCvG3eRl9ph5E) were not moved i= nto the protocol elements section of the latest draft (https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-10#s= ection-4)

I spoke with Kurt, and this appears t= o have been an oversight.

To be clear about the pro= tocol elements section, I've cribbed it from DKIM and proposed it to:
<= div>a) provide context for the entire ARC Chain
b) define prot= ocol components that are not specific to only sealing or validating the chai= n

As such, I believe both the concept of chain vali= dation status and the ordering of hops belong in protocol elements.

+1.

This also opens the question of where S= ection 8 (https://tools.ietf.org/html/draft-ie= tf-dmarc-arc-protocol-10#section-8) belongs. This section now feels= more like a kitchen sink and implementation guidance.

<= div>I would suggest:

8.1 be stricken as it's a norm= ative modification of DKIM, or replaced with language to the effect of "ARC M= UST be the last signer of the message; otherwise it cannot be validated on r= eceipt." which can go in signer actions

8.2 should be moved to proto= col elements

8.3 to signer actions

8.4 to verifier actions

=
+1 to all of those.

=
8.5 should be stricken (this is bad advice t= hat could result in backscatter, and I'm unsure where it came from, I can fi= nd no working group conversation around this)
<= br>
It is a reasonable choice, however.  That is: If you're g= oing to give an SMTP reply, this is the right one to use, but maybe warn tha= t backscatter (and provide or reference a definition of that term) can resul= t.

-MSK

____________________= ___________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mai= lman/listinfo/dmarc
= --Apple-Mail-813AAB74-E841-4D0E-AA9E-BE304B04BC89-- From nobody Tue Jan 2 09:13:04 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 BAAF4124E15 for ; Tue, 2 Jan 2018 09:13:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 z8uACOzbEO6J for ; Tue, 2 Jan 2018 09:13:00 -0800 (PST) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A8F8124207 for ; Tue, 2 Jan 2018 09:13:00 -0800 (PST) Received: by mail-lf0-x235.google.com with SMTP id g63so34271086lfl.11 for ; Tue, 02 Jan 2018 09:13:00 -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=+SwMEBv/mpR+IgL82EXBec6Hn0O2MpN0WQO/yRG7Qr8=; b=Q30BuyerWEPF3xWwuZ1kRdFFCr/16OrncQUTdkXedc413yaxv9zELPMIxhGxBUwhcx aSsulQ4HQgZPL9CT/JP4hf0RjLqLKOTys5aYBM1FVimZEMISMnfkhn+qDwSF69QMULwX KBzOdyqlmSgiDvVp20MQjRMAaumx7C28rXNkY= 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=+SwMEBv/mpR+IgL82EXBec6Hn0O2MpN0WQO/yRG7Qr8=; b=HhDYYnmw0kfRLWnnYg8KUS0oRR+REU7hEn69oxVmkv4lH5JnQX2+LrR+QmN4yzg3WV Bl7sM5xLyrjtxBDq35QBlr+AxKClIoSnDUbFjP28Ra24s/piM7SVX1+y9iQS3QywSgNH KmQPrB8oPOwlfn3defQvbkngSmz6U/uzi4fz5OQZuHcw9xfPdfXQS7aa04oDYj1Xgp4N rQbiD+69Axcc1rpEz3JlguglpOmoNRTnkdsgfrHAF55yT3WMs+XN7i1F3c4G4Zz6UoVB ZM3MosiAyQ8AXBMoJYuKo29MeELqBxo8YquqDmwkZvU2owgdCdG0n4N1jvtxOpzGzMb8 eQvg== X-Gm-Message-State: AKGB3mLkKb+PF/YkHSR5cjhyCMCUMu7SywcZKIvBQoxk3qApiMQtSKWL d96JK3gCqe9t+k0Uh34mC/7WI7ofxjBoh7c0sdPpD1b0 X-Google-Smtp-Source: ACJfBouwAFMF5SKZDREbXA4K91KDbvlVLXlySz1gjwRtxvH4gp0mLQV/urgFgPgS3O6luRpXRXMVmYC2x6VqZXWESn8= X-Received: by 10.46.22.15 with SMTP id w15mr6125387ljd.17.1514913178223; Tue, 02 Jan 2018 09:12:58 -0800 (PST) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.25.56.11 with HTTP; Tue, 2 Jan 2018 09:12:57 -0800 (PST) In-Reply-To: References: From: "Kurt Andersen (b)" Date: Tue, 2 Jan 2018 17:12:57 +0000 X-Google-Sender-Auth: 68kUAgVbXH_xgtL0Ors1PZsLhnk Message-ID: To: Seth Blank Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="f403045fc1b8da9d780561ce357f" Archived-At: Subject: Re: [dmarc-ietf] ARC spec clean up if 7601bis proceeds 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, 02 Jan 2018 17:13:03 -0000 --f403045fc1b8da9d780561ce357f Content-Type: text/plain; charset="UTF-8" On Fri, Dec 29, 2017 at 12:58 AM, Seth Blank wrote: > If 7601bis proceeds to allow content for filters in addition to humans, > then I believe the actions in the ARC draft (https://tools.ietf.org/html/ > draft-ietf-dmarc-arc-protocol-10) are as follows: > > Section 5.2 is cleaned up to inherit AAR ABNF from 7601bis. > Yes > Section 5.2.1 is stricken. > No - the instance variable is still germane. We may choose to move it elsewhere, but the info needs to stay. > New IANA registrations (I'm pretty certain this is wrong!): > authentication-results methods: dkim header.s > header.s is already defined in RFC6376 section 7.2 so I don't think that it needs further citation. > authentication-results methods: arc smtp.client-id > Should be smtp.client-ip no "id". > authentication-results methods: arc chain.closest-fail > See separate thread (Clarifying the value of arc.closest-fail) that I'm about to spin up. > authentication-results results: arc pass|fail|none|policy > Reading this, and initially conflating it with the cv values, I think that we should work on clarifying the wording to distinguish between the purely mechanical "did you check the ARC chain and, if so, is it valid?" vs the what did you do as a result of said information. Currently, this information is not called for in the A-R or AAR, just in the modified DMARC report to senders. Would we want to add it to the A-R/AAR as arc.effect? We could then have arc.cv for the mechanical result and arc.effect (none|pass|fail|other) for the policy-mediated impact on processing the message. > After this, I believe most of section 9 (except 9.3) can be stricken or > greatly reduced into verifier actions. > We can see. It may take a bit more work on the verifier section or better clarity/organization. --Kurt --f403045fc1b8da9d780561ce357f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Dec 29, 2017 at 12:58 AM, Seth Blank <seth@sethblank.com> wrote:
If 7601bis pro= ceeds to allow content for filters in addition to humans, then I believe th= e actions in the ARC draft (https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-10) are as follows:

=
Section 5.2 is cleaned up to inherit AAR ABNF from 7601bis.

Yes
=C2=A0
Section 5.2.1 is stricken.
<= /div>

No - the instance variable is still g= ermane. We may choose to move it elsewhere, but the info needs to stay.
=C2=A0
New IANA registrations (I'm pretty certain this is wrong!):
=
authentication-results methods: dkim header.s

header.s is already defined in RFC6376 section 7.= 2 so I don't think that it needs further citation.=C2=A0
=C2= =A0
authenticatio= n-results methods: arc smtp.client-id

Should be smtp.client-ip no "id".
=C2=A0
authentication-results m= ethods: arc chain.closest-fail

= See separate thread (Clarifying the value of arc.closest-fail) that I'm= about to spin up.
=C2=A0
authentication-results results: arc pass|fail|none|polic= y

Reading this, and initial= ly conflating it with the cv values, I think that we should work on clarify= ing the wording to distinguish between the purely mechanical "did you = check the ARC chain and, if so, is it valid?" vs the what did you do a= s a result of said information. Currently, this information is not called f= or in the A-R or AAR, just in the modified DMARC report to senders. Would w= e want to add it to the A-R/AAR as arc.effect? We could then have arc.cv for the mechanical result and arc.effect (non= e|pass|fail|other) for the policy-mediated impact on processing the message= .
=C2=A0
After this, I believe most of section 9 (except 9.3) can be st= ricken or greatly reduced into verifier actions.

We can see. It may take a bit more work on the verifier s= ection or better clarity/organization.=C2=A0

--Kur= t=C2=A0

--f403045fc1b8da9d780561ce357f-- From nobody Tue Jan 2 09:34:58 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 328A6126DEE for ; Tue, 2 Jan 2018 09:34:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 N8HNJtZPQyvW for ; Tue, 2 Jan 2018 09:34:55 -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 A0372124E15 for ; Tue, 2 Jan 2018 09:34:54 -0800 (PST) Received: by mail-lf0-x233.google.com with SMTP id h140so5568100lfg.1 for ; Tue, 02 Jan 2018 09:34:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:from:date:message-id:subject:to; bh=PkskD5Op+AjDKZErlw5JMHTNnfRSiYRLBFtm2TQqJrc=; b=ci27xjTvKN0wn+34D1L4l4jmKYCFikhWWlUKdDrayc7qKrdNF8zZgBiNjDkMK6ESRk mVXZp0ETufOB/Nc6OPYgj1mcAggGhYNbc1yP3H4KVAKociGYA0molVwqSjHrrBHyflMv +N2WrwKGVsp+omYVo1bNU9sn1g8EWZTelQrp8= 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:from:date:message-id:subject :to; bh=PkskD5Op+AjDKZErlw5JMHTNnfRSiYRLBFtm2TQqJrc=; b=cHO+Wb2Bl0aNMGoghloA0vE6OeVPYSHviPkyvDW84giyE053n20+Ksw6iw12Ss8/CL sZgws6cO57rzyp8jiFSQelvRjqV1B7Jycofr4EUHZwIYB0Uj/E6OtNpr1uvcG4JGYA++ NbTVOIWyv1hJaDXZGHdCCKapXuJABCmid38Xp4u1L1UDqRpBbj8IKP4I+i+jLKoTGFBX NUf3zcXJ7eiAJtTniwNXTLyHJ9GkcpgAlCeKfWZheXFvxbzVFLtVo6O+jOMzfBm2YWvK ozp0NvKeoBhcruOFqBvEq+nfVps3z15x10PL5BXbBvN3N2EG5AXctOSSTddckwhbo5ve Gx+A== X-Gm-Message-State: AKGB3mJJvSQsSQQJ8cbrveGVrHd3MGMvWnlA7T3sTM/gJ5LdW5SpKTtL Us7SIBGBMolALTGmJCbNwkRhXyo815uiIjeDB3aM8riwOBE= X-Google-Smtp-Source: ACJfBotiA9Bqfxn6JRhu2U3a5aQbUlkEg8FUFEW1CNT27Gepu83W/iMxCTjkepZ0mKyujlalXNYkr2jjcuxXsWiGLfw= X-Received: by 10.25.233.25 with SMTP id g25mr24730252lfh.101.1514914492357; Tue, 02 Jan 2018 09:34:52 -0800 (PST) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.25.56.11 with HTTP; Tue, 2 Jan 2018 09:34:51 -0800 (PST) From: "Kurt Andersen (b)" Date: Tue, 2 Jan 2018 17:34:51 +0000 X-Google-Sender-Auth: skfbrAcNipQu0xUlXaKY7CJ6WwA Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a113c3c542eb5f10561ce847d" Archived-At: Subject: [dmarc-ietf] Clarifying the value of arc.closest-fail 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, 02 Jan 2018 17:34:57 -0000 --001a113c3c542eb5f10561ce847d Content-Type: text/plain; charset="UTF-8" As I went through the edits for https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-10#section-5.2.1 I was unable to understand the value added by having the "arc.closest-fail" listed in the AAR. Looking back through the list archives, the idea for this pvalue seems to have come up in mid-August, captured in this snippet: On Wed, Sep 6, 2017 at 4:02 AM, Bron Gondwana wrote: > On Wed, 6 Sep 2017, at 07:52, Seth Blank wrote: > > On Mon, Aug 14, 2017 at 5:12 PM, Bron Gondwana > wrote: > > That seems like it would be enough to fix that objection. An additional > "first AMS failure" header at each hop would give you a list of who > actually modified the message. > > arc.closest_fail has been defined to accomplish this. > > That looks great. It adds enough information that my other questions are > basically efficiency concerns, which are not nothing, but at least ARC > signing doesn't make things worse... > It seems that Bron is advocating a change in the verify process where by all AMS signatures would have to be checked rather than just the most recent one. Going through the archives showed me that the language in 5.2.1 should say "...the most recent AMS that fails to validate..." rather than "...the most recent AS that fails to validate..." but then the verifier actions would also need to be updated in section 6 (steps 3+). If we are only concerned with changes in the body of the message which are being introduced by intermediaries, it seems like we could just check for changes in the bh value between hops rather than requiring each verifier to walk (possibly) the whole list of AMS headers. Does this provide enough "bang for the buck" to make it worthwhile? or should we cut out this field? --Kurt --001a113c3c542eb5f10561ce847d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As I went through the edits for=C2=A0https://t= ools.ietf.org/html/draft-ietf-dmarc-arc-protocol-10#section-5.2.1 I was= unable to understand the value added by having the "arc.closest-fail&= quot; listed in the AAR.

Looking back through the list a= rchives, the idea for this pvalue seems to have come up in mid-August, capt= ured in this snippet:

On Wed, Sep 6, 2017 at 4:02 = AM, Bron Gondwana=C2=A0<brong@fastmailteam.com>=C2=A0wr= ote:
On Wed, 6 Sep 2017, at 0= 7:52, Seth Blank wrote:
On Mon, Aug 14, 2017 at 5:12 PM, Bron Gondwana <brong@fastmailteam.com&g= t; wrote:
> That seems like it would be enough to fix that= objection.=C2=A0 An additional "first AMS failure" header at eac= h hop would give you a list of who actually modified the message.
=

arc.closest_fail has been defined to accomplish t= his.
That l= ooks great.=C2=A0 It adds enough information that my other questions are ba= sically efficiency concerns, which are not nothing, but at least ARC signin= g doesn't make things worse...

<= div>It seems that Bron is advocating a change in the verify process where b= y all AMS signatures would have to be checked rather than just the most rec= ent one. Going through the archives showed me that the language in 5.2.1 sh= ould say "...the most recent AMS that fails to validate..." rathe= r than "...the most recent AS that fails to validate..." but then= the verifier actions would also need to be updated in section 6 (steps 3+)= . If we are only concerned with changes in the body of the message which ar= e being introduced by intermediaries, it seems like we could just check for= changes in the bh value between hops rather than requiring each verifier t= o walk (possibly) the whole list of AMS headers.

=
Does this provide enough "bang for the buck" to make it wort= hwhile? or should we cut out this field?

--Kurt
--001a113c3c542eb5f10561ce847d-- From nobody Tue Jan 2 09:57:58 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 8B70C127863 for ; Tue, 2 Jan 2018 09:57:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 5XqjufksfY7B for ; Tue, 2 Jan 2018 09:57:53 -0800 (PST) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A000412D77B for ; Tue, 2 Jan 2018 09:57:52 -0800 (PST) Received: by mail-lf0-x22a.google.com with SMTP id o26so42231596lfc.10 for ; Tue, 02 Jan 2018 09:57:52 -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=Wc/TC6SVFNirrI7XrT/4BPGJD7T+ghEo6bUWnZosrOw=; b=ZMDkcF5gjGTUHh5NZpWsJyo/9V14kQat8ONO8FpZs8pZVQyBBPwxR02Bd2j0Cfrjxa c28ru8J3WWvlbihSssBLcY1ZUEchrbkelD5wlwe78lmOj/ztPABn/EhxZDkdD71if8vk FxGBPNaPL7CqzN9QNVHkWfsNLTbBXzKohimA8= 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=Wc/TC6SVFNirrI7XrT/4BPGJD7T+ghEo6bUWnZosrOw=; b=DeNkTDWwRRzDxow3NH8iwFl3l7PDoNc6tbPENnM9L1aW9SYBg67Nk5z4WPf7heOlto swH4CX06Ysg7S3skfZaWWlU/+aDMrT0qxe5tmPceEJDpPgy7LEbccO6WjH5Os1c+RNkO PHnciq7Mmu5eyHIrMvE8BLR7ZNES8d2H+y1N0RtUypWQlqlXIS5j+/eNU4PIAkaY8V4l bPRufNALsjwPbM9IitSbxi47XMdrxh9Bc+fYgDHEtmEL7myLFhPG78HZEkbX9n7AfIA3 iF4589Fn0cm2IHlsGbaUor6bWzZwQgAJN1I/a9g4TQupBH1mqwj05KK4NERTtDXxm7sD Ie8w== X-Gm-Message-State: AKGB3mLWHfHTc38S5SC7nVtQRfOQQJcLYp2x/7+1RvsvZHhzXNMtzGdT pjv1e5orCu7iyQyZge7b1xax1jbRtt7NQdAX2atWx7Rg+dQ= X-Google-Smtp-Source: ACJfBovJGWj/yI3dUbvvpuVJUnXMMIz1izBzWbWFDYzCBoK21tdrQJvXtwVFy16M8aBPimCi2/Wb+MQ02umD6/EYTVQ= X-Received: by 10.46.126.4 with SMTP id z4mr25294969ljc.146.1514915870701; Tue, 02 Jan 2018 09:57:50 -0800 (PST) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.25.56.11 with HTTP; Tue, 2 Jan 2018 09:57:49 -0800 (PST) In-Reply-To: References: From: "Kurt Andersen (b)" Date: Tue, 2 Jan 2018 17:57:49 +0000 X-Google-Sender-Auth: _dS-OyMqxFYOnf0kpsSN79_MSpU Message-ID: To: Seth Blank Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="089e0827ae605692bc0561ced694" Archived-At: Subject: Re: [dmarc-ietf] ARC draft questions (speak up!): Experimental Status and Considerations 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, 02 Jan 2018 17:57:56 -0000 --089e0827ae605692bc0561ced694 Content-Type: text/plain; charset="UTF-8" On Fri, Dec 29, 2017 at 12:15 AM, Seth Blank wrote: > I'm beginning a new thread to explicitly address some differences of > opinion in the working group. > > Coming out of IETF99 and surrounding working group conversations ( > https://mailarchive.ietf.org/arch/msg/dmarc/5_OP8lVi-a3yHMS0hqs1clyLWj4, > https://mailarchive.ietf.org/arch/msg/dmarc/4Gu1EErK4iuo9pQnZ-uJ2tKpMDQ, > https://mailarchive.ietf.org/arch/msg/dmarc/X-3nVPUQgIy-AGt4tJfkbPZZTjI), > I was under the impression that working group consensus was that ARC would > be submitted as an Experimental draft. > > I know Kurt has very strong opinions that we NOT proceed as Experimental, > and I wanted to make sure he got to state his case. > > 1) Unless a chair speaks up that consensus is already Experimental, we > should have the conversation now and nail this down. > Citing from https://datatracker.ietf.org/doc/minutes-99-dmarc/: Barry: When ready for WGLC? > Kurt: New draft tomorrow, hope to be ready for LC in a week. > 4a. Document status discussion > Dave Crocker: Suggest experimental for now because the operational issues > associated with the chain of signing aren't known. Revisit when ready for > a BCP. Kurt: Have enough implementations to make a proposed standard. Murray: If it's WGLC in a week, I'd prefer experimental. If we take more > time, then proposed standard. Decision: We will continue discussing on the list, and will not hold up > WGLC for this issue. We need to have a working group decision by the time > we request publication (after WGLC). It's quite clear that my assertion of being ready for LC before the end of July 2017 was a wild flight of fancy; but I'm glad to see that I didn't entirely invent the interpretation of continuing on a "proposed standard" path. While John Levine cited the benefits of the "experimental" approach taken for EAI ( https://mailarchive.ietf.org/arch/msg/dmarc/gvUecJuYLT9GIh5zbcZ_U9CgNkw), I'm also biased by the "let's all just play nice" mess that came from designating incompatible "versions" of SPF as competing experiments (see https://tools.ietf.org/html/rfc6686 for the eventual outcome of that six year long experiment). I think that any protocol which has not already been widely implemented is, in some sense, experimental - if you are looking at it from the perspective of hind-sight, you might have done some things differently/more efficiently/etc. One might not have called IPv6 "IP"-anything or may have chosen a longer address space for IPv4 for instance. I'm willing to go along with the consensus of the group, but wanted to (re)express my continued opposition to the experimental track for this. --Kurt --089e0827ae605692bc0561ced694 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Dec 29, 2017 at 12:15 AM, Seth Blank <seth@sethblank.com> wrote:
I'm beginning a new thread to explicitly address some differences = of opinion in the working group.

Coming out of IETF99 an= d surrounding working group conversations (https= ://mailarchive.ietf.org/arch/msg/dmarc/5_OP8lVi-a3yHMS0hqs1clyLWj= 4, https://mailarchive.ietf.org/arch/ms= g/dmarc/4Gu1EErK4iuo9pQnZ-uJ2tKpMDQ, ht= tps://mailarchive.ietf.org/arch/msg/dmarc/X-3nVPUQgIy-AGt4tJfkbPZ= ZTjI), I was under the impression that working group consensus was that= ARC would be submitted as an Experimental draft.

= I know Kurt has very strong opinions that we NOT proceed as Experimental, a= nd I wanted to make sure he got to state his case.

1) Unless a chair speaks up that consensus is already Experimental, we sho= uld have the conversation now and nail this down.

Citing from=C2=A0https://datatracker.ietf.= org/doc/minutes-99-dmarc/:

Barry: When ready for WGLC?=
Kurt: New draft tomorrow, hope to be ready for LC in a week.
=C2=A0 = 4a. Document status discussion
Dave Crocker: Suggest experimental for no= w because the operational issues associated with the chain of signing aren&= #39;t known.=C2=A0 Revisit when ready for a BCP.=C2=A0Kurt: Have enough implementations= to make a proposed standard.=C2=A0
Murray: If it's WGLC in a week, I'd prefer e= xperimental.=C2=A0 If we take more time, then proposed standard.=C2=A0

<more notes about the discussion omitted her= e>=C2=A0

Decision: We will continue discussing on the list, and will not hold= up WGLC for this issue. We need to have a working group decision by the ti= me we request publication (after WGLC).=C2=A0

It's quite clear that my assertion of being ready for LC before the = end of July 2017 was a wild flight of fancy; but I'm glad to see that I= didn't entirely invent the interpretation of continuing on a "pro= posed standard" path.=C2=A0=C2=A0

While John = Levine cited the benefits of the "experimental" approach taken fo= r EAI (https://mailarchive.ietf.org/arch/msg/dmarc/gvUecJuYLT9GIh5zbc= Z_U9CgNkw), I'm also biased by the "let's all just play ni= ce" mess that came from designating incompatible "versions" = of SPF as competing experiments (see https://tools.ietf.org/html/rfc6686 for the eventual = outcome of that six year long experiment).

I think that any protocol which has not already bee= n widely implemented is, in some sense, experimental - if you are looking a= t it from the perspective of hind-sight, you might have done some things di= fferently/more efficiently/etc. One might not have called IPv6 "IP&quo= t;-anything or may have chosen a longer address space for IPv4 for instance= .

I'm willing to= go along with the consensus of the group, but wanted to (re)express my con= tinued opposition to the experimental track for this.

--Kurt
--089e0827ae605692bc0561ced694-- From nobody Tue Jan 2 10:29:21 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 01A9412D7F1 for ; Tue, 2 Jan 2018 10:29:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 7i0H2k95Vi6y for ; Tue, 2 Jan 2018 10:29:18 -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 9C35D12D7EF for ; Tue, 2 Jan 2018 10:29:17 -0800 (PST) Received: by mail-lf0-x234.google.com with SMTP id h140so5716887lfg.1 for ; Tue, 02 Jan 2018 10:29:17 -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=JexQAUHe//7JD4zpuKj0h6HGwcKQKVyKiJiL2DXJN1s=; b=TdNy++AF80sseV2X33xJl4qv09xTlljCQewZYthSbLsND8qXyF1850KmPhTZ9tgkmv 5Jij+m9T1ArPEBGZBs83qvV6oGWUcLxduPKBGBNHxcy1WfhGSYD2SegjUed0lJFKJNWA IbCFKWlAB8xHERGz5eoLDleex2Z8s4SeH/iyo= 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=JexQAUHe//7JD4zpuKj0h6HGwcKQKVyKiJiL2DXJN1s=; b=ZlQgyRfCU7Bf3VwOr1gUkriJvidKVZ4aE96n6k+iorQPLNr/yrwfRBy2R0KIePcoXq jLrhmAufBje4ufAfMHJE/SfRtzl+N8/IHida9D1QZVmybF2cddqmy0mVc7rHZRnAkoSN KyQzTMAvnHv0ZBaR3BNGThROP/N+OKRr64rbTUSkeuOJyLctB/V+m4ASLYhhV6M8M/mY JNbWVMUDVSEIoEcqona8ZvT0oEV3vP/h27uCYUHbKLhbeAj+lZmoZgFO8sM2SBypsCFT wxapHQZuUHkQ4w8yqLrsNKZpIug3Bb45JlGpXb1EHOE+PnYeZIWGQtf57+wkHr0i2tme iLTQ== X-Gm-Message-State: AKGB3mKdzAcwYMpD6qVKpvD7HaaHYyc+RsJWeReQsh9voP0/0trpz/Ls WMIPx1fdEgkRhD0aDRwjxniY1aPHyFPkX2bfZ/RwSVB/ X-Google-Smtp-Source: ACJfBotbRjQbIBzQeGj5TTz5/v6c1HvW4lZHsw9p1OSuM8VthtaULtKZ1kXvfA4R21NDaoOPNY2PcnvWy/13hJjhSuI= X-Received: by 10.25.125.2 with SMTP id y2mr12580749lfc.54.1514917755515; Tue, 02 Jan 2018 10:29:15 -0800 (PST) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.25.56.11 with HTTP; Tue, 2 Jan 2018 10:29:14 -0800 (PST) In-Reply-To: References: From: "Kurt Andersen (b)" Date: Tue, 2 Jan 2018 18:29:14 +0000 X-Google-Sender-Auth: L4KnDFG9rrOoi6jE9_SdtCedjNU Message-ID: To: Seth Blank Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a114b007aae8d420561cf469c" Archived-At: Subject: Re: [dmarc-ietf] ARC draft: Call for ARC Implementations to be included 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, 02 Jan 2018 18:29:20 -0000 --001a114b007aae8d420561cf469c Content-Type: text/plain; charset="UTF-8" On Fri, Dec 29, 2017 at 1:23 AM, Seth Blank wrote: > The Implementation Status section of the draft ( > https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-10#section-14) > feels out of date. > Yes - I forgot to update that in the -10 version. I've added in information about MessageSystems Momentum, Oracle, MAIL::DKIM. I've also incorporated Murray's note and an update for OpenARC. I'll reach out to contacts at Cloudmark/Proofpoint to see what their status might be for the various MTA systems that they support. --Kurt --001a114b007aae8d420561cf469c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Dec 29, 2017 at 1:23 AM, Seth Blank <seth@sethblank.com> wrote:
The Implementat= ion Status section of the draft (https://tools.i= etf.org/html/draft-ietf-dmarc-arc-protocol-10#section-14) fee= ls out of date.

Yes - I forgot to upd= ate that in the -10 version. I've added in information about MessageSys= tems Momentum, Oracle, MAIL::DKIM. I've also incorporated Murray's = note and an update for OpenARC. I'll reach out to contacts at Cloudmark= /Proofpoint to see what their status might be for the various MTA systems t= hat they support.

--Kurt=C2=A0
--001a114b007aae8d420561cf469c-- From nobody Tue Jan 2 10:37: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 D157012D7FC for ; Tue, 2 Jan 2018 10:37:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 Qv8MM5_f8che for ; Tue, 2 Jan 2018 10:37:28 -0800 (PST) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3B0E12D7F8 for ; Tue, 2 Jan 2018 10:37:27 -0800 (PST) Received: by mail-lf0-x22d.google.com with SMTP id m20so43438264lfi.6 for ; Tue, 02 Jan 2018 10:37:27 -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=k2ZCSfblSR7h4OyhNVQSV3j05yNCQlxTi/e02NMNW7o=; b=bhx6WzRFEMkRcI8KOX+oLUhl0Nv1YzWR1bnO5StDeyAsqPCWF7HBZXpAR4R8lbprUN FrgMrmdDUhbqE0tjG+e2Dx8WAcGcx4X6AzjsPx6PSN1UhvPZRNFP2Mh2ccFnieD7VJy1 ougKzEv+P3ShhFRLxAhih+sYNFpWtuWwMKxG0= 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=k2ZCSfblSR7h4OyhNVQSV3j05yNCQlxTi/e02NMNW7o=; b=Q3j7sJaEotts72cZfcMPnez1QqlDh191EeuO/rvTG5VGDvHn6ck2Zr7KGD5hXn7QSm AJ6hnIxmmJHyk5Yx7bYq+QHqBCghiPBc2KqfIiBg7hIKETDZzGYkv2YKI2NK/XwBb83O uiESVPlTjiQtmUrzYM6CUHkJoO2ltZqoeCIyOM2LiBS0O1JBBKynnMtcIunrSRQkR7EQ Ka/uPG3pwnvN+Jv+e5+SZKEOUUWD6QTk/rDYkm+xPZXbv8MmA052r4wIHvxkuyDgF/em eQpvYlwzGatAti32lc4BnRZaYlh/2yPqeTgqvXqArGH5TEbMLEd/pC/UvrwKhgC+xveo uVIg== X-Gm-Message-State: AKGB3mLkgNlCZLA2Tc2iu+KrHxele1Ivo4sXMqykRLkKYo3K9VO4kpoC 5QeL1vfT9QzGoKlNdnJul4SsQqqRCMRzFR7Wl6cNCg== X-Google-Smtp-Source: ACJfBotBa2vPMXroQI0kjwQ+4KJ3qaNU/FehBfsj16StWT6iG07vv8BeyBHAmm2FgWpU7PW+B+wx4R1hevjpaue4kXA= X-Received: by 10.46.83.76 with SMTP id t12mr24473941ljd.45.1514918245888; Tue, 02 Jan 2018 10:37:25 -0800 (PST) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.25.56.11 with HTTP; Tue, 2 Jan 2018 10:37:24 -0800 (PST) In-Reply-To: References: <20171229035742.325D018916FA@ary.local> From: "Kurt Andersen (b)" Date: Tue, 2 Jan 2018 18:37:24 +0000 X-Google-Sender-Auth: xq_a4489x_kohULTM34qS0Dwkgc Message-ID: To: John R Levine Cc: "Murray S. Kucherawy" , "dmarc@ietf.org" , Seth Blank Content-Type: multipart/alternative; boundary="94eb2c1cf32ce91eba0561cf63ce" Archived-At: Subject: Re: [dmarc-ietf] ARC draft-10 Section 10 - Algorithm Rotation - can we address separately? 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, 02 Jan 2018 18:37:30 -0000 --94eb2c1cf32ce91eba0561cf63ce Content-Type: text/plain; charset="UTF-8" On Fri, Dec 29, 2017 at 6:36 PM, John R Levine wrote: > I still don't understand why we need to say more than DKIM did on this >> topic. > > > I don't think this will be super complicated, but I do think it would be a > mistake to try and publish now and then retrofit rather than adding it > before we publish. > I agree (which is why I started off with the first draft that is currently found in https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-10#section-10). The mechanics of one doc, two docs, three docs more (can you tell that I've been cleaning out Dr. Seuss from my bookshelves over the break?) is less important to me than having a workable strategy. Migrations are always the hardest part of an implementation. --Kurt --94eb2c1cf32ce91eba0561cf63ce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Dec 29, 2017 at 6:36 PM, John R Levine <johnl@taugh.com> w= rote:
I still don't understand why we need to say more than DKIM did on this<= br> topic.
I don't think this will be super complicated, but I do think it would b= e a mistake to try and publish now and then retrofit rather than adding it = before we publish.

I agree (which is wh= y I started off with the first draft that is currently found in ht= tps://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-10#section-10).= The mechanics of one doc, two docs, three docs more (can you tell that I&#= 39;ve been cleaning out Dr. Seuss from my bookshelves over the break?) is l= ess important to me than having a workable strategy. Migrations are always = the hardest part of an implementation.

--Kurt

--94eb2c1cf32ce91eba0561cf63ce-- From nobody Tue Jan 2 10:48:41 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 C679C12D7FB for ; Tue, 2 Jan 2018 10:48:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 uy5jfxPc3Muh for ; Tue, 2 Jan 2018 10:48:37 -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 647E712D7F8 for ; Tue, 2 Jan 2018 10:48:37 -0800 (PST) Received: by mail-lf0-x233.google.com with SMTP id j143so11342966lfg.0 for ; Tue, 02 Jan 2018 10:48:37 -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=hgdeAOYfEdvGyVodV7gIdOtxl/j5dCH59+rCNoCQJOI=; b=X3s33jtVLmLRCHlG6mUb7ofVRbFXrbZsLMogl1E7nUOjUJwNtw5zuX0bfl/CIt+D7w LKt1PLoY18f/gNF05+3ofTyaC0IIYSR7HHtWM3mIEyjnTIAe1fhZZmYjLFP/9lho/1tX ZkRUyAwxMlkfic5KnrSZ6MqRX59BYCOfHs1HU= 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=hgdeAOYfEdvGyVodV7gIdOtxl/j5dCH59+rCNoCQJOI=; b=ssqIa8JNE6NMnx2coumV1PC6f1ymj+xKjiNHzcIIHGczdq8aJo/2iSSM06WliH4BJl tfRjCgxuJn2BEjOhAwhJlUhIEEMdlGX9hXYKHe/mTh0tmq0+bS+2MSwv/8r1c4azObby tzrCpq1O8xfyzBu3A6fcZbSv68pARiEXiyruZ9O3vAUM/a/6VVJAtRTnDqQuiaeI6Vek IJBjNU3iCvh4h9PypfeZbxwguXZwgKPs0pLR4rYaGxEST43D9wDoCAybgnTi4rKKt3GW 0B4Wy6s/7h89Kbbue0EVRiT+wARGv8MgQaqK4XpHyMafvjOJE1TxVm5um4rVUG7jcDd2 l7Mg== X-Gm-Message-State: AKGB3mJ4qmNjn+TS0jlLa5c1abBt8s/9ke7nDX4iiv4KcDZATCNdcX7F x3VKPOThnlr6tPz7y7pyAyw3Sm9bwZh9mPpC+HtJh1ee X-Google-Smtp-Source: ACJfBotfLNjiBPsXgDF5sU7iPZR6N1m6eXur7e1KcrWBQhjgkXrZpVUz7KvYB/9aAWaSqcxYPZRvLoLXAjwrFZJEmEE= X-Received: by 10.46.22.15 with SMTP id w15mr6258018ljd.17.1514918915526; Tue, 02 Jan 2018 10:48:35 -0800 (PST) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.25.56.11 with HTTP; Tue, 2 Jan 2018 10:48:34 -0800 (PST) In-Reply-To: References: From: "Kurt Andersen (b)" Date: Tue, 2 Jan 2018 18:48:34 +0000 X-Google-Sender-Auth: fE8fId0rod-JnYO4u0HMna8-_a4 Message-ID: To: Seth Blank Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="f403045fc1b8d2e7090561cf8bae" Archived-At: Subject: Re: [dmarc-ietf] ARC draft-10 protocol elements section and question about reducing section 8 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, 02 Jan 2018 18:48:40 -0000 --f403045fc1b8d2e7090561cf8bae Content-Type: text/plain; charset="UTF-8" On Fri, Dec 29, 2017 at 12:44 AM, Seth Blank wrote: > Sections 4.7 and 4.8 from my proposal (https://mailarchive.ietf.org/ > arch/msg/dmarc/yl1HWdNbmQR1wHlCvG3eRl9ph5E) were not moved into the > protocol elements section of the latest draft ( > https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-10#section-4) > > This also opens the question of where Section 8 ( > https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-10#section-8) > belongs. This section now feels more like a kitchen sink and implementation > guidance. > Both section changes noted in my edits-in-progress for -11. --Kurt --f403045fc1b8d2e7090561cf8bae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Dec 29, 2017 at 12:44 AM, Seth Blank <seth@sethblank.com> wrote:
Sections = 4.7 and 4.8 from my proposal (https://mailarchiv= e.ietf.org/arch/msg/dmarc/yl1HWdNbmQR1wHlCvG3eRl9ph5E) were n= ot moved into the protocol elements section of the latest draft (https://tools.ietf.org/html/draft-ietf-dmarc-arc-proto= col-10#section-4)

This also opens the que= stion of where Section 8 (https://tools.ietf.org/= html/draft-ietf-dmarc-arc-protocol-10#section-8) belongs. Thi= s section now feels more like a kitchen sink and implementation guidance.

Both section changes noted in my= edits-in-progress for -11.

--Kurt=C2=A0
--f403045fc1b8d2e7090561cf8bae-- From nobody Tue Jan 2 11:13: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 63644126CF6 for ; Tue, 2 Jan 2018 11:13:52 -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=ktiE05hf; dkim=pass (1536-bit key) header.d=taugh.com header.b=XnBVYpx2 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 oI2gBuzDNaB8 for ; Tue, 2 Jan 2018 11:13:50 -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 B856B1200F3 for ; Tue, 2 Jan 2018 11:13:49 -0800 (PST) Received: (qmail 80469 invoked from network); 2 Jan 2018 19:13:48 -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=13a53.5a4bd9ec.k1801; bh=7vUj2QGcNbCM/HHszoYfBuT+jA9CfU/Ws0563I0eyzU=; b=ktiE05hf4CcgJB6M7C4C293IAFN6QuuQhrOZe+AtGMQobQYbUXFyuJtOFpd4+o13OELTg3CDmm/ic+sI8TtlHVGQ4ISWcfrlBOzcXVhoTuY3i+LRmKrxj4vPDhiwwUSn9gsKbduwQwS6co1Rj+8WFLG/hdokVm8F+kErXOcQhhoYQC9KBGgQkC2SV8BjqEm1sLw18TTTb7VJnd2WBc/SD9vb/41M/D1sCDpZGjILO+CSTjhNLManZI8QchBMP4gh 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=13a53.5a4bd9ec.k1801; bh=7vUj2QGcNbCM/HHszoYfBuT+jA9CfU/Ws0563I0eyzU=; b=XnBVYpx2Qd2lCNowLOI10Acx0r4znxf25NsSCDtW1Wf4fYGnoKM5yHwfpBELe9OOk1V8c4XT+DuBi3JTqdC034oHTZtxSvVVj5p5wZB4bIEUx/ulrLgq1kDZOGL8KW6e+YWl9CuiQHLF7ecB8MXe/JwHT6TPWLUd4P5hbQKeFKbTRlVe2Y2Sm9E3rauLGuzHPsFOjhdFa9I/QcFuaeN1pi5PFJxK/ENU6jeLF26C5uUpJpldsprGL2DqeobsNstF 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; 02 Jan 2018 19:13:48 -0000 Date: 2 Jan 2018 14:13:47 -0500 Message-ID: From: "John R Levine" To: "Kurt Andersen (b)" Cc: "dmarc@ietf.org" In-Reply-To: References: <20171229035742.325D018916FA@ary.local> 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] ARC draft-10 Section 10 - Algorithm Rotation - can we address separately? 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, 02 Jan 2018 19:13:52 -0000 On Tue, 2 Jan 2018, Kurt Andersen (b) wrote: >> I don't think this will be super complicated, but I do think it would be a >> mistake to try and publish now and then retrofit rather than adding it >> before we publish. > > I agree (which is why I started off with the first draft that is currently > found in https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-10#section-10). > The mechanics of one doc, two docs, three docs more (can you tell that I've > been cleaning out Dr. Seuss from my bookshelves over the break?) is less > important to me than having a workable strategy. Migrations are always the > hardest part of an implementation. Oh, good. For reasons outlined in previous messages, I'm pretty sure that without some changes to the current spec, the only way to do a migration will be to invent new headers (ARC-2-Seal: ARC-2-Message-Signature: ...) which would look awfully silly. R's, John From nobody Tue Jan 2 11:38:34 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 CC5E112D80E for ; Tue, 2 Jan 2018 11:38:32 -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 gEiqZHc2gizv for ; Tue, 2 Jan 2018 11:38:31 -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 D3CF1126CF6 for ; Tue, 2 Jan 2018 11:38:30 -0800 (PST) Received: (qmail 83488 invoked from network); 2 Jan 2018 19:38:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent; s=1461e.5a4bdfb5.k1801; bh=xFIw2U/GM0Vy+nVqoHWVBGKDjN+Q3DEmpe/ttkl9dk0=; b=qDxZbQl6NLNZjAqNpauEUTDoUREgIhGO2rVcULNH/IaYJ00f43gmvW3ghvy45H1ETtwC+Sjlya12o7kJS6kMw/UDFY1BzjSOp9YEc7Ldb0J3Wj0v9g0v/15GmI8FkzUtQiyK7Bhv/2595W3ukhupZwpiegYZYH223d3upAL0Tg7++/nBsGGA/rUhM8Nv3bgV8Jh/V1M4zk16dYw3ALRQviiEx2uXxwg0pRn1EZsUMhLAtYyLF8SnuMKw+l7Zo9Qq 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; 02 Jan 2018 19:38:29 -0000 Date: 2 Jan 2018 14:38:28 -0500 Message-ID: From: "John R. Levine" To: dmarc@ietf.org 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: [dmarc-ietf] Section 5.2.1, header.ds considered confusing 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, 02 Jan 2018 19:38:33 -0000 I don't see the point of the header.ds field. We already have header.d, so why not just add header.s? If there are two DKIM validations, the A-R header will look like this, no confusion I can see: Authentication-Results: example.com; ... dkim=pass header.d=foo.com header.s=abc; header.b="A9hX4wGQ"; dkim=none header.d=bar.com header.s=def; header.b="4icXsmdd"; ... Bonus question: so what would this mean? Authentication-Results: example.com; ... dkim=pass header.d=foo.com header.ds=bar.com,abc; header.b="A9hX4wGQ"; ... 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 Tue Jan 2 12:45:32 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 119461270AE for ; Tue, 2 Jan 2018 12:45:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 xM5YkMFNFe50 for ; Tue, 2 Jan 2018 12:45:29 -0800 (PST) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4106F12422F for ; Tue, 2 Jan 2018 12:45:29 -0800 (PST) Received: by mail-lf0-x230.google.com with SMTP id m20so43765089lfi.6 for ; Tue, 02 Jan 2018 12:45:29 -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=D4I4Uj12QQn+cTTc+AH+XJSrgyzQMgljXxP+XDrT2No=; b=CWYBhSqqtcV2MIKe1Iu4qcLxMBhLSZO02vhLUcG4Kv/HH8zKGPnj8y0dBR6lahzAmc HyFJn1+56IXtMtgYUsoE+rWD5mmf9GSZ2+NNsx/2RAE7TU2XFfaSdtjzzthuGoBlaaoh pQjpgXzjAIy5TF9YXfgB9HhWrz+BXLDYeQDPU= 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=D4I4Uj12QQn+cTTc+AH+XJSrgyzQMgljXxP+XDrT2No=; b=UMoJW4CXtpZLwPt6H5uoMgVqu3XP+/v+wKnbxeJ6KOby+Her9NP8OSosPyACvzu89r 7tH24DUDj6Pe1wIpf5z6d+f5XyEcbyxupnzy3Vo0qztWGdIfKGsvIdCSMCUeylIgSZxz 3Hvu41uSmjogQINelToAD0ny2y1Pe0on/n14heGrcSfnTPhOCxRr4Baa/ZFrDWohc40A 2PAD1N1o0+WyktkdgJzicHdZ6GJffK8B1nF3OxNml2vpiUf7MZgPT2LmanyEb7fbLMGf auXAsiU4ZgPDqhibQX1n1OTf++IL/VGYcupBCX02mssyjJs3NezWr7KT4w3VcFvhHXvv xk0g== X-Gm-Message-State: AKGB3mJMtqXzotR35fiMxiP9FsstyoUZwHr+rZTprWbYOmPyIBwE8bqS pUCi45y7/NPHa95TdZRhFuxAJT7uSrwm5ibwwfU0mg== X-Google-Smtp-Source: ACJfBovs7aqmkt7lZeDyS2KWFElXxWCs9Qe9PW4VUK7r53WdK7g/HLr6vqiVSbclRa3zySaEq3yrS54Mhs6HPduxriA= X-Received: by 10.25.149.5 with SMTP id x5mr6121812lfd.129.1514925927348; Tue, 02 Jan 2018 12:45:27 -0800 (PST) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.25.56.11 with HTTP; Tue, 2 Jan 2018 12:45:26 -0800 (PST) In-Reply-To: References: From: "Kurt Andersen (b)" Date: Tue, 2 Jan 2018 20:45:26 +0000 X-Google-Sender-Auth: FUcseJ2oa9lRHbDzN_bqW1HCJJQ Message-ID: To: "John R. Levine" Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a113fa536c2c60d0561d12d55" Archived-At: Subject: Re: [dmarc-ietf] Section 5.2.1, header.ds considered confusing 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, 02 Jan 2018 20:45:31 -0000 --001a113fa536c2c60d0561d12d55 Content-Type: text/plain; charset="UTF-8" On Tue, Jan 2, 2018 at 7:38 PM, John R. Levine wrote: > I don't see the point of the header.ds field. We already have header.d, > so why not just add header.s? > Yes, quite so. Please see my note from earlier this morning. header.s is already defined for 7601, we just need to indicate that it needs to be added into the A-R and AAR rather than leaving it to chance. --Kurt --001a113fa536c2c60d0561d12d55 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Jan 2, 2018 at 7:38 PM, John R. Levine <johnl@iecc.com> wro= te:
I don't see the point of the head= er.ds field.=C2=A0 We already have header.d, so why not just add header.s?<= br>

Yes, quite so. Please see my note from = earlier this morning. header.s is already defined for 7601, we just need to= indicate that it needs to be added into the A-R and AAR rather than leavin= g it to chance.

--Kurt

--001a113fa536c2c60d0561d12d55-- From nobody Tue Jan 2 13:45:09 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 AD3E212D82C for ; Tue, 2 Jan 2018 13:45:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4HeMHXfWT9m for ; Tue, 2 Jan 2018 13:45:05 -0800 (PST) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F437126CBF for ; Tue, 2 Jan 2018 13:45:05 -0800 (PST) Received: by mail-ua0-x22a.google.com with SMTP id n9so26985607ual.13 for ; Tue, 02 Jan 2018 13:45:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=zusXjZmHimkxagul1dlRCkKhQzSmR5PQtJZwDdJlSho=; b=EJ/GBXn5PliLnelVm+eSICuvc5OmdAcEcSNiV7HNLSOOpUizCju/cFUVzgSF6gqgt9 qOrKJ1F2K1+jViQFOYuoC535FtjqBdzn7ZSlkn/bn/4sRXucLm73VRHJTCxUXVzS1EFj jxNvTyeSF+2pIl/9AUoW9IF9y4ozqHFtCce3F1VYrHyweI3VUklXR6jHpi/IQaXsDfzk cQc6pkNMez+zZoZLzyB4OZzspOPLeBYt17p6x2nL1AvYGeMZT32ExRS2mdLFGCSnvQy9 buyfvHlt93J++na+Tw8Xt/fyohWy4RUsaIjQrUiolSOUVDBiAPSa+kzAD9ZSU+zq/eUY GwLg== 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=zusXjZmHimkxagul1dlRCkKhQzSmR5PQtJZwDdJlSho=; b=aNHFYaRCY3iF+81BSuhqaJb8KM1Bjkw2oXcP+fPodL/Vp5bexxj8F6hRC08MU7TIf6 5Ql8g6lg+JBA8WyLqtteAYewLOVPTKmrVl1ow4ywlqChWYYQ3fQYv5E/PeC2BfZz0bIy K1dP1yIVE/nw+JPdpI9uvq8a11Yl6ShBRhFZBYRxGyhcY/YyjThDxkiZmRyKyiZDzuiR z+hDy1TSHZrRv7hQSySJCKLVjBYB/vaM+lc05Oo/83QtVy4lUeqs87VpjUV6dYuemjSS Ga60fr6uaEWqmjmEXbs9QHbHCXKoemQnbHm9zOQE/PjulIJ7EHd/LCO4t0hfyEpKYOyU kQvg== X-Gm-Message-State: AKGB3mILDAav/EXg5+vI5GAfGGz0ciAAtxbHHFjUvoXocjkbpGuwgBAV mWtHX4KUbXd9epDJP5L8zPUns9AvbIzfA2S8CU8YIwAr X-Google-Smtp-Source: ACJfBouylUVjSVLQpetS0hN0v/AqJ83KdgOxBPCMDCHNIKmbZCXXJ2s8M96DAqM1XhxMoT8bLvZklmTZdRpX+M2STSY= X-Received: by 10.176.0.15 with SMTP id 15mr3019439uai.132.1514929503990; Tue, 02 Jan 2018 13:45:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.33.165 with HTTP; Tue, 2 Jan 2018 13:44:43 -0800 (PST) In-Reply-To: References: From: Seth Blank Date: Tue, 2 Jan 2018 13:44:43 -0800 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a11c166aaf210040561d2022a" Archived-At: Subject: Re: [dmarc-ietf] Section 5.2.1, header.ds considered confusing 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, 02 Jan 2018 21:45:08 -0000 --001a11c166aaf210040561d2022a Content-Type: text/plain; charset="UTF-8" On Tue, Jan 2, 2018 at 12:45 PM, Kurt Andersen (b) wrote: > On Tue, Jan 2, 2018 at 7:38 PM, John R. Levine wrote: > >> I don't see the point of the header.ds field. We already have header.d, >> so why not just add header.s? >> > > Yes, quite so. Please see my note from earlier this morning. header.s is > already defined for 7601, we just need to indicate that it needs to be > added into the A-R and AAR rather than leaving it to chance. > header.s is NOT defined: https://www.iana.org/assignments/email-auth/email- auth.xhtml That's why I explicitly mentioned in the earlier thread about IANA registrations (https://mailarchive.ietf.org/arch/msg/dmarc/72GKJ1mMd6Pc5_ DWYGgnLE-Uzxw) that we'd need to add it after 7602bis. To John's point, this is why I've been pushing hard for 7601bis, adding header.s to DKIM is far cleaner than trying to do header.ds in arc directly. This is why I asked question #2 in this thread: https://mailarchive.ietf.org/arch/msg/dmarc/xUUbT15vqoBmH7RraJ_pesrd9z0 Seth --001a11c166aaf210040561d2022a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Jan 2, 2018 at 12:45 PM, Kurt Andersen (b) <kboth@drkurt.com> wrote:
On Tue, Jan 2, 2018 at 7:38 PM, John R. Le= vine <johnl@iecc.com> wrote:
I don't see the point of the header.ds field.=C2=A0 = We already have header.d, so why not just add header.s?

Yes, quite so. Please see my note from earlier this= morning. header.s is already defined for 7601, we just need to indicate th= at it needs to be added into the A-R and AAR rather than leaving it to chan= ce.


That's why I ex= plicitly mentioned in the earlier thread about IANA registrations (https://mailarchive.ietf.org/arch/msg/dmarc/72GKJ1= mMd6Pc5_DWYGgnLE-Uzxw)=C2=A0that we'd need to add it after 760= 2bis.

To John's point, this is why I've be= en pushing hard for 7601bis, adding header.s to DKIM is far cleaner than tr= ying to do header.ds in arc directly. This is why I asked question #2 in th= is thread:=C2=A0https://mailarchive.ietf.or= g/arch/msg/dmarc/xUUbT15vqoBmH7RraJ_pesrd9z0

<= div>Seth --001a11c166aaf210040561d2022a-- From nobody Tue Jan 2 15:23:19 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 D92D01242F5 for ; Tue, 2 Jan 2018 15:23:17 -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 4kS1mp32dnRW for ; Tue, 2 Jan 2018 15:23:15 -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 0CB121200F3 for ; Tue, 2 Jan 2018 15:23:15 -0800 (PST) Received: by mail-lf0-x231.google.com with SMTP id h140so14308lfg.1 for ; Tue, 02 Jan 2018 15:23:14 -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=gGQi3et/lNAPsM5DGcsk64nwMNJa9Lke2/gTbzi2y50=; b=ZTqnDRYj31DwCwrXHYl8yh1N6oA2jQTuTDtMry+DhX5H2+ltbKXLIA3WZpx5sN9HiW hPZcEWrwKElYcw3Uo4vqjPfy/Ui4qVBbDeQhOg1/xcabB6mZoJXLKjbFhl7z1sAjn7vm RbrQdGzeBAQh4otdQsicbjZ434eJV38PJu/0E= 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=gGQi3et/lNAPsM5DGcsk64nwMNJa9Lke2/gTbzi2y50=; b=iftzOuoEbWFAj3hMotKQJd1bZ8mYPSXR/tO8TdzmeGJnEPmEtNL0RR+msC/eO2gZ81 51BHs86TPpMD0cB0edskVM/AbC2/jYyJ3RM+QPH+DpXhKFOsOLQ9uXhosmc0nFEzTZ+X MwQ7WBti3G90X0hEOLFMM3orKQ+AIzG2WnTgd6V4e/D2Zo151jOpV/WufWqeEaVyWX7v 6KlppF/9fovdYo0wtlD5mRiTj2EwOmt8ttCnbOlgo6Wr8qHLMuCEr+8HF4QO9zVOb43V CyPWuK4RtH01p/iqbvQ4mY7bVIoHcfJTbwC2tD5/PfrCetdFNcOtHxPWjksCg2BS2feQ zbJA== X-Gm-Message-State: AKGB3mKrd+v4w7kUzdoGYg5jk4Ufy/RzGdPIzCsLg3tC8fHhBX4j3ASE TWz88KLX++LFBkd+/+s3das9bB/8/rPIRDGNRtLvM0Ce4fc= X-Google-Smtp-Source: ACJfBot+PgwjxcOw352E/Me7c7qgGsVjTmfvXcEkEXJIMTsxfEudKRxq6XERnmHFEvLz+BKh9G+tltUyACASrGNb3TA= X-Received: by 10.25.208.82 with SMTP id h79mr7095224lfg.65.1514935393006; Tue, 02 Jan 2018 15:23:13 -0800 (PST) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.25.56.11 with HTTP; Tue, 2 Jan 2018 15:23:12 -0800 (PST) In-Reply-To: References: From: "Kurt Andersen (b)" Date: Tue, 2 Jan 2018 23:23:12 +0000 X-Google-Sender-Auth: eqdQVf1zatjbne3d25qrJdzW0sg Message-ID: To: Seth Blank Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a11412b98f54d6c0561d3615c" Archived-At: Subject: Re: [dmarc-ietf] Section 5.2.1, header.ds considered confusing 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, 02 Jan 2018 23:23:18 -0000 --001a11412b98f54d6c0561d3615c Content-Type: text/plain; charset="UTF-8" On Tue, Jan 2, 2018 at 9:44 PM, Seth Blank wrote: > On Tue, Jan 2, 2018 at 12:45 PM, Kurt Andersen (b) > wrote: > >> On Tue, Jan 2, 2018 at 7:38 PM, John R. Levine wrote: >> >>> I don't see the point of the header.ds field. We already have header.d, >>> so why not just add header.s? >>> >> >> Yes, quite so. Please see my note from earlier this morning. header.s is >> already defined for 7601, we just need to indicate that it needs to be >> added into the A-R and AAR rather than leaving it to chance. >> > > header.s is NOT defined: https://www.iana.org/ > assignments/email-auth/email-auth.xhtml > > That's why I explicitly mentioned in the earlier thread about IANA > registrations (https://mailarchive.ietf.org/arch/msg/dmarc/72GKJ1mMd6Pc5_D > WYGgnLE-Uzxw) that we'd need to add it after 7601bis. > > To John's point, this is why I've been pushing hard for 7601bis, adding > header.s to DKIM is far cleaner than trying to do header.ds in arc > directly. This is why I asked question #2 in this thread: > https://mailarchive.ietf.org/arch/msg/dmarc/xUUbT15vqoBmH7RraJ_pesrd9z0 > I'm just not getting (from reading the text of 7601 several times today) how including an extra ptype makes a "normative redefinition" of 7601. RFC7001 clearly says that additional ptypes are expected over time. If anything, we're considering a "normative redefinition" of 6008 which talks about listing info for more than one DKIM header, but I think the term is a misnomer. It appears to me that the "7601 replaces all former definitions" work was just incompletely implemented by IANA. We can certainly patch over those gaps as we care about the data for ARC within our spec, but it seems like having an IANA errata for 7601 would be a cleaner and more apropos vehicle. --Kurt --001a11412b98f54d6c0561d3615c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Jan 2, 2018 at 9:44 PM, Seth Blank <seth@sethblank.com>= wrote:
On Tue, Jan 2, 2018 = at 12:45 PM, Kurt Andersen (b) <kboth@drkurt.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
On Tue, Jan 2, 2018 at 7:38 PM, John R.= Levine <johnl@iecc.com> wrote:
I don't see the point of the header.ds field.=C2= =A0 We already have header.d, so why not just add header.s?

Yes, quite so. Please see my note from earlier = this morning. header.s is already defined for 7601, we just need to indicat= e that it needs to be added into the A-R and AAR rather than leaving it to = chance.


That'= ;s why I explicitly mentioned in the earlier thread about IANA registration= s (https://mailarchive.ietf.org/arch/msg/dm= arc/72GKJ1mMd6Pc5_DWYGgnLE-Uzxw)=C2=A0that we'd need to add it= after 7601bis.

To John's point, this is why I= 've been pushing hard for 7601bis, adding header.s to DKIM is far clean= er than trying to do header.ds in arc directly. This is why I asked questio= n #2 in this thread:=C2=A0https://mailarchive.ie= tf.org/arch/msg/dmarc/xUUbT15vqoBmH7RraJ_pesrd9z0

I'm just not getting (from reading the text of 7= 601 several times today) how including an extra ptype makes a "normati= ve redefinition" of 7601. RFC7001 clearly says that additional ptypes = are expected over time. If anything, we're considering a "normativ= e redefinition" of 6008 which talks about listing info for more than o= ne DKIM header, but I think the term is a misnomer.

It appears to me that the &qu= ot;7601 replaces all former definitions" work was just incompletely im= plemented by IANA. We can certainly patch over those gaps as we care about = the data for ARC within our spec, but it seems like having an IANA errata f= or 7601 would be a cleaner and more apropos vehicle.

--Kurt
--001a11412b98f54d6c0561d3615c-- From nobody Tue Jan 2 16:40:00 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 9CCCE127137 for ; Tue, 2 Jan 2018 16:39:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 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, 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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=bXPqnL8P; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=J2b6DjBx 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 Bls4-V110Dox for ; Tue, 2 Jan 2018 16:39:57 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCCA8120721 for ; Tue, 2 Jan 2018 16:39:56 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 31ED120C4D for ; Tue, 2 Jan 2018 19:39:56 -0500 (EST) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Tue, 02 Jan 2018 19:39:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=qVICoswu8SSHLA6oR z5Bn8Bocy2+8B/E+F2DmicPZFQ=; b=bXPqnL8P2qzr9QATDYkuCyyGvMUaajg3i iniAOgKjjtuvrQbcW3Luj+CkCre++IY1fR8L9yTMJS+K4XSK9chs3ms3z1lZo7NP MW+RbVvO/MlKn27ISkiBk+0+NVQU3GEkq7PBuFnhGIQOZ63+KjQjLBiSdHnF5u7E Zsnf6It/kYdtRKI6iYOMqH+qgxi6Iwvd/1CG6E0nqVKqQdxeGhfDYGXmomik93i3 V1UKUq1WHWPr5MnOB/UTbjW28yOgVxZknvdVWPQRHX0NAvDTNw9XX8Ruc/w3JkCw qhkK4Xbwl5L2jFvu/retG9NQxFEYZLMHF3E4wHQVehiCpbf8s4bEQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=qVICos wu8SSHLA6oRz5Bn8Bocy2+8B/E+F2DmicPZFQ=; b=J2b6DjBxRvxRZU6XrovJLO bHDD5OP9YMZ7uHhb4hNL+tOryv0pnkCfRyaO185hOP5dvo4FhRh9xlNYQZL3P6sS 1XjFzCIN3UhHKg1DPyPL8H4j22U65Oh1JH2PG5tFLodDHtDA2C2ZeluE3c/hPBWw RorcqbDZnRAScmOc6lRhKNk8mGHonZwCEqraYgJl8i+fL+4FGH2BpdV5m44fKVsv Dmh7Cz2zTOLJ55kgGrEOLoxyvIVvr6zvkWqZTvfN+q71oI5EdILRm+zY3JmfI1x1 2jt/O5GmKIkGrJIHJSV9taOc9+2kMfeuAL4DkLdIW/ujF42h/z+BS02rA+/wPN4g == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 097E39E240; Tue, 2 Jan 2018 19:39:55 -0500 (EST) Message-Id: <1514939995.3318165.1222346488.5B169072@webmail.messagingengine.com> From: Bron Gondwana To: dmarc@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_151493999533181650" X-Mailer: MessagingEngine.com Webmail Interface - ajax-cc9a457c Date: Wed, 03 Jan 2018 11:39:55 +1100 In-Reply-To: References: Archived-At: Subject: Re: [dmarc-ietf] Clarifying the value of arc.closest-fail 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: Wed, 03 Jan 2018 00:40:00 -0000 This is a multi-part message in MIME format. --_----------=_151493999533181650 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Wed, 3 Jan 2018, at 04:34, Kurt Andersen (b) wrote: > As I went through the edits for > https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-10#section-5.2.1 > I was unable to understand the value added by having the "arc.closest- > fail" listed in the AAR. Please read my examples again if the problem wasn't clear, because you don't get security by imagining the best cases where everyone behaves themselves, you get security by imagining that everybody is trying to get away with the worst abuses they can without being detected. Without a closest-fail from each step, or a similar way to determine changes, information about abuses gets lost along the chain, and the final receiver can't tell who modified the message along the way. > Looking back through the list archives, the idea for this pvalue seems > to have come up in mid-August, captured in this snippet:> > On Wed, Sep 6, 2017 at 4:02 AM, Bron Gondwana > wrote:>> __ >> >> On Wed, 6 Sep 2017, at 07:52, Seth Blank wrote: >>> On Mon, Aug 14, 2017 at 5:12 PM, Bron Gondwana >>> wrote:>>> > That seems like it would be enough to fix that objection. An >>> > additional "first AMS failure" header at each hop would give you a >>> > list of who actually modified the message.>>> >>> arc.closest_fail has been defined to accomplish this. >> >> That looks great. It adds enough information that my other questions >> are basically efficiency concerns, which are not nothing, but at >> least ARC signing doesn't make things worse...> > It seems that Bron is advocating a change in the verify process where > by all AMS signatures would have to be checked rather than just the > most recent one. Going through the archives showed me that the > language in 5.2.1 should say "...the most recent AMS that fails to > validate..." rather than "...the most recent AS that fails to > validate..." but then the verifier actions would also need to be > updated in section 6 (steps 3+). Yes, it should say most recent AMS, not AS. All AS should always validate. > If we are only concerned with changes in the body of the message > which are being introduced by intermediaries, it seems like we could > just check for changes in the bh value between hops rather than > requiring each verifier to walk (possibly) the whole list of AMS > headers. No, that's bogus. The message is not the body, the message is body+subject+from+to. In particular, a bad actor intermediate could totally change the meaning of a message by changing the subject. Messages where the majority of meaning is in the subject definitely exist. Subject: Please clean out your stuff from the fridge Body: Thanks, Bron. vs Subject: URGENT: your need to paypal $5000 to foo@bar.com TODAY or we will lose $IMPORTANT_CONTRACT Body: Thanks, Bron. Both have the same bh=, but they're very different messages. > Does this provide enough "bang for the buck" to make it worthwhile? or > should we cut out this field? If we cut the field, then ARC usage guidelines need to say "don't seal if you didn't change the message" or we're breaking the value of the chain. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_151493999533181650 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Wed, 3 Jan 2018, at 04:34, Kurt Andersen (b) wrote:
As I went through the edits for https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-10#section-5.2.1 I was unable to understand the value added by having the "arc.closest-fail" listed in the AAR.

Please read my examples again if the problem wasn't clear, because you don't get security by imagining the best cases where everyone behaves themselves, you get security by imagining that everybody is trying to get away with the worst abuses they can without being detected.

Without a closest-fail from each step, or a similar way to determine changes, information about abuses gets lost along the chain, and the final receiver can't tell who modified the message along the way.

Looking back through the list archives, the idea for this pvalue seems to have come up in mid-August, captured in this snippet:

On Wed, Sep 6, 2017 at 4:02 AM, Bron Gondwana <brong@fastmailteam.com> wrote:


On Wed, 6 Sep 2017, at 07:52, Seth Blank wrote:
On Mon, Aug 14, 2017 at 5:12 PM, Bron Gondwana <brong@fastmailteam.com> wrote:
> That seems like it would be enough to fix that objection.  An additional "first AMS failure" header at each hop would give you a list of who actually modified the message.

arc.closest_fail has been defined to accomplish this.

That looks great.  It adds enough information that my other questions are basically efficiency concerns, which are not nothing, but at least ARC signing doesn't make things worse...

It seems that Bron is advocating a change in the verify process where by all AMS signatures would have to be checked rather than just the most recent one. Going through the archives showed me that the language in 5.2.1 should say "...the most recent AMS that fails to validate..." rather than "...the most recent AS that fails to validate..." but then the verifier actions would also need to be updated in section 6 (steps 3+).

Yes, it should say most recent AMS, not AS.  All AS should always validate.

If we are only concerned with changes in the body of the message which are being introduced by intermediaries, it seems like we could just check for changes in the bh value between hops rather than requiring each verifier to walk (possibly) the whole list of AMS headers.

No, that's bogus.  The message is not the body, the message is body+subject+from+to.  In particular, a bad actor intermediate could totally change the meaning of a message by changing the subject.  Messages where the majority of meaning is in the subject definitely exist.

Subject: Please clean out your stuff from the fridge

Body:
Thanks,
Bron.

vs

Subject: URGENT: your need to paypal $5000 to foo@bar.com TODAY or we will lose $IMPORTANT_CONTRACT

Body:
Thanks,
Bron.

Both have the same bh=, but they're very different messages.

Does this provide enough "bang for the buck" to make it worthwhile? or should we cut out this field?

If we cut the field, then ARC usage guidelines need to say "don't seal if you didn't change the message" or we're breaking the value of the chain.

Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


--_----------=_151493999533181650-- From nobody Tue Jan 2 17:04: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 737A7127136 for ; Tue, 2 Jan 2018 17:04:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.76 X-Spam-Level: X-Spam-Status: No, score=-1.76 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.25, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=oBjMlZP+; dkim=pass (1536-bit key) header.d=taugh.com header.b=nMecptEw 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 E-hml22XeePz for ; Tue, 2 Jan 2018 17:04:02 -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 E9E8C1200F3 for ; Tue, 2 Jan 2018 17:04:01 -0800 (PST) Received: (qmail 35771 invoked from network); 3 Jan 2018 01:04:00 -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=8bb9.5a4c2c00.k1801; bh=EnO+IN5XdD+IoiDhk6B2XeXeR9XzGK0gogIDtlW0uN8=; b=oBjMlZP+vrJuEJmCHuh9I5cbfUDY7CLRp8kgcCu18emQvllyaNqUt3kQsUfx0YBeh0wB788Ytv3RLnZNIJU2ceWYiZACSxp/tC/mHqf6PLQDGXQAl2TsebzfN8cPxkiZnyRCyqwfQKZ7DoUrULw83X2U0R/wqHi4Piz7YSs9V/70x1vwCFkMgxs5/zzhIkWLUvZtsIEhZp/PtvtLmIHGG0LEysscpaMGFTbTxlKoN28MCMjTulMV097jkdb0pI6z 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=8bb9.5a4c2c00.k1801; bh=EnO+IN5XdD+IoiDhk6B2XeXeR9XzGK0gogIDtlW0uN8=; b=nMecptEwzp6cfLyQxXSr/9b6nWe0lOlqEH+GYu+Ds8xpTBE9ISSIxyfrHPo9gn0UVvA4n6XvwW2/YQjCS1fssu2ieWa82DKc67NTYgY3ig8naQ/m6AsJXj0BafjTQ5hn7yGlLHWvwmZFsRKTDwR/orflfKLMIIHJMi/rYWAeR+hlP3PJYdcadFE6IC/+X1xPWSXIizqbOPfaeKBNicGe9/CPYMmf2rPHTEq3l5fCNhHd/gGFFELknjtJlnnO81Tf 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; 03 Jan 2018 01:04:00 -0000 Received: by ary.qy (Postfix, from userid 501) id 5FC2918C0F85; Tue, 2 Jan 2018 20:03:59 -0500 (EST) Date: 2 Jan 2018 20:03:59 -0500 Message-Id: <20180103010400.5FC2918C0F85@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: seth@sethblank.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] Section 5.2.1, header.ds considered confusing 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: Wed, 03 Jan 2018 01:04:03 -0000 In article you write: >header.s is NOT defined: https://www.iana.org/assignments/email-auth/email- >auth.xhtml Quite right, need to put it in the IANA considerations of something. FWIW, I added header.s to my SMTP daemon this afternoon. It took about 10 minuutes. I'm a pretty good programmer, but I'm not *that* good. R's, John From nobody Tue Jan 2 17:56: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 354ED1271DF for ; Tue, 2 Jan 2018 17:56:58 -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 Kf-f3k5weOAd for ; Tue, 2 Jan 2018 17:56:56 -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 275C9127136 for ; Tue, 2 Jan 2018 17:56:56 -0800 (PST) Received: by mail-lf0-x233.google.com with SMTP id a12so228074lfe.13 for ; Tue, 02 Jan 2018 17:56:55 -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=i2kogtzEI6dpk/eeNT6BsgIIhnIgTPEwj/IWyWKShOk=; b=A+5UNNvGqj24ZAF8+KEETjc9nx+8JpZjdw7UzQGguTlmDx88n4inth4u+zTXT7Kj0O 6i+GtxGJYEE8aofRDk2mf1qtviavnp97cgIhjgsiiZShm0yLpQY1uglZwvgqj8MIOzAK F0HSN38+FQsOoFo89yOZCd2GRMBcjoF3IbLZc= 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=i2kogtzEI6dpk/eeNT6BsgIIhnIgTPEwj/IWyWKShOk=; b=dwHBpXHC0SWmfN6dEjblWwmnSRZyoRmhuCxQ/jPzvFAFJa9Di4oc55EwLGnWf1i0mV hN5TcvjfyBUoewgdTvCW7HJ3OQwqMHWtHX7Yurw+JIpol6hFg6hBIiIMgvZd6n2crgRn qzkpQ8IMH9OVoeBu2HduH1f9isirVbYpRjSThqTFcRt+/cIwS1VPY9vXYYmnWQvQv6VZ GIFVMESz6ZSqNDRiN71hlYnlvIT89LIsyn3wDq8vhjbolXIFpybqzwIhY2F++TiD7tmr P5V+iHoSt4glSTsaoU4puySjeg9bZxEsjBI8sXuMA5CS2Zf/t/ai0cDnrecD46PlgpBw 970Q== X-Gm-Message-State: AKGB3mJZgYCMgRCbDyQvSYWtxz80r53u8CYx06S1XaAk4/+nPBuiqmuS I2go2VXwIYx6YHZP1SoskphTaFrAAekvjyebQYiRFUdkYlg= X-Google-Smtp-Source: ACJfBotrzZVSvXYw21IMJps7XENsK9aa6ybdasDKUS87PEZDfptBwF8ak2eNIDIXXD+a6tmCLbyz25jUPEeDQ3i+iM0= X-Received: by 10.25.208.82 with SMTP id h79mr7239896lfg.65.1514944614232; Tue, 02 Jan 2018 17:56:54 -0800 (PST) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.25.56.11 with HTTP; Tue, 2 Jan 2018 17:56:53 -0800 (PST) In-Reply-To: <1514939995.3318165.1222346488.5B169072@webmail.messagingengine.com> References: <1514939995.3318165.1222346488.5B169072@webmail.messagingengine.com> From: "Kurt Andersen (b)" Date: Wed, 3 Jan 2018 01:56:53 +0000 X-Google-Sender-Auth: MLsNA9S6nz6wkxaFqW5wIF_xRiY Message-ID: To: Bron Gondwana Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a11412b98960e470561d587aa" Archived-At: Subject: Re: [dmarc-ietf] Clarifying the value of arc.closest-fail 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: Wed, 03 Jan 2018 01:56:58 -0000 --001a11412b98960e470561d587aa Content-Type: text/plain; charset="UTF-8" On Wed, Jan 3, 2018 at 12:39 AM, Bron Gondwana wrote: > On Wed, 3 Jan 2018, at 04:34, Kurt Andersen (b) wrote: > > As I went through the edits for https://tools.ietf.org/htm > l/draft-ietf-dmarc-arc-protocol-10#section-5.2.1 I was unable to > understand the value added by having the "arc.closest-fail" listed in the > AAR. > > Without a closest-fail from each step, or a similar way to determine > changes, information about abuses gets lost along the chain, and the final > receiver can't tell who modified the message along the way. > So, if we have a message that goes through four mailing lists before final delivery, each of which modify the subject and everyone is "doing the right thing" (I know that's not exactly an abuse scenario), we would expect: * ARC 1: cv=none, closest-fail=0 * ARC 2: cv=pass, closest-fail=0 * ARC 3: cv=pass, closest-fail=1 * ARC 4: cv=pass, closest-fail=2 * final recipient ADMD ARC verifier would find cv=pass and evaluate closest-fail at 3 Is that what you have in mind? --Kurt --001a11412b98960e470561d587aa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Jan 3, 2018 at 12:39 AM, Bron Gondwana <brong@fastmailteam.com> wrote:
On Wed, 3 Jan 2018, at 04:34, K= urt Andersen (b) wrote:
As I went through the edits for=C2=A0https:/= /tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-10#section-5.2= .1 I was unable to understand the value added by having the "arc.c= losest-fail" listed in the AAR.
Without a closest-fail from each step, or = a similar way to determine changes, information about abuses gets lost alon= g the chain, and the final receiver can't tell who modified the message= along the way.

So, if we have = a message that goes through four mailing lists before final delivery, each = of which modify the subject and everyone is "doing the right thing&quo= t; (I know that's not exactly an abuse scenario), we would expect:

* ARC 1: cv=3Dnone, closest-fail=3D0
* ARC 2= : cv=3Dpass, closest-fail=3D0
* ARC 3: cv=3Dpass, closest-fail=3D= 1
* ARC 4: cv=3Dpass, closest-fail=3D2
* final recipien= t ADMD ARC verifier would find cv=3Dpass and evaluate closest-fail at 3

Is that what you have in mind?

--Kurt
--001a11412b98960e470561d587aa-- From nobody Tue Jan 2 23:05:36 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 12F6F1250B8 for ; Tue, 2 Jan 2018 23:05:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQsNNmtUbEXL for ; Tue, 2 Jan 2018 23:05:33 -0800 (PST) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::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 01710120713 for ; Tue, 2 Jan 2018 23:05:33 -0800 (PST) Received: by mail-qt0-x22f.google.com with SMTP id 33so1138246qtv.1 for ; Tue, 02 Jan 2018 23:05:32 -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=X7Ej8U7Ul1UJ5H8vpx0zUKo2hYp1hFD8ynGuE4FNeiA=; b=hXXNDSgdxROeB1fG9l906C5tUX+AgGQ8LYjdFeHnFGD5s1EnoVGHUCchBngme1xXxL t076PgPH0+xNUb9FgbaUItLDMCKxcTZvHyFLVkhFUdkXlTPT0JQ0DTMTCh73GtZGQvH5 YtOB0cj+27LjL0TZqAXbaIOcLVKL+SOpFn72RuVqpdcdYOqO6Qp8Tn0dnbFqAY6rC4iK 0dyYWvPFoknJZafmEzgxyhpw/nrd9BpxpAocblfbZoJrGF/yxbfQJ2I+fET/GyBoZ1b/ 3SCh6vK/ZrlQRo2agWWpK6HJBQmWQCsQvRQlxJ49+CszJRMeVU8HOIVgA+gZZhxlHZia vE8g== 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=X7Ej8U7Ul1UJ5H8vpx0zUKo2hYp1hFD8ynGuE4FNeiA=; b=HeVgLE5tJslmH48hvIwtKpUztVZzFUqx82fGAiNU/Lx5/pTLsKqG6O0Q+s6yOuI3Zw 9iDkEFiNB4D7j2N8pF5XgKkRrR7ApwHK8cNqYuhsenyUDVWacWzGVgQRf7465CbRIv1z zScIbA/H6B3wf4U5Ofk3mL2ZjsKmwUCkJFf5YvW4msTqOVNIdCzmFDBdvRAAqqSVqJGf MIK9IdK0oRL5nqsTrIK+jBpypiJhA9la49d2gAyLZaiTUPTaqFThrb7Ld02tnVP4F91D ewQ/tLjOwu04EJbdIzzujtUaJa7nCRV6rFtqLTd2HclX47xVunp6LCbngDFh7s2F3+uG GRxA== X-Gm-Message-State: AKGB3mJY/TsQnH6WvEg7dWBcjY+csQiFW13W0UjLyyug52XEU9qQwrOI Kq2zBqgv8N3iw/JSflmm7lDMq8JVeAW9OHMB0eI= X-Google-Smtp-Source: ACJfBosIxaXfopb5SgQRMXBuICVNsMDUoH2rv8N6f2LYLqTF/7tABV9/UKxsHf7mUihIJ/BL1J4JoKFUyHbAU+iuprk= X-Received: by 10.200.46.233 with SMTP id i38mr661833qta.109.1514963132002; Tue, 02 Jan 2018 23:05:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.33.1 with HTTP; Tue, 2 Jan 2018 23:05:31 -0800 (PST) In-Reply-To: References: From: "Murray S. Kucherawy" Date: Wed, 3 Jan 2018 02:05:31 -0500 Message-ID: To: "Kurt Andersen (b)" Cc: Seth Blank , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a113b08de54b84a0561d9d79b" Archived-At: Subject: Re: [dmarc-ietf] ARC draft questions (speak up!): Experimental Status and Considerations 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: Wed, 03 Jan 2018 07:05:35 -0000 --001a113b08de54b84a0561d9d79b Content-Type: text/plain; charset="UTF-8" On Tue, Jan 2, 2018 at 12:57 PM, Kurt Andersen (b) wrote: > While John Levine cited the benefits of the "experimental" approach taken > for EAI (https://mailarchive.ietf.org/arch/msg/dmarc/ > gvUecJuYLT9GIh5zbcZ_U9CgNkw), I'm also biased by the "let's all just play > nice" mess that came from designating incompatible "versions" of SPF as > competing experiments (see https://tools.ietf.org/html/rfc6686 for the > eventual outcome of that six year long experiment). > I'm not sure I understand the comparison. ARC, as far as I know, doesn't have two factions attempting to advance their own agendas in a common space. We have just one protocol here. Instead, the bulk of the debate has been about whether this WG is prepared to stand behind its processing via the standards track, and I thought we were leaning toward the answer to that being "no" right now, and the core issue is whether we want it to be standards track first or have an RFC number first. If getting it published in some state is more critical than having it on the standards track, then "experimental" is, to me, the only option right now. And that's what I think I said in Singapore. I think that any protocol which has not already been widely implemented is, > in some sense, experimental - if you are looking at it from the perspective > of hind-sight, you might have done some things differently/more > efficiently/etc. One might not have called IPv6 "IP"-anything or may have > chosen a longer address space for IPv4 for instance. > > I'm willing to go along with the consensus of the group, but wanted to > (re)express my continued opposition to the experimental track for this. > Dave Crocker can probably articulate this better than me, but I'll take a run at it. There are two primary drivers for this decision for me: 1) ARC is trying to do something that's different enough from DKIM (i.e., recording some kind of handling chain) that we really should have some deployment and impact experience before we can say we have enough confidence to call it a proposed standard; and 2) The advice that all handlers need to apply a seal to the message, to which Bron previously and rather strenuously voiced opposition. I believe the decision was to defer on that issue until we've run some real-world experiments, which to my knowledge haven't happened. Unless I've somehow missed a change in posture either by him or by the specification (which is entirely possible), we're not done enough to say it ought to be on the standards track. The counter-argument to (1) is that Proposed Standard really is only a proposal, but I think our goals are loftier than that here. Then again DKIM went out PS, right? Well yes, it did, but we weren't in any perceived hurry that I can recall. -MSK --001a113b08de54b84a0561d9d79b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jan 2, 2018 at 12:57 PM, Kurt Andersen (b) <kboth@= drkurt.com> wrote:
While John= Levine cited the benefits of the "experimental" approach taken f= or EAI (https://mailarchive.ietf.org/arch/msg/= dmarc/gvUecJuYLT9GIh5zbcZ_U9CgNkw), I'm also biased by the &qu= ot;let's all just play nice" mess that came from designating incom= patible "versions" of SPF as competing experiments (see <= a href=3D"https://tools.ietf.org/html/rfc6686" target=3D"_blank">https://to= ols.ietf.org/html/rfc6686 for the eventual outcome of that six yea= r long experiment).

I&#= 39;m not sure I understand the comparison.=C2=A0 ARC, as far as I know, doe= sn't have two factions attempting to advance their own agendas in a com= mon space.=C2=A0 We have just one protocol here.=C2=A0 Instead, the bulk of= the debate has been about whether this WG is prepared to stand behind its = processing via the standards track, and I thought we were leaning toward th= e answer to that being "no" right now, and the core issue is whet= her we want it to be standards track first or have an RFC number first.=C2= =A0 If getting it published in some state is more critical than having it o= n the standards track, then "experimental" is, to me, the only op= tion right now.=C2=A0 And that's what I think I said in Singapore.
<= /div>

<= font color=3D"#616161">= I think that any protocol which has not already been widely implemented is,= in some sense, experimental - if you are looking at it from the perspectiv= e of hind-sight, you might have done some things differently/more efficient= ly/etc. One might not have called IPv6 "IP"-anything or may have = chosen a longer address space for IPv4 for instance.

I'm willing to go along with the conse= nsus of the group, but wanted to (re)express my continued opposition to the= experimental track for this.
Dave Crocker can probably articulate this better than me, but = I'll take a run at it.

There are two primary d= rivers for this decision for me:

1) ARC is trying to do something th= at's different enough from DKIM (i.e., recording some kind of handling = chain) that we really should have some deployment and impact experience bef= ore we can say we have enough confidence to call it a proposed standard; an= d

2) The advice that all handlers need to apply a seal to= the message, to which Bron previously and rather strenuously voiced opposi= tion.=C2=A0 I believe the decision was to defer on that issue until we'= ve run some real-world experiments, which to my knowledge haven't happe= ned.=C2=A0 Unless I've somehow missed a change in posture either by him= or by the specification (which is entirely possible), we're not done e= nough to say it ought to be on the standards track.

The counter-argument to (1) is that Proposed Standard really is only a pr= oposal, but I think our goals are loftier than that here.=C2=A0 Then again = DKIM went out PS, right?=C2=A0 Well yes, it did, but we weren't in any = perceived hurry that I can recall.

-MSK
--001a113b08de54b84a0561d9d79b-- From nobody Wed Jan 3 00:04:35 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 EEC66126C22 for ; Wed, 3 Jan 2018 00:04:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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] 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 Z9g-O9NMklhs for ; Wed, 3 Jan 2018 00:04:32 -0800 (PST) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A8B812025C for ; Wed, 3 Jan 2018 00:04:32 -0800 (PST) Received: by mail-vk0-x229.google.com with SMTP id n2so446609vkf.4 for ; Wed, 03 Jan 2018 00:04:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=ILFYSlP8E6XI28ETQnKL9qeyle0ubqfiP80s3OU5CGw=; b=bZoJrpez0qY4oNS+MNJ8+H3dAN1VCG/QqRVL6RGC0IXZpnFdEm7jFuYghdkKSvdU3c EPh2BZcW5wT+PZ344wrNPfRdr2NeswRVrz+LLbkzMkvVG7egpzWhr84qFyIF12YNQQTO y1DtPrxFVLfbFZ7b8C4Sxm/jStWSnz9Gu+DZ0HHyeP8A+TE+Q258Y/S6F7SStK9QlQWY fcwnnvsyxcfEnWlq/oAwItwxVXLYqat5g0I8+MCGZOx1WjFE3/4NHgOnaSATS2Sh9XxH gDS5juRzKSx1PFoyfVfyAkEjHKSJdPKz2LnINQP9U50TkU2Ac47qYy9f7BJazHdccHO6 5HIg== 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=ILFYSlP8E6XI28ETQnKL9qeyle0ubqfiP80s3OU5CGw=; b=GB/7TgnD3P52DVEtLbTTwo69UxQW5R7wfE4bSNM2MOqd3StjWgBTzg1YI/KNDr3XhY s4YH8eWJir3hASNq5X0iLnsJ9/phijpfIOCclyVsEIlJuGbtWuqXUCCSfxhSt63xU49R A8iUaJt2V4rki4SLzOuUbziGg7lIlF2kPUteJv/B9U0l05m/gmcRwUcwbcI8n/G2s0Zn MeeWlbcrka3Q87MpxsYhL9kFINbTw3B3ZftA+HInS1i974M65/sJ9w2cD5McnHjVvyI7 cQKMbpsZjv/ERqBsVyVK/qsXPYejgP1x1RiPeXhDI7GuJguAWEQKzZqVxmMx9qqL8y3Y sr0g== X-Gm-Message-State: AKGB3mL1kvZBcLaBr1HvcHp/l3IIfGELhE0o1fdFJ9nHy22LjbWyUSrz fjPHMIJSo7+UeWNOzABkyRw8DTpZLkDK6Tfldvzgkhj9 X-Google-Smtp-Source: ACJfBotZmNkFfglkAycz6LOOLEi8LQyGUUL8/Ot+XyB/yauleoJgp2GIQLO3ThJ3AhlaUNwoRjvFNkS9QzomV96JiV4= X-Received: by 10.31.2.136 with SMTP id 130mr515004vkc.185.1514966670797; Wed, 03 Jan 2018 00:04:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.33.165 with HTTP; Wed, 3 Jan 2018 00:04:10 -0800 (PST) In-Reply-To: References: From: Seth Blank Date: Wed, 3 Jan 2018 00:04:10 -0800 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a113da83c428fd00561daaae1" Archived-At: Subject: Re: [dmarc-ietf] ARC draft questions (speak up!): Experimental Status and Considerations 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: Wed, 03 Jan 2018 08:04:34 -0000 --001a113da83c428fd00561daaae1 Content-Type: text/plain; charset="UTF-8" On Tue, Jan 2, 2018 at 11:05 PM, Murray S. Kucherawy wrote: > > 2) The advice that all handlers need to apply a seal to the message, to > which Bron previously and rather strenuously voiced opposition. I believe > the decision was to defer on that issue until we've run some real-world > experiments, which to my knowledge haven't happened. Unless I've somehow > missed a change in posture either by him or by the specification (which is > entirely possible), we're not done enough to say it ought to be on the > standards track. > To be clear, Bron's concern was that "anyone can seal" destroys the signal to final receivers about who modified the message, which might be crucially important. The counter-argument was that ARC won't get adoption unless it's benign and therefore easy for intermediaries to make a sealing decision, so the compromise was to add arc.closest-fail to the AR/AAR. This way, ARC participants can seal when in doubt and a final receiver has the data to determine which sealers modified vs simply handled the message. Furthermore, for me "experimental" comes from the fact that there are several open issues on which there has been lasting discussion within this group with no resolution that data from an experiment will quickly shine light on. It was for these reasons that I proposed the experimental considerations section. I believe the argument in favor of Experimental is a weighty one, and I think ARC fixes a meaty enough problem that getting to a published RFC is of greater and more timely importance than getting to Proposed Standard. And if we get to Experimental and gather data quickly, Proposed Standard won't be far behind... S --001a113da83c428fd00561daaae1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Jan 2, 2018 at 11:05 PM, Murray S. Kucherawy <superuser@gmail.com> wrote:
2) The advice that all h= andlers need to apply a seal to the message, to which Bron previously and r= ather strenuously voiced opposition.=C2=A0 I believe the decision was to de= fer on that issue until we've run some real-world experiments, which to= my knowledge haven't happened.=C2=A0 Unless I've somehow missed a = change in posture either by him or by the specification (which is entirely = possible), we're not done enough to say it ought to be on the standards= track.

To be clear= , Bron's concern was that "anyone can seal" destroys the sign= al to final receivers about who modified the message, which might be crucia= lly important. The counter-argument was that ARC won't get adoption unl= ess it's benign and therefore easy for intermediaries to make a sealing= decision, so the compromise was to add arc.closest-fail to the AR/AAR. Thi= s way, ARC participants can seal when in doubt and a final receiver has the= data to determine which sealers modified vs simply handled the message.
=C2=A0
Furthermore, for me "experimental" comes= from the fact that there are several open issues on which there has been l= asting discussion within this group with no resolution that data from an ex= periment will quickly shine light on. It was for these reasons that I propo= sed the experimental considerations section.

I bel= ieve the argument in favor of Experimental is a weighty one, and I think AR= C fixes a meaty enough problem that getting to a published RFC is of greate= r and more timely importance than getting to Proposed Standard. And if we g= et to Experimental and gather data quickly, Proposed Standard won't be = far behind...

S
--001a113da83c428fd00561daaae1-- From nobody Wed Jan 3 08:04:17 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 A04C6129C53 for ; Wed, 3 Jan 2018 08:04:16 -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 XXYhI6KzOYD3 for ; Wed, 3 Jan 2018 08:04:14 -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 167D41275F4 for ; Wed, 3 Jan 2018 08:04:13 -0800 (PST) Received: by mail-lf0-x22f.google.com with SMTP id h140so2165203lfg.1 for ; Wed, 03 Jan 2018 08:04:13 -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=RDmutQcFOarC6hArDUtYV6wXKq2/FkraW/N10BXu2+0=; b=d68GkSt1xbyS5VHAZ344euueBaxe0JsWDJAhIS/p0ZZABA5a16gHQjVvPMAWkjpzGB q/6N3mYFFk/wWwMTaK92TZT9c5VrFFwCwgdZFJG9UgzdYKCfDHAKsq0fSIdjHj09hnjb ziFh+qHaoeMr6L6ZitwHkRwGfoHGsrnSokRHY= 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=RDmutQcFOarC6hArDUtYV6wXKq2/FkraW/N10BXu2+0=; b=PkcHkzE1bDqeGesZ4LbHmnO/nEMvr2Ikb5pNxmD9ggYo3rPGMVNlg/BWJuoWjrOi6O Q9Ni1nb/7zR4DvSp21xasjSuncxgWK6G3uXDcPjfCgf/3tfYO6GQ1OuKwcW4eH5Th+ug 5g81WxGCA9caodaRDvw15I1i3yTr7ESDkI3xJnBTVx8qA7cX9q5tIDGvukodq6DfZADi BjczatZKT5MO29nlM2HQ080Y58LgpWBoScKtzjT4btH9izdS+XQqV2giyqbrJsQGiDEV p+lwgdBnP2HkAt55l3JlBuHtNKPELcGuXvkJ3+ZZTNs1c1hjqkrfVCLlVMip/wWOolUU VFUA== X-Gm-Message-State: AKGB3mI4UQjOYhdZv9lmWqKyKYulYzHW1J9cXfNWTkIwic56Yl56/ieC 4zG+H2w9z5AGDLEcAjSwSBTXpDg2Ir/Y5m9TXD4qiWdSU7o= X-Google-Smtp-Source: ACJfBotfdG9PjOcxgeF58MOJXjprpI975XcZFibev3PGeytVkVtaH2lZWqEyZ5HlG9e8gEFkeeRWVlbMJytJkMk/o5M= X-Received: by 10.46.22.15 with SMTP id w15mr1217490ljd.17.1514995451928; Wed, 03 Jan 2018 08:04:11 -0800 (PST) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.25.56.11 with HTTP; Wed, 3 Jan 2018 08:04:10 -0800 (PST) In-Reply-To: References: From: "Kurt Andersen (b)" Date: Wed, 3 Jan 2018 16:04:10 +0000 X-Google-Sender-Auth: dTJUQiGqv9Hc2El4HqeEWpDtfd4 Message-ID: To: Seth Blank Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="f403045fc1b8bfbc7e0561e15dfd" Archived-At: Subject: Re: [dmarc-ietf] ARC draft questions (speak up!): Experimental Status and Considerations 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: Wed, 03 Jan 2018 16:04:17 -0000 --f403045fc1b8bfbc7e0561e15dfd Content-Type: text/plain; charset="UTF-8" On Wed, Jan 3, 2018 at 8:04 AM, Seth Blank wrote: > > . . .for me "experimental" comes from the fact that there are several open > issues on which there has been lasting discussion within this group with no > resolution that data from an experiment will quickly shine light on. . . > I'm less sanguine about the likelihood of the deployment "quickly" generating data, especially since a bunch of what we are most interested in will be cloaked within the veil of proprietary processing within individual ADMDs. > I believe the argument in favor of Experimental is a weighty one, and I > think ARC fixes a meaty enough problem that getting to a published RFC is > of greater and more timely importance than getting to Proposed Standard. . . > Speed of getting an RFC number issued is, to me, the salient assertion. --Kurt --f403045fc1b8bfbc7e0561e15dfd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Jan 3, 2018 at 8:04 AM, Seth Blank <seth@sethblank.com>= wrote:
=C2=A0
. . .for me &qu= ot;experimental" comes from the fact that there are several open issue= s on which there has been lasting discussion within this group with no reso= lution that data from an experiment will quickly shine light on. . .
<= /div>

I'm less sanguine abo= ut the likelihood of the deployment "quickly" generating data, es= pecially since a bunch of what we are most interested in will be cloaked wi= thin the veil of proprietary processing within individual ADMDs.
= =C2=A0
I believe the argument in favor= of Experimental is a weighty one, and I think ARC fixes a meaty enough pro= blem that getting to a published RFC is of greater and more timely importan= ce than getting to Proposed Standard. . .

Speed of getting an RFC number issued is, to me,= the salient assertion.=C2=A0

--Kurt=C2=A0
--f403045fc1b8bfbc7e0561e15dfd-- From nobody Wed Jan 3 08:43:53 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 BCE60129C6B for ; Wed, 3 Jan 2018 08:43:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=dHtYd6Yw; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=tUvOYYTR 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 wVPHImCliji1 for ; Wed, 3 Jan 2018 08:43:50 -0800 (PST) Received: from groups.winserver.com (mail.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id D81241241F5 for ; Wed, 3 Jan 2018 08:43:49 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=5193; t=1514997822; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=u6DY43yCVazpL88LEB1HitV3Jc0=; b=dHtYd6YwT9cJ6P5ZhjSPMLIyq2crZikWbJW4kbNl6AgWr0tXDvkjJgzCDH+YhN Q1cnArd/kVUhBmNXMmn/ABYsPDYw8D+qyfAca4nKEAXzpKEvOF5FaE9wHlC4Tx7+ +gcjZKdCizo00IrmSqCd9M0+t1DuEVBlDWteoe0toq05Y= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Wed, 03 Jan 2018 11:43:42 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 571544454.1.3248; Wed, 03 Jan 2018 11:43:40 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=5193; t=1514997593; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=bUAzo8D WZZTAlOHpxhmpm3AiQ0ukatOiurqI9MaVFZE=; b=tUvOYYTR84aXFWvvzTdja+c NopWTp7zFritm0lxCKD83eCCOM+JdV89ElwrY9/Y3X3VNmVDxfKhWIfE4vpMLOJS sYkcMf/NcOC9FGIbo07hiaqGATRB4SQFkUTlIDlLeKJlHcd4T9NdnoYv7R+0b0oD SVHG5DbMYBpR6aIl2z8o= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Wed, 03 Jan 2018 11:39:53 -0500 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 571466064.9.242616; Wed, 03 Jan 2018 11:39:51 -0500 Message-ID: <5A4D083B.3090904@isdg.net> Date: Wed, 03 Jan 2018 11:43:39 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] ARC draft questions (speak up!): Experimental Status and Considerations 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: Wed, 03 Jan 2018 16:43:53 -0000 DKIM had a sound proof of concept when it was introduced, and I hate to bring it up, but its key attraction, both technically and from a marketing standpoint, came when it was tied to a DKIM Policy model as the original specification had it proposed: DKIM/SSP proposal: Proposed: o=~ NEUTRAL (signature optional [,No 3rd party?]) o=- STRONG (signature required, 3rd party allowed) o=! EXCLUSIVE (signature required, no 3rd party) o=. NEVER (no mail expected) o=^ USER WG suggestions: o=? WEAK (signature optional, no third party) o=~ NEUTRAL (signature optional, 3rd party allowed) It had a solid hash bound required anchor using a Domain Author Domain with a published policy for rejection, filtering, classification, whatever local policy wanted to use including nothing at all. So solid was the proof of concept, in the words of one prominent person in the group, "It's scary" of what people can do with a strong, exclusive rejection/filtering policy model. And the best part was it actually worked with a low false positive rate -- except for the indirect, mailing list streams and years later, we are still dealing with the latter. ARC has no ties to Policy. The ARC chain concept is sensitive, extremely high overhead and IMO, unnecessary for what we have been trying to resolve related to DKIM Policy Strong rejection policies and how to escape it with the blessings of the originating Author Domain. Making ARC a PS isn't going to change the fact it is a weak idea (less than "Half Baked") at this point in addressing the DKIM Policy Rejection issue with indirect mail. Tying ARC to a policy system may move the consideration much further because it may start discussions on Policy Scenarios of what are valid, invalid ARC seals. Until then, I'll continue to watch to see where "yuns" are going with this expensive RFC5322 header overhead add-on. -- HLS On 1/3/2018 2:05 AM, Murray S. Kucherawy wrote: > On Tue, Jan 2, 2018 at 12:57 PM, Kurt Andersen (b) > wrote: > > While John Levine cited the benefits of the "experimental" > approach taken for EAI > (https://mailarchive.ietf.org/arch/msg/dmarc/gvUecJuYLT9GIh5zbcZ_U9CgNkw > ), > I'm also biased by the "let's all just play nice" mess that came > from designating incompatible "versions" of SPF as competing > experiments (see https://tools.ietf.org/html/rfc6686 > for the eventual outcome of > that six year long experiment). > > > I'm not sure I understand the comparison. ARC, as far as I know, > doesn't have two factions attempting to advance their own agendas in a > common space. We have just one protocol here. Instead, the bulk of > the debate has been about whether this WG is prepared to stand behind > its processing via the standards track, and I thought we were leaning > toward the answer to that being "no" right now, and the core issue is > whether we want it to be standards track first or have an RFC number > first. If getting it published in some state is more critical than > having it on the standards track, then "experimental" is, to me, the > only option right now. And that's what I think I said in Singapore. > > I think that any protocol which has not already been widely > implemented is, in some sense, experimental - if you are looking > at it from the perspective of hind-sight, you might have done some > things differently/more efficiently/etc. One might not have called > IPv6 "IP"-anything or may have chosen a longer address space for > IPv4 for instance. > > I'm willing to go along with the consensus of the group, but > wanted to (re)express my continued opposition to the experimental > track for this. > > > Dave Crocker can probably articulate this better than me, but I'll > take a run at it. > > There are two primary drivers for this decision for me: > > 1) ARC is trying to do something that's different enough from DKIM > (i.e., recording some kind of handling chain) that we really should > have some deployment and impact experience before we can say we have > enough confidence to call it a proposed standard; and > > 2) The advice that all handlers need to apply a seal to the message, > to which Bron previously and rather strenuously voiced opposition. I > believe the decision was to defer on that issue until we've run some > real-world experiments, which to my knowledge haven't happened. > Unless I've somehow missed a change in posture either by him or by the > specification (which is entirely possible), we're not done enough to > say it ought to be on the standards track. > > The counter-argument to (1) is that Proposed Standard really is only a > proposal, but I think our goals are loftier than that here. Then > again DKIM went out PS, right? Well yes, it did, but we weren't in > any perceived hurry that I can recall. > > -MSK > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > From nobody Wed Jan 3 08:45:19 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 575A0124D68 for ; Wed, 3 Jan 2018 08:45:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TkT2PSTMkwaJ for ; Wed, 3 Jan 2018 08:45:16 -0800 (PST) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99E671241F5 for ; Wed, 3 Jan 2018 08:45:16 -0800 (PST) Received: by mail-pf0-x232.google.com with SMTP id m26so947900pfj.11 for ; Wed, 03 Jan 2018 08:45:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=5T0wrYB/mJsWZNo3xHoR6t6Ea/yQ3CQg3i/ieUbvT08=; b=snmJrGPqHF2PGslOWA9Ez668rSY/9JAF56qWpizfvL8Vw6KaiJTw7qfUMltxxewibC VdwX/ZRIT55H1RcwElE73XepJtvZd8OEhwrjYgMAS5/c19zbG+XrYk2//WZhEcicQW4u xbvvcLOLNxeOoHowJi+5cndH6zegeNSCA90Jfxq3A1HgYiV8VXLYzV9/IBP3NRJBdSem SZ7+hHUbPk5qQlCUDaBTtRgfRhFiTDazjJ7yc7RtcsXUttC0p9GlklfQ7SS7Y0e4Dy8+ 7hKKnuvWtTwz3i3vi9ZO1yIIlSJixnq6PHlKvOkAx5E5uBBL8Z26gH8oFixi4lUW9/bo 17oQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=5T0wrYB/mJsWZNo3xHoR6t6Ea/yQ3CQg3i/ieUbvT08=; b=amtg8Hv5P6wUC15V9JwePAFX7ffqSHsxpfOIBunwti2C8EYPRiSAe5/eOaZglBszoP 3KTxyA3Xr/qrs5V3vx3F7selpGB90wen5Ho94AsYbREprSSjX1x/ioVDevrtJ8rdne67 vWR4RPC2F1WacuSh2Xb4tAvgGo4MZpQ1/kvLjBvtjGirQUsXWtM3DJuptX7uE6ldKUYM xLO4ZrgI+vNZRrNO1ycBQmtAzdH2+5h9m4uVj4keOEs8dcyxNsKHcQDZS6bQ7/u+F8NH wqzzSa+WhrzpjV6xFKFiNm6wvTfH/ZQ1IhsVPSOsmdxqWez2gUWZ3+8tsghsaMb7vk91 mDnA== X-Gm-Message-State: AKGB3mINAm+9jrrGGrafkbM3Yl3xZ6eo5Kz3epFDdI/hzexArT5SfTWJ 9Vq+8qAd/aSng855+KTxpf/vx4ce X-Google-Smtp-Source: ACJfBotsciRFDwy7QPD2EEjUsGdHL2H5GQyN7dvUrBuRK/YTIsBzqA3FHHfG6KeWFYwhKIiRHqNppw== X-Received: by 10.99.66.197 with SMTP id p188mr1677623pga.371.1514997915532; Wed, 03 Jan 2018 08:45:15 -0800 (PST) Received: from ?IPv6:2600:1700:a3a0:870:c4e8:d795:bbab:6d47? ([2600:1700:a3a0:870:c4e8:d795:bbab:6d47]) by smtp.gmail.com with ESMTPSA id a87sm3980840pfg.159.2018.01.03.08.45.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Jan 2018 08:45:14 -0800 (PST) To: "Kurt Andersen (b)" , Seth Blank Cc: "dmarc@ietf.org" References: From: Dave Crocker Message-ID: Date: Wed, 3 Jan 2018 08:44:56 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] ARC draft questions (speak up!): Experimental Status and Considerations 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: Wed, 03 Jan 2018 16:45:18 -0000 > While John Levine cited the benefits of the "experimental" approach > taken for EAI > (https://mailarchive.ietf.org/arch/msg/dmarc/gvUecJuYLT9GIh5zbcZ_U9CgNkw), > I'm also biased by the "let's all just play nice" mess that came from > designating incompatible "versions" of SPF as competing experiments (see > https://tools.ietf.org/html/rfc6686 for the eventual outcome of that six > year long experiment). > > I think that any protocol which has not already been widely implemented > is, in some sense, experimental - if you are looking at it from the > perspective of hind-sight, you might have done some things > differently/more efficiently/etc. One might not have called IPv6 > "IP"-anything or may have chosen a longer address space for IPv4 for > instance. Both of the above examples demonstrate a corrupted use of the term, pretty much rendering it useless. Such a rendering does not seem very helpful to the community, not does it reflect the intent of the label. Here's some text that I think points in a more constructive direction: https://www.ietf.org/iesg/informational-vs-experimental.html "If the IETF may publish something based on this on the standards track once we know how well this one works, it's Experimental." There have been some very specific descriptions of focused concern for fragility and interactions about ARC. Those are what justify Experimental. There needs to be explicit documentation of those concerns and suggestions for measuring ARC performance to assess the field experiences with regard to those concerns. I offered examples of these earlier: ARC Experimental goals https://www.ietf.org/mail-archive/web/dmarc/current/msg03812.html In an earlier note, I also noted: ARC RFC status to target https://www.ietf.org/mail-archive/web/dmarc/current/msg03707.html "Having intermediaries signing thing and having receivers base delivery and labeling decisions on those signatures is new and, I think, significantly different that doing that for SPF or DKIM. Who should sign and when isn't yet well understood. How those signatures should get evaluated by receiving filtering engines also is not yet well-understood." Re: [dmarc-ietf] ARC RFC status to target "From that perspective, I suspect a good target for marking readiness for standardization is the ability of the community to produce an experience-based BCP about ARC Use." ARC RFC status to target https://www.ietf.org/mail-archive/web/dmarc/current/msg03730.html Re: [dmarc-ietf] Question for Thursday's meeting consideration: extending DMARC DNS record to cover ARC https://www.ietf.org/mail-archive/web/dmarc/current/msg03789.html "ARC is an underlying authentication mechanism that calls for a new assessment mechanism, since the role of the authenticated entity is different than the entities currently being assessed by filtering engines. " So... These were offered to explain the significant reasons this specification is not likely to be well-understood at initial deployment but is likely to raise significant operational challenges. And they offered a basis for evaluating initial use, to determine efficacy. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Jan 3 12:48:12 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 C9A4612785F for ; Wed, 3 Jan 2018 12:48:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.76 X-Spam-Level: X-Spam-Status: No, score=-1.76 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.25, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=tQcs7OQb; dkim=pass (1536-bit key) header.d=taugh.com header.b=c7iBbTpq 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 wkDS7EC_bIq1 for ; Wed, 3 Jan 2018 12:48:09 -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 5B85B126C83 for ; Wed, 3 Jan 2018 12:48:09 -0800 (PST) Received: (qmail 14084 invoked from network); 3 Jan 2018 20:48:07 -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=3702.5a4d4187.k1801; bh=0pAIyytyVna1RzIG5bn9BVYH0j3zHxnvc4TZzWavuF0=; b=tQcs7OQb1PtS6ppo3e/qvUbH13Wy5kDBO7Mv8aMyadm4cpKGVZpTG+cqIHSc4aImQgiPDrrLlImyOA/mbLfqevd36OFrVr7/jdK/OMmAiiuPPu3a1re8Lo21ZGVq5g0JTrkNQgDJwsJmtuBUs9mhAMWfqw32b4tiw/mQSNZYekQPzILIRikk1xUk2JRJ0cPV7Ai+R79kkQzdQfe0W58CsshEToGlIcGpZ/zB1bXmlPSfAYMmQFP53bnd4/FZ1GP3 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=3702.5a4d4187.k1801; bh=0pAIyytyVna1RzIG5bn9BVYH0j3zHxnvc4TZzWavuF0=; b=c7iBbTpqo10QlAg3ziOhaEcwaU/m8vtV7ndEv11eDf1Z1gcLrF6EQZ8mVorr3nYLJePB7vs4mpKU1Yp8unem8VkmqW1UQaNmLXoYLXhNeRknSdTr0U+pTvBHoBPGR99j5wBynqINY+obU9wR1shk4Y4HywfOli7Nyv7rLcT/dtHGIXBt0/3jEODghaYrnQ0YxmEThBZDYdYLUn3t38P1Xg5lO/r5PrZOfh6l3VeJ6JjO5w234diwBSH63Lf5gkVr 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; 03 Jan 2018 20:48:06 -0000 Received: by ary.qy (Postfix, from userid 501) id C191218C7E78; Wed, 3 Jan 2018 15:48:06 -0500 (EST) Date: 3 Jan 2018 15:48:06 -0500 Message-Id: <20180103204806.C191218C7E78@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: brong@fastmailteam.com In-Reply-To: <1514939995.3318165.1222346488.5B169072@webmail.messagingengine.com> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Clarifying the value of arc.closest-fail 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: Wed, 03 Jan 2018 20:48:11 -0000 In article <1514939995.3318165.1222346488.5B169072@webmail.messagingengine.com> you write: >Please read my examples again if the problem wasn't clear, because you >don't get security by imagining the best cases where everyone behaves >themselves, you get security by imagining that everybody is trying to >get away with the worst abuses they can without being detected. Seems to me this makes some assumptions about the way ARC consumers will use ARC chains to decide whether to ignore a DMARC failure. Personally, I think the most likely scenario is that they'll look at all of the signers to see if they all are reasonably trustworthy, and if so, look at the i=1 seal to see if the message would have passed before being munged, and if so allow it. This requires having a giant reputation database for every ARC signer, but that's not much of a stretch beyond the reputation database you need to decide whether to look at the ARC chain at all. Trying to guess who changed something and whether they were malicious seems unlikely to work. R's, John From nobody Wed Jan 3 12:58:08 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 D4DB2128961 for ; Wed, 3 Jan 2018 12:58:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4T81aLPDj1B for ; Wed, 3 Jan 2018 12:58:04 -0800 (PST) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::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 8B0F5126C83 for ; Wed, 3 Jan 2018 12:58:04 -0800 (PST) Received: by mail-ua0-x22f.google.com with SMTP id x10so1875832ual.8 for ; Wed, 03 Jan 2018 12:58:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EtQJ7tAVkoF5Zm8wPJ/PYgAxdrJzJ+GRhWzUDqr5Nb4=; b=JQgaULl4Fzia8eMn5/A+EolyOTkEPBBsWxzGxR1+FY3UPKoyHcT5CdQ32MKR9gIDHd JYEJXcziHANNddF4AlSAI5sdk15U++dHTMetQgoHWtGgcx0anqomwfApuyN/Bo3Y/gRW w+Lfidho9GLKyBr81lP4FeGn5XqqNsfmChRqTgE1xqqztfpGBGtcovRgOHX8UQnB9U82 S3S8b0e1xhDQ2fvJdP5nT1xVVo/Ho9UzjBj8RVlKIIWxhIUYZ5TlCecXJ5GCqtXVzbuE FD0t1cURtfxqtHBd4bhqDU/lGtmIz8k6H4a0bEZONj7FJM6Yyz3OQXJrj9SWfvyZsaXJ PNSg== 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=EtQJ7tAVkoF5Zm8wPJ/PYgAxdrJzJ+GRhWzUDqr5Nb4=; b=QQl+9mj2pRKmzsp//4RUjPTsqIcbjERdBeNv89O00G0JNh7VzYFVtSw1ppYLipEB3K ISAQhueICo/fPOiqLHgDtNv8xuw3IwOxe4pP+Zvx2tA7mglDEueuLKAE8qPHIaHiKqfc ru7cR1yQweN6En8Z0MiFQSdFkYKa2+t625IM2hJRSHwlRMoOf+hiRuyxecIV5r/wXFdm 7St2hIfa7bhzO7IfijlvR0j8K1AN8rn7WCei81CpY4zwxiBxLjwI6wVqNc3RmdpKWXFd PHVW1ij/H/kcabkHkquSXzSY126zZQUR8lfxs68LH7YPt4tF4RuBnTxt8w5xHcyRZfZT HAyw== X-Gm-Message-State: AKGB3mIco+lpmYbY2FwzjtH0N6O7yyv0lQ1tBHxXkkRpIFcYsvmqssZr nv9opuWFi7zfH/odd5fUNfmDGmodDHG7l/OPuyeQHe5y X-Google-Smtp-Source: ACJfBovXbb7j4hX8TOs+s01/r9EYcP5ELAHPP98jf9r02Z+YWLdB4rfe/x9W9fkWxgFDoi7J05GLDIFHp84orQvle78= X-Received: by 10.176.80.168 with SMTP id c37mr2778814uaa.178.1515013083415; Wed, 03 Jan 2018 12:58:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.33.165 with HTTP; Wed, 3 Jan 2018 12:57:42 -0800 (PST) In-Reply-To: <20180103204806.C191218C7E78@ary.qy> References: <1514939995.3318165.1222346488.5B169072@webmail.messagingengine.com> <20180103204806.C191218C7E78@ary.qy> From: Seth Blank Date: Wed, 3 Jan 2018 12:57:42 -0800 Message-ID: To: John Levine Cc: dmarc@ietf.org, Bron Gondwana Content-Type: multipart/alternative; boundary="94eb2c1927a4aae9900561e578a0" Archived-At: Subject: Re: [dmarc-ietf] Clarifying the value of arc.closest-fail 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: Wed, 03 Jan 2018 20:58:07 -0000 --94eb2c1927a4aae9900561e578a0 Content-Type: text/plain; charset="UTF-8" On Wed, Jan 3, 2018 at 12:48 PM, John Levine wrote: > > Seems to me this makes some assumptions about the way ARC consumers > will use ARC chains to decide whether to ignore a DMARC failure. > Personally, I think the most likely scenario is that they'll look at > all of the signers to see if they all are reasonably trustworthy, and > if so, look at the i=1 seal to see if the message would have passed > before being munged, and if so allow it. This requires having a giant > reputation database for every ARC signer, but that's not much of a > stretch beyond the reputation database you need to decide whether to > look at the ARC chain at all. > Yes, but since the decision with ARC was to keep the additional trace information because it wasn't clear what was useful, to me this falls cleanly into this same bucket. I'll propose text for the Experimental Considerations section to outline this around arc.closest-fail so it can be appropriately watched. --94eb2c1927a4aae9900561e578a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Jan 3, 2018 at 12:48 PM, John Levine <johnl@taugh.com> wro= te:
Seems to me this makes some assumptions a= bout the way ARC consumers
will use ARC chains to decide whether to ignore a DMARC failure.
Personally, I think the most likely scenario is that they'll look at all of the signers to see if they all are reasonably trustworthy, and
if so, look at the i=3D1 seal to see if the message would have passed
before being munged, and if so allow it.=C2=A0 This requires having a giant=
reputation database for every ARC signer, but that's not much of a
stretch beyond the reputation database you need to decide whether to
look at the ARC chain at all.

Yes, but = since the decision with ARC was to keep the additional trace information be= cause it wasn't clear what was useful, to me this falls cleanly into th= is same bucket.

I'll propose text for the Expe= rimental Considerations section to outline this around arc.closest-fail so = it can be appropriately watched.=C2=A0

--94eb2c1927a4aae9900561e578a0-- From nobody Wed Jan 3 14:50:08 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 27681129C6A for ; Wed, 3 Jan 2018 14:50:06 -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 oISQ1ydDFcIu for ; Wed, 3 Jan 2018 14:50:04 -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 2CD78120046 for ; Wed, 3 Jan 2018 14:50:04 -0800 (PST) Received: by mail-lf0-x233.google.com with SMTP id c19so2996131lfg.3 for ; Wed, 03 Jan 2018 14:50:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:from:date:message-id:subject:to:cc; bh=/dklvvvUrn8SMKa8x4SxTeYXDe4JPCVyWSydOGrgHhY=; b=MztfqmrGp4kXm82FKHGoyg6dDPO6uz9cJTNtSSPZLrpJ7Qd8V0jNZWPvex1wHWgYDn SwUvl2LgHBK3008MVy/9/eCP19zCPWFMhMeRK1Z7w4RHVvgWQb+KZLIT+SqTPnxobtSs ZdXtmvTNGhCPZyFT7E6zOJvUqjTlHjjHHzphY= 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:from:date:message-id:subject :to:cc; bh=/dklvvvUrn8SMKa8x4SxTeYXDe4JPCVyWSydOGrgHhY=; b=Z0/fxMJ5OB95Q6LdaEnI9Q4fP7cBT5LPyW8HKspv+ZDT9Lu7D6RPj/NgQuPjvj4yWe KCYsXE4NE2brGPQ47NVJ9jUBwI5w9QyMS/Y6jmfad7+GEI0ikNwIXZ7YIIT0CnVPHa5x K5jPQ8YFdqMaZzsMH30+/s+iXwXEheWNG7k5BV32HtdNCtHCt6mnRlRnyjGq9kxJ1OY6 i+cU204XiSIXC6VMvKaTZfGzctWdWfirgVL9uB/OZdytimoWiBKwXCJlZH4pTwXmQuYr leC+I5niqut50/AnLGmuyRYoORw2B85UOWQLmg6HyJv0LAyQOYzJAB5Vv/8vZCLvmDch VuSw== X-Gm-Message-State: AKGB3mI4NFpVTFumkpfL/Yn0KXXi1dLl4GyRaJOBUA7etDQ+Ur5IMU7Q DhZnMAbME5Sa3bjh25D6epIIIEyw+RiwoCXg32YSF0xo X-Google-Smtp-Source: ACJfBovOPnmc3BtFFYKI5hpt00pznUy47CUe2F5svAHXR32kgcurGUpo/BXi2McLMgATIX32Oodl2gBKlWsdzaVF6EM= X-Received: by 10.25.222.18 with SMTP id v18mr1656040lfg.143.1515019802250; Wed, 03 Jan 2018 14:50:02 -0800 (PST) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.25.56.11 with HTTP; Wed, 3 Jan 2018 14:50:01 -0800 (PST) From: "Kurt Andersen (b)" Date: Wed, 3 Jan 2018 22:50:01 +0000 X-Google-Sender-Auth: 3uaoMS5nyVFBctXRTpz-hrF4KxI Message-ID: To: Seth Blank Cc: John Levine , Bron Gondwana , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="f403045c31562426460561e70995" Archived-At: Subject: Re: [dmarc-ietf] Clarifying the value of arc.closest-fail 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: Wed, 03 Jan 2018 22:50:06 -0000 --f403045c31562426460561e70995 Content-Type: text/plain; charset="UTF-8" While I wait for Bron's confirmation that my understanding matches his (see email from yesterday), on Wed, Jan 3, 2018 at 8:57 PM, Seth Blank < seth@sethblank.com> wrote: > > . . .text for . . . arc.closest-fail . . . > I'm uncomfortable with the terminology implied by the term "arc.closest-fail". I think that it is more "ams.closest-fail" or "arc.ams-broken". AMS is expected to not verify except in the most recent ARC set. Doing so is not in any way a "failure" and has no bearing on the validity of the ARC chain (as documented in the cv parameter). Opinions regarding a replacement term? --Kurt --f403045c31562426460561e70995 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Whil= e I wait for Bron's confirmation that my understanding matches his (see= email from yesterday), on Wed, Jan 3, 2018 at 8:57 PM, Seth Blank <seth@= sethblank.com> wrote:

. . .text for . . . arc.closest-fai= l . . .=C2=A0

I'm uncomfortable with the terminology implied by the= term "arc.closest-fail". I think that it is more "ams.close= st-fail" or "arc.ams-broken". AMS is expected to not verify = except in the most recent ARC set. Doing so is not in any way a "failu= re" and has no bearing on the validity of the ARC chain (as documented= in the cv parameter). Opinions regarding a replacement term?

--Kurt
--f403045c31562426460561e70995-- From nobody Wed Jan 3 15:00:39 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 6BBC012D77B for ; Wed, 3 Jan 2018 15:00:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93AhsKJbldoY for ; Wed, 3 Jan 2018 15:00:35 -0800 (PST) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84546129C6C for ; Wed, 3 Jan 2018 15:00:35 -0800 (PST) Received: by mail-ua0-x230.google.com with SMTP id 34so2059144uav.5 for ; Wed, 03 Jan 2018 15:00:35 -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=/rWVMW3fZlwzaK/QSJgEA9lDrB91MrmTZqoDGbg1+xU=; b=DSFsJEcjjb/foSIZToVywiom6JLcdxJtr6HIwMdx8yxlWcBAOj+JJOY87YrZAySzA7 ceeeWCzL/yN0NDiuVvQZMKRMfsY+WuYumrrEBIsVHA15hYR5fTzCrCCossgD+34OHVFp chCp0WtrT1islzwvyGMilD1kVfJpXiiz+aMt/x9vhfSbhlElwSfNQWDfLlP82TsBC6YO WASM1dbYJPec/WZpOagn/KnZ0LGBuFN9Z4b0v4dhbt4YRrdIiVYMf3N9IjOElAPZkeZK hwGlV0V4H1+/UJ5TDShaJtts5RRGEQmzgcA7duzRDXI3gB8wyMEvsnCwy9pdCUFVpJ+x zj6A== 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=/rWVMW3fZlwzaK/QSJgEA9lDrB91MrmTZqoDGbg1+xU=; b=ajLI3LL7KjN9pfLrIGbCMap570M0Vs89zA1avEK7Jl+QHRfYdZww9W51EORq51atHl zhzjPTP26gn2f/c5Qp+4VMr8Qj0Ek6+Fa6ngpzRSnJLy0EKijK2/i3SM8miWHUWnSzYk YRxibYHB6q90ngHam0onA6kns1luoRTPZi/zGywoNjPTehHwb8kaTbOXc1zjcr/aUKk5 O+UlzyfeLe1vupIsheyJpWwNJJrfhomd8fA74M4sKF3AFDLHaYZB2UlRoYUe1pxBwTjL Ym4dZNlCU6YDJIzacw97Gxe9RlWc+PG9IXjNCUzk4hB0iQj2JID1JO20749WK6gRem+Y nukA== X-Gm-Message-State: AKGB3mLH8rxQ7ZfNkwuPD74D+PYWfLJJge1xpf5wy7g3tZD9W2ClnyFm +OiiTlz8BBQIhl5v2l0LunpeRwg6dWLeKT9LXe2Xsjfc X-Google-Smtp-Source: ACJfBotfIbJYwEK7MYa3SEX/UuuvxbZpwHhX/72za95Z3GqxcteCrtrPpEJ/16/C1EkO5GJpnxtKPD13kQkcC8sZnCg= X-Received: by 10.176.0.15 with SMTP id 15mr3046688uai.132.1515020434184; Wed, 03 Jan 2018 15:00:34 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Seth Blank Date: Wed, 03 Jan 2018 23:00:22 +0000 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a11c166aaceb3430561e72ec7" Archived-At: Subject: Re: [dmarc-ietf] Clarifying the value of arc.closest-fail 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: Wed, 03 Jan 2018 23:00:37 -0000 --001a11c166aaceb3430561e72ec7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jan 3, 2018 at 14:50 Kurt Andersen (b) wrote: > I'm uncomfortable with the terminology implied by the term > "arc.closest-fail". I think that it is more "ams.closest-fail" or > "arc.ams-broken". AMS is expected to not verify except in the most recent > ARC set. Doing so is not in any way a "failure" and has no bearing on the > validity of the ARC chain (as documented in the cv parameter). Opinions > regarding a replacement term? > My strong preference is this be tracked and the considerstions therein referenced in Experimental Considerations. I have no strong preference what we actually call it. I=E2=80=99m fine with ams.cb for =E2=80=9Cclosest break=E2=80=9D if that ke= eps things nice and tidy for an A-R (i.e. arc=3Dpass ams.cb=3D1). I also like it because then we have arc cv and ams cb. But I=E2=80=99m spli= tting hairs, and again, don=E2=80=99t really care what it=E2=80=99s called. > --001a11c166aaceb3430561e72ec7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jan 3, 2018 at 14:= 50 Kurt Andersen (b) <kboth@drkurt.c= om> wrote:
I'm uncomfortable with the = terminology implied by the term "arc.closest-fail". I think that = it is more "ams.closest-fail" or "arc.ams-broken". AMS = is expected to not verify except in the most recent ARC set. Doing so is no= t in any way a "failure" and has no bearing on the validity of th= e ARC chain (as documented in the cv parameter). Opinions regarding a repla= cement term?

My strong preference is this be tracked and the considerstion= s therein referenced in Experimental Considerations. I have no strong prefe= rence what we actually call it.

I=E2=80=99m fine with ams.cb for =E2=80=9Cclosest break=E2=80=9D = if that keeps things nice and tidy for an A-R (i.e. arc=3Dpass ams.cb=3D1).=

I also like it because = then we have arc cv and ams cb. But I=E2=80=99m splitting hairs, and again,= don=E2=80=99t really care what it=E2=80=99s called.
--001a11c166aaceb3430561e72ec7-- From nobody Wed Jan 3 15:09:38 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 1031F1241F8 for ; Wed, 3 Jan 2018 15:09:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 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, 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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=LZMCn3DK; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=XA7S/Als 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 I8ed1Lqg5mox for ; Wed, 3 Jan 2018 15:09:35 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20C49120046 for ; Wed, 3 Jan 2018 15:09:35 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 909D620BCF; Wed, 3 Jan 2018 18:09:34 -0500 (EST) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Wed, 03 Jan 2018 18:09:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=tAwCoC 0qoLeT+FqR4xEfJBs2uzDFahVCvZh2lwgwi9Y=; b=LZMCn3DKWWgVCFJKkU2D4/ 3SCV7yp3HvcqKPX1JxKFVtKYxvTWADS+j7NP1wxGGqGYRRVItVwbTv0yDo/vuSd8 kA4aq9vmXBaOuATTRCUMDHgFF2oHzhZpgVpyu2pPSSJk4eM3UY3bRDRjGAGQrtUn fJJzLP3AwVVvmUp1o79VVRRsRUzhAQ9nODN6P8P5ZLYcSJ1uOYS94LJ2zgYi/DrJ zBamZ/Yq6h+2o3ryuMD7NlLWhoBWWSEsEiVNrxadwYqld6jdagMD798gCV2crO2C 27NgBUdiV+6SQ9ItqylR6Ae2X4ZSDIGoNETIvYmNWOOrsZI3EsfQfPM8+n9P9n8g == DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=tAwCoC 0qoLeT+FqR4xEfJBs2uzDFahVCvZh2lwgwi9Y=; b=XA7S/AlsfzoZWRStC37ieX qgsfETQeeb7DxeTp0zV+BUb6j4K47pWyozi+zIcA/K+H/9zop4Soqr8anfO8EYjw UEaQEDlcvymn0BlHX5R1ZRE9ABm+1lRXy9qAKe5YoJG7UByo10umOtndUjz8YUz9 b6a1FKc8NNxiCIWBBDND1mnMkfk4Sl2iGnojRGYm5mwkLOa6Fy8V5i7ppLRa7mFX WEj3J8+X1yTeiMU/O5PBGa55iZEiK/ghakdtR/spurgvaPViDEarBrkpxU6aVldu HnnadCLv1MvW8FL5SVsZ07CyLqJRHCXUMD0WCIWdwDWNZzGhGcDGtK3LPc3ZcZNQ == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 6A4A09E259; Wed, 3 Jan 2018 18:09:34 -0500 (EST) Message-Id: <1515020974.3103467.1223486072.1869C8B9@webmail.messagingengine.com> From: Bron Gondwana To: "Kurt Andersen (b)" , Seth Blank Cc: John Levine , dmarc@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_151502097431034670" X-Mailer: MessagingEngine.com Webmail Interface - ajax-cc9a457c Date: Thu, 04 Jan 2018 10:09:34 +1100 In-Reply-To: References: Archived-At: Subject: Re: [dmarc-ietf] Clarifying the value of arc.closest-fail 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: Wed, 03 Jan 2018 23:09:37 -0000 This is a multi-part message in MIME format. --_----------=_151502097431034670 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Thu, 4 Jan 2018, at 09:50, Kurt Andersen (b) wrote: > While I wait for Bron's confirmation that my understanding matches his > (see email from yesterday), I'll go check on that... > on Wed, Jan 3, 2018 at 8:57 PM, Seth Blank wrote:>> >> . . .text for . . . arc.closest-fail . . . > I'm uncomfortable with the terminology implied by the term "arc.closest- > fail". I think that it is more "ams.closest-fail" or "arc.ams-broken". > AMS is expected to not verify except in the most recent ARC set. Doing > so is not in any way a "failure" and has no bearing on the validity of > the ARC chain (as documented in the cv parameter). Opinions regarding > a replacement term? Happy for the terminology to change. amc.closest-fail might be better. An analogy might be that each AMS casts a shadow of legitimacy forwards a certain length. While the AMS still holds, you know that the things it covers are unchanged since the step that signed it. That's really valuable to know. To give a clear english description for what I want, it is "Oldest AMS which is still valid". I don't care what it's called, or if it is "oldest- valid" or "newest-invalid" or whatever, so long as the thing I do care about can be accurately extracted. I'd also like to know the bootstrap pre-ARC case, which thankfully AAR contains as dkim=pass, spf=pass, etc. While dkim=pass is still true, we know it wasn't modified by the first ARC signer either. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_151502097431034670 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Thu, 4 Jan 2018, at 09:50, Kurt Andersen (b) wrote:
While I wait for Bron's confirmation that my understanding matches his (see email from yesterday),

I'll go check on that...

on Wed, Jan 3, 2018 at 8:57 PM, Seth Blank <seth@sethblank.com> wrote:

. . .text for . . . arc.closest-fail . . . 
I'm uncomfortable with the terminology implied by the term "arc.closest-fail". I think that it is more "ams.closest-fail" or "arc.ams-broken". AMS is expected to not verify except in the most recent ARC set. Doing so is not in any way a "failure" and has no bearing on the validity of the ARC chain (as documented in the cv parameter). Opinions regarding a replacement term?


Happy for the terminology to change.  amc.closest-fail might be better.

An analogy might be that each AMS casts a shadow of legitimacy forwards a certain length.  While the AMS still holds, you know that the things it covers are unchanged since the step that signed it.  That's really valuable to know.

To give a clear english description for what I want, it is "Oldest AMS which is still valid".  I don't care what it's called, or if it is "oldest-valid" or "newest-invalid" or whatever, so long as the thing I do care about can be accurately extracted.

I'd also like to know the bootstrap pre-ARC case, which thankfully AAR contains as dkim=pass, spf=pass, etc.  While dkim=pass is still true, we know it wasn't modified by the first ARC signer either.

Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


--_----------=_151502097431034670-- From nobody Wed Jan 3 15:20: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 DD3BE12D7EC for ; Wed, 3 Jan 2018 15:20:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 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, 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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=lALGCtEr; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=TWF7ecM/ 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 3Z2QDE60yDy5 for ; Wed, 3 Jan 2018 15:20:42 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1F8212D77B for ; Wed, 3 Jan 2018 15:20:41 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 0E0E120BF3 for ; Wed, 3 Jan 2018 18:20:41 -0500 (EST) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Wed, 03 Jan 2018 18:20:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=dRpqoiIljnvLy/3wl j+AZnVUUM70ww01Q9DAMxQVB1A=; b=lALGCtErZ5QbmO1sOuMjPnbozGbHMfXxJ QtHsPA1ygSwao+/SQzF/x5PgOll9nztOdT2mZI7ixcn9eYA7annzvgoxtc0v1GP3 nT8nBOV5CTsIfTzKtf8Jb+lgiRoW/0PtTNlD6Y8tkxpVVI7GYsk2s/3ujySgnZHO 5aGf0Dl3QACVZ/H1tWuF/CwrAfXmgxoJzL920gGIJtuOxOx7wtE9deSHTM/5zUFG BPxv2neDuyW4UbhObg0Gl4W2hhq69PGN3cBQrG7cBEXJ8gbNEbvxRiqgDIqwo6DG e4WlCPi7ZPr3s7H9AsvvhCCItYVpGEyNi9Em++mOkh/qClq+QJqiQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=dRpqoi IljnvLy/3wlj+AZnVUUM70ww01Q9DAMxQVB1A=; b=TWF7ecM/+BrSwqWjF1rYj/ nejDy6Kr3ic05QzDEBTDFMCBZrnp1KTSLNVn0vE8MKehn6v5uQkmyVUNT6TmFilN 7ssyjilmBjvyJJCcU9zxE2T0XYN4XhnpuULjxee0AdOCJta3bUETDpk/ZLa0U5uV oOhKrsoh0AuNqIFtTF93N4HmCz5KqDm7D6BBgtkC7qI6Cw3R9dnP0W7d4hgGq4BO 240LmpCNgkTcjGQQsug64jZzehd4BIzfvihVVdsdynPZoCKTN9AGi+muInWVnBtd NnKkB/gu9tov8gx9lqitjwMrBvR47qMFlOD0MaEJBYaE9FRFa/V7kMh10gTrdNzA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id D93F89E295; Wed, 3 Jan 2018 18:20:40 -0500 (EST) Message-Id: <1515021640.3106167.1223502368.3DB28018@webmail.messagingengine.com> From: Bron Gondwana To: dmarc@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_151502164031061672" X-Mailer: MessagingEngine.com Webmail Interface - ajax-cc9a457c References: <1514939995.3318165.1222346488.5B169072@webmail.messagingengine.com> Date: Thu, 04 Jan 2018 10:20:40 +1100 In-Reply-To: Archived-At: Subject: Re: [dmarc-ietf] Clarifying the value of arc.closest-fail 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: Wed, 03 Jan 2018 23:20:44 -0000 This is a multi-part message in MIME format. --_----------=_151502164031061672 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" I assume this was the one that you wanted my clarification on? On Wed, 3 Jan 2018, at 12:56, Kurt Andersen (b) wrote: > On Wed, Jan 3, 2018 at 12:39 AM, Bron Gondwana > wrote:>> __ >> >> On Wed, 3 Jan 2018, at 04:34, Kurt Andersen (b) wrote: >>> As I went through the edits for >>> https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-10#section-5.2.1 >>> I was unable to understand the value added by having the "arc.closest- >>> fail" listed in the AAR.>> >> Without a closest-fail from each step, or a similar way to determine >> changes, information about abuses gets lost along the chain, and the >> final receiver can't tell who modified the message along the way.> > So, if we have a message that goes through four mailing lists before > final delivery, each of which modify the subject and everyone is > "doing the right thing" (I know that's not exactly an abuse scenario), > we would expect:> > * ARC 1: cv=none, closest-fail=0 > * ARC 2: cv=pass, closest-fail=0 > * ARC 3: cv=pass, closest-fail=1 > * ARC 4: cv=pass, closest-fail=2 > * final recipient ADMD ARC verifier would find cv=pass and evaluate > closest-fail at 3> > Is that what you have in mind? Well, closest-fail on ARC 1 is meaningless. But yes - each AMS only holds for its own message here, which means ARC 1's AMS was valid to 2, but not 3 or 4. ARC 2's AMS was only valid to 3, not 4. Etc. This is the boring case, because we don't need closest-fail then. More interesting is if ARC 2 and ARC 3 DIDN'T change the Subject, because then we would have: * ARC 1: cv=none, closest-fail=0 * ARC 2: cv=pass, closest-fail=0 * ARC 3: cv=pass, closest-fail=0 * ARC 4: cv=pass, closest-fail=0 * final recipient ADMD ARC verifier would find cv=pass and evaluate closest-fail at 3 But let's rewrite it as oldest-pass, because that's clearer. Your case: * ARC 1: cv=none, ams.oldest-pass=0 * ARC 2: cv=pass, ams.oldest-pass=1 * ARC 3: cv=pass, ams.oldest-pass=2 * ARC 4: cv=pass, ams.oldest-pass=3 * final recipient ADMD ARC verifier would find cv=pass and evaluate ams.oldest- pass as 4. And my case where 2 and 3 didn't change anything: * ARC 1: cv=none, ams.oldest-pass=0 * ARC 2: cv=pass, ams.oldest-pass=1 * ARC 3: cv=pass, ams.oldest-pass=1 * ARC 4: cv=pass, ams.oldest-pass=1 * final recipient ADMD ARC verifier would find cv=pass and evaluate ams.oldest- pass as 4. >From which the final recipient can also see that, if they trust ARC 4 not to lie, neither ARC 2 or ARC 3 changed anything which was covered by ARC 1's AMS. There is no need to trust either ARC 2 or ARC 3's signatures in my example, which is the point here. Even if ARC 2 or ARC 3 are not yet known or trusted, you can tell that they didn't modify this particular message. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_151502164031061672 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
I assume this was the one that you wanted my clarification on?

On Wed, 3 Jan 2018, at 12:56, Kurt Andersen (b) wrote:
On Wed, Jan 3, 2018 at 12:39 AM, Bron Gondwana <brong@fastmailteam.com> wrote:


On Wed, 3 Jan 2018, at 04:34, Kurt Andersen (b) wrote:
As I went through the edits for https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-10#section-5.2.1 I was unable to understand the value added by having the "arc.closest-fail" listed in the AAR.

Without a closest-fail from each step, or a similar way to determine changes, information about abuses gets lost along the chain, and the final receiver can't tell who modified the message along the way.

So, if we have a message that goes through four mailing lists before final delivery, each of which modify the subject and everyone is "doing the right thing" (I know that's not exactly an abuse scenario), we would expect:

* ARC 1: cv=none, closest-fail=0
* ARC 2: cv=pass, closest-fail=0
* ARC 3: cv=pass, closest-fail=1
* ARC 4: cv=pass, closest-fail=2
* final recipient ADMD ARC verifier would find cv=pass and evaluate closest-fail at 3

Is that what you have in mind?

Well, closest-fail on ARC 1 is meaningless.

But yes - each AMS only holds for its own message here, which means ARC 1's AMS was valid to 2, but not 3 or 4.  ARC 2's AMS was only valid to 3, not 4.  Etc.

This is the boring case, because we don't need closest-fail then.  More interesting is if ARC 2 and ARC 3 DIDN'T change the Subject, because then we would have:

* ARC 1: cv=none, closest-fail=0
* ARC 2: cv=pass, closest-fail=0
* ARC 3: cv=pass, closest-fail=0
* ARC 4: cv=pass, closest-fail=0
* final recipient ADMD ARC verifier would find cv=pass and evaluate closest-fail at 3

But let's rewrite it as oldest-pass, because that's clearer.  Your case:

* ARC 1: cv=none, ams.oldest-pass=0
* ARC 2: cv=pass, ams.oldest-pass=1
* ARC 3: cv=pass, ams.oldest-pass=2
* ARC 4: cv=pass, ams.oldest-pass=3
* final recipient ADMD ARC verifier would find cv=pass and evaluate ams.oldest-pass as 4.

And my case where 2 and 3 didn't change anything:

* ARC 1: cv=none, ams.oldest-pass=0
* ARC 2: cv=pass, ams.oldest-pass=1
* ARC 3: cv=pass, ams.oldest-pass=1
* ARC 4: cv=pass, ams.oldest-pass=1
* final recipient ADMD ARC verifier would find cv=pass and evaluate ams.oldest-pass as 4.

From which the final recipient can also see that, if they trust ARC 4 not to lie, neither ARC 2 or ARC 3 changed anything which was covered by ARC 1's AMS.

There is no need to trust either ARC 2 or ARC 3's signatures in my example, which is the point here.  Even if ARC 2 or ARC 3 are not yet known or trusted, you can tell that they didn't modify this particular message.

Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


--_----------=_151502164031061672-- From nobody Wed Jan 3 15:28:38 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 CE9621241F8 for ; Wed, 3 Jan 2018 15:28:36 -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 N27S-QUd7gy3 for ; Wed, 3 Jan 2018 15:28:35 -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 9FC07127201 for ; Wed, 3 Jan 2018 15:28:34 -0800 (PST) Received: by mail-lf0-x233.google.com with SMTP id u84so3057549lff.7 for ; Wed, 03 Jan 2018 15:28:34 -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=ca1nVRPr5hOQcBHbKN2Dp5kQZj2r0g8Rgmy+SkCM4GA=; b=U5uwzSFzmfDLFhT8yJNum1b6HE+yItCwl9/c0UGgpt6eM/ZBB0JzD0imRntZbOkyVp HT2w9TTv3u3yywaJmy5mySnw8eutAIX7lPrADqy35HTxbHq8I9wJBiaBPDVsexzTzFIJ PrI6uN1ZrSnhVFfZ4sA0Ur4sf9D7MvmjbgnXU= 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=ca1nVRPr5hOQcBHbKN2Dp5kQZj2r0g8Rgmy+SkCM4GA=; b=bJBt08drdbpZtT1o75SMukhd8MAJ5iMDp3+uCI0A45v3E+i9IWg+EKBzH35THZdfVa 7b7RG/Pxm7sENY168TFuVYsxwtPaokuUyvd6au4s0t9YwZEikAQtqUuB4ZRdIfDLokgb BXxOvA0UzoSEmYqjO2YPSyG/OZDx5yW3CvYwkbEiuuPOxCUzXONCaTURd/UDmp7xAeTN HwMZgrtYKo7MFZFa3addOm5jMZOqNJ0in8zxAZCJTY/851yb1P8IaLJ/6s21QAJwQheL MCFnPjIS6xwuDAYU07ei8JWSZ8qX9h47uwa2l52HA7heO9GkGvcyNSF8mIWDGncUBjzN GckQ== X-Gm-Message-State: AKGB3mL8lxuO0jkJYPqaT9go1LgtApWprqCnxNw///Fwd8hS0zosavNg 5ab9RULXvNGIffK4Iw3/zon/vkO7CSPcJgdJPAxZCg== X-Google-Smtp-Source: ACJfBou+4A+4ieF0R0R7UFTO3e+B2kmE68inc76Apowm1mypG9MYCNRgo5RPElLKORKUcd1etzZyqCr8QkuOc+eK+wM= X-Received: by 10.46.83.76 with SMTP id t12mr1585628ljd.45.1515022112613; Wed, 03 Jan 2018 15:28:32 -0800 (PST) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.25.56.11 with HTTP; Wed, 3 Jan 2018 15:28:31 -0800 (PST) In-Reply-To: <1515021640.3106167.1223502368.3DB28018@webmail.messagingengine.com> References: <1514939995.3318165.1222346488.5B169072@webmail.messagingengine.com> <1515021640.3106167.1223502368.3DB28018@webmail.messagingengine.com> From: "Kurt Andersen (b)" Date: Wed, 3 Jan 2018 23:28:31 +0000 X-Google-Sender-Auth: jM5XEMeFDWj-uODGHxADS8J6U9w Message-ID: To: Bron Gondwana Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c1cf32cd982780561e792ca" Archived-At: Subject: Re: [dmarc-ietf] Clarifying the value of arc.closest-fail 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: Wed, 03 Jan 2018 23:28:37 -0000 --94eb2c1cf32cd982780561e792ca Content-Type: text/plain; charset="UTF-8" On Wed, Jan 3, 2018 at 11:20 PM, Bron Gondwana wrote: > I assume this was the one that you wanted my clarification on? > Yes, thanks > But let's rewrite it as oldest-pass, because that's clearer. Your case: > > * ARC 1: cv=none, ams.oldest-pass=0 > * ARC 2: cv=pass, ams.oldest-pass=1 > * ARC 3: cv=pass, ams.oldest-pass=2 > * ARC 4: cv=pass, ams.oldest-pass=3 > * final recipient ADMD ARC verifier would find cv=pass and evaluate > ams.oldest-pass as 4. > > And my case where 2 and 3 didn't change anything: > > * ARC 1: cv=none, ams.oldest-pass=0 > * ARC 2: cv=pass, ams.oldest-pass=1 > * ARC 3: cv=pass, ams.oldest-pass=1 > * ARC 4: cv=pass, ams.oldest-pass=1 > * final recipient ADMD ARC verifier would find cv=pass and evaluate > ams.oldest-pass as 4. > > From which the final recipient can also see that, if they trust ARC 4 not > to lie, neither ARC 2 or ARC 3 changed anything which was covered by ARC > 1's AMS. > > There is no need to trust either ARC 2 or ARC 3's signatures in my > example, which is the point here. Even if ARC 2 or ARC 3 are not yet known > or trusted, you can tell that they didn't modify this particular message. > Very helpful - thanks. I think that expressing it in the positive "oldest-pass" form makes the point much clearer. Unless there is an outcry from the rest of the group, I'd like to change to this terminology. --Kurt --94eb2c1cf32cd982780561e792ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Jan 3, 2018 at 11:20 PM, Bron Gondwana <brong@fastmailteam.com> wrote:
I assume this was the one that you wa= nted my clarification on?

Y= es, thanks
=C2=A0
But let's rewrite it as oldest-p= ass, because that's clearer.=C2=A0 Your case:

* ARC 1: cv=3Dnone, ams.oldest-pass=3D0
* ARC 2: cv=3Dpass, ams.oldest-pass=3D1
* ARC 3: cv=3Dpass, ams.oldest-pass=3D2
* ARC 4: cv=3Dpass, ams.oldest-pass=3D3
* final recipient ADMD ARC verifier would find cv=3Dpass and evaluate = ams.oldest-pass as 4.

And my case where 2 and 3 didn't chang= e anything:

* ARC 1: cv=3Dnone, ams.oldest-pass=3D0
=
* ARC 2: cv=3Dpass, ams.oldest-pass=3D1
* ARC 3: cv=3Dpass, ams.oldest-pass=3D1
* ARC 4: cv=3Dpass, ams.oldest-pass=3D1
* final recipient ADMD ARC verifier would find cv=3Dpass and evaluate = ams.oldest-pass as 4.

From which the final recipient can also se= e that, if they trust ARC 4 not to lie, neither ARC 2 or ARC 3 changed anyt= hing which was covered by ARC 1's AMS.

There is no need to trust either ARC 2 or = ARC 3's signatures in my example, which is the point here.=C2=A0 Even i= f ARC 2 or ARC 3 are not yet known or trusted, you can tell that they didn&= #39;t modify this particular message.

=
Very helpful - thanks. I think that expres= sing it in the positive "oldest-pass" form makes the point much c= learer. Unless there is an outcry from the rest of the group, I'd like = to change to this terminology.

--Kurt
--94eb2c1cf32cd982780561e792ca-- From nobody Wed Jan 3 15:36:24 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 D6806127058 for ; Wed, 3 Jan 2018 15:36:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRfCouyhj0Ip for ; Wed, 3 Jan 2018 15:36:21 -0800 (PST) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::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 EFBB71241F8 for ; Wed, 3 Jan 2018 15:36:20 -0800 (PST) Received: by mail-ua0-x233.google.com with SMTP id g16so8909uak.2 for ; Wed, 03 Jan 2018 15:36:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=y/c547qa/AzS5QqkmfUFEfd7Gm80IjQLv/u6n/Ing80=; b=1kr049/XzzHi1ujyEQskJymq7xwBObQ1Y0MBp8S9nU8vIFiU630EGWtUfOarlePP3V QVpRfr74KVCqMh8NsT4X3E0c9G86dDDVM40UVTeX5QhsJ8CXqWNzamD84V6xh/0A3Fi/ TmNlfpFj4RST8Zy12whl39VCU2R0NxJvKGkZwmydftV7lbN9oC8Pp4o7nPIEYa+SKozu fVFKeDcWFgOCpVGKgWJPqPwzF1Qh/UeIM4O7stUDHdIxQbMQ0+c06kMd0a/k/OB3ag71 DcZq/sXXcM4se+qS+URdJ8JS2Lf3S1YUZPc6a6LOjulmhfBN7Fi7rtBTQ+jDS8ccp+Uy tS0A== 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=y/c547qa/AzS5QqkmfUFEfd7Gm80IjQLv/u6n/Ing80=; b=NJVJUxK+BqMFe5DdBSJewrxOcY4nXtGC8teWmuzrWjQ/7eP0ROrcbRXMi6V2ab8wPU in9FkhuL2WEz2RTpdItjGx5wM1eTuJKzof/K2LOsKEjI8ixkcUcrj9SQfIjXth1dbzbG lrzCNUUtgew52mFhKK9sCCNP51709vl4NwWQSdPwtt408zlXi+fwuSHopbjX+FQiiA5C b14Jk8CzksKYe6Xi5EyxOhfmQwATJMl4N/ajB2MQDuxzO8dh/X5KBFa0sftmzZ4x+SQo yALZ52Ln0HZkjG6IBlzXL1IJezw5sd8WWfFB9MAQtt1gfSK2IAaRgWDqwjalBBb+6Owp VyTg== X-Gm-Message-State: AKGB3mLtVh67XdSa8QdB7rTHe/+z7JUeb6XbZvqzPh0wI3Y0pkxOBRBf YBLIFOOokyG2fGGH1T4wfaYaNIc33QvSUDbDYy+FjOCq X-Google-Smtp-Source: ACJfBosJabjEdweqpUrLxW1a30C3e/WFdhSNxEieQwrkGbVZuDtD1LQELakci65VtxlGaIndw+PJO+JocDRHt9cRx9U= X-Received: by 10.176.48.89 with SMTP id x25mr3115458ual.45.1515022579647; Wed, 03 Jan 2018 15:36:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.33.165 with HTTP; Wed, 3 Jan 2018 15:35:59 -0800 (PST) In-Reply-To: References: <1514939995.3318165.1222346488.5B169072@webmail.messagingengine.com> <1515021640.3106167.1223502368.3DB28018@webmail.messagingengine.com> From: Seth Blank Date: Wed, 3 Jan 2018 15:35:59 -0800 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="f4030437d0c4afdfa40561e7ae96" Archived-At: Subject: Re: [dmarc-ietf] Clarifying the value of arc.closest-fail 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: Wed, 03 Jan 2018 23:36:23 -0000 --f4030437d0c4afdfa40561e7ae96 Content-Type: text/plain; charset="UTF-8" On Wed, Jan 3, 2018 at 3:28 PM, Kurt Andersen (b) wrote: > > Very helpful - thanks. I think that expressing it in the positive > "oldest-pass" form makes the point much clearer. Unless there is an outcry > from the rest of the group, I'd like to change to this terminology. > No objection --f4030437d0c4afdfa40561e7ae96 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Jan 3, 2018 at 3:28 PM, Kurt Andersen (b) <kboth@drkurt.com> wrote:
Very helpful - thanks. I think that expressing it in the positive= "oldest-pass" form makes the point much clearer. Unless there is= an outcry from the rest of the group, I'd like to change to this termi= nology.

No objection=C2=A0
--f4030437d0c4afdfa40561e7ae96-- From nobody Thu Jan 4 21:16:57 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 EF2F6124217 for ; Thu, 4 Jan 2018 21:16:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tG26_3hY_2j4 for ; Thu, 4 Jan 2018 21:16:55 -0800 (PST) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2E33126C2F for ; Thu, 4 Jan 2018 21:16:54 -0800 (PST) Received: by mail-qt0-x230.google.com with SMTP id i40so4540435qti.8 for ; Thu, 04 Jan 2018 21:16:54 -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=YayicYehkZlJU2qdwSKhlxkJtJ3mwPHhnf9DnZuXKk0=; b=YXaMCCLKZfuIN2QDjoEh4SGUnF7sFiv2PABmWGJ+KdeyGxGNfB4ImFkD5/a6l/Zj3X F9BuvsbS2CFDQ9OkJS0t+etUu+PQeeL8DR3N0Z2Ybplil2hZ/xeW1ScmV5/2FXBDRRlK t++zEbLXAFK/95H6ob8xGohkzNifpE+GUiySmDBxIw+mzjb/n1to70HRm5Eh1kEfhWtf IiQdl7TgtV/ZyvQSOff2LHYlsOPwXkLJkHkU6fWvZh/AiLZ1Y9TZ8rrViWYHAjE8gc31 LcIEuaIT7QK3czKByoa04AUAUS1+Jc6B+daFXK1qJnkQl/VY0DZklVYojLKVcWIS+m1x O0mg== 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=YayicYehkZlJU2qdwSKhlxkJtJ3mwPHhnf9DnZuXKk0=; b=SBPVhA2d+SRJa/FU7bTIa0wtieZPZgbEwFO1UoOra7Zxym680jW8KPJCQUdavIs2uH rT02BomcmeXl/oghfSguL13NIYI1a06D/4jiELtTccXmFrphzTh0hPAmigTs/PUcNEsC Mw4dh6uZYS3HV1cnhZeNKaNN+YAPOh7ybDkqNbv6dAlOPMjSAE0WmyuK9jqGMVpV+bMW WTITrWp+e0EFqEO5XKtCWy8bu3qSUKN5S6PCsZH9GHNeZ6ZL+Jm8L+i6pS4O2lU0uWDl eYrBZElqL+qnVvnDgvVHGk0ymuEqjaJeDP5Sdy1I8sE0fa9ddlDydcUetWizWZ6ibtQH JHSw== X-Gm-Message-State: AKwxytcZJTcMV+vx2qI9+RWqpPSo7O946eeVEuFgZe6hrBARJHTCE52L JRyFAlv4Wu1S3hB04mCla8yOk3x8LH00Zy0zG5WFrQ== X-Google-Smtp-Source: ACJfBoujfPGY8zobLBhGI70/RTq8Bs0Na9+vFcL5+mvXvcE1Sr+qUBwcczs2RbFf5ugJ2MxxoyIyJe64Amj+yR9+/Do= X-Received: by 10.200.20.24 with SMTP id k24mr2791720qtj.109.1515129413911; Thu, 04 Jan 2018 21:16:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.33.1 with HTTP; Thu, 4 Jan 2018 21:16:53 -0800 (PST) In-Reply-To: References: From: "Murray S. Kucherawy" Date: Fri, 5 Jan 2018 00:16:53 -0500 Message-ID: To: "Kurt Andersen (b)" Cc: Seth Blank , Bron Gondwana , "dmarc@ietf.org" , John Levine Content-Type: multipart/alternative; boundary="089e082947348149260562008e13" Archived-At: Subject: Re: [dmarc-ietf] Clarifying the value of arc.closest-fail 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, 05 Jan 2018 05:16:57 -0000 --089e082947348149260562008e13 Content-Type: text/plain; charset="UTF-8" On Wed, Jan 3, 2018 at 5:50 PM, Kurt Andersen (b) wrote: > While I wait for Bron's confirmation that my understanding matches his > (see email from yesterday), on Wed, Jan 3, 2018 at 8:57 PM, Seth Blank < > seth@sethblank.com> wrote: > >> >> . . .text for . . . arc.closest-fail . . . >> > > I'm uncomfortable with the terminology implied by the term > "arc.closest-fail". I think that it is more "ams.closest-fail" or > "arc.ams-broken". AMS is expected to not verify except in the most recent > ARC set. Doing so is not in any way a "failure" and has no bearing on the > validity of the ARC chain (as documented in the cv parameter). Opinions > regarding a replacement term? > I would prefer "arc.*" to "ams.*", because all of the registered examples name the protocol from which the information is being taken. But the text describing "ptype" allows for either, so it's only a preference. -MSK --089e082947348149260562008e13 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jan 3, 2018 at 5:50 PM, Kurt Andersen (b) <kboth@d= rkurt.com> wrote:
While I wait for Bron's confir= mation that my understanding matches his (see email from yesterday), on Wed= , Jan 3, 2018 at 8:57 PM, Seth Blank <seth@sethblank.com> w= rote:

<= /div>
. . .text for . . . arc.closest-fail . . .=C2=A0

I'm unco= mfortable with the terminology implied by the term "arc.closest-fail&q= uot;. I think that it is more "ams.closest-fail" or "arc.ams= -broken". AMS is expected to not verify except in the most recent ARC = set. Doing so is not in any way a "failure" and has no bearing on= the validity of the ARC chain (as documented in the cv parameter). Opinion= s regarding a replacement term?

I would prefer "arc.*" to "ams.*", because all of the = registered examples name the protocol from which the information is being t= aken.=C2=A0 But the text describing "ptype" allows for either, so= it's only a preference.

-MSK
--089e082947348149260562008e13-- From nobody Thu Jan 4 21:18:39 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 5F209126C2F for ; Thu, 4 Jan 2018 21:18:38 -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 x3UtYM_9NPa7 for ; Thu, 4 Jan 2018 21:18:36 -0800 (PST) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FE99124217 for ; Thu, 4 Jan 2018 21:18:36 -0800 (PST) Received: by mail-qk0-x235.google.com with SMTP id q14so4708824qke.7 for ; Thu, 04 Jan 2018 21:18:36 -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=pBAVu6+fYG9uDQztcXwUjo9WSo5C9lXSPlSWGngupzk=; b=WCXRgmuMbyzNxDSb1k/d27L3No8TM6gv4vzBinIzA1MYZbaGYDKDnOchsBRbyNJkZv 8xrpEU8fZyJKwc8yvcDG3CeDsstuo/gUXSIxxKu8fwqoLGkIVxaYEO+BzptRGSaWto6Y Fkdmfb10ltTkAx53gyNBHR4CfmjiHyp8ak6q/CbnKUO+CUzl8xN0Z+40gdlipv7l/kZX nYRWhtMzgw9ttqZ5TRrwq8E9N/Lm5exvX7773cAB1cRnpfS5PXJk7+sfIeH+gHWIs/X9 a8zQu+sHSV6iwSK5UyyDUCjECqY5r4BNxH776MswHblVKIUy1qQKMPAeLPH+w3BwgtKl HEBw== 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=pBAVu6+fYG9uDQztcXwUjo9WSo5C9lXSPlSWGngupzk=; b=S0vPZc8qvBbgePRnRjzdejJuBoYm9zst17KbU+jCMG9Eutf2m62S2+/wDcoKE1Pk9Z wLkZJmST9jAYStWrte9uLvY7QAA1s6ecODuUhDB1qTfjfUyo9L8AqeEKX0o7NC6lmsrk WJxRNVilwZH7WU/uO1CHjIUaaedqRZwWoj5+Np6EDLNSD7BX0ZwL6blYd41flbpzvd8X TPDN3VHX0i93hR2Theq9lsqvft9EJqNKKy2pgXOY0KZ8JWtyNx7wkdigXGMGJGCw+cmq kN9gx4mM1eObRKs9WS4TDK680NeUNez5HrfUE3tDw6/FY5Vl0uz9Tp50al2Js4e8E5gp M1HA== X-Gm-Message-State: AKwxytdd1GmtJck+kMlS5digxIguswg1vL3s6Lj4cFiM+YsYo2z8Wwj2 tHVd9VaABXggQIoy42foteLzz4t/jz02+TwC+l62Qg== X-Google-Smtp-Source: ACJfBotEiu140LFSNCFX9QKI/BGnCHzvEXfJNrLfcKnIz31/wTiFu1LIjAVLYrvZPNFic6/9FdVtzZgAao1gu/9G6TI= X-Received: by 10.55.18.72 with SMTP id c69mr2482983qkh.223.1515129515561; Thu, 04 Jan 2018 21:18:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.33.1 with HTTP; Thu, 4 Jan 2018 21:18:35 -0800 (PST) In-Reply-To: References: <1514939995.3318165.1222346488.5B169072@webmail.messagingengine.com> <1515021640.3106167.1223502368.3DB28018@webmail.messagingengine.com> From: "Murray S. Kucherawy" Date: Fri, 5 Jan 2018 00:18:35 -0500 Message-ID: To: "Kurt Andersen (b)" Cc: Bron Gondwana , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a1146a0e49059730562009452" Archived-At: Subject: Re: [dmarc-ietf] Clarifying the value of arc.closest-fail 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, 05 Jan 2018 05:18:38 -0000 --001a1146a0e49059730562009452 Content-Type: text/plain; charset="UTF-8" On Wed, Jan 3, 2018 at 6:28 PM, Kurt Andersen (b) wrote: > On Wed, Jan 3, 2018 at 11:20 PM, Bron Gondwana > wrote: > >> I assume this was the one that you wanted my clarification on? >> > > Yes, thanks > > >> But let's rewrite it as oldest-pass, because that's clearer. Your case: >> >> * ARC 1: cv=none, ams.oldest-pass=0 >> * ARC 2: cv=pass, ams.oldest-pass=1 >> * ARC 3: cv=pass, ams.oldest-pass=2 >> * ARC 4: cv=pass, ams.oldest-pass=3 >> * final recipient ADMD ARC verifier would find cv=pass and evaluate >> ams.oldest-pass as 4. >> >> And my case where 2 and 3 didn't change anything: >> >> * ARC 1: cv=none, ams.oldest-pass=0 >> * ARC 2: cv=pass, ams.oldest-pass=1 >> * ARC 3: cv=pass, ams.oldest-pass=1 >> * ARC 4: cv=pass, ams.oldest-pass=1 >> * final recipient ADMD ARC verifier would find cv=pass and evaluate >> ams.oldest-pass as 4. >> >> From which the final recipient can also see that, if they trust ARC 4 not >> to lie, neither ARC 2 or ARC 3 changed anything which was covered by ARC >> 1's AMS. >> >> There is no need to trust either ARC 2 or ARC 3's signatures in my >> example, which is the point here. Even if ARC 2 or ARC 3 are not yet known >> or trusted, you can tell that they didn't modify this particular message. >> > > Very helpful - thanks. I think that expressing it in the positive > "oldest-pass" form makes the point much clearer. Unless there is an outcry > from the rest of the group, I'd like to change to this terminology. > Just to be clear, we're saying "*.oldest-pass" will contain the instance number of the most recent AMS that passed? Or is it the distance from the verifier to the most recent passing ADMD? -MSK --001a1146a0e49059730562009452 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jan 3, 2018 at 6:28 PM, Kurt Andersen (b) <kboth@d= rkurt.com> wrote:
On Wed, Jan 3, 20= 18 at 11:20 PM, Bron Gondwana <brong@fastmailteam.com> = wrote:
I assume this was the one that you wa= nted my clarification on?

Yes, thanks
=C2=A0
But let's rewrite it as oldest-p= ass, because that's clearer.=C2=A0 Your case:

* ARC 1: cv=3Dnone, ams.oldest-pass=3D0
* ARC 2: cv=3Dpass, ams.oldest-pass=3D1
* ARC 3: cv=3Dpass, ams.oldest-pass=3D2
* ARC 4: cv=3Dpass, ams.oldest-pass=3D3
* final recipient ADMD ARC verifier would find cv=3Dpass and evaluate = ams.oldest-pass as 4.

And my case where 2 and 3 didn't chang= e anything:

* ARC 1: cv=3Dnone, ams.oldest-pass=3D0
=
* ARC 2: cv=3Dpass, ams.oldest-pass=3D1
* ARC 3: cv=3Dpass, ams.oldest-pass=3D1
* ARC 4: cv=3Dpass, ams.oldest-pass=3D1
* final recipient ADMD ARC verifier would find cv=3Dpass and evaluate = ams.oldest-pass as 4.

From which the final recipient can also se= e that, if they trust ARC 4 not to lie, neither ARC 2 or ARC 3 changed anyt= hing which was covered by ARC 1's AMS.

There is no need to trust either ARC 2 or = ARC 3's signatures in my example, which is the point here.=C2=A0 Even i= f ARC 2 or ARC 3 are not yet known or trusted, you can tell that they didn&= #39;t modify this particular message.

Very helpful - thanks. I think that= expressing it in the positive "oldest-pass" form makes the point= much clearer. Unless there is an outcry from the rest of the group, I'= d like to change to this terminology.

Just to be clear, we're saying "*.oldest-pass" will co= ntain the instance number of the most recent AMS that passed?=C2=A0 Or is i= t the distance from the verifier to the most recent passing ADMD?

-MSK
--001a1146a0e49059730562009452-- From nobody Thu Jan 4 22:52: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 77780126C2F for ; Thu, 4 Jan 2018 22:52:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 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, 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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=jRqRiZ6u; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Hf5F2boj 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 K6xMYbwENCVu for ; Thu, 4 Jan 2018 22:52:51 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3F5C120454 for ; Thu, 4 Jan 2018 22:52:51 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id BEF3C20DE9 for ; Fri, 5 Jan 2018 01:52:50 -0500 (EST) Received: from web6 ([10.202.2.216]) by compute6.internal (MEProxy); Fri, 05 Jan 2018 01:52:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=rqZwsum8Tl/De7oEU yTUViCQWvDI5YQXwRog7toaacE=; b=jRqRiZ6udzFnBIywCl0rQLucWlhYpC6t6 0MWzpFmmj2rE13c5FjldCtO3E+1mLORVpTzZC9ga2oksCdcX4/eJ2Tu7tMHEsBgq Yp6zWjZaHvlWOxY6dhzM+teymVzvvaFoVjrBgW86BYm4ZraFKA+lDzMtY08h8Dgy b7WXKkGB1GPgLKUp/WHP5nDS5wbhzBL0tFQw4nAma7Za3IpAzQOhuArPJVyT9x3B PcAvedjiAHlDWmF956cF3YhL+nWuoNRGT0OzbAeTcfPrg8+vscklW7WcAZBw7xUu 0MwMWTAXdxPBP4/eggfvHKWZDSA+cNV8aa7Q6F2QEeU384IjYRVAA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=rqZwsu m8Tl/De7oEUyTUViCQWvDI5YQXwRog7toaacE=; b=Hf5F2boj5GhGq7oz//cvkt mIZvJR2ns2Vzz8GqzaiJsZMkrMF6Tz1tqrTW2CdMTc88Z/NzhTIVoVzFzEFgzfmV TtQm8gCQ4+r4eEN1EGOQYQprMmmXR93ImsdS5+I7AHQzanU/ZQVDPGkZ3G2fLReb fBJuNOtaCvjQv5dv0VB33X2QGkBb8/ezFKOpT8b+Dcd0EqbOsKtqKhSaqDqwmmXx dEEw3NFvh7SyCk3SOa7CfzIPN8R8NntNYrxXoBqkM7F397iAYAMXxjrhdzU1iDEp ShKRDpY9a6d2n1It9fNXVcBK3ycxwAv53rw+rxR+WH22WJO+4LwNRRSUUAbabv8A == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 5E9A0425A; Fri, 5 Jan 2018 01:52:50 -0500 (EST) Message-Id: <1515135170.791502.1224976560.5E5B35AA@webmail.messagingengine.com> From: Bron Gondwana To: dmarc@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15151351707915022" X-Mailer: MessagingEngine.com Webmail Interface - ajax-1d83f2c7 In-Reply-To: Date: Fri, 05 Jan 2018 17:52:50 +1100 References: <1514939995.3318165.1222346488.5B169072@webmail.messagingengine.com> <1515021640.3106167.1223502368.3DB28018@webmail.messagingengine.com> Archived-At: Subject: Re: [dmarc-ietf] Clarifying the value of arc.closest-fail 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, 05 Jan 2018 06:52:53 -0000 This is a multi-part message in MIME format. --_----------=_15151351707915022 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Instance number please. Less calculation. On Fri, 5 Jan 2018, at 16:18, Murray S. Kucherawy wrote: > On Wed, Jan 3, 2018 at 6:28 PM, Kurt Andersen (b) > wrote:>> On Wed, Jan 3, 2018 at 11:20 PM, Bron Gondwana >> wrote:>>> __ >>> I assume this was the one that you wanted my clarification on? >> >> >> Yes, thanks >> >> >>> >>> >>> But let's rewrite it as oldest-pass, because that's clearer. >>> Your case:>>> >>> >>> * ARC 1: cv=none, ams.oldest-pass=0 >>> * ARC 2: cv=pass, ams.oldest-pass=1 >>> * ARC 3: cv=pass, ams.oldest-pass=2 >>> * ARC 4: cv=pass, ams.oldest-pass=3 >>> * final recipient ADMD ARC verifier would find cv=pass and evaluate >>> ams.oldest-pass as 4.>>> >>> And my case where 2 and 3 didn't change anything: >>> >>> * ARC 1: cv=none, ams.oldest-pass=0 >>> * ARC 2: cv=pass, ams.oldest-pass=1 >>> * ARC 3: cv=pass, ams.oldest-pass=1 >>> * ARC 4: cv=pass, ams.oldest-pass=1 >>> * final recipient ADMD ARC verifier would find cv=pass and evaluate >>> ams.oldest-pass as 4.>>> >>> From which the final recipient can also see that, if they trust ARC >>> 4 not to lie, neither ARC 2 or ARC 3 changed anything which was >>> covered by ARC 1's AMS.>>> >>> There is no need to trust either ARC 2 or ARC 3's signatures in my >>> example, which is the point here. Even if ARC 2 or ARC 3 are not >>> yet known or trusted, you can tell that they didn't modify this >>> particular message.>>> >>> >>> >> >> Very helpful - thanks. I think that expressing it in the positive "oldest- >> pass" form makes the point much clearer. Unless there is an outcry >> from the rest of the group, I'd like to change to this terminology.> > Just to be clear, we're saying "*.oldest-pass" will contain the > instance number of the most recent AMS that passed? Or is it the > distance from the verifier to the most recent passing ADMD?> > -MSK > _________________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_15151351707915022 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
Instance number please.  Less calculation.


On Fri, 5 Jan 2018, at 16:18, Murray S. Kucherawy wrote:
On Wed, Jan 3, 2018 at 6:28 PM, Kurt Andersen (b) <kboth@drkurt.com> wrote:
On Wed, Jan 3, 2018 at 11:20 PM, Bron Gondwana <brong@fastmailteam.com> wrote:

I assume this was the one that you wanted my clarification on?


Yes, thanks

 


But let's rewrite it as oldest-pass, because that's clearer.  Your case:


* ARC 1: cv=none, ams.oldest-pass=0
* ARC 2: cv=pass, ams.oldest-pass=1
* ARC 3: cv=pass, ams.oldest-pass=2
* ARC 4: cv=pass, ams.oldest-pass=3
* final recipient ADMD ARC verifier would find cv=pass and evaluate ams.oldest-pass as 4.

And my case where 2 and 3 didn't change anything:

* ARC 1: cv=none, ams.oldest-pass=0
* ARC 2: cv=pass, ams.oldest-pass=1
* ARC 3: cv=pass, ams.oldest-pass=1
* ARC 4: cv=pass, ams.oldest-pass=1
* final recipient ADMD ARC verifier would find cv=pass and evaluate ams.oldest-pass as 4.

From which the final recipient can also see that, if they trust ARC 4 not to lie, neither ARC 2 or ARC 3 changed anything which was covered by ARC 1's AMS.

There is no need to trust either ARC 2 or ARC 3's signatures in my example, which is the point here.  Even if ARC 2 or ARC 3 are not yet known or trusted, you can tell that they didn't modify this particular message.




Very helpful - thanks. I think that expressing it in the positive "oldest-pass" form makes the point much clearer. Unless there is an outcry from the rest of the group, I'd like to change to this terminology.

Just to be clear, we're saying "*.oldest-pass" will contain the instance number of the most recent AMS that passed?  Or is it the distance from the verifier to the most recent passing ADMD?

-MSK
_______________________________________________
dmarc mailing list

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com

--_----------=_15151351707915022-- From nobody Fri Jan 5 08:18: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 B36B312704A for ; Fri, 5 Jan 2018 08:18:20 -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 KsQDNj3xz8xO for ; Fri, 5 Jan 2018 08:18:19 -0800 (PST) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB75B126C0F for ; Fri, 5 Jan 2018 08:18:18 -0800 (PST) Received: by mail-lf0-x22a.google.com with SMTP id h5so5676827lfj.2 for ; Fri, 05 Jan 2018 08:18:18 -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=3RDmD5TcqBvX1gBW63jDhLhnzJgGnEfRCRwwaEE05K8=; b=Jv6ssr6bPUBJbSd2+nWmyOY1Wk2yxQ+MV34vBNdeaglehpC0NxdXqI7Mnx/0uBw0sC H8tW4iL+BgTaYUmGGEHXIPoc6Ot0Mc63BVgRNv+sU00T559xukWAR3WMMT0AS0tXUpSg ldvI3gMV3yAq6VvE94NAR1U/lK2Bf8+meVxzs= 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=3RDmD5TcqBvX1gBW63jDhLhnzJgGnEfRCRwwaEE05K8=; b=JIR2MUCK4i+UC4pC3g7o1mfSF4wkgH54MCbJDJZgptRPXE+aaRGIIRfg7Y/ZvsqBvH FC2CiKchbLCP5ZxdRQRruvOAxCYawnG+9kQc3La4LZMTCVPmupWHUiQ0/IeyGyqSpY3h 3Gurd8mlpSSBIBjavFal5cCaAcBJQR2OiARrxya3dgmmoXHITu9zcxN9N5zYaAsMw//r VEwJYo+xzir0K7tpIefIVdZa4weafqIpX27csgCVMqhzZoXeVei0PczRMig0vLHnClfr vodKWWNLqdyiYctWAIOVNPmQNjKhKySDK+pFoIlhTJQg7eoKCQ3jnDjL6+4lkcsaqCtZ CaWw== X-Gm-Message-State: AKwxyte6ptQ0d29OkbJ6ZzoSPN6cJqbOkGkZix0ijGiRIutb3e9xIQZQ fRZT6zXlI9Q2YkpTPcarxzFJ/Imp8Py+e1oVRJirbJ2o X-Google-Smtp-Source: ACJfBouFiMAog5YeFZY9fKWZaiXfYZj2N3/f/IWmvOK9jsVCNkXHg/VogB/ColBqUyyD+QbScgwFIRnNR4AURInaI3I= X-Received: by 10.25.219.198 with SMTP id t67mr1871794lfi.65.1515169097105; Fri, 05 Jan 2018 08:18:17 -0800 (PST) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.25.56.11 with HTTP; Fri, 5 Jan 2018 08:18:16 -0800 (PST) In-Reply-To: <1515135170.791502.1224976560.5E5B35AA@webmail.messagingengine.com> References: <1514939995.3318165.1222346488.5B169072@webmail.messagingengine.com> <1515021640.3106167.1223502368.3DB28018@webmail.messagingengine.com> <1515135170.791502.1224976560.5E5B35AA@webmail.messagingengine.com> From: "Kurt Andersen (b)" Date: Fri, 5 Jan 2018 16:18:16 +0000 X-Google-Sender-Auth: bNEWXObLs1vZbB08j3k9cSel2Lk Message-ID: To: Bron Gondwana Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0663b6cedaf3056209cb00" Archived-At: Subject: Re: [dmarc-ietf] Clarifying the value of arc.closest-fail 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, 05 Jan 2018 16:18:20 -0000 --94eb2c0663b6cedaf3056209cb00 Content-Type: text/plain; charset="UTF-8" On Fri, Jan 5, 2018 at 6:52 AM, Bron Gondwana wrote: > Instance number please. Less calculation. > Agreed. --94eb2c0663b6cedaf3056209cb00 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Jan 5, 2018 at 6:52 AM, Bron Gondwana <brong@fastmailteam.com= > wrote:
Instance number please.=C2=A0 Less ca= lculation.

Agreed.=C2=A0
<= /div>
--94eb2c0663b6cedaf3056209cb00-- From nobody Thu Jan 18 23:14:13 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 70D6D1201F2 for ; Thu, 18 Jan 2018 23:14:12 -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 45czp0i0FnTF for ; Thu, 18 Jan 2018 23:14:10 -0800 (PST) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (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 D40591243F6 for ; Thu, 18 Jan 2018 23:14:09 -0800 (PST) Received: by mail-lf0-x22e.google.com with SMTP id x196so876682lfd.12 for ; Thu, 18 Jan 2018 23:14:09 -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=1+IEzEZL5od374maJ8Hlrp4qRJ6dZ360DzgKe+0iZzE=; b=T71YZvMtAntL0N65OqTIfud4zgPgx7x5S1jhtmy1/8CakVJRkYlPUrwpSlGhUjmN2x tYGSBV9THOjq7pTxfFMwBEnhua3oyA4k5bWE3rsuNbfqA3dJY6HgwPt5vw3FOFEkGywh x8FTpmzjU89QI4gAGqg9ns3dxe40vemB2CPxULmekwKJPgdr9KHSKPg2voNV/0johSxc qGRDOmQuMYfz1mbQG6u43tlhjWrK/0Ri59iJfr+8jWv+f1WB5ZMSpWHfJ1zvHr0lLPVN W7KVLQV9U3G1TGKWAu39oegZFXaWqkLKnHanDk2YdWH66ZMTDyURgB172RxxV1OsVAZq 7vnw== 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=1+IEzEZL5od374maJ8Hlrp4qRJ6dZ360DzgKe+0iZzE=; b=EzviN1WFZLDMRENAf0NbP0TdSHnkWTwbgxnXd/23tQuR6ku3brrA/E6HkNAh5LvJjX y5vUAASgo7ZdZ+wcVnWISjy1lKAh3cl+9mSRtie2b9jZv/X3gZzg7hgTi4aG81xV8AF4 OhuILv4m2q9jcNzulTL/CkoV7NQsqwWM6sSoKS6qL6fWuV2JPrguUB5dC+hqx/+dRqjy r1rNR1MXpayuMaPrCBLGSDAbLAgS/klgnmOPstCsu/c84egr3d7IXnKftoR8pg9qx/TO Oe6eNpLt8PUJ/21UiAjefYWkGvHQlgNhMKAXbCkEwKi7bpW+eoUelBTSPLZcUgaNRwxI 1yfA== X-Gm-Message-State: AKwxytcpa54T/MpchBBYo3fC/qAFySVVngy9+06loyYVBwFqRmwinDx4 6/C2OXY0OaRZ14Ln7OiRbQIegExgIb5u5y9YtuftrA== X-Google-Smtp-Source: ACJfBouppqjDgDBQZXhIPHws0Wd0Zhi4BPwuTC36J1NWlXPRJtAqtsaFzYiyTEP77j9jTa9hngfMN2PTmeArNG3U8jE= X-Received: by 10.25.79.8 with SMTP id d8mr2923001lfb.59.1516346047658; Thu, 18 Jan 2018 23:14:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.101.74 with HTTP; Thu, 18 Jan 2018 23:14:06 -0800 (PST) In-Reply-To: <151634590227.26703.10578026115669957075.idtracker@ietfa.amsl.com> References: <151634590227.26703.10578026115669957075.idtracker@ietfa.amsl.com> From: "Murray S. Kucherawy" Date: Thu, 18 Jan 2018 23:14:06 -0800 Message-ID: To: dmarc@ietf.org Content-Type: multipart/alternative; boundary="94eb2c1cd20c86fec805631bd3a4" Archived-At: Subject: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-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, 19 Jan 2018 07:14:12 -0000 --94eb2c1cd20c86fec805631bd3a4 Content-Type: text/plain; charset="UTF-8" As requested, I'm spinning up a revision effort of RFC7601 to accommodate ARC's needs. The first version is exactly the text of RFC7601. This is so that the IESG (and anyone else) can look at the differences between the -00 of this draft and the final version and see the full set of changes between the existing RFC and what we're proposing for the new one. -01 will be up soon, incorporating the suggested changes in prose and ABNF discussed previously on this list. -MSK ---------- Forwarded message ---------- From: Date: Thu, Jan 18, 2018 at 11:11 PM Subject: New Version Notification for draft-kucherawy-dmarc-rfc7601bis-00.txt To: "Murray S. Kucherawy" A new version of I-D, draft-kucherawy-dmarc-rfc7601bis-00.txt has been successfully submitted by Murray Kucherawy and posted to the IETF repository. Name: draft-kucherawy-dmarc-rfc7601bis Revision: 00 Title: Message Header Field for Indicating Message Authentication Status Document date: 2018-01-18 Group: Individual Submission Pages: 52 URL: https://www.ietf.org/internet-drafts/draft-kucherawy-dmarc- rfc7601bis-00.txt Status: https://datatracker.ietf.org/doc/draft-kucherawy-dmarc- rfc7601bis/ Htmlized: https://tools.ietf.org/html/draft-kucherawy-dmarc- rfc7601bis-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-kucherawy- dmarc-rfc7601bis-00 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. 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. The IETF Secretariat --94eb2c1cd20c86fec805631bd3a4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As requested, I'm spinning up a revisio= n effort of RFC7601 to accommodate ARC's needs.

The first = version is exactly the text of RFC7601.=C2=A0 This is so that the IESG (and= anyone else) can look at the differences between the -00 of this draft and= the final version and see the full set of changes between the existing RFC= and what we're proposing for the new one.

-01 will be up = soon, incorporating the suggested changes in prose and ABNF discussed previ= ously on this list.

-MSK

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Thu, Jan= 18, 2018 at 11:11 PM
Subject: New Version Notification for draft-kucher= awy-dmarc-rfc7601bis-00.txt
To: "Murray S. Kucherawy" <superuser@gmail.com>


<= br> A new version of I-D, draft-kucherawy-dmarc-rfc7601bis-00.txt
has been successfully submitted by Murray Kucherawy and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-kucherawy-dmarc-rf= c7601bis
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Message Header Field for Indicatin= g Message Authentication Status
Document date:=C2=A0 2018-01-18
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 52
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-kuche= rawy-dmarc-rfc7601bis-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-rfc= 7601bis/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0h= ttps://tools.ietf.org/html/draft-kucherawy-dmarc-rfc7601bis-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-kucherawy-dm= arc-rfc7601bis-00


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.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--94eb2c1cd20c86fec805631bd3a4-- From nobody Fri Jan 19 10:49: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 49CD3127023 for ; Fri, 19 Jan 2018 10:49: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4pWzwNe7keX0 for ; Fri, 19 Jan 2018 10:49:39 -0800 (PST) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::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 5987D1277BB for ; Fri, 19 Jan 2018 10:49:39 -0800 (PST) Received: by mail-pf0-x22f.google.com with SMTP id k19so2002351pfj.5 for ; Fri, 19 Jan 2018 10:49:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=lUNpwivpWpuGhHKkUTciw4ABZwKACHgK1Vbb9Vyb0dI=; b=LCo8tEWoKE1siSwFEr1zWxDyHvXU50ALdmRCPO9ef3Gw7KSSTY49oKSelJDDdbVaIc pkUIGnLogt65oP3NlU+9IgYdD16q9525zS0u0euVc51SJXTbwc/+o6vM/y5jKHaUWwLa g2iPHTeSUpLNcpuDQb9AeeF91xNEbGGr+anmIltIzQcW6GsXKyK7VveKSxvherXKoauz 9onmzMgzQGNZPrU55p4ejdOTiwlZALXstd8NP7vuM9EWq05ncvUPdCeJsZkB8odHNOPQ KLn4vmOVMbsuc+SDXF1G+q+z+7x0I1TA5/ys7pm+UoN1pqEJwEz/GbyZcct1Ex0b6q4Z yhgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=lUNpwivpWpuGhHKkUTciw4ABZwKACHgK1Vbb9Vyb0dI=; b=FIMhscDSnuSO1/blyslZ+PvJXyuQljYei1lfGyq28nHiQWO1WTctsZReYRJQUVftgj 8DHgUs6v4OY8R3INHTgXP8syrbxCVTUu2kdVeZpJnkhNQbTbSxzBcm8ZfPaTocygdnah gL85UIdRCk1eu/YXOUBDyWfbzv8zazJHBJbK3NpNxLTN8l+yzLlUEfOY6mIyyrUZ6pex 9oWWV+nQgEntATO+uekymub0k89N+ZkeHTbcJ0Fr9XGXQKaVbg3PQZTiP4Zo3PFHB9mD wTv06WqGMZ3W1fQ2ynWTQSTa8oFCmFFTbo/Q70g8yjFFCbit8DUuEcrAn6xMZ28TB4iF 7Sug== X-Gm-Message-State: AKwxytd+7Bl0UNkl7dbzwmZ50kzKIVcS3dxO3cZ7kB5TQLT6xNX/RT8y OiRS/0+L1fCrDr8t1GgKWD8KMV60 X-Google-Smtp-Source: ACJfBotteJVQvgPF4SPhvOn4ZQ7eC+bkTDnoZTNxJVFfm+HzPQ+bxZVVv9FNu8MiUUpNz/2akF1sAQ== X-Received: by 10.98.46.2 with SMTP id u2mr23687079pfu.30.1516387778186; Fri, 19 Jan 2018 10:49:38 -0800 (PST) Received: from ?IPv6:2600:1700:a3a0:870:90d8:16b0:8b28:c02a? ([2600:1700:a3a0:870:90d8:16b0:8b28:c02a]) by smtp.gmail.com with ESMTPSA id y131sm19090744pfg.69.2018.01.19.10.49.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Jan 2018 10:49:36 -0800 (PST) To: "Murray S. Kucherawy" References: <151634590227.26703.10578026115669957075.idtracker@ietfa.amsl.com> Cc: dmarc@ietf.org From: Dave Crocker Message-ID: <4e00e9f7-9996-c90b-bb92-f54bb3c042c9@gmail.com> Date: Fri, 19 Jan 2018 10:49:34 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-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, 19 Jan 2018 18:49:42 -0000 On 1/18/2018 11:14 PM, Murray S. Kucherawy wrote: > -01 will be up soon, incorporating the suggested changes in prose and > ABNF discussed previously on this list. If I missed this, I apologize, but would it be possible to post a message which summarizes the nature/goals of the changes that are planned? I'm not challenging the work, but just wanting to make sure the wg is in synch about how the doc should be adjusted. Thanks. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Jan 19 13:41:43 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 96F3812D835 for ; Fri, 19 Jan 2018 13:41:41 -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 jGwq9q6Ufw5L for ; Fri, 19 Jan 2018 13:41:37 -0800 (PST) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C11D91201F2 for ; Fri, 19 Jan 2018 13:41:36 -0800 (PST) Received: by mail-lf0-x22a.google.com with SMTP id h92so3713224lfi.7 for ; Fri, 19 Jan 2018 13:41:36 -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=R4eYaEMgcMR6Bm8o0cYwoXHj6kS1o7HteX+cg2xk3f0=; b=KyiApd15vQKo6EPukjYYDsgk15mUbCkmKlF/DMhqaKuftqYAXVqeo6kB7RvgjZJ91g 1naOUEUmtqh+O4jE21ZRKUAeCiLcQageSlkr4sR9vPQzKQCxqjflJIT6rMqePQE+FTp4 j8O4pA7K5752dumT1UtpgtuPRvdnctIeDb6P0= 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=R4eYaEMgcMR6Bm8o0cYwoXHj6kS1o7HteX+cg2xk3f0=; b=qlIRIfx3nzStquHJ21IE6E54cjggLTL9VKfTx9jg2LpnGJ6F4D99zfkJkkScTMgfVw TiP9uFtwNtLR3djGEmMyzBO9kys7aRchWBITcZAqK3y9MXVTJR3DcwGHmXNi8JslCdXU G4FsWPacxNzfpY7CNgUdNuG0u3mUaHm/+nYAGAT3fRKsXL220umnJ4BArvWz2edyC0vk yvv7UFiGDgwDSVCy1OnSMzAWl6/N3VlxolV7+x5Ffn5xmPTpBYi4V4FWZ9CusnFL/C5c 9jHNG1t6BhgI6dhISIw/4zADlT0qPUC8ioTvUxIlXhM21emMQuwq6eC1zek4b/AUde1J E6Cw== X-Gm-Message-State: AKwxytdPikiVMioACL2zA+XIrUaeBvSJebzvNMFyAy2rk7KgPGIWkwg+ rSBRqrDIqrOQfPZjOk+qMCJKlm3v1YRPZZ9eO7kqCyF/cGs= X-Google-Smtp-Source: ACJfBosQgsP5XscHDRmeQLlHnuPv5SsOKcnRJFFQLHAJ9Wh7Y2D0tSBr9t99/c6+YTu3AJnEsAfexHD/HGwtGtZKe0I= X-Received: by 10.25.109.10 with SMTP id i10mr24868038lfc.54.1516398094808; Fri, 19 Jan 2018 13:41:34 -0800 (PST) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.25.193.138 with HTTP; Fri, 19 Jan 2018 13:41:33 -0800 (PST) In-Reply-To: <4e00e9f7-9996-c90b-bb92-f54bb3c042c9@gmail.com> References: <151634590227.26703.10578026115669957075.idtracker@ietfa.amsl.com> <4e00e9f7-9996-c90b-bb92-f54bb3c042c9@gmail.com> From: "Kurt Andersen (b)" Date: Fri, 19 Jan 2018 13:41:33 -0800 X-Google-Sender-Auth: mSicQr5U-G8Srt3--1-V5409MQ0 Message-ID: To: Dave Crocker Cc: "Murray S. Kucherawy" , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="089e082f57fcc79211056327f167" Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-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, 19 Jan 2018 21:41:42 -0000 --089e082f57fcc79211056327f167 Content-Type: text/plain; charset="UTF-8" On Fri, Jan 19, 2018 at 10:49 AM, Dave Crocker wrote: > On 1/18/2018 11:14 PM, Murray S. Kucherawy wrote: > >> -01 will be up soon, incorporating the suggested changes in prose and >> ABNF discussed previously on this list. >> > > > If I missed this, I apologize, but would it be possible to post a message > which summarizes the nature/goals of the changes that are planned? > > I'm not challenging the work, but just wanting to make sure the wg is in > synch about how the doc should be adjusted. > > Thanks. > > d/ The intent is outlined in high level within the -10 version (section 5.2) of the protocol doc. The better explanation is in Seth's email from September ( https://mailarchive.ietf.org/arch/msg/dmarc/xUUbT15vqoBmH7RraJ_pesrd9z0): 1) The optimal ABNF for AAR would inherit the A-R payload ABNF from 7601. Unfortunately, authres-header was defined in a way that makes this difficult. Is there a better way to say that the AAR inherits the A-R payload, and if anything modifies the definition of authres-header in 7601, the AAR also needs to inherit this change? To be super specific, this is the current authres-header ABNF from 7601: authres-header = "Authentication-Results:" [CFWS] authserv-id [ CFWS authres-version ] ( no-result / 1*resinfo ) [CFWS] CRLF Optimally, there would be: authres-payload = [CFWS] authserv-id [ CFWS authres-version ] ( no-result / 1*resinfo ) [CFWS] CRLF And then we could have: arc-authres-header = "ARC-Authentication-Results:" [CFWS] arc-info authres-payload --Kurt --089e082f57fcc79211056327f167 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jan 19, 2018 at 10:49 AM, Dave Crocker=C2=A0<= span dir=3D"ltr"><dcrocker@gmail.com>=C2=A0wrote:
On 1/18/2018 11:14 PM, Murray S. Kucherawy wrote:
-01 will be up soon, incorporating the= suggested changes in prose and ABNF discussed previously on this list.
=


If I missed this, I apologize, but would it be = possible to post a message which summarizes the nature/goals of the changes= that are planned?

I'm not challenging the work, but just wantin= g to make sure the wg is in synch about how the doc should be adjusted.
=
Thanks.

d/
=C2=A0
The intent is outlined in high level within the -10 version (section 5.2)= of the protocol doc. The better explanation is in Seth's email from Se= ptember (https://mailarchive.ietf.org/arch/msg/dmarc/xUUbT15vqoBmH7Rr= aJ_pesrd9z0):

1) The opt= imal ABNF for AAR would inherit the A-R payload ABNF from 7601. Unfortunate= ly,=C2=A0authres-header=C2=A0<= wbr>was defined in a way that makes this difficult. Is there a better way t= o say that the AAR inherits the A-R payload, and if anything modifies the d= efinition of=C2=A0auth= res-header=C2=A0in 7601, the AAR also needs to inherit this change?

To be super specific, this is the current=C2=A0authres-header=C2=A0ABNF from 7601:
=

=C2=A0 =C2=A0 =C2=A0authres-header=C2=A0=3D "Authentication-Results:" [CFWS= ] authserv-id
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [ CFWS=C2=A0authres-version ]
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 ( no-result / 1*resinfo ) [CFWS] CRLF

Optimally, there would be:

= =C2=A0 =C2=A0 =C2=A0au= thres-payload =3D [CFWS]=C2=A0authserv-id
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 [ CFWS=C2=A0aut= hres-version ]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ( no-result / 1*resi= nfo ) [CFWS] CRLF

And then we co= uld have:

<= div>
=C2=A0 =C2=A0arc-authres-header=C2=A0=3D "ARC-Authentication-Res= ults:" [CFWS] arc-info=C2=A0authres-payload

--Kurt
--089e082f57fcc79211056327f167-- From nobody Fri Jan 19 15:06:32 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 D891512D876 for ; Fri, 19 Jan 2018 15:06:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.761 X-Spam-Level: X-Spam-Status: No, score=-1.761 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.25, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=zoQhl+PI; dkim=pass (1536-bit key) header.d=taugh.com header.b=r20M3NJQ 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 4bXC9ca7vf67 for ; Fri, 19 Jan 2018 15:06:30 -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 B36AA12420B for ; Fri, 19 Jan 2018 15:06:30 -0800 (PST) Received: (qmail 7219 invoked from network); 19 Jan 2018 23:06:29 -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=1c30.5a6279f5.k1801; bh=Ht/skOHaEXcOiRCD4n5Lvw5Yms3ldbHCsSOAOD149aI=; b=zoQhl+PIP/CXGgxlwwJSexbW3Zh6qiZvtYsTITkZq7SQ00RZf0VaeyhrHEGNKxq7ZmVizFdFkP/RM6k63mfIrTSnwV7fkZwbDWCxj7jUTtzzWl3qM76bbnpKOjNYOTo/q2imlmCr3Zm3kJY4uFdj+1yIzvnci7Im71i3wYTHR9RdhX+4mRGXbbuieMhwoTYyGIY3U1NWAs8O01Y8BOrDF8QVbjP24fX5fKioWEKOhuYBbSasutX5Qh4nzleGO5AD 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=1c30.5a6279f5.k1801; bh=Ht/skOHaEXcOiRCD4n5Lvw5Yms3ldbHCsSOAOD149aI=; b=r20M3NJQup0g/v37I4bh/2Cid+l871XRV9sHR8ozq2L/mN4qsTiokZvLssuSd8Zkwoxbs+K6Yq9xZyzpt3TTPBNKFNg66FBev+QzxvRCrU73Bze6vTiaWJUyrSZIrQz83OlLW1tXXMAresdgX+Xfmj0YYIFkufSloOSl0h2pzzFLFB6UACxi2ktUuoV0mtMiAbf7HDhdg4NWiJjWWHDBBsGWQmN2yb2VJwHKqyvp/4ojWrUQhkcKr9GvybuYKQ4T 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; 19 Jan 2018 23:06:29 -0000 Received: by ary.qy (Postfix, from userid 501) id 2CA691950C4A; Fri, 19 Jan 2018 18:06:27 -0500 (EST) Date: 19 Jan 2018 18:06:27 -0500 Message-Id: <20180119230629.2CA691950C4A@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: kboth@drkurt.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] Fwd: New Version Notification for draft-kucherawy-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, 19 Jan 2018 23:06:32 -0000 If I may budge in here, any chance we could put in a few tweaks for EAI mail? I think the main changes would be that if the A-R or AAR header is in an EAI message, domain names and local parts can be UTF-8 rather than ASCII. I specifically do not want to change any of the keywords or codes, since they're for software, not for people. I realize that we should update RFC 6376 at the same time for DKIM signatures, but I'll take what I can get. R's, John From nobody Fri Jan 19 16:11: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 1B6D2129C6F for ; Fri, 19 Jan 2018 16:11:37 -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 P-swk6-qQJCO for ; Fri, 19 Jan 2018 16:11:35 -0800 (PST) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA1EF126C0F for ; Fri, 19 Jan 2018 16:11:22 -0800 (PST) Received: by mail-vk0-x229.google.com with SMTP id v70so1940334vkd.8 for ; Fri, 19 Jan 2018 16:11:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=VboJJpdKf7v9R1SqbPVgnm6vtmZjonWyRTwLYcPyOe4=; b=b1xGhwV2Lp0Buc0wSrP0w9Et8/CZRnelHelGKyxUzOb9cnOBXbBtAINoEnP2WGUQ4G zI9ppQXA/AcxCB3AtTbU+btesUnP/DmDgGfvNzpCFjxJdiDpuV0uFpEjgJXcsGY0yZqd PpntNLfuyLFOjjZKuA02KZtYkBC8lJAQFejVP1Sk60fDqjKXOCjkD77sa+NbWVBH7yDr rfxXXPoOty4p0yf9UpvFH9Jd+5rLS525Hj6VaImbdvmuwTruyRWHWrYcDpSc0+1KReHf 9mGPGbhi5b1tzSoXkGdYwFYs+PQNIl11DZY+QI/PTKBG+Z6x5PhaeL8R/EA+tWygdldU JNpQ== 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=VboJJpdKf7v9R1SqbPVgnm6vtmZjonWyRTwLYcPyOe4=; b=Qz0lyxrtmQgV2ml/AlXl3vTygPPwnNQCceFNVmuHkiXGjvjjok8DvGpBzkCM+NHUy1 f0QPFYCUFgraM120v54ZUF58awkeW86NpNLHVYmyPqeXiv89129rtbAuQYq9PJIpoS92 w/uCzxsKGHzCHq+y7DFlK8wHaFB8LJiUgp+RxKGwpmY6mgEB9Lu2Kire+y0eSnRvWaxf tizCQ/CaZnmxZ1wJXM6Q2JCMkoqGJ1RqrAgK7/OgTlCjs5++Ra9RLobyQqj8kFATL5WD Mlnw9E0Tv9WAxaFsGfgHwx6PENljq7mDjsnHhKWRzW0nr2V80mWnifRF+6UyR1a4bDoZ /Vkg== X-Gm-Message-State: AKwxyteFk4mHRwzQ2jSsYNPaQMXYlt07VB9l/uo7nv/ehFshDVMDmHe5 B8EK73/QUD1U+1uZsD+Fy/4XpHBDTOLGOCXTKivh3u5d X-Google-Smtp-Source: AH8x226SHz0Ryo1WGhn0bPGGYd8lp8SdD28vdUja8L8LzhfJMRCcw1mLWWk4PlPVMtfSVf6kG/fOGaYsGQQsejx7aTU= X-Received: by 10.31.213.7 with SMTP id m7mr157615vkg.44.1516407081261; Fri, 19 Jan 2018 16:11:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.37.173 with HTTP; Fri, 19 Jan 2018 16:11:00 -0800 (PST) In-Reply-To: References: <151634590227.26703.10578026115669957075.idtracker@ietfa.amsl.com> <4e00e9f7-9996-c90b-bb92-f54bb3c042c9@gmail.com> From: Seth Blank Date: Fri, 19 Jan 2018 16:11:00 -0800 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c07aadc69f90905632a09e0" Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-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, 20 Jan 2018 00:11:49 -0000 --94eb2c07aadc69f90905632a09e0 Content-Type: text/plain; charset="UTF-8" On Fri, Jan 19, 2018 at 1:41 PM, Kurt Andersen (b) wrote: > If I missed this, I apologize, but would it be possible to post a message >> which summarizes the nature/goals of the changes that are planned? >> >> I'm not challenging the work, but just wanting to make sure the wg is in >> synch about how the doc should be adjusted. >> >> Thanks. >> > > The intent is outlined in high level within the -10 version (section 5.2) > of the protocol doc. The better explanation is in Seth's email from > September (https://mailarchive.ietf.org/arch/msg/dmarc/ > xUUbT15vqoBmH7RraJ_pesrd9z0): > > So to be really specific, those are the implications for the ARC draft post-7601bis, not the initial intent for 7601bis itself (which is tied closely, but distinct). The ARC impetus for an update to 7601 was twofold: 1) To allow for ARC information to be encoded in the A-R in a way that is allowed in the registry a) to keep the AAR definition crisp b) to avoid hacks like a header.ds tuple c) to allow all the information needed for a DMARC report to be properly stamped without resorting to shenanigans or a 4th header 2) To allow for authres ABNF to be inheritable Seth --94eb2c07aadc69f90905632a09e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Jan 19, 2018 at 1:41 PM, Kurt Andersen (b) <kboth@drkurt.com> wrote:
If I missed this, I= apologize, but would it be possible to post a message which summarizes the= nature/goals of the changes that are planned?

I'm not challengi= ng the work, but just wanting to make sure the wg is in synch about how the= doc should be adjusted.

Thanks.

The intent is outlined in high level withi= n the -10 version (section 5.2) of the protocol doc. The better explanation= is in Seth's email from September (https://mai= larchive.ietf.org/arch/msg/dmarc/xUUbT15vqoBmH7RraJ_pesrd9z0)= :


So to be real= ly specific, those are the implications for the ARC draft post-7601bis, not= the initial intent for 7601bis itself (which is tied closely, but distinct= ).

The ARC impetus for an update to 7601 was twofo= ld:
1) To allow for ARC information to be encoded in the A-R in a= way that is allowed in the registry
=C2=A0 =C2=A0 a) to keep the= AAR definition crisp
=C2=A0 =C2=A0 b) to avoid hacks like a head= er.ds tuple
=C2=A0 =C2=A0 c) to allow all the information needed = for a DMARC report to be properly stamped without resorting to shenanigans = or a 4th header
2) To allow for authres ABNF to be inheritable

Seth
--94eb2c07aadc69f90905632a09e0-- From nobody Fri Jan 19 19:49:28 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 9F77F12785F for ; Fri, 19 Jan 2018 19:49:26 -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 (1024-bit key) header.d=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbggVf9FcBma for ; Fri, 19 Jan 2018 19:49:23 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (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 5480312D7F1 for ; Fri, 19 Jan 2018 19:49:16 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QO1LKBH4FK005YHS@mauve.mrochek.com> for dmarc@ietf.org; Fri, 19 Jan 2018 19:44:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1516419853; bh=rrqfBaHYJP39OnCyWaanKhUKi10xRNQ6igkeWbErpm0=; h=From:Cc:Date:Subject:In-reply-to:References:To:From; b=fWJnWTr2LFSGAxgcAckrs/22I/VQOuocskNjY7i+P69X6sTJIsk2xjsTz9btdFMOC k+ve/rVIZwPfU/rimtOPYtfnFjMd7aUGwD+IFBSzr3ZmtyNGFY70UVECWCuZnBmxGi kKdTsZB5cAy16wHwKj+/kwiBzG5PaddfKMO0wib4= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QNWCG2JBHS000051@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for dmarc@ietf.org; Fri, 19 Jan 2018 19:44:10 -0800 (PST) From: ned+dmarc@mrochek.com Cc: Dave Crocker , "dmarc@ietf.org" , "Murray S. Kucherawy" Message-id: <01QO1LKA09X6000051@mauve.mrochek.com> Date: Fri, 19 Jan 2018 19:43:12 -0800 (PST) In-reply-to: "Your message dated Fri, 19 Jan 2018 13:41:33 -0800" References: <151634590227.26703.10578026115669957075.idtracker@ietfa.amsl.com> <4e00e9f7-9996-c90b-bb92-f54bb3c042c9@gmail.com> To: "Kurt Andersen (b)" Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-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, 20 Jan 2018 03:49:27 -0000 Given that this work is specificall for the benefit of DMARC/ARC, it makes sense to me to do the work on this list/in this group. Ned > On Fri, Jan 19, 2018 at 10:49 AM, Dave Crocker wrote: > > On 1/18/2018 11:14 PM, Murray S. Kucherawy wrote: > > > >> -01 will be up soon, incorporating the suggested changes in prose and > >> ABNF discussed previously on this list. > >> > > > > > > If I missed this, I apologize, but would it be possible to post a message > > which summarizes the nature/goals of the changes that are planned? > > > > I'm not challenging the work, but just wanting to make sure the wg is in > > synch about how the doc should be adjusted. > > > > Thanks. > > > > d/ > The intent is outlined in high level within the -10 version (section 5.2) > of the protocol doc. The better explanation is in Seth's email from > September ( > https://mailarchive.ietf.org/arch/msg/dmarc/xUUbT15vqoBmH7RraJ_pesrd9z0): > 1) The optimal ABNF for AAR would inherit the A-R payload ABNF from 7601. > Unfortunately, authres-header was defined in a way that makes this > difficult. Is there a better way to say that the AAR inherits the A-R > payload, and if anything modifies the definition of authres-header in 7601, > the AAR also needs to inherit this change? > To be super specific, this is the current authres-header ABNF from 7601: > authres-header = "Authentication-Results:" [CFWS] authserv-id > [ CFWS authres-version ] > ( no-result / 1*resinfo ) [CFWS] CRLF > Optimally, there would be: > authres-payload = [CFWS] authserv-id > [ CFWS authres-version ] > ( no-result / 1*resinfo ) [CFWS] CRLF > And then we could have: > arc-authres-header = "ARC-Authentication-Results:" [CFWS] arc-info > authres-payload > --Kurt From nobody Fri Jan 19 19:52:16 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 D60F712785F for ; Fri, 19 Jan 2018 19:52:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=iXg8SYJr; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=RsoDaSOW 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 8KQa0QhK05XS for ; Fri, 19 Jan 2018 19:52:12 -0800 (PST) Received: from news.winserver.com (news.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6281273B1 for ; Fri, 19 Jan 2018 19:52:11 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=623; t=1516420325; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=dW9GvYRg10PRQ0HaZ9TFeIzBSWw=; b=iXg8SYJreluDhjbgfr2thv63Koub6aH0X1Avlsr2kf6EPoUn0+tl9m9ASj1kax dy3FTy9oIPsDC8sb2Vu25Y133k6fyQZf4XeQVyQapXIRkgtxsC8mnmsFUfj5nWYY WDch0J2fhAI+/eOETRBtnTGFlf1CM9Jl2zt4srtMC9p00= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Fri, 19 Jan 2018 22:52:05 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 1994031833.1.2324; Fri, 19 Jan 2018 22:52:04 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=623; t=1516420067; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=SrfP5x7 j44vV4AcRq9gDeEvUVAY2TNtWbI++bKzblYI=; b=RsoDaSOWmWzT9RwNEDSlzN/ VnDQfMVVSdlbuEQLM2mJrpGaN67ASDDg6NVNrwDxJIhMxKsYJRRO55CPs9zTlSjg Eb7Txdu0PTIB6mGnUFBkFb0/gSUYYvtQ8/VZyjaSsZ/f3+lYH76UHplvEctBLipj HwmLsHu3LjgVbWArnDZE= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Fri, 19 Jan 2018 22:47:47 -0500 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 1993939783.9.408220; Fri, 19 Jan 2018 22:47:45 -0500 Message-ID: <5A62BCE7.7040101@isdg.net> Date: Fri, 19 Jan 2018 22:52:07 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <151634590227.26703.10578026115669957075.idtracker@ietfa.amsl.com> <4e00e9f7-9996-c90b-bb92-f54bb3c042c9@gmail.com> In-Reply-To: <4e00e9f7-9996-c90b-bb92-f54bb3c042c9@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-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, 20 Jan 2018 03:52:14 -0000 On 1/19/2018 1:49 PM, Dave Crocker wrote: > On 1/18/2018 11:14 PM, Murray S. Kucherawy wrote: >> -01 will be up soon, incorporating the suggested changes in prose >> and ABNF discussed previously on this list. > > > If I missed this, I apologize, but would it be possible to post a > message which summarizes the nature/goals of the changes that are > planned? +1 > I'm not challenging the work, but just wanting to make sure the wg is > in synch about how the doc should be adjusted. > > Thanks. If this is done, then shouldn't the ARC proposal be standard track rather than experimental? -- HLS From nobody Fri Jan 19 20:19:12 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 F423612D7EE for ; Fri, 19 Jan 2018 20:19:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=linkedin.com header.b=LIQa5c1U; dkim=pass (1024-bit key) header.d=microsoft.onmicrosoft.com header.b=JMjDHTO4 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 nMdMOyvo31LV for ; Fri, 19 Jan 2018 20:19:09 -0800 (PST) Received: from mail522.linkedin.com (mail522.linkedin.com [108.174.6.122]) (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 9313012D77E for ; Fri, 19 Jan 2018 20:19:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; s=proddkim1024; t=1516421948; bh=BS8Yo7FNh1XLzHAJ6EwAT4jEf+u3IpuvdkGBpodGsSY=; h=From:To:Subject:Date:Content-Type:MIME-Version; b=LIQa5c1UHtjNVEJbaMoE/VOZ3iOEGlxl5hTka9v+eoDkY9D0bvgGZ24I1tX8ImSGt 9e8QsrmgBLexOgomhb4gcYncyT/BZnrc+hx3RjGUwACD2jwAYci9igVSKgyiYt6sZg NZEkvPxAP6msiDw7tbh2RaFsxn73lyJZcp1/ceCo= Authentication-Results: mail522.prod.linkedin.com x-tls.subject="/C=US/ST=WA/L=Redmond/O=Microsoft Corporation/OU=Microsoft Corporation/CN=mail.protection.outlook.com"; auth=pass (cipher=ECDHE-RSA-AES256-SHA384) Authentication-Results: mail522.prod.linkedin.com; iprev=pass policy.iprev="207.46.163.85"; spf=softfail smtp.mailfrom="kandersen@linkedin.com" smtp.helo="nam02-bl2-obe.outbound.protection.outlook.com"; dkim=pass header.d=microsoft.onmicrosoft.com; tls=pass (verified) key.ciphersuite="TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384" key.length="256" tls.v="tlsv1.2" cert.client="C=US,ST=WA,L=Redmond,O=Microsoft Corporation,OU=Microsoft Corporation,CN=mail.protection.outlook.com" cert.clientissuer="C=US,ST=Washington,L=Redmond,O=Microsoft Corporation,OU=Microsoft IT,CN=Microsoft IT TLS CA 4" Received: from [207.46.163.85] ([207.46.163.85:34574] helo=NAM02-BL2-obe.outbound.protection.outlook.com) by mail522.prod.linkedin.com (envelope-from ) (ecelerity 3.6.21.53563 r(Core:3.6.21.0)) with ESMTPS (cipher=ECDHE-RSA-AES256-SHA384 subject="/C=US/ST=WA/L=Redmond/O=Microsoft Corporation/OU=Microsoft Corporation/CN=mail.protection.outlook.com") id 40/33-19995-C33C26A5; Sat, 20 Jan 2018 04:19:08 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.onmicrosoft.com; s=selector1-microsoft-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=BS8Yo7FNh1XLzHAJ6EwAT4jEf+u3IpuvdkGBpodGsSY=; b=JMjDHTO4AJb7drcrk8vILMexHVIMex96j9mWLgx47uCuukqtGBkHwzgemuhjBA11Yn1oWRIyX+dayOBCr156E6ARxMYOxq5HmHom3JfxRobeTTF+E4KgkMGz7EfCLuPeAtkEpazHapjZD6SFMqQ+6Wub4/UNYGcAJ8XgChLWWM0= Received: from DM5PR21MB0826.namprd21.prod.outlook.com (10.173.172.8) by DM5PR21MB0763.namprd21.prod.outlook.com (10.173.172.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.444.7; Sat, 20 Jan 2018 04:19:07 +0000 Received: from DM5PR21MB0826.namprd21.prod.outlook.com ([fe80::20f4:bb6b:bbb6:8c4f]) by DM5PR21MB0826.namprd21.prod.outlook.com ([fe80::20f4:bb6b:bbb6:8c4f%2]) with mapi id 15.20.0444.004; Sat, 20 Jan 2018 04:19:07 +0000 From: Kurt Andersen To: Hector Santos CC: "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dmarc-rfc7601bis-00.txt Thread-Index: AQHTkaXQe4qh2fm4g06kQfjv9ylkmQ== Date: Sat, 20 Jan 2018 04:19:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2600:100f:b114:c4db:8f22:d65b:1823:7480] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR21MB0763; 6:Hg0lbIgvMxFwuOf65ZeRidyK/ZkI2ZLkjDntSYXqIEpUWZU0smwK/dkG9+WLEWwGE4lqjuNMVJYNr2ZpxqkYyIqmaySVJNBz17PKoKA0qEaL8WH6v6Fjx1NUSBkSzmu24oqQng4qgpce7T2LXtEzq3FbmoJOidm/Y53uGsnciL7Q2j2Oi8iMN1USp1fZDicdKUMik3RroTMd6OXHiv8nuYMry+2rQGuHa1To0qUvVOHVHhQYnzR/05fCGxraNSc2cYH/QNfxJyNICVOdvAAqppiGIg5ca7UYmTjgmOQoOB/7H0UbrkuQeQqZDaebmAB1KUL2xEUrPH+6sidMIe4YIVZkg/GjZPpqgealkByZt07pbTH/p/IS6t08HuuScpIH; 5:12L4APc3AeVS9okGH8thD+1fQGLzBUq+l05jQ3EB3gNMC5PfzBtgtFkF1sUJxhl8uxIvyolpVPRhraKivHlLfvByUo0x/wOO0FODMPwzeCR30fJhhCpK1xMhcfmdoRDAsIByhCiTxhyoIfNczX2bcHOB7X66QDtlFEK4Zs6QWtQ=; 24:xBSlSpJHGq87yMDDFewoprZGHUk9qk51osalW/i3HRtXqWqoDoG8Ny8dHXd1QSpJVUJxSJ+03u6c+A59iJ1QcxWhwKGD2CjYMPbcdbW8om4=; 7:BIZ/uV5coJm09e+mFFEd8BD2+1mqs5BJjB6xVe55QZilfzHwOGl4gnXxet2VT4x7NbO700N0sa4S1rS5rfXjAtUT7MoteZb1SsLpQHLPoi+6tBDOxxg9XHsdiz7xD2bUjUYGC3HAo/nwfwLxBhZEupnKZ2uyinGLO89ICVPXUYxhiJHbdeccNP76iyJTPe5nDATsFFuxD7Nu1sowEEkbYf0NFm3PkCfFxYb3YJOyZ80lTT0L6ibXTuA4WFHPi5UZ x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: b66cce10-2dfb-4c69-fc3e-08d55fbcf2ae x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534125)(4602075)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603307)(7193020); SRVR:DM5PR21MB0763; x-ms-traffictypediagnostic: DM5PR21MB0763: x-o365ent-eop-header: Message Processed By - CBR_LInkedIn_Mail_To_External x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040501)(2401047)(8121501046)(5005006)(3002001)(3231046)(2400081)(944501161)(10201501046)(93006095)(93001095)(6055026)(61426038)(61427038)(6041288)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(6072148)(201708071742011); SRVR:DM5PR21MB0763; BCL:0; PCL:0; RULEID:(100000803126)(100110400120); SRVR:DM5PR21MB0763; x-forefront-prvs: 0558D3C5AC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(346002)(366004)(376002)(39860400002)(39380400002)(199004)(189003)(47662002)(561944003)(316002)(14454004)(105586002)(230783001)(305945005)(106356001)(3280700002)(33896004)(68736007)(478600001)(5250100002)(3660700001)(558084003)(53936002)(31686004)(5660300001)(97736004)(7736002)(10090500001)(6116002)(2906002)(79102999)(6246003)(53546011)(25786009)(6506007)(6436002)(54896002)(4326008)(6486002)(86362001)(102836004)(81156014)(81166006)(9686003)(6512007)(8936002)(2900100001)(6346003)(6916009)(31696002)(99286004)(229853002)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR21MB0763; H:DM5PR21MB0826.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: linkedin.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=kandersen@linkedin.com; x-microsoft-antispam-message-info: xUza2GGMGRPap0h1IWv0RNkKB9s3d8Ua5Rzj4BzYd70BNK8sSd45p3id2Bo0MnjnWGhcoeEyZQqAF7URLrKV3A== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_ebdd453f0b6946119378f27d8c05d4faemailandroidcom_" MIME-Version: 1.0 X-OriginatorOrg: linkedin.com X-MS-Exchange-CrossTenant-Network-Message-Id: b66cce10-2dfb-4c69-fc3e-08d55fbcf2ae X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jan 2018 04:19:07.1806 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR21MB0763 Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-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, 20 Jan 2018 04:19:11 -0000 --_000_ebdd453f0b6946119378f27d8c05d4faemailandroidcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiBKYW4gMTksIDIwMTggMTk6NTMsIEhlY3RvciBTYW50b3MgPGhzYW50b3NAaXNkZy5uZXQ+ IHdyb3RlOg0KDQpJZiB0aGlzIGlzIGRvbmUsIHRoZW4gc2hvdWxkbid0IHRoZSBBUkMgcHJvcG9z YWwgYmUgc3RhbmRhcmQgdHJhY2sNCnJhdGhlciB0aGFuIGV4cGVyaW1lbnRhbD8NCg0KTWFraW5n IDc2MDEgbW9yZSBleHRlbnNpYmxlIGRvZXMgbm90IGFmZmVjdCB0aGUgc3RhdGUgb2YgQVJDLg0K DQotLUt1cnQNCg0K --_000_ebdd453f0b6946119378f27d8c05d4faemailandroidcom_ Content-Type: text/html; charset="utf-8" Content-ID: <846E646053D2C24C882EF10BE602F5D8@microsoft.onmicrosoft.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdiBkaXI9ImF1 dG8iPg0KPGRpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+DQo8ZGl2IGNsYXNzPSJn bWFpbF9xdW90ZSI+T24gSmFuIDE5LCAyMDE4IDE5OjUzLCBIZWN0b3IgU2FudG9zICZsdDtoc2Fu dG9zQGlzZGcubmV0Jmd0OyB3cm90ZToNCjxibG9ja3F1b3RlIGNsYXNzPSJxdW90ZSIgc3R5bGU9 Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVm dDoxZXgiPg0KPGRpdj48Zm9udCBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQi Pg0KPGRpdj48YnI+DQpJZiB0aGlzIGlzIGRvbmUsIHRoZW4gc2hvdWxkbid0IHRoZSBBUkMgcHJv cG9zYWwgYmUgc3RhbmRhcmQgdHJhY2sgPGJyPg0KcmF0aGVyIHRoYW4gZXhwZXJpbWVudGFsPzxi cj4NCjwvZGl2Pg0KPC9zcGFuPjwvZm9udD48L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXYgZGlyPSJhdXRvIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJh dXRvIj5NYWtpbmcgNzYwMSBtb3JlIGV4dGVuc2libGUgZG9lcyBub3QgYWZmZWN0IHRoZSBzdGF0 ZSBvZiBBUkMuPC9kaXY+DQo8ZGl2IGRpcj0iYXV0byI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0i YXV0byI+LS1LdXJ0PC9kaXY+DQo8ZGl2IGRpcj0iYXV0byI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9l eHRyYSI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8YmxvY2txdW90ZSBjbGFzcz0icXVv dGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtw YWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXY+PGZvbnQgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMXB0Ij4NCjxkaXY+PC9kaXY+DQo8L3NwYW4+PC9mb250PjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_ebdd453f0b6946119378f27d8c05d4faemailandroidcom_-- From nobody Sat Jan 20 08:00: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 DC83112D832 for ; Sat, 20 Jan 2018 08:00:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ncsc.gov.uk 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 LvOupNzeYJis for ; Sat, 20 Jan 2018 08:00:10 -0800 (PST) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20129.outbound.protection.outlook.com [40.107.2.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E864A12D82E for ; Sat, 20 Jan 2018 08:00:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncsc.gov.uk; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=kTfI4wWYuTGI17+9vVVsbJiiiv21dA834bh7GaTrMh8=; b=LQA76N8sMOP1gMQg9b52V7WFZnagFPbFi7pBZmtMJY1an7yPFFRALlHb9Xjam01Rt7lyKZ1vzMd6OVCnlbKuuAyFL0qyKEB2CZUXELJ0LLxlj4YXKA5gNEtG8bOS7SGErADHBxX33XgLx+f8Sl1vtawbVAy1tGKP/09ejFslWLU= Received: from LOXP12301MB1655.GBRP123.PROD.OUTLOOK.COM (10.167.32.148) by LOXP12301MB1653.GBRP123.PROD.OUTLOOK.COM (10.167.32.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.428.17; Sat, 20 Jan 2018 16:00:05 +0000 Received: from LOXP12301MB1655.GBRP123.PROD.OUTLOOK.COM ([10.167.32.148]) by LOXP12301MB1655.GBRP123.PROD.OUTLOOK.COM ([10.167.32.148]) with mapi id 15.20.0428.019; Sat, 20 Jan 2018 16:00:05 +0000 From: Ian Levy To: John R Levine CC: "Kurt Andersen (b)" , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Preventing abuse of public-suffix-level domains Thread-Index: AQHTdevoT2ysiWzEvUO1V0Z1nq0wk6NHbc2AgAOAYQCAAPZqoIAAnvOAgAAIy4CAAtzJ4IAAIRGAgCC04WA= Date: Sat, 20 Jan 2018 16:00:05 +0000 Message-ID: References: <20171219171548.EA07418299CE@ary.qy> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ian.levy@ncsc.gov.uk; x-originating-ip: [165.225.81.62] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; LOXP12301MB1653; 7:3BsKn29uWlH8KGswiXYBAsF1ym0oXr+XBKxqVvLcRhfydkRW6GQ6AzWzFuVL2YxjOf1Q+KUY4QPy95wh3LGXewhDvol0/sOt77dwY2QUN7griZL6amgVbYiJuM4jxp1T1yj/oYcmlaFfbBeD0QcsCtCA1GgMxAWpiwzyluDQQ4eK7Jtphlythj4uKrHtE89xVg7/rPAjSkyl5Z+pXKEfjCRusrbYR6tztN9TPF2zojoOfVmHrGEfz1/El29hdRJD x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 482beb10-0d8d-45c1-d993-08d5601edf90 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534125)(4602075)(7168020)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:LOXP12301MB1653; x-ms-traffictypediagnostic: LOXP12301MB1653: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705)(189930954265078)(45079756050767)(27231711734898); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(3231023)(2400081)(944501161)(93006095)(93001095)(10201501046)(3002001)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123560045)(20161123562045)(20161123564045)(6072148)(201708071742011); SRVR:LOXP12301MB1653; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:LOXP12301MB1653; x-forefront-prvs: 0558D3C5AC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39380400002)(396003)(39840400004)(376002)(346002)(199004)(189003)(13464003)(81156014)(53936002)(3846002)(8936002)(6306002)(86362001)(45080400002)(6116002)(55016002)(6246003)(9686003)(8676002)(81166006)(305945005)(3660700001)(2906002)(74482002)(478600001)(229853002)(7736002)(966005)(68736007)(74316002)(3280700002)(6436002)(7696005)(2900100001)(25786009)(93886005)(4326008)(59450400001)(76176011)(55236004)(42882006)(53546011)(230783001)(102836004)(6916009)(2950100002)(105586002)(99286004)(106356001)(77096007)(5660300001)(75922002)(14454004)(66066001)(54906003)(97736004)(26005)(33656002)(6506007)(316002); DIR:OUT; SFP:1102; SCL:1; SRVR:LOXP12301MB1653; H:LOXP12301MB1655.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ncsc.gov.uk does not designate permitted sender hosts) x-microsoft-antispam-message-info: D4EgOoONELrUHC7vgrWtFsVC5dJQiHUQ1K7qwv1NOyrc6GCFJ2xh99f6kl7QpQu5+6zDAvP5j7lzvZMcaGCgeg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ncsc.gov.uk X-MS-Exchange-CrossTenant-Network-Message-Id: 482beb10-0d8d-45c1-d993-08d5601edf90 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jan 2018 16:00:05.7796 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 14aa5744-ece1-474e-a2d7-34f46dda64a1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: LOXP12301MB1653 Archived-At: Subject: Re: [dmarc-ietf] Preventing abuse of public-suffix-level domains 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, 20 Jan 2018 16:00:13 -0000 John, all, We did some work over the holidays and couple of weeks ago implemented some= thing along these lines. It all seems to be working and we're collecting da= ta about spoofs of non-existent domains and some interesting (apparent) mis= configurations that are nothing to do with DMARC. We'll report on the results when we've got sufficient data and done the ana= lysis. Thanks again for the pointer! Ta. I. -- Dr Ian Levy Technical Director National Cyber Security Centre Staff Officer : Kate Atkins, kate.a@ncsc.gov.uk -----Original Message----- From: John R Levine [mailto:johnl@taugh.com] Sent: 22 December 2017 15:39 To: Ian Levy Cc: Kurt Andersen (b) ; dmarc@ietf.org Subject: RE: [dmarc-ietf] Preventing abuse of public-suffix-level domains > Thanks for this. I think we'd decided this wouldn't work (along with JISC= , who currently run the authoritative DNS for gov.uk). For the life of me, = I can't remember why though! It's worth reading RFC 4592, a fairly dense description of how DNS wildcard= s work, to be clear about what names *.gov.uk wil match and what they won't= so you know what to expect. People even within the IETF can find them con= fusing. R's, John > > We'll have another look at it after the holidays. We have every intention= of making delegates responsible for doing something sensible in their name= space as well. > > Thanks again. > > Ta. > > I. > > -- > Dr Ian Levy > Technical Director > National Cyber Security Centre > > Staff Officer : Kate Atkins, kate.a@ncsc.gov.uk > > -----Original Message----- > From: John R Levine [mailto:johnl@taugh.com] > Sent: 20 December 2017 17:58 > To: Kurt Andersen (b) > Cc: Ian Levy ; dmarc@ietf.org > Subject: Re: [dmarc-ietf] Preventing abuse of public-suffix-level > domains > > On Wed, 20 Dec 2017, Kurt Andersen (b) wrote: >>> I need to be able to emulate in some way the effect of SPF and DMARC >>> records for non-existent first level subdomains under the PSL gov.uk >>> - to stop spoof mail apparently coming from them being delivered. > >> I'm quite sure that you will need to do this via synthetic records >> being returned either by the gov.uk name servers or by having gov.uk >> refer to a general "parked domain" name server (farm) for all of the >> non-existent subdomains ... > > With your current DNS setup, you could add this, no new name servers > needed: > > *.gov.uk. IN TXT "v=3Dspf1 -all" > *.gov.uk. IN TXT "v=3DDMARC1; p=3Dreject; rua=3Dmailto:; ruf= =3Dmailto:" > > This will cover all undelegated names below gov.uk, e.g. abc.gov.uk and a= bc.def.gov.uk. It won't cover names under existing subdomains, e.g. > abc.mod.gov.uk but it's better than nothing. > > Unless the people who host your DNS are willing to let you use customized= stunt servers, which seems unlikely considering who they are, that's about= the best you can do without getting the cooperation of your delegatees. > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. > https://emea01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fjl. > ly&data=3D02%7C01%7Cian.levy%40ncsc.gov.uk%7Cbd63e2124c974606c8a808d547d > 33b16%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C636493894920036818& > sdata=3DiUTep54zAORBtIwqsMU%2BjEg51F%2FhxgAEPX%2BXl9IEfmU%3D&reserved=3D0 > This information is exempt under the Freedom of Information Act 2000 > (FOIA) and may be exempt under other UK information legislation. Refer > any FOIA queries to ncscinfoleg@ncsc.gov.uk > > Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please c= onsider the environment before reading this e-mail. https://emea01.safelink= s.protection.outlook.com/?url=3Dhttps%3A%2F%2Fjl.ly&data=3D02%7C01%7Cian.le= vy%40ncsc.gov.uk%7C6d5ee308376e4b91cd4408d549522859%7C14aa5744ece1474ea2d73= 4f46dda64a1%7C0%7C0%7C636495539574482595&sdata=3DbAmgktrJccTyMBNd35VYt2EGGn= 3iPAboKD6ywMNrEQI%3D&reserved=3D0 This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk From nobody Sat Jan 20 09:00:47 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 EDE991273E2 for ; Sat, 20 Jan 2018 09:00:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFyolGgIvove for ; Sat, 20 Jan 2018 09:00:44 -0800 (PST) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (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 37B30120726 for ; Sat, 20 Jan 2018 09:00:44 -0800 (PST) Received: by mail-ua0-x22e.google.com with SMTP id i15so3174448uak.3 for ; Sat, 20 Jan 2018 09:00:44 -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=zAzO2EhILD/QCOzvqOPv3obXAzPWOxPRMsJmNTlsYvM=; b=YYvXq/YgFLwGLHhlfZQYe24jffqj9j7CNNv9FJLiMxt5wFPjNoigiImA9T02KXf6WN gElgd++RhVaoD2rQd1EKd9DSiI/AiJh/qHh9GiJJcEgsSNIVBe3S2uQ3mZz0hkxmU0EF PQ56cckXwt6SOr6X9L40+ZnLbAollcYeGlDCuR/jM8BBQXmSk4icJDKulUfYB+ReE0bi pSDTIg70bD5AIn8Tm9lLskelN9h9Bwz715H/kbXIidnYhx0FZY1LL0OUxthed8J8Ha+6 9qwGe49Er9cBLDOH7QyOV6uwxtfk3oRVEFH78VcyfeZhBhpK1Rbq3GdjJGqlL5ZvPQhB Eysw== 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=zAzO2EhILD/QCOzvqOPv3obXAzPWOxPRMsJmNTlsYvM=; b=au+JBmXdvqgTzuDXi2zOToiJqTW5mDMlvsrf+3hSSFkfd6es8ogrQIQR7tkJywcPSn g//XJvuOYlPZECpri3lgr2bz/zfgU5Id7dT70GbYh9NroCXQL94JFFf5nG/nJTLG0vi/ haiJJ1Y465B/yuw4U2qp3m8eMfo2XEqHWdinBvNA1Stj6hTbcECzkmBsaEakc0s+if1I KElWCw0lemvyAVljKwy7R+kjvnQLu12Bf4cZ4Qpz5sL1kBvkwvNKIUkhzMfvO04vCCbf UlXzPyYlysOQBSURmWT1OvxLqYee+z7BssZTIcVaSYp7pnII7WvEk2jqHla62pg1Seoy ai/Q== X-Gm-Message-State: AKwxyte963eZuFAPENr4n/oZUFCHAvf6j0yI00vwGB7DFNtK0Fb+IpuR 1/i5bZLJSWve2kNQ/iE/rKvZfK3uhQVtkhCDIoX+YeDY X-Google-Smtp-Source: AH8x224ujW7Sd8LebWxiFtvSB+EnozREzf4AxUUuZ3P3h4Qp3I1pEJqh1u9bUzzXJI6m7bI23Z7bidRnu/QpX8LAGvM= X-Received: by 10.176.7.150 with SMTP id c22mr1590322uaf.45.1516467642472; Sat, 20 Jan 2018 09:00:42 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Seth Blank Date: Sat, 20 Jan 2018 17:00:30 +0000 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="f403045f8b3024b5ea056338235b" Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-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, 20 Jan 2018 17:00:46 -0000 --f403045f8b3024b5ea056338235b Content-Type: text/plain; charset="UTF-8" On Fri, Jan 19, 2018 at 20:19 Kurt Andersen wrote: > Making 7601 more extensible does not affect the state of ARC. > Agreed. Extending 7601 lets us meaningfully simplify the ARC draft, but does not otherwise affect the state of the tech or the underlying experiment. Seth > --f403045f8b3024b5ea056338235b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Fri, Jan 19, 2018 = at 20:19 Kurt Andersen <kander= sen@linkedin.com> wrote:
Making 7601 more extensible does not affe= ct the state of ARC.

Agreed. Extending 7601 lets us meaningfully simplify = the ARC draft, but does not otherwise affect the state of the tech or the u= nderlying experiment.

Se= th
--f403045f8b3024b5ea056338235b-- From nobody Sat Jan 20 09:11: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 97CEF1270A0 for ; Sat, 20 Jan 2018 09:11: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 (1024-bit key) header.d=isdg.net header.b=N0DqRafo; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=KGI9vOvI 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 SHKfroBeF0Uv for ; Sat, 20 Jan 2018 09:11:56 -0800 (PST) Received: from ntbbs.santronics.com (pop3.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id E24C0120726 for ; Sat, 20 Jan 2018 09:11:55 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=626; t=1516468311; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=NI8IuaMor67hiJrSiylD4CxWEMs=; b=N0DqRafoSyglycg5Z49fcg4+NUMaILFylmYf9Hs+/mBOs6FeGp0rB9SMxUfpxa m8qSEqY9LXCmmXghUe5s2aOQWr+5fKCdLuqhUXkjz8ZS7At5BOXyc6w1S2PJwj8O /h2ferTeGidHX7IF22ULBx8eLm4HtkBnDbcTqx6TLP25U= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Sat, 20 Jan 2018 12:11:51 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 2042017257.1.1532; Sat, 20 Jan 2018 12:11:50 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=626; t=1516468052; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=7WNBNBZ VmwY14ZoKCnbTRMiaAkCQEui5ck05HKOf8Fs=; b=KGI9vOvI9mCogy2Gr+/2OY+ b6fNxRUMQxToJCxKkEt2Xenqgrfhd/7BcwkeUJRKZnMh7lWml62sGxm3pveBsp4Q rVqGvUk2NT7NhTCr/3vyZq0FwW7cNCJjxC6g6iXtRZGbUTy6agaibfaSkQfZ8u5+ kQyaC2E8SGjCRgV8tgF4= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Sat, 20 Jan 2018 12:07:32 -0500 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 2041925579.9.39996; Sat, 20 Jan 2018 12:07:31 -0500 Message-ID: <5A63785A.2030702@isdg.net> Date: Sat, 20 Jan 2018 12:11:54 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-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, 20 Jan 2018 17:11:57 -0000 On 1/19/2018 11:19 PM, Kurt Andersen wrote: > > On Jan 19, 2018 19:53, Hector Santos wrote: > > > If this is done, then shouldn't the ARC proposal be standard track > rather than experimental? > > > Making 7601 more extensible does not affect the state of ARC. > It was my understanding that the IETF frowns upon making proposed standards RFC connections to experimental, non-standard stuff. If ARC fails as an experiment, 7601 will be left with legacy dependencies and wasted development *overhead* on an abandoned experimentation that has yet to proven its value. Thanks -- HLS From nobody Sat Jan 20 09:18:08 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 D361C120726 for ; Sat, 20 Jan 2018 09:18:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=Xw9QWoOQ; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=F2VUV7DN 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 Qv8QrL7qo2tp for ; Sat, 20 Jan 2018 09:18:06 -0800 (PST) Received: from ntbbs.santronics.com (ntbbs.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id A81F41270A0 for ; Sat, 20 Jan 2018 09:18:05 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=917; t=1516468675; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=mnyv0Oe+kdxERceHdcYKQ02Q97Y=; b=Xw9QWoOQGmmU67A6yh5RGp41sWHGGefeqtOaaRGpjJcW+bqa0BaXo1zCDKgKrm M4TwhUzaKFwLfsXh+ihYO8lOGdVKY8NiUrHcsMJts21xzmZUCG/sj+sgY5EZjZlj TwTaVAzP0kgPWTxFpgfTpin4boQDuv9rrC9gjJ1v7jmV0= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Sat, 20 Jan 2018 12:17:55 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 2042382393.1.856; Sat, 20 Jan 2018 12:17:55 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=917; t=1516468416; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=JcbJ0K7 f8LWeIXoDOsFtoj3uvy8kSQM1iCvExaFYq1o=; b=F2VUV7DNrYdKhix6vTy1q/p yOQY/HQM+/8Jg7Q0sp8fxoHgnFEADrJ6UoxE/i2p8/VQZdSiEtksKbOG5zl2UvgD qPOkenlCwjey2GrJWB9ykN4ARKqTeEq+9y6RT4vpsZ/6HKv42bDgfiOHl9qp1tQ4 Xytjma23111Pk3hsP3Hc= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Sat, 20 Jan 2018 12:13:36 -0500 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 2042289283.9.40904; Sat, 20 Jan 2018 12:13:35 -0500 Message-ID: <5A6379C6.3090305@isdg.net> Date: Sat, 20 Jan 2018 12:17:58 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <5A63785A.2030702@isdg.net> In-Reply-To: <5A63785A.2030702@isdg.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-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, 20 Jan 2018 17:18:07 -0000 IMEV, 7601 should be extendable without continuing modifying 7601 by augmented technology, i.e. ARC itself should do the 7601 "add-on" considerations and that shouldn't effect 7061 or any 7601 implementations. On 1/20/2018 12:11 PM, Hector Santos wrote: > On 1/19/2018 11:19 PM, Kurt Andersen wrote: >> >> On Jan 19, 2018 19:53, Hector Santos wrote: >> >> >> If this is done, then shouldn't the ARC proposal be standard track >> rather than experimental? >> >> >> Making 7601 more extensible does not affect the state of ARC. >> > > It was my understanding that the IETF frowns upon making proposed > standards RFC connections to experimental, non-standard stuff. > > If ARC fails as an experiment, 7601 will be left with legacy > dependencies and wasted development *overhead* on an abandoned > experimentation that has yet to proven its value. > > Thanks > -- HLS From nobody Sat Jan 20 09:52: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 0C01A126CF6 for ; Sat, 20 Jan 2018 09:52:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 O56mOx8HU7n7 for ; Sat, 20 Jan 2018 09:52:43 -0800 (PST) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB65C120726 for ; Sat, 20 Jan 2018 09:52:42 -0800 (PST) Received: by mail-lf0-x22d.google.com with SMTP id t139so5819492lff.0 for ; Sat, 20 Jan 2018 09:52:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Kv7wadARdb1pi09R8Pnb7oN0P69LentivQ64fW5a4Nc=; b=GG0cLieTC8km9L7/t6avuFsuKU9/XWlK4E9odfo0rpm4sGUvRodetSm/hQr40HBPJw vT0oPehQKEh1/zCd+/NC1Xbh6ySC1ToYL1YJGghOROtC6eKMJbsepHAFF/5CUZXvsMTz 1+0kxgY9hNV7A89VPr/1Rx8PJwr0fOxYFbxA4= 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=Kv7wadARdb1pi09R8Pnb7oN0P69LentivQ64fW5a4Nc=; b=jK6dyqTMZ7jiXQg/fI97keLpPc3l3mKj2cCtPXfCxEfQghM3gmLP64ZEZ13t/TKgkZ za0kMgkzSum30pJzdjsVWfYCk6XVEcns5P8Tekmv0g6rA4cT2u0w0OAu4kSPcxNQUOX1 kXWVBeUOOwKMAs6bVk/YOS6HOkzwVJ+lKN/fhebZtPD7yB1xgqDbuAIPtyN7SQ4W/Nn4 9Lo+S9tRjPjBc+InQ+hnZYcEqfTZC0QoyJuZttzyWrGTR2C2XalCdbcxIdsUGU71B5ih nopPvVly69MfIQOv2m41Juecq70aB9GVEf+1vtDz0yXeecQMfvgJs16E2+xKNosocNK7 k59g== X-Gm-Message-State: AKwxytd5Po3yzdTz144rFTevWgFs6emxDPt6K8A+HOjig3XEJug1zfCG GrbUi4rK4s8tHxHKUYT7mN80f3VOgXOsMrTYc+sXpmH9 X-Google-Smtp-Source: AH8x226fDaSnAb42cXEYt5SWvgiWuGig//M/03AhU2pC5BqbfqWTzq6vR6mpHtvgUD+X0YqWjzVByMHoYg+TNxuzvlw= X-Received: by 10.46.77.193 with SMTP id c62mr1214520ljd.148.1516470760766; Sat, 20 Jan 2018 09:52:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.193.138 with HTTP; Sat, 20 Jan 2018 09:52:39 -0800 (PST) Received: by 10.25.193.138 with HTTP; Sat, 20 Jan 2018 09:52:39 -0800 (PST) In-Reply-To: <5A6379C6.3090305@isdg.net> References: <5A63785A.2030702@isdg.net> <5A6379C6.3090305@isdg.net> From: Kurt Andersen Date: Sat, 20 Jan 2018 09:52:39 -0800 Message-ID: To: Hector Santos Cc: dmarc@ietf.org Content-Type: multipart/alternative; boundary="94eb2c1aa5f6021705056338dd32" Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-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, 20 Jan 2018 17:52:45 -0000 --94eb2c1aa5f6021705056338dd32 Content-Type: text/plain; charset="UTF-8" That is our plan. The change to 7601 is to segment the ABNF for clearer extension by ARC. Wait and see what Murray puts in and then we can discuss. On Jan 20, 2018 09:18, "Hector Santos" wrote: > IMEV, 7601 should be extendable without continuing modifying 7601 by > augmented technology, i.e. ARC itself should do the 7601 "add-on" > considerations and that shouldn't effect 7061 or any 7601 implementations. > > On 1/20/2018 12:11 PM, Hector Santos wrote: > >> On 1/19/2018 11:19 PM, Kurt Andersen wrote: >> >>> >>> On Jan 19, 2018 19:53, Hector Santos wrote: >>> >>> >>> If this is done, then shouldn't the ARC proposal be standard track >>> rather than experimental? >>> >>> >>> Making 7601 more extensible does not affect the state of ARC. >>> >>> >> It was my understanding that the IETF frowns upon making proposed >> standards RFC connections to experimental, non-standard stuff. >> >> If ARC fails as an experiment, 7601 will be left with legacy >> dependencies and wasted development *overhead* on an abandoned >> experimentation that has yet to proven its value. >> >> Thanks >> >> > -- > HLS > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --94eb2c1aa5f6021705056338dd32 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That is our plan. The change to 7601 is to segment the AB= NF for clearer extension by ARC. Wait and see what Murray puts in and then = we can discuss.

On Jan 20, 2018 09:18, "Hector Santos" <hsantos@isdg.net> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">IMEV, 7601 should be extendable without conti= nuing modifying 7601 by augmented technology, i.e. ARC itself should do the= 7601 "add-on" considerations and that shouldn't effect 7061 = or any 7601 implementations.

On 1/20/2018 12:11 PM, Hector Santos wrote:
On 1/19/2018 11:19 PM, Kurt Andersen wrote:

On Jan 19, 2018 19:53, Hector Santos <hsantos@isdg.net> wrote:


=C2=A0 =C2=A0 If this is done, then shouldn't the ARC proposal be stand= ard track
=C2=A0 =C2=A0 rather than experimental?


Making 7601 more extensible does not affect the state of ARC.


It was my understanding that the IETF frowns upon making proposed
standards RFC connections to experimental, non-standard stuff.

If ARC fails as an experiment, 7601 will be left with legacy
dependencies and wasted development *overhead* on an abandoned
experimentation that has yet to proven its value.

Thanks


--
HLS


_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--94eb2c1aa5f6021705056338dd32-- From nobody Sat Jan 20 18:15:16 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 AACEE126CD8 for ; Sat, 20 Jan 2018 18:15:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 3FEx-vMQDgId for ; Sat, 20 Jan 2018 18:15:12 -0800 (PST) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (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 CB05A120713 for ; Sat, 20 Jan 2018 18:15:11 -0800 (PST) Received: by mail-lf0-x22e.google.com with SMTP id t139so6511710lff.0 for ; Sat, 20 Jan 2018 18:15:11 -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=3LtLvLT0h7aCIsAayuxeoTp1tvFDn+2qXkKcmZy94V4=; b=ej5plv0cWRyFoucdpTUshSYvhzjhucpwvhGEUvAbm7PcJZa6EKX0HlZEESapAbe8un roBARdLpbv9mQYPCsxLyEW4fHY4fPfOsG6oYh4JmdiopOErEqvrbFvrYBh/ogT8vPLvO X+dff4pxFydWbbm+mofL2I+kPQQe9imvcsokLlnkFqtbzzCPLUGePbO02nJU2OzeKs6n SxX34gg9faIT1SxqEUfQg68ey4w9b8IAgAjcEzhR5iOg9rDpabeU/M+yU/jzoo6oNaH1 K++jZPQ5ZSfm6EUkedhv8wV7bZ9jBPCqfzLOKoN1MSO8icCaWxo+mJ4zc7Kc5Pnym5RB YaVw== 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=3LtLvLT0h7aCIsAayuxeoTp1tvFDn+2qXkKcmZy94V4=; b=g65Y55Gmak2kbbkmqWWZiNiZDjRetG9N61FatSNci8hA08uWr0GWTk2hZ5N28DbYP5 T5qR0wyQwLaSMImr/AOnUKhCDWcIMvMysecKA2W+oEKnAy9Im2qlOR2fDNBpo9cquSqn tiQMDh2mimrgv9IinZZyPG5LxcEj6FtaRFxcXXZIQmXnb1+7YlHqB/V3Y6nDuoFx13/8 3zuCNiXPuRNrwQt5PxyboctbVWGettLryhpA/NkCk2ftfMh7lk5YfTW9Ghq9LbIfkjuQ F+RbcT46ijQreW6D40ntVbWINj1W17TEbKHDX4AsuDBW6VEP24LdfCjqdid5SmResii3 iy2Q== X-Gm-Message-State: AKwxytfolRBE2lxNDRvrO6raNrZDwZ55jCGuRY7kNbAxSBJ/wtrECKiV j+RhL3yqrskgwQ8beLDMlW5/GeeZ4ucwt4HAoAV9Yw== X-Google-Smtp-Source: AH8x227p9KSuoMNW93jYLXdLZgUFspcpCXHUJITSlVw64FGaPFMIB57IzPZLMv7gWd4F3mHEgU/yhSB78/eKCAtl8pM= X-Received: by 10.46.124.11 with SMTP id x11mr1637304ljc.99.1516500910005; Sat, 20 Jan 2018 18:15:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.101.74 with HTTP; Sat, 20 Jan 2018 18:15:09 -0800 (PST) In-Reply-To: References: <5A63785A.2030702@isdg.net> <5A6379C6.3090305@isdg.net> From: "Murray S. Kucherawy" Date: Sat, 20 Jan 2018 18:15:09 -0800 Message-ID: To: Kurt Andersen Cc: dmarc@ietf.org Content-Type: multipart/alternative; boundary="f4f5e8072a800ae32905633fe25f" Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-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, 21 Jan 2018 02:15:14 -0000 --f4f5e8072a800ae32905633fe25f Content-Type: text/plain; charset="UTF-8" On Sat, Jan 20, 2018 at 9:52 AM, Kurt Andersen wrote: > That is our plan. The change to 7601 is to segment the ABNF for clearer > extension by ARC. Wait and see what Murray puts in and then we can discuss. > > On Jan 20, 2018 09:18, "Hector Santos" wrote: > >> IMEV, 7601 should be extendable without continuing modifying 7601 by >> augmented technology, i.e. ARC itself should do the 7601 "add-on" >> considerations and that shouldn't effect 7061 or any 7601 implementations. >> > Kurt's correct. ARC (experimental) depends on A-R (standards track), not the other way around. -MSK --f4f5e8072a800ae32905633fe25f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Jan 20, 2018 at 9:52 AM, Kurt Andersen <kurta@dr= kurt.com> wrote:
That is our p= lan. The change to 7601 is to segment the ABNF for clearer extension by ARC= . Wait and see what Murray puts in and then we can discuss.

On Jan 20, 2018 09:18, "Hector Santos" <hsantos@isdg.net> wro= te:
IMEV, 7601 shoul= d be extendable without continuing modifying 7601 by augmented technology, = i.e. ARC itself should do the 7601 "add-on" considerations and th= at shouldn't effect 7061 or any 7601 implementations.
<= /div>

Kurt's correct.= =C2=A0 ARC (experimental) depends on A-R (standards track), not the other w= ay around.

-MSK
--f4f5e8072a800ae32905633fe25f-- From nobody Sun Jan 21 10:07:32 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 1AE69126D73 for ; Sun, 21 Jan 2018 10:07:31 -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 (1024-bit key) header.d=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynvb8VC8iC-L for ; Sun, 21 Jan 2018 10:07:29 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (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 AC7D9124217 for ; Sun, 21 Jan 2018 10:07:29 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QO3TTPZLM8006LR9@mauve.mrochek.com> for dmarc@ietf.org; Sun, 21 Jan 2018 10:02:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1516557747; bh=cW5J1up5iHx8pAx6MnShcxGUUMTG8eDu5GMmZMIrCLQ=; h=From:Cc:Date:Subject:In-reply-to:References:To:From; b=ls1VZERaPevpE4DHWfAaShmEPuoU5wx0//hnQPSvSceRjq1Vrd7T64ygKE/ygOkjy GC92SOrtdHaDKT+nVuE7zCTlyTQc6JTARFL9SInYZlhMDr/t+wgRvQxCgjZi5TVy/F eBhhuSg2W1fPdvh91Skkp0K83FxFq7puFLe4FFsg= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QNWCG2JBHS000051@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for dmarc@ietf.org; Sun, 21 Jan 2018 10:02:24 -0800 (PST) From: ned+dmarc@mrochek.com Cc: dmarc@ietf.org, kboth@drkurt.com Message-id: <01QO3TTOHMLE000051@mauve.mrochek.com> Date: Sun, 21 Jan 2018 10:01:34 -0800 (PST) In-reply-to: "Your message dated Fri, 19 Jan 2018 18:06:27 -0500" <20180119230629.2CA691950C4A@ary.qy> References: <20180119230629.2CA691950C4A@ary.qy> To: John Levine Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-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, 21 Jan 2018 18:07:31 -0000 This would need to be coordinated with the EAI people/list, but as long as it isn't controversial I don't see a reason not to put it in. Ned > If I may budge in here, any chance we could put in a few tweaks for > EAI mail? > I think the main changes would be that if the A-R or AAR header is in > an EAI message, domain names and local parts can be UTF-8 rather than > ASCII. I specifically do not want to change any of the keywords or > codes, since they're for software, not for people. > I realize that we should update RFC 6376 at the same time for DKIM > signatures, but I'll take what I can get. > R's, > John > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Sun Jan 21 12:15:10 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 60C43124235 for ; Sun, 21 Jan 2018 12:14:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.761 X-Spam-Level: X-Spam-Status: No, score=-1.761 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.25, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=inH05v94; dkim=pass (1536-bit key) header.d=taugh.com header.b=tPLNQDqi 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 tbiYgKWkOl4F for ; Sun, 21 Jan 2018 12:14:58 -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 BA314120726 for ; Sun, 21 Jan 2018 12:14:41 -0800 (PST) Received: (qmail 13186 invoked from network); 21 Jan 2018 20:14:40 -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=3380.5a64f4b0.k1801; bh=vpCZA9SwrGyUkhrHqiATZgYxpvKMNMV2UzOM8nF1SxI=; b=inH05v94bzONdpcDFoYGWVhsCCvSQ2eq/JhR+pm7rj+c7aUHL1P1Mv5PCW0HD4VziCcPPL4AwcaOonLsJgV4O9mO5BUbSDg2pjEFPcaWdUEWMG3MSWTKWO/D76iHTkF5tiZH4bi7XehDdnAO/MZKpJJheo6/Qik+Oa68ibkTEN+oFtz/1yKp3zF2HiZEiUC4l62Tmoj8imH8n2n8+JRbEi9yQyAeDUsQThMM6Lh6p3avn10nBFLva0+FiijbhMan 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=3380.5a64f4b0.k1801; bh=vpCZA9SwrGyUkhrHqiATZgYxpvKMNMV2UzOM8nF1SxI=; b=tPLNQDqivPu1MtfWLfwgL87hSJMde82ma+vnF4WrIR5gcnPCFMzEDvx9Ig+qRB2ldM0R+EgcwEEmP+RErH3RZNqvNzpkqK04cgJIuXQHYIdwcVVdcfuMjrW9L6SgOg1PFHnIaxQcky3XKUQsChiE7jSnu4/4FtbE353xS03MPzHO76C+TPgYZShHY2xPpBUdX4O/eazFp6fYH1aG7CBKUaNP/4IPA+b/+EjY2Q6JZs7eBa+rgTaemYpiLPKdSWsi 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; 21 Jan 2018 20:14:40 -0000 Received: by ary.qy (Postfix, from userid 501) id 81955197EB8C; Sun, 21 Jan 2018 15:14:39 -0500 (EST) Date: 21 Jan 2018 15:14:39 -0500 Message-Id: <20180121201439.81955197EB8C@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: ned+dmarc@mrochek.com In-Reply-To: <01QO3TTOHMLE000051@mauve.mrochek.com> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-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, 21 Jan 2018 20:15:09 -0000 In article <01QO3TTOHMLE000051@mauve.mrochek.com> you write: >This would need to be coordinated with the EAI people/list, but as long >as it isn't controversial I don't see a reason not to put it in. It's not supposed to be controversial, the minimum changes to make stuff work with EAI UTF-8 messages. R's, John >> If I may budge in here, any chance we could put in a few tweaks for >> EAI mail? > >> I think the main changes would be that if the A-R or AAR header is in >> an EAI message, domain names and local parts can be UTF-8 rather than >> ASCII. I specifically do not want to change any of the keywords or >> codes, since they're for software, not for people. > >> I realize that we should update RFC 6376 at the same time for DKIM >> signatures, but I'll take what I can get. From nobody Sun Jan 21 14:39:26 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 72010126D74 for ; Sun, 21 Jan 2018 14:39:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=kMXTZ3+A; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=nyaumzCR 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 VfFzA4uPC5AB for ; Sun, 21 Jan 2018 14:39:22 -0800 (PST) Received: from groups.winserver.com (dkim.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 358A5126C25 for ; Sun, 21 Jan 2018 14:39:22 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1396; t=1516574358; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=T2Y5zP8IR/Qc9OBKHICXB5vebcw=; b=kMXTZ3+ACXTGLB+oRDgYzXwzrVhZuhxBOME0MVwYVUil3XCwN2mkF8b1gzXLwM Y5x2rJ4Y4qn63mF2R3quSLFY0WAJ6sz3YJnqLp2qAU83dD+xYzhirp/9mxGcJruU 24HUGR4MZXrbDhdH2yHO4aYqu9Zx95cGAvsR0oc35OcnM= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Sun, 21 Jan 2018 17:39:18 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 2148063866.1.3512; Sun, 21 Jan 2018 17:39:18 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1396; t=1516574096; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=JDNm3BO S4ceUYjcfeRwZ5JfHLYeI10d2/1DUU27vj40=; b=nyaumzCR1zXLb87k7S6SKWy 35i+R9f/bHicsIAr++3SKYuH4XmXjcW5L6FPn0o5YeZwZIYCBun0ZFzqDgcUQ+Pd VEd0w4ZHboMtN8JzCg5Brmtt5d4pAy+yt6d3Kwy6JIMu73iv8yYu4WlrpmgFf8wN hZboFWQVe+wAtxdCwkzM= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Sun, 21 Jan 2018 17:34:56 -0500 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 2147970345.9.138496; Sun, 21 Jan 2018 17:34:56 -0500 Message-ID: <5A651691.40103@isdg.net> Date: Sun, 21 Jan 2018 17:39:13 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <5A63785A.2030702@isdg.net> <5A6379C6.3090305@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-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, 21 Jan 2018 22:39:24 -0000 On 1/20/2018 9:15 PM, Murray S. Kucherawy wrote: > On Sat, Jan 20, 2018 at 9:52 AM, Kurt Andersen > wrote: > > That is our plan. The change to 7601 is to segment the ABNF for > clearer extension by ARC. Wait and see what Murray puts in and > then we can discuss. > > On Jan 20, 2018 09:18, "Hector Santos" > wrote: > > IMEV, 7601 should be extendable without continuing modifying > 7601 by augmented technology, i.e. ARC itself should do the > 7601 "add-on" considerations and that shouldn't effect 7061 or > any 7601 implementations. > > > Kurt's correct. ARC (experimental) depends on A-R (standards track), > not the other way around. That is what I would think, but the key concern I would think, we don't want to add something ARC related to A-R if its not generic and only specific to ARC. Personally, it may be premature. Wait until ARC is more than settle in its direction before modifying any standard track item. But if its a generic change, that fits more than just ARC, that sounds ok. Keep in mind, there are might be others, besides my own package, who can't/won't (for various reasons) use OpenARC or OpenDMarc and/or OpenA-R. Hopefully, we will be able to write (implement) this from the RFC "functional specifications" from scratch. Thanks -- HLS From nobody Sun Jan 21 19:55:47 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 1E7E4126CC7 for ; Sun, 21 Jan 2018 19:55:46 -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=ecuDHcMV; dkim=pass (1536-bit key) header.d=taugh.com header.b=e/8PPikk 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 alDNozf0bh0S for ; Sun, 21 Jan 2018 19:55:44 -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 DDDF912025C for ; Sun, 21 Jan 2018 19:55:43 -0800 (PST) Received: (qmail 94698 invoked from network); 22 Jan 2018 03:55:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent; s=171e8.5a6560bf.k1801; bh=1xWsBbWO30L/6SZua4+JqIpo5XEQ1yocOyP0q8M9R1E=; b=ecuDHcMVJKDRvo1UlibkCchYS5e/9LOXZGalJteGY+BaBlZndbTHVhy0L2yudGFNGGUasXjRiw9RfL1ObxJ4KDDbqs0AE2xqM+Lo3lfOTaqAVvxp8PXhfIV/u1npwgr3rGhTElKm1OsQA1kf8giaR0jIlnRAlHubJs6Rqs5h6lj0/sD4tEvCOE+VVaeo4c4mJCvBsEBZDLwcW1HeSCenL34Bf+5TwXkbMnTNHAilVmWni6CDRtwaHKnoZEz3BZry DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent; s=171e8.5a6560bf.k1801; bh=1xWsBbWO30L/6SZua4+JqIpo5XEQ1yocOyP0q8M9R1E=; b=e/8PPikkTCzY6BcNN+nm1mxD/hdaDz+isZ+eJpDhTZ3cBZfWuUrAZkCXwTsMAWV1uGWw9DRPHsw6HerK7A+my+RasXkfHG/AF58lsmjNtPpfSHtRwr/LpSEQJ0bKHnDSiRxlvyal3pTjjlTS5oR5YXCF3MFilvYMHjALFYUsSnjkP1aRhf9+eC+pR/VWQY6UD7ObrwmgKusHRfmODoiOYKqLn2c3LWgxS3bC4ieNJlHjDbHorzVSHmhmPguF8IBj 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; 22 Jan 2018 03:55:42 -0000 Date: 21 Jan 2018 22:55:42 -0500 Message-ID: From: "John R Levine" To: dmarc@ietf.org, eai@ietf.org 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: [dmarc-ietf] New version of E-mail Authentication for Internationalized Mail draft 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, 22 Jan 2018 03:55:46 -0000 Read all about it: https://datatracker.ietf.org/doc/draft-levine-appsarea-eaiauth/ This is an updated version of a draft I wrote two years ago, that tries to nail down the small changes to SPF, DKIM, and DMARC in EAI messages. This version adds a section for the Authentication-Results header. What it mostly says is that wherever you can have a domain name in a mail message header it can be a U-label, and wherever there's a mailbox, the local part can be UTF-8, while stuff in the DNS doesn't change and domains there are A-labels, same as always. It's intended to be utterly unsurprising, but there's enough ambiguity and well-intended bad advice in existing RFCs that I think this is worth doing. I'm working on an intro to implenting EAI document underwritten by ICANN so it would be nice if this were far enough along that I could point to it in the relevant sections rather than just Making Stuff Up. R's, John From nobody Mon Jan 22 14:47:31 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 7463A126D74; Mon, 22 Jan 2018 14:47:28 -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.69.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151666124833.29662.2027318647035746565@ietfa.amsl.com> Date: Mon, 22 Jan 2018 14:47:28 -0800 Archived-At: Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-11.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: Mon, 22 Jan 2018 22:47:28 -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 : Authenticated Received Chain (ARC) Protocol Authors : Kurt Andersen Brandon Long Steven Jones Seth Blank Murray Kucherawy Filename : draft-ietf-dmarc-arc-protocol-11.txt Pages : 54 Date : 2018-01-22 Abstract: The Authenticated Received Chain (ARC) protocol creates a mechanism whereby a series of handlers of an email message can conduct authentication of the email message as it passes among them on the way to its destination, and record the status of that authentication at each step along the handling path, for use by the final recipient in making choices about the disposition of the message. Changes in the message that might break DKIM or DMARC can be identified through the ARC set of header fields. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-protocol/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-11 https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-arc-protocol-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-arc-protocol-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 22 14:50:44 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 41AF0126D74; Mon, 22 Jan 2018 14:50:34 -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.69.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151666143420.29825.14976064361643334478@ietfa.amsl.com> Date: Mon, 22 Jan 2018 14:50:34 -0800 Archived-At: Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-usage-04.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: Mon, 22 Jan 2018 22:50:34 -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 : Recommended Usage of the Authenticated Received Chain (ARC) Authors : Steven Jones Kurt Andersen John Rae-Grant J. Trent Adams Filename : draft-ietf-dmarc-arc-usage-04.txt Pages : 16 Date : 2018-01-22 Abstract: The Authentication Received Chain (ARC) provides a means to preserve email authentication results and verify the identity of email message handlers, each of which participates by inserting certain header fields before passing the message on. But the specification does not indicate how intermediaries and receivers should interpret or utilize ARC. This document will provide guidance in these areas. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-usage/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmarc-arc-usage-04 https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-arc-usage-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-arc-usage-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 22 15:06:49 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 B3DC7126DCA for ; Mon, 22 Jan 2018 15:06:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 YGZ0jJNgIKEV for ; Mon, 22 Jan 2018 15:06:46 -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 8BBCC1241F3 for ; Mon, 22 Jan 2018 15:06:45 -0800 (PST) Received: by mail-lf0-x233.google.com with SMTP id f136so12659284lff.8 for ; Mon, 22 Jan 2018 15:06:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:from:date:message-id:subject:to; bh=PVQ0OJpUsXlmF+kehgTf9ZvglpexXNb/WVRmaw1kPcI=; b=NWqLkhKYT2Z5PA1dpvNnc9Oxs2TNtjZvcYMvhXa1G4N3plWi74jWHaMR13iuGROp6/ EhHOenRkKOd92CEqXLdV7R1iKTM1aTPKpdxOki7Xd/qv5MLKupr6r38SMTHPS+O+KDYx ic1RSxjbpnNCuZa8cXIHFOUTyF9fa/idQeWjc= 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:from:date:message-id:subject :to; bh=PVQ0OJpUsXlmF+kehgTf9ZvglpexXNb/WVRmaw1kPcI=; b=ZIdE3P37bAUoByCV/mu7MB2V5D+0kKcho0j5UqWlSDhJjmBJV9nMN4DpFRbvszEZuO Z/PoGJ9U+96l3jhqaPMYKUASHHpSUJey54v2UqZfGExa9lzhCggZ4FfHZ0DEVSV3AzeK s02aWqydHjpABhDVW4EOOecFXGZP1KnuEiy5oeVOBPy7pxqMpX1khItbZ3SZNVqmoelc 60u5lkeylBp6T2fdlmqb6ujx1DmnfMMCNk8+xnO5q26GmHLeHyuxT1jL/7F0S4CruTD/ nOZL6vh0gudCl2LVH3qEm5OWZ5D8x0/emVTnukzdlpWZzaCYiju/wdkG5xALUzgZWakw Cm/w== X-Gm-Message-State: AKwxytfo1SJ5PX5AVfINvflBWwGvF+ZfTmBSwcR802LO4NI2hXIGj0Wi vMoVBugixhyVIqF6lJqsbjMIM+r1ONarbwi4FZexduvu X-Google-Smtp-Source: AH8x2253yQvEXLmiJmcfcxemFr8n3sMGaVtXs7u/XYr6EMST/S5Y4UNlOUdpsEEK7Mt7g6LmsW6Z1PXZ/KBcJ3ZJ08M= X-Received: by 10.46.32.76 with SMTP id g73mr233242ljg.75.1516662403388; Mon, 22 Jan 2018 15:06:43 -0800 (PST) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.25.193.138 with HTTP; Mon, 22 Jan 2018 15:06:42 -0800 (PST) From: "Kurt Andersen (b)" Date: Mon, 22 Jan 2018 15:06:42 -0800 X-Google-Sender-Auth: gVwWUWbb95ADr1LhUcoqbYG3Pck Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a1142bceccc67720563657ba1" Archived-At: Subject: [dmarc-ietf] New versions of the drafts submitted today (1/22) 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, 22 Jan 2018 23:06:47 -0000 --001a1142bceccc67720563657ba1 Content-Type: text/plain; charset="UTF-8" I submitted new versions with the following highlights: - usage-04: moves the "efficacy" section out of the usage document - protocol-11: - Changes status to "experimental", - adds in the "efficacy" section and - a variety of other notes are incorporated from the last draft version - removes the former section 10 to the new document below - Still does not incorporate the 7601bis change streamlining because I have not yet seen the 7601bis-01 to reference - multi-00: new document to specify how to deal with signing algorithm evolution; release is pending chair approval for the new doc --Kurt --001a1142bceccc67720563657ba1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I submitted new versions with the following highlights:
  • usage-04: moves the "efficacy" section out of the usage= document
  • protocol-11:=C2=A0
    • Changes status to "ex= perimental",=C2=A0
    • adds in the "efficacy" section an= d=C2=A0
    • a variety of other notes are incorporated from the last dra= ft version
    • removes the former section 10 to the new document below<= /li>
    • Still does not incorporate the 7601bis change streamlining because = I have not yet seen the 7601bis-01 to reference
  • multi-00: new = document to specify how to deal with signing algorithm evolution; release i= s pending chair approval for the new doc
--Kurt
--001a1142bceccc67720563657ba1-- From nobody Mon Jan 22 15:31:30 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 751C912D82F; Mon, 22 Jan 2018 15:31:23 -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.69.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151666388340.29511.6134716533130932183@ietfa.amsl.com> Date: Mon, 22 Jan 2018 15:31:23 -0800 Archived-At: Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-multi-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: Mon, 22 Jan 2018 23:31: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 : Using Multiple Signing Algorithms with the ARC (Authenticated Received Chain) Protocol Authors : Kurt Andersen Seth Blank John Levine Filename : draft-ietf-dmarc-arc-multi-00.txt Pages : 8 Date : 2018-01-22 Abstract: The Authenticated Received Chain (ARC) protocol creates a mechanism whereby a series of handlers of an email message can conduct authentication of the email message as it passes among them on the way to its destination. Initial development of ARC has been done with a single allowed signing algorithm, but parallel work in the DCRUP working group (https://datatracker.ietf.org/wg/dcrup/about/) is expanding the supported algorithms. This specification defines how to extend ARC for multiple signing algorithms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-multi/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmarc-arc-multi-00 https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-arc-multi-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 Jan 24 06:14:32 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 DCCED12422F for ; Wed, 24 Jan 2018 06:14:30 -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 eqdjP9nW1aan for ; Wed, 24 Jan 2018 06:14:29 -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 15F7A124319 for ; Wed, 24 Jan 2018 06:14:29 -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.102) id 1eeLoo-0004Tz-Go for dmarc@ietf.org (return-path ); Wed, 24 Jan 2018 14:14:26 +0000 References: To: dmarc@ietf.org From: Jeremy Harris X-Forwarded-Message-Id: Message-ID: Date: Wed, 24 Jan 2018 14:14:25 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: 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: Wed, 24 Jan 2018 14:14:31 -0000 On 22/01/18 22:47, internet-drafts@ietf.org wrote: > Filename : draft-ietf-dmarc-arc-protocol-11.txt [...] > https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-11 Section 5.3 defines the AMS as being identical, with exceptions, to a DKIM signature header. This might be taken to mean that the header name is "DKIM-Signature"; clarification would help, either by giving the header name to be used or by using wording like "The ARC-Message-Signature header field content is syntactically and semantically identical to"... The same applies to sections 5.2 and 5.4. The header fields are admittedly mentioned in section 2 "Overview". -- Cheers, Jeremy From nobody Wed Jan 24 07:53:27 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 E54E8126D46 for ; Wed, 24 Jan 2018 07:53:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=JU6XGDgl; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=WBiEAWOy 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 6EAXvjj6sBUc for ; Wed, 24 Jan 2018 07:53:23 -0800 (PST) Received: from mail.catinthebox.net (mail.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 7ECD0126C26 for ; Wed, 24 Jan 2018 07:53:23 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3670; t=1516809199; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=TAYNeGdP0kA+myecRa1mg/sGJwk=; b=JU6XGDglx34hfXXcj+BAfJV0zBgU0HqV9GvlAxCT476ncyTl7HBIPh1llXaMxx YJUrlkZHWCUODmxYIbVOKfFVlqUnvf12VtW6zR1dAfUdJ1qyg/X0XlFNOs3UzYq6 c1bBaOVBXw3THhtC81deFXmVlcX5nj/n+AQpuWSbffrpg= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Wed, 24 Jan 2018 10:53:19 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 2382901640.1.1628; Wed, 24 Jan 2018 10:53:18 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3670; t=1516808931; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=oWXovzj A23mUVClrXqqC8JSD5mJtNDDRX1tI8PHnm60=; b=WBiEAWOy8qexjKaSSRr/+9O TbYbm5MsYELiwydWcv7/h62i/LWCGntRVfrhuiBubZywkP1B2oJG123iZpcfCMaL aK5tNMcQvZtx4Ktad1pArdXfYgxBBpP8qvcDos05UUyge5rc0xc/QZtzjefGNVN0 +xuig24VSG49jcj/xAH0= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Wed, 24 Jan 2018 10:48:51 -0500 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 2382804314.9.384148; Wed, 24 Jan 2018 10:48:50 -0500 Message-ID: <5A68ABEC.4060501@isdg.net> Date: Wed, 24 Jan 2018 10:53:16 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <151666124833.29662.2027318647035746565@ietfa.amsl.com> In-Reply-To: <151666124833.29662.2027318647035746565@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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: Wed, 24 Jan 2018 15:53:26 -0000 Quick review note: The draft introduction talks about the "False Positive" problem with restrictive DMARC policies -- the reason why we are here. We need to keep in mind, DMARC also comes with "True Positives" DMARC failures as well. DMARC Author Domains who will either be ignorant (unaware of ARC) and/or does not wish to implement it (yet) and expect all DMARC failed messages to be handled according (rejects/quarantine) by receivers. This is expected to be especially true during the experimentation and migration to support period. We are here because of the reject/quarantine problem. People are not going to just stop processing this filter until ARC proves itself. For easier plug and play logic, the compliant ARC Receivers will need a signal from the DMARC Author Domain that ARC can/should be applied when DMARC failures. I suggest a new ARC section for an DMARC extended tag, "arc=" and/or using the first Author Domain created ARC header to signal ARC compliance. For the DMARC Extended Tag (throwing it out there): arc=0 ARC not expected to preempt failures (default) arc=1 The Original Domain signs with ARC, not required if author domain is the first seal. arc=y The Original Domain MAY NOT sign with ARC but others can to forward failed messages. Something like the above to convey the various possibilities the DMARC/ARC will mostly be encountering which will basically be: if DMARC fails { //========================== // NEW! Added ARC Policy support //========================== if Mail.Headers["ARC-Seal"].domain == AuthorDomain or DMARC.Tags["arc"] != "0" { Add ARC seals/headers return SUCCESS; } //========================== Fail the message return FAILURE; } Thanks On 1/22/2018 5:47 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Domain-based Message Authentication, Reporting & Conformance WG of the IETF. > > Title : Authenticated Received Chain (ARC) Protocol > Authors : Kurt Andersen > Brandon Long > Steven Jones > Seth Blank > Murray Kucherawy > Filename : draft-ietf-dmarc-arc-protocol-11.txt > Pages : 54 > Date : 2018-01-22 > > Abstract: > The Authenticated Received Chain (ARC) protocol creates a mechanism > whereby a series of handlers of an email message can conduct > authentication of the email message as it passes among them on the > way to its destination, and record the status of that authentication > at each step along the handling path, for use by the final recipient > in making choices about the disposition of the message. Changes in > the message that might break DKIM or DMARC can be identified through > the ARC set of header fields. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-protocol/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-11 > https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-arc-protocol-11 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-arc-protocol-11 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > -- HLS From nobody Wed Jan 24 18:39:20 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 5259E12D7EA for ; Wed, 24 Jan 2018 18:39:19 -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 UrNEtHH_CtuN for ; Wed, 24 Jan 2018 18:39:17 -0800 (PST) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C901124205 for ; Wed, 24 Jan 2018 18:39:17 -0800 (PST) Received: by mail-lf0-x229.google.com with SMTP id f136so7812130lff.8 for ; Wed, 24 Jan 2018 18:39:17 -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=+rq/4iDnpgAjMvBlhimQHSTwV9p7gRIlwu18/DyQdpc=; b=T0hsuwgEud3i2fnhkLbdixYUJccKB7WmAsBoP8fCMeA1SPAXQYCr/jaGun8pIUW6VB 4OpbjXdr+r1cDZSnV+/nVEeP6dt88CwS0eipM5QQUfx5re+SAO3hPzMmmPE7checmxMV 3i3UqAfEDSsxEpL1aG8CtcUUtgNPA2YwoXM6s= 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=+rq/4iDnpgAjMvBlhimQHSTwV9p7gRIlwu18/DyQdpc=; b=JNSwDK52UyUkIDKPDx4fLYFNlqYhfYG09el1hkp6JUzEqsWx8Vutv7r/3hVe9xgvMB YQ8jczwag9kZLdIChYEu9PoYINttA5XrHDQjZgU6O0c9mu/3Y4gLl/nIm1xGM0tmEisI WYHdAC3f7f8QU9RxlayLpARwJIgNbsZfd04rM6VVd/7AiGsXkUGkEPIMqjaZ2NC2w9Sv bGWtta2y93cU0/70YFsSWX+3jLOLzZK9lgU1PxhRp4Xq91olFNMFwEhcLXhWC19T8s+1 uNb+OL73BC6uew0RpJEnxd13J+NneTITV0v/TciGCEbN394RWR1sCnx1T4MbpVseNpMT yHtQ== X-Gm-Message-State: AKwxyteyckkY5H0O8O39OhxBuF+czVI3+fjhYsnGTHBxnBiJGh/x385y AjafGr3ARpYWUq7RACKaSnOPOeFSZIRTiWd7gEQllw== X-Google-Smtp-Source: AH8x225v1eh+Q+3QfkbCSHYtOyYE4wPX/ebBgBLeyw2Kj1w3xSGsNTdGsM6qz0RQOrTdRcvpHdrxHdGcVP9qhWoFl/I= X-Received: by 10.46.29.83 with SMTP id d80mr1719768ljd.95.1516847955299; Wed, 24 Jan 2018 18:39:15 -0800 (PST) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.25.193.138 with HTTP; Wed, 24 Jan 2018 18:39:13 -0800 (PST) In-Reply-To: References: From: "Kurt Andersen (b)" Date: Wed, 24 Jan 2018 18:39:13 -0800 X-Google-Sender-Auth: O8FYBSBAgvjgHVaF6l6_WtrlHsM Message-ID: To: Jeremy Harris Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c1ac16a8de1a0056390afb8" 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: Thu, 25 Jan 2018 02:39:19 -0000 --94eb2c1ac16a8de1a0056390afb8 Content-Type: text/plain; charset="UTF-8" On Wednesday, January 24, 2018, Jeremy Harris wrote: > > Section 5.3 defines the AMS as being identical, with exceptions, > to a DKIM signature header. This might be taken to mean that the > header name is "DKIM-Signature"; clarification would help, > either by giving the header name to be used or by using wording > like > > "The ARC-Message-Signature header field content is syntactically and > semantically identical to"... > > The same applies to sections 5.2 and 5.4. The header fields > are admittedly mentioned in section 2 "Overview". Thanks for the suggestion. Will incorporate into the next revision. --Kurt --94eb2c1ac16a8de1a0056390afb8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wednesday, January 24, 2018, Jeremy Harris <jgh@wizmail.org> wrote:
=
Section 5.3 defines the AMS as being identical, with exceptions,
to a DKIM signature header.=C2=A0 This might be taken to mean that the
header name is "DKIM-Signature"; clarification would help,
either by giving the header name to be used or by using wording
like

=C2=A0 "The ARC-Message-Signature header field content is syntacticall= y and
=C2=A0 =C2=A0semantically identical to"...

The same applies to sections 5.2 and 5.4.=C2=A0 The header fields
are admittedly mentioned in section 2 "Overview".

Thanks for the suggestion. Will incorporate into the next = revision.

--Kurt=C2=A0
--94eb2c1ac16a8de1a0056390afb8-- From nobody Wed Jan 24 18:39:28 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 9EFC312D7EA for ; Wed, 24 Jan 2018 18:39:20 -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 01QMCjhkhYWe for ; Wed, 24 Jan 2018 18:39:19 -0800 (PST) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (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 A175712AF6E for ; Wed, 24 Jan 2018 18:39:18 -0800 (PST) Received: by mail-lf0-x22e.google.com with SMTP id t79so7846541lfe.3 for ; Wed, 24 Jan 2018 18:39:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:from:date:message-id:subject:to:cc; bh=D2WHGUoR6wto7OPWle8+p8HBx9eJDF96lirtBNEEEgI=; b=b8xsTwV5Iepaesb9hZY/x7zXBj2IjDEkdlWDJS5nTe0BBNe2sz9QHR9p8CibxiG5Du k4wj4xn/zGEpRM1o2E83bcfYZlRX2T3KyXFCbesOqjHCMJLFFlj7ycC0cG/RNgoteEVu EtmJFWL90n0QtD86s4mT+t/HPXZ8b2nPWwd4E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=D2WHGUoR6wto7OPWle8+p8HBx9eJDF96lirtBNEEEgI=; b=PoCEKuS939imZtdP+QKLa+6JygUK+8rCqbfrF2+rFlKVux3RSHVISVFQ3tA0p2vVlw vCtSLgD3CR3mxAgWkDWt1vJrHyXhF+LwAblrSBLLUvpO746ZpXyBpQP6hGQwQDGMxKUd 2Pt60W37kJwKvr46AWLYj1u5wNOWZ9dND6HZnSKiyVNru2jNKDY1siUsPXC/Hn8TwKb/ mfPyhaIWuFJCh412lNGIPMLggZBym4ZG5Ckr0No3yVRjG7KRNfv21edbW9IWGu8RNkfJ +SJg7cmTJfhAe4ZIdR5fXKnZhaB29cBIjiCL51qQ9iwwy7rL6EE1Mt+HQ2r3PVyIJzrF bOGg== X-Gm-Message-State: AKwxyteNwxAs3oshjZHavbyKDhLdIeECn3K8RWDkxV/qAVIxDOamiV5b n/ATSYN5Vrd0KMF/0CbHNs/+y8xFWZzT/NQ8HCWeMWnu X-Google-Smtp-Source: AH8x224Ed3njHqNDc5MCDsOJu6uSYlpodVUTuK9uQX59QCuLpoPaGLOwsbOTr9GfwHwjIDlTViOrt4HybzHwvUcAmHI= X-Received: by 10.25.21.22 with SMTP id l22mr4735951lfi.143.1516847956738; Wed, 24 Jan 2018 18:39:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.193.138 with HTTP; Wed, 24 Jan 2018 18:39:14 -0800 (PST) From: Kurt Andersen Date: Wed, 24 Jan 2018 18:39:14 -0800 Message-ID: To: Hector Santos Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a113fc088a3d5a3056390afb7" Archived-At: Subject: Re: [dmarc-ietf] Adapting DMARC for ARC (synthetic topic change) 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, 25 Jan 2018 02:39:20 -0000 --001a113fc088a3d5a3056390afb7 Content-Type: text/plain; charset="UTF-8" On Wednesday, January 24, 2018, Hector Santos wrote: > Quick review note: > > The draft introduction talks about the "False Positive" problem with > restrictive DMARC policies -- the reason why we are here. > > We need to keep in mind, DMARC also comes with "True Positives" DMARC > failures as well. > Hector, This sort of suggestion will be just the sort of thing to discuss when the WG moves into the next milestone phase of work. Given our timeline track record, I'm not sure when that might be :-/ but seems like a reasonable subject of discussion in London at IETF101. Chairs - can we get a F2F on the schedule for London? --Kurt --001a113fc088a3d5a3056390afb7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wednesday, January 24, 2018, Hector Santos <hsantos@isdg.net> wrote:
Date: Wed, 24 Jan 2018 18:39:16 -0800 X-Google-Sender-Auth: A1Z8JU_fZL-_IOdRwGnHWMrJQeo Message-ID: To: Barry Leiba , Tim Draegen , Ned Freed Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a114037d0bd4c1b056390af51" Archived-At: Subject: [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, 25 Jan 2018 02:39:21 -0000 --001a114037d0bd4c1b056390af51 Content-Type: text/plain; charset="UTF-8" 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. IETF101 would be a great opportunity to discuss the next steps for the WG. --Kurt --001a114037d0bd4c1b056390af51 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'd like to request a F2F meeting in London at IETF101. I plan to creat= e 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 coul= d launch WGLC for the ARC protocol before the end of February.=C2=A0
<= div>
IETF101 would be a great opportunity to discuss the next= steps for the WG.

--Kurt
--001a114037d0bd4c1b056390af51-- From nobody Wed Jan 24 19:23:06 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 31F3812D7EC for ; Wed, 24 Jan 2018 19:23:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=WEyzNCbF; dkim=pass (1536-bit key) header.d=taugh.com header.b=fbfs9iDQ 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 TOLGI04geiqY for ; Wed, 24 Jan 2018 19:23:02 -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 223E212711E for ; Wed, 24 Jan 2018 19:23:01 -0800 (PST) Received: (qmail 4911 invoked from network); 25 Jan 2018 03:23:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=1327.5a694d94.k1801; bh=5E1vNWdrejfuYxDtoTykx9DhScgEvAQWc+QPOggpJLY=; b=WEyzNCbFbmM6ovudO3inY6o0c0BqO8yA6h+N4m++yq0Ca2GnUik+SJc2nqu0N+aXOYPtPqh9pVpbAvQkalimT4hsP0xdkzMNKeijoOwBqBuA2KODQIPsK6bazQaatUvCv5LInsVGrkulq6eO6Ar1MRmKQCjdyX4TmBkEpT1NOp1D4JD64GVZzkZldLb3B8TkCS2tmQDTVKZhLAhOUust/qA6JLVIY13ErUOOMIOTm5OiutOw02nFr8CbLkypf6+E DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=1327.5a694d94.k1801; bh=5E1vNWdrejfuYxDtoTykx9DhScgEvAQWc+QPOggpJLY=; b=fbfs9iDQV+fTBZUQ1F67udkgcfPs6MGrVB0MeMeE6E+Hclrg6iDPSGzxDJjPNxUeHe0hW1OgY1ysZanHpJGbd4RsdgqTLlX//0T88XCpX7jGBhhtNmHTm8RDPougJVO2/BPawzqPhPzVcyRFJjOHbWYcs/XETaRAamAA5WRtb42PIV6/tlwNjyUWEutQELDqoyprRW2rMVAWV6Scyo7KxswH7zVIPG6rtwHo7LZdss9vmjAXey9z4/EQ1352uDrB 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; 25 Jan 2018 03:23:00 -0000 Received: by ary.qy (Postfix, from userid 501) id 6C69E19C59D1; Wed, 24 Jan 2018 22:22:59 -0500 (EST) Date: 24 Jan 2018 22:22:59 -0500 Message-Id: <20180125032300.6C69E19C59D1@ary.qy> From: "John Levine" To: dmarc@ietf.org, kboth@drkurt.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] 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, 25 Jan 2018 03:23:04 -0000 The WG chairs do it online, start here: https://datatracker.ietf.org/accounts/login/?next=/secr/sreq/ R's, John From nobody Fri Jan 26 12:24:09 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 8939F12762F for ; Fri, 26 Jan 2018 12:24:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fiction.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 1KuN5yV6HX5h for ; Fri, 26 Jan 2018 12:24:05 -0800 (PST) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::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 D909B124B17 for ; Fri, 26 Jan 2018 12:24:04 -0800 (PST) Received: by mail-io0-x231.google.com with SMTP id b198so1679970iof.6 for ; Fri, 26 Jan 2018 12:24:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fiction.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TIJuux/gtQPMVJOGPKVxfJHYqiU9D4g9f5D01WsFas4=; b=U7ZJLkCrzMq3uuzLqj/23TYRloMVH4ZSC1wOaYu/wItGeHfkTNiDgyeEguYc/XBeCx McfaeKNELY9b1H3COjPZtrkIIFlfkFfU+oiXDKILpfJwqp9dDCnYVjjaE2wtrEoJvLSL 942YkkLiP31eMcnQD+jV7RTMl54JCPSR4waJqImQZZR0Pmm9wrGYfeQkGYCmmufKh4J0 xd/m9wesc3P8yKHKuh5CCQiR/fiU1bS1Q7FtHbZDyGRc/7fU3TzivPT75OmkCJTw4MOJ Fwm3PlN6PHxs9hESQAx1gSdBZ34/ASV2mWgtNFr5cEkAx8wGuAE7h4dKy6mm6dhMURSc Cb3A== 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=TIJuux/gtQPMVJOGPKVxfJHYqiU9D4g9f5D01WsFas4=; b=YqkX0I9Cocma1ZupWWjKEFshSMbT5usA+q1eTyFBrdyWaHyGxi+7J65Gq4FWg2rNB+ 6H2jMwbq5K9dDf31UIFSGcmrT7E7fI48Kiaye3OYkdJLgHhFSSVaPD+er/JQ7XrIDviC owzz+72YjEGdDk6VQZvX0olKT5m9liRcxqjTf2mDOOO67PUrCeuHd6TXP2NVRUBSRYWH DwMqsUBjbATXh2J6rmQtUSDKLpjt5E7Cnbete+cg4XH6kpFq1IIEdG2BrhyWcV5J0Nc4 D+DzNhmu0pRGpm5C+pKpSdkJycUuZ2xkNrT5+0KAyZeVylTIgDcu/+yS/93Y0WuVx0vw UZ4Q== X-Gm-Message-State: AKwxytfD0R/FOvf+cBC3qUDI0vjvWwdmoZ0caBXrZpslitBKgg78X9xz JFuLjUPNzqpxdPvFnHJ6nJAhYWLQ X-Google-Smtp-Source: AH8x224QjwrMA5HZsO+IdYxFNBr0CDYt368/5s8CPQAHJp1SSWd9NLlL4cCAmDPyy7ui7zXhmiNB9A== X-Received: by 10.107.18.232 with SMTP id 101mr18170742ios.164.1516998243905; Fri, 26 Jan 2018 12:24:03 -0800 (PST) Received: from mail-io0-f180.google.com (mail-io0-f180.google.com. [209.85.223.180]) by smtp.gmail.com with ESMTPSA id y186sm897963ioy.57.2018.01.26.12.24.01 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Jan 2018 12:24:01 -0800 (PST) Received: by mail-io0-f180.google.com with SMTP id f4so1682832ioh.8 for ; Fri, 26 Jan 2018 12:24:01 -0800 (PST) X-Received: by 10.107.201.136 with SMTP id z130mr3957384iof.257.1516998241140; Fri, 26 Jan 2018 12:24:01 -0800 (PST) MIME-Version: 1.0 References: <151666124833.29662.2027318647035746565@ietfa.amsl.com> <5A68ABEC.4060501@isdg.net> In-Reply-To: <5A68ABEC.4060501@isdg.net> From: Brandon Long Date: Fri, 26 Jan 2018 20:23:45 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Hector Santos Cc: dmarc@ietf.org Content-Type: multipart/alternative; boundary="94eb2c0b8cd84a8aea0563b3adc3" 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: Fri, 26 Jan 2018 20:24:08 -0000 --94eb2c0b8cd84a8aea0563b3adc3 Content-Type: text/plain; charset="UTF-8" I sometimes override DMARC p=quarantine failures with filters, does DMARC require a filters extended tag and compliance by mail clients to not allow overriding of the filters if the domain requests it? My point is, fundamentally in the mail eco-system, whether something is delivered or rejected or labeled as spam is at the discretion of the receiver. Having increasing levels of "but I really mean it" for DMARC is not useful. Also, the sender doesn't implement ARC, so why should they care? Also, I think some of this already happens today based on reports. We get complaints about where we override DMARC from domains all the time, and that goes into our work on making our overrides more correct. I don't see how arc=n helps that at all. If you wanted to help that, you'd want some mechanism or automation with which a domain owner could tell a particular mailbox provider that they're doing a bad job, and that's a lot more complicated than arc=n. Brandon On Wed, Jan 24, 2018 at 7:53 AM Hector Santos wrote: > Quick review note: > > The draft introduction talks about the "False Positive" problem with > restrictive DMARC policies -- the reason why we are here. > > We need to keep in mind, DMARC also comes with "True Positives" DMARC > failures as well. DMARC Author Domains who will either be ignorant > (unaware of ARC) and/or does not wish to implement it (yet) and expect > all DMARC failed messages to be handled according (rejects/quarantine) > by receivers. This is expected to be especially true during the > experimentation and migration to support period. We are here because > of the reject/quarantine problem. People are not going to just stop > processing this filter until ARC proves itself. > > For easier plug and play logic, the compliant ARC Receivers will need > a signal from the DMARC Author Domain that ARC can/should be applied > when DMARC failures. I suggest a new ARC section for an DMARC > extended tag, "arc=" and/or using the first Author Domain created ARC > header to signal ARC compliance. > > For the DMARC Extended Tag (throwing it out there): > > arc=0 ARC not expected to preempt failures (default) > > arc=1 The Original Domain signs with ARC, not required > if author domain is the first seal. > > arc=y The Original Domain MAY NOT sign with ARC but > others can to forward failed messages. > > Something like the above to convey the various possibilities the > DMARC/ARC will mostly be encountering which will basically be: > > if DMARC fails > { > //========================== > // NEW! Added ARC Policy support > //========================== > if Mail.Headers["ARC-Seal"].domain == AuthorDomain > or DMARC.Tags["arc"] != "0" > { > Add ARC seals/headers > return SUCCESS; > } > //========================== > Fail the message > return FAILURE; > } > > Thanks > > > On 1/22/2018 5:47 PM, internet-drafts@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Domain-based Message Authentication, > Reporting & Conformance WG of the IETF. > > > > Title : Authenticated Received Chain (ARC) Protocol > > Authors : Kurt Andersen > > Brandon Long > > Steven Jones > > Seth Blank > > Murray Kucherawy > > Filename : draft-ietf-dmarc-arc-protocol-11.txt > > Pages : 54 > > Date : 2018-01-22 > > > > Abstract: > > The Authenticated Received Chain (ARC) protocol creates a mechanism > > whereby a series of handlers of an email message can conduct > > authentication of the email message as it passes among them on the > > way to its destination, and record the status of that authentication > > at each step along the handling path, for use by the final recipient > > in making choices about the disposition of the message. Changes in > > the message that might break DKIM or DMARC can be identified through > > the ARC set of header fields. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-protocol/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-11 > > https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-arc-protocol-11 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-arc-protocol-11 > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > dmarc mailing list > > dmarc@ietf.org > > https://www.ietf.org/mailman/listinfo/dmarc > > > > > > -- > HLS > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --94eb2c0b8cd84a8aea0563b3adc3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I sometimes override DMARC p=3Dquarantine failures with fi= lters, does DMARC require a filters extended tag and compliance by mail cli= ents to not allow overriding of the filters if the domain requests it?
=
My point is, fundamentally in the mail eco-system, whether s= omething is delivered or rejected or labeled as spam is at the discretion o= f the receiver.=C2=A0 Having increasing levels of "but I really mean i= t" for DMARC is not useful.

Also, the sender doesn't implem= ent ARC, so why should they care?

Also, I think so= me of this already happens today based on reports.=C2=A0 We get complaints = about where we override DMARC from domains all the time, and that goes into= our work on making our overrides more correct.=C2=A0 I don't see how a= rc=3Dn helps that at all.=C2=A0 If you wanted to help that, you'd want = some mechanism or automation with which a domain owner could tell a particu= lar mailbox provider that they're doing a bad job, and that's a lot= more complicated than arc=3Dn.

Brandon


On Wed, Jan 24, 2018 a= t 7:53 AM Hector Santos <hsantos@isd= g.net> wrote:
Quick review n= ote:

The draft introduction talks about the "False Positive" problem w= ith
restrictive DMARC policies -- the reason why we are here.

We need to keep in mind, DMARC also comes with "True Positives" D= MARC
failures as well.=C2=A0 DMARC Author Domains who will either be ignorant (unaware of ARC) and/or does not wish to implement it (yet) and expect
all DMARC failed messages to be handled according (rejects/quarantine)
by receivers.=C2=A0 This is expected to be especially true during the
experimentation and migration to support period.=C2=A0 We are here because<= br> of the reject/quarantine problem. People are not going to just stop
processing this filter until ARC proves itself.

For easier plug and play logic, the compliant ARC Receivers will need
a signal from the DMARC Author Domain that ARC can/should be applied
when DMARC failures.=C2=A0 =C2=A0I suggest a new ARC section for an DMARC extended tag, "arc=3D" and/or using the first Author Domain creat= ed ARC
header to signal ARC compliance.

For the DMARC Extended Tag (throwing it out there):

=C2=A0 =C2=A0 arc=3D0=C2=A0 =C2=A0 =C2=A0ARC not expected to preempt failur= es (default)

=C2=A0 =C2=A0 arc=3D1=C2=A0 =C2=A0 =C2=A0The Original Domain signs with ARC= , not required
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if author domain is the fi= rst seal.

=C2=A0 =C2=A0 arc=3Dy=C2=A0 =C2=A0 =C2=A0The Original Domain MAY NOT sign w= ith ARC but
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 others can to forward fail= ed messages.

Something like the above to convey the various possibilities the
DMARC/ARC will mostly be encountering which will basically be:

=C2=A0 =C2=A0if DMARC fails
=C2=A0 =C2=A0{
=C2=A0 =C2=A0 =C2=A0 //=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
=C2=A0 =C2=A0 =C2=A0 // NEW!=C2=A0 Added ARC Policy support
=C2=A0 =C2=A0 =C2=A0 //=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
=C2=A0 =C2=A0 =C2=A0 if Mail.Headers["ARC-Seal"].domain =3D=3D Au= thorDomain
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0or DMARC.Tags["arc"] !=3D "= ;0"
=C2=A0 =C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Add ARC seals/headers
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return SUCCESS;
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 //=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
=C2=A0 =C2=A0 =C2=A0 Fail the message
=C2=A0 =C2=A0 =C2=A0 return FAILURE;
=C2=A0 =C2=A0}

Thanks


On 1/22/2018 5:47 PM, internet-drafts@ietf.org wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the Domain-based Message Authentication, = Reporting & Conformance WG of the IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: Authenticated Received Chain (ARC) Protocol
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: Kurt Andersen
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 Brandon Long
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 Steven Jones
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 Seth Blank
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 Murray Kucherawy
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-dmarc-arc-protocol-11.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 54
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2018-01-22
>
> Abstract:
>=C2=A0 =C2=A0 =C2=A0The Authenticated Received Chain (ARC) protocol cre= ates a mechanism
>=C2=A0 =C2=A0 =C2=A0whereby a series of handlers of an email message ca= n conduct
>=C2=A0 =C2=A0 =C2=A0authentication of the email message as it passes am= ong them on the
>=C2=A0 =C2=A0 =C2=A0way to its destination, and record the status of th= at authentication
>=C2=A0 =C2=A0 =C2=A0at each step along the handling path, for use by th= e final recipient
>=C2=A0 =C2=A0 =C2=A0in making choices about the disposition of the mess= age.=C2=A0 Changes in
>=C2=A0 =C2=A0 =C2=A0the message that might break DKIM or DMARC can be i= dentified through
>=C2=A0 =C2=A0 =C2=A0the ARC set of header fields.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc= /draft-ietf-dmarc-arc-protocol/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-i= etf-dmarc-arc-protocol-11
> https://datatracker.ietf.= org/doc/html/draft-ietf-dmarc-arc-protocol-11
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdif= f?url2=3Ddraft-ietf-dmarc-arc-protocol-11
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org. >
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org=
> https://www.ietf.org/mailman/listinfo/dmarc
>
>

--
HLS


_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--94eb2c0b8cd84a8aea0563b3adc3-- From nobody Mon Jan 29 07:52:52 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 765BC131808 for ; Mon, 29 Jan 2018 07:52:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=c7fDXAGc; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=QXmGxOO2 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 bIzL4_GZ_Ga2 for ; Mon, 29 Jan 2018 07:52:48 -0800 (PST) Received: from pop3.winserver.com (ftp.catinthebox.net [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id CAE93127011 for ; Mon, 29 Jan 2018 07:51:23 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=5089; t=1517241079; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=FStrejOch3DBeGYa/5Dm+Bc+XvM=; b=c7fDXAGcrZ/V7xYmarhX42rd9kccU2Osi2rCnFC9MwUegWZUfVDJRZjMfbzfDe kAYIMnM/BPiuVkBK6k80R8adk6dPsxpx6mWzydIJTeKvdCwCH/8+7Jlf+s8HjdA8 ykfYECh1cd41B/GXnbNV/UQ8PpMiu/2pu/qtZkT1OtFvo= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Mon, 29 Jan 2018 10:51:19 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 2814777242.20357.3372; Mon, 29 Jan 2018 10:51:19 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=5089; t=1517240803; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=/RZRL1w ESNO2NglijXO81kynxOsqFwvl8GCDR73T38s=; b=QXmGxOO221vgqDf2vjpMdOI 4G4gLJwjLqnueECA1LdxK9J3AfTTSjVbhfADkjudoAkNj+Ni+PRFnnZyztDB1eVQ 328pLQW7kvVxuyL1hHNzVkFIihEiuX1kHZfDt7KcJdgnuLjBjSgWXOyhHraOAII3 kp4ghCHSyueUc/QFOxNc= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Mon, 29 Jan 2018 10:46:43 -0500 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 2814676298.9.153928; Mon, 29 Jan 2018 10:46:42 -0500 Message-ID: <5A6F42F3.2070700@isdg.net> Date: Mon, 29 Jan 2018 10:51:15 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: Brandon Long CC: dmarc@ietf.org References: <151666124833.29662.2027318647035746565@ietfa.amsl.com> <5A68ABEC.4060501@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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: Mon, 29 Jan 2018 15:52:51 -0000 Hi, On 1/26/2018 3:23 PM, Brandon Long wrote: > I sometimes override DMARC p=quarantine failures with filters, does > DMARC require a filters extended tag and compliance by mail clients to > not allow overriding of the filters if the domain requests it? Local Policy always prevails. But we all work towards developing a common protocol and hopefully, and ideally, do so on a cooperative competitive basis where all nodes are treated the same at the protocol level. The add-on value may be what the implementation may offer at the local level to customers, i.e. features, options, etc. 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. See RFC5016, "Requirements for a DomainKeys Identified Mail (DKIM) Signing Practices Protocol." Also note section 5.3 Item 10 which basically reminds us about Local Policy expectations. But to me, thats just a protocol option: How should DMARC failures be handled? (o) Reject with _55x_ SMTP rejection code (_) Quarantine to user's spam box. [X] NEW! Check for the DMARC arc= tag. etc. I will have something like that in my implementation and even more options as we learn more how ARC is suppose to operate and fit in with the rest of the DKIM/POLICY/TRUST architectural model and system. Others may automatically presumed everything is accepted (250 reply code) and put into the user's spam box where it can be eyeballed by them (or completely forgotten by them). Some here strongly believe that is the only to operate (never reject). I believe in options. > My point is, fundamentally in the mail eco-system, whether something > is delivered or rejected or labeled as spam is at the discretion of > the receiver. Having increasing levels of "but I really mean it" for > DMARC is not useful. yes, thats a given, always, Local Policy always prevails. But that is exactly why the extended policy signal would offer a more explicit indication of the the domain's intent. With no tag, there is an element of "fuzziness" for the receiver on whether it is doing the right thing. If the domain has arc=0, then the compliant ARC/DMARC receiver SHOULD honor the intent of the protocol when the policy is restrictive. If the domain has arc != 0, then the compliant ARC/DMARC receiver CAN|MAY use ARC to preempt a restrictive policy DMARC failure. There is no ambiguity now, both technically and legally, if I may add, presuming that there may be DMARC domains who do not want any ARC processing of failed mail, using ARC to bypass a True Positive failure may have some level of liability concerns. i.e. you can't ignore this consideration. > Also, the sender doesn't implement ARC, so why should they care? Because of the point above. Its always better to be protocol specific. Also consider the ARC-ignorant receiver (who just doesn't know anything about it) but it supports DMARC, it may honor restrictive policies. That would be the DMARC protocol expectation. It would behave with an default 'arc=0" policy when it reads a DMARC record because it knows nothing about it. > Also, I think some of this already happens today based on reports. We > get complaints about where we override DMARC from domains all the > time, and that goes into our work on making our overrides more > correct. I don't see how arc=n helps that at all. There will be domains who will not want to participate in a concept that can bypass true positive DMARC failures -- it can be viewed as security loophole. Having an indicator will definitely help receivers with their processing logic, including development and usage of APIs. Without it, ARC will add a new element of DMARC processing fuzziness unless you are presuming that any receiver even contemplating ARC implies that the receiver is automatically going to ignore author domain wishes. Be careful with that because that would be enough for some implementators and domains to nix the whole ARC idea. > If you wanted to > help that, you'd want some mechanism or automation with which a domain > owner could tell a particular mailbox provider that they're doing a > bad job, and that's a lot more complicated than arc=n. Yes I would think that would be more complex, but also a different idea. Receivers are already doing a DMARC lookup. Adding an extended tag like "arc=" will assist receivers in how to process failures without ambiguity. To me, the only real protocol design question would be what ARC would recommend as the default "arc=" value. Using "arc=1" as the default would presume ARC can bypass any DMARC failure without explicit permission from the Author Domain. The burden would be on the current DMARC p=reject/quarantine policies domains to add an "arc=0" to tell receivers "Please don't skip failures by using ARC." Thanks -- HLS From nobody Tue Jan 30 11:05:26 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 189EB12FA95 for ; Tue, 30 Jan 2018 11:05:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 feInN6WqrnPl for ; Tue, 30 Jan 2018 11:05:22 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6419A126B6D for ; Tue, 30 Jan 2018 11:05:22 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id y80so11525543qkb.4 for ; Tue, 30 Jan 2018 11:05:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=yy02/nTqMok+OfLIBHWR1zrhD3DzPVtECWvOkDT6Cdc=; b=WFz1+ISFWg1pdicrUEGYRKCbWcmIwqxjtZ+FT4tcdgK6FpoHI0rw+loiBig4do6X1Y 0kqE8Ve14/4hMrXbWqy+9z5oi7KwU75p+gWPy1ycthlJ0EHiMlCy3SuaZEJKMjsudogY GhG6/K5Dec74dna+yO67ZWS7u86mZ7KPPI+i4IWTGR2KNiYEg3nFOCDzwDjvSHuFg13j 3Ix9HXPyY0Z9kr5jRD7ovHXkrgXaa9MxVltgmlbxal/O57aB72t9hq/nbAHVII3okZY+ Db8OGnrqyO16YLP3AUGjoXLd4RWfMbrul7poN55aioJ45Ox9K9SIRPXkZkBUvU32xbK8 WEDQ== 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=yy02/nTqMok+OfLIBHWR1zrhD3DzPVtECWvOkDT6Cdc=; b=s44aNaXqlF7hiMk6K5PHbTUzPUT3JwRZ6Snwogcc0TJ7nv9YOZuAPv2LGmEkYuy9pn A3mabxWgRggaSHRxOwCQUdloCA66KiPCI0GF57agWkXHkRrM8DDJ/QLhu3TDMd/sNv/Q FkulP8tsVGaxFlmH0M+OLQ4CTG7DeloNUpWBmEV2kbwH7dFgDnT4EsSzKKhbFhYRFTBc D2y6qZ+MA61GyfQIvydQuEJakGLwQmSJscgLFcKH5likPCjysrEBxalSiQ2jfRjlL1e/ bMynEj5nuquiUaouyH2mzhu/VNT19BIcl7OcdZT9WhswZ4K+leQgFmkpwWEKVS0jn2Io i9ew== X-Gm-Message-State: AKwxytdsy9G8hCbGO/BCIz5cCqzKQ7wlZvGVxNse3hH81A4yGlDwEa16 3uw3DAcEyM5+S3MYAGj5rJyQU5tJRL1gdaxnL3A= X-Google-Smtp-Source: AH8x227EHleT5kB3v0k9vq+8M6lkX/mSX17+/yxy0/GUtHScmUH17oeqllsDzbXCm8z5zqLjCXIlcZY1vOPUwyEK5ZM= X-Received: by 10.55.86.195 with SMTP id k186mr33448992qkb.338.1517339121503; Tue, 30 Jan 2018 11:05:21 -0800 (PST) MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 10.200.35.199 with HTTP; Tue, 30 Jan 2018 11:05:21 -0800 (PST) In-Reply-To: References: From: Barry Leiba Date: Tue, 30 Jan 2018 14:05:21 -0500 X-Google-Sender-Auth: KBAexiRUwVrZVeMqJe10MNsjJ9A Message-ID: To: "Kurt Andersen (b)" Cc: Tim Draegen , Ned Freed , "dmarc@ietf.org" Content-Type: text/plain; charset="UTF-8" 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, 30 Jan 2018 19:05:24 -0000 > 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. > 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. I expect that we won't be spending any of that session time on the ARC protocol document itself. 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. Barry, off to make a session request From nobody Tue Jan 30 11:10:52 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 D0BE212E896; Tue, 30 Jan 2018 11:10:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: aamelnikov@fastmail.fm, dmarc@ietf.org, barryleiba@gmail.com, dmarc-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.70.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151733944979.31740.4024374479217772228.idtracker@ietfa.amsl.com> Date: Tue, 30 Jan 2018 11:10:49 -0800 Archived-At: Subject: [dmarc-ietf] dmarc - New Meeting Session Request 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, 30 Jan 2018 19:10:50 -0000 A new meeting session request has just been submitted by Barry Leiba, a Chair of the dmarc working group. --------------------------------------------------------- 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 ---------------------------------------------------------