From nobody Tue Sep 5 14:52:36 2017 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 6D70812EC30 for ; Tue, 5 Sep 2017 14:52:34 -0700 (PDT) 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 7zicyq0ZSd0Z for ; Tue, 5 Sep 2017 14:52:32 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003: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 BDC1312422F for ; Tue, 5 Sep 2017 14:52:31 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id r20so3500077oie.0 for ; Tue, 05 Sep 2017 14:52:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=g9fb+NSzSyULlYbpmRhhPJAs7UPXJj6/3Weef9W0JZA=; b=bi1ocToS2xqpCPQf2mvMV+xDiwdWxLY4EGg7eoiUFLJULZlwRZbw6FwCGsT89pJHZO yosHaihno7YTYF3FsuIBq9/AgOe+G9kLNM2Pv/Jn2t7xX2E/zja9pQTWqJMLhmud2lKN jOG5UJPyUVe9yKWO9r44ig7vUu5N7qbin/oDgvqSKuvL+8IJCjtM1fMgudplwsZKYDBx WXETJSHnwlqvbjiemAFrDYe8MEMKSmWU1xzFvnmZe4K4mpM3uez9cy7MBfPHFCrHm9nl 4+RsbY1PJ78fPZKZL5OsWe1E1BRK374R3NCcRWKYc7AgIE8H8Qz+91HjCMyM2YB9aKeF H4Kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=g9fb+NSzSyULlYbpmRhhPJAs7UPXJj6/3Weef9W0JZA=; b=Fa4lFGIFtvkUia5h6RMX1+CRIOe2kiV2mV0CeYbwSp/FioQ7Cu/HM+OA+GBRUWAUKq Aju6CItybWsndSYbPhr6VS9EFGN1RevcTaDUXkM8y2I6tuwEX8pdjQvQZs8aCXcMyW3y lt2h0xYUSjuFPcHX4rE3uF0QaVdb82nEP44Hgk/zTEYt0f/1+jsfJlnddSZjTXG+Y4uX dyUQaJM7/zO12nFfT3k6z9LF/jnYEh//dC5FzK8x0lAW0cgLieZ09dUfsppNcSQfoKeE pxiLouWtfrdCQGPrjorv3HkSarG82eahxDNB5TeSIEI3wIQcDSKaJHAnIX9qFKLxrF6U sylA== X-Gm-Message-State: AHPjjUjGwFHcRDf1Vy3oRf6qZLrR5piiQbjKDgHlyhLElrSCZaESSNC5 TRWJzoSH4TpSl7r5Yhy3PJkZwlIsYGAZ4TxCUw== X-Google-Smtp-Source: ADKCNb51l8/+TRb7r1tAPNQ3HDWuLl3ayDSPQ2EsyrOvcMWJnXo9m8/d5yF7jCl4f6TXz+C2yz0Q/NGR7902qRbnPq4= X-Received: by 10.202.215.8 with SMTP id o8mr544363oig.247.1504648350538; Tue, 05 Sep 2017 14:52:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.88.139 with HTTP; Tue, 5 Sep 2017 14:52:10 -0700 (PDT) From: Seth Blank Date: Tue, 5 Sep 2017 14:52:10 -0700 Message-ID: To: dmarc@ietf.org Content-Type: multipart/alternative; boundary="001a113d38027236e70558783ee8" Archived-At: Subject: [dmarc-ietf] ARC draft-08 updates to section 5.1 and WG questions 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, 05 Sep 2017 21:52:34 -0000 --001a113d38027236e70558783ee8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable There have been substantial comments both on and off list about section 5.1.1. I've suggested new language for all of 5.1, below, to remove normative modification of 7601, and address several other issues. There are questions for the WG below the suggested text. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Replace 5.1 with: The ARC-Authentication-Results (AAR) header field is semantically and syntactically identical to the Authentication-Results header defined in [RFC7601#2.2] as authres-header (A-R), except that the first element =E2=80=9CAuthentication-Results:=E2=80=9D in authres-header is replaced wit= h arc-authres-prefix as follows: arc-authres-header-prefix =3D "ARC-Authentication-Results:" [CFWS] arc-i= nfo arc-info =3D %x69 =E2=80=9C=3D=E2=80=9D arc-hop *([CFWS] =E2=80=9C;=E2= =80=9D [CFWS] propspec) [CFWS] =E2=80=9C;=E2=80=9D arc-hop =3D 1*2DIGIT ; 1-50 The purpose of this header field is to transmit the results of any authentication done on the message upstream to participating ADMDs validating and continuing the chain. The AAR MUST contain all A-R results from within the participating ADMD, regardless of how many A-R headers are on the message. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Replace 5.1.1 with: 5.1.1. ptypes and properties for arc-info Certain information pertinent to ascertaining message disposition can be lost in transit when messages are handled by intermediaries. For example, failing DKIM signatures are sometimes removed by MTAs, and most DKIM signature on messages modified by intermediaries will fail. Therefore, a passing DKIM-Signature from the first ARC signer is likely to have been removed by final receipt of the message. The AAR, and in particular the ptype-properties stamped in arc-info, provide a mechanism for this information to survive transit. The ptypes and properties defined in this section SHOULD be stamped in the AAR: * smtp.client_id - The connecting client IP address from which the message is received; * header.ds - The domain/selector pair for each dkim signature on the message (header.ds=3Dexample.com,selector) * arc.closest_fail - The hop number of the most recent AMS that fails to validate, or 0 if all hops pass. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Open questions: 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 =3D "Authentication-Results:" [CFWS] authserv-id [ CFWS authres-version ] ( no-result / 1*resinfo ) [CFWS] CRLF Optimally, there would be: authres-payload =3D [CFWS] authserv-id [ CFWS authres-version ] ( no-result / 1*resinfo ) [CFWS] CRLF And then we could have: arc-authres-header =3D "ARC-Authentication-Results:" [CFWS] arc-info authres-payload 2) The optimal way to transmit DKIM selector information is in the DKIM A-R methodspec as header.s. If we want to prevent a normative modification of 7601, I've proposed "header.ds" which will accomplish the same thing. 3) In the ARC-Seal megathread, there was an aside about knowing the last hop which validated: 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. 4) Have the ptype-properties been defined properly, and will these AAR ptype-properties need an IANA registry? 5) Finally, the ams[n] and as[n] entities were dropped, as these values are guaranteed to be on the final message if an ARC chain passes, so there's no need to encode them separately. Seth --001a113d38027236e70558783ee8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There have been substantial comments both on and off list = about section 5.1.1. I've suggested new language for all of 5.1, below,= to remove normative modification of 7601, and address several other issues= . There are questions for the WG below the suggested text.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

<= div>Replace 5.1 with:

The ARC-Authentication-Resul= ts (AAR) header field is semantically and syntactically identical to the Au= thentication-Results header defined in [RFC7601#2.2] as authres-header (A-R= ), except that the first element =E2=80=9CAuthentication-Results:=E2=80=9D = in authres-header is replaced with arc-authres-prefix as follows:

=C2=A0 =C2=A0arc-authres-header-prefix =3D "ARC-Authen= tication-Results:" [CFWS] arc-info

=C2=A0 =C2= =A0 arc-info =3D %x69 =E2=80=9C=3D=E2=80=9D arc-hop *([CFWS] =E2=80=9C;=E2= =80=9D [CFWS] propspec) [CFWS] =E2=80=9C;=E2=80=9D

=C2=A0 =C2=A0 arc-hop =3D 1*2DIGIT =C2=A0; 1-50

T= he purpose of this header field is to transmit the results of any authentic= ation done on the message upstream to participating ADMDs validating and co= ntinuing the chain.

The AAR MUST contain all A-R r= esults from within the participating ADMD, regardless of how many A-R heade= rs are on the message.

=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

Replace 5.1.1 wi= th:

5.1.1. ptypes and properties for arc-info

Certain information pertinent to ascertaining message = disposition can be lost in transit when messages are handled by intermediar= ies. For example, failing DKIM signatures are sometimes removed by MTAs, an= d most DKIM signature on messages modified by intermediaries will fail. The= refore, a passing DKIM-Signature from the first ARC signer is likely to hav= e been removed by final receipt of the message.

Th= e AAR, and in particular the ptype-properties=C2=A0stamped in arc-info, pro= vide a mechanism for this information to survive transit.

The ptypes and properties=C2=A0defined in this section SHOULD be st= amped in the AAR:

* smtp.client_id - The connectin= g client IP address from which the message is received;
* header.= ds - The domain/selector pair for each dkim signature on the message (heade= r.ds=3Dexample.com,selector)
*= arc.closest_fail - The hop number of the most recent AMS that fails to val= idate, or 0 if all hops pass.

=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Open questio= ns:

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 in= herits 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:

=C2=A0 =C2=A0 =C2=A0authres-header =3D= "Authentication-Results:" [CFWS] authserv-id
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [ CFWS authres-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=A0authres-payload =3D [CFW= S]=C2=A0authserv-id
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 [ CFWS authres-version ]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 ( no-result / 1*resinfo ) [CFWS] CRLF

And then we could have:

=C2=A0 =C2=A0arc-aut= hres-header =3D "ARC-Authentication-Results:" [CFWS] arc-info aut= hres-payload

2) The optimal way to transmit = DKIM selector information is in the DKIM A-R methodspec as header.s. If we = want to prevent a normative modification of 7601, I've proposed "h= eader.ds" which will accomplish the same thing.

3) In the ARC-Seal megathread, there was an aside about knowing the last= hop which validated:

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.=C2=A0 An additional "first AMS failure&= quot; header at each hop would give you a list of who actually modified the= message.

arc.closest_fail has been defi= ned to accomplish this.

4) Have the ptype-properti= es been defined properly, and will these AAR ptype-properties need an IANA = registry?

5) Finally, the ams[n] and as[n] entitie= s were dropped, as these values are guaranteed to be on the final message i= f an ARC chain passes, so there's no need to encode them separately.

Seth
--001a113d38027236e70558783ee8-- From nobody Tue Sep 5 15:34:42 2017 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 C02551321CB for ; Tue, 5 Sep 2017 15:34:41 -0700 (PDT) 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 7sD-OfssT11M for ; Tue, 5 Sep 2017 15:34:40 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1D9E132143 for ; Tue, 5 Sep 2017 15:34:39 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id x190so17171508oix.3 for ; Tue, 05 Sep 2017 15:34:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=CxWBm7w11naGcj4JmGM5I8OAd1vBmIztyyyf0o+pFbM=; b=oZv4Z0vE1yuTvU7I8IwU+GqfMl7aQC0iwn6eYaHx1QBKODqkohggzJGt+yr4gXE4SQ cryNqR0CaT19vqnhkwi8My24AnZQgUXZQtkXBC2qwnJ0Ej6pyR76sxNaVOOJv8lSsule dQADYjfgxpMjLs0AZbsV8X9UYs4exZlZfyAFDeRNpnaF+tZ4o1wHG73Wb/pBBFQABMj+ XccJPpPm10bw7JoTUKFhHuyBmeSZB7oZkL7o5DBLW2f6pPSE+GFjLgwvuvnjyZ+XhhaT +wxt7bvYlUMktzYB+gcu8vAL+wDxSAmtA5FLUQN0J3DhBZRF4FGcbHZLqzkFv3FB9CqI 2xQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=CxWBm7w11naGcj4JmGM5I8OAd1vBmIztyyyf0o+pFbM=; b=I8XIuv1KQuq1Fm06br8lcBLrbcc2njuaLbwnY/5r298aLTUDZwJDZQXey7zbFPdcu3 taH/ThoQbGI9zxZa6SjRAIMeJ17ZOzIqjPBwCZcCdmTp6CF5R/vWXT/s9UOMn4OeaH9j SaiTPAA4tuMSQvbGfI0oPZzwIJp2nUEV34yYfUbzlmCcDuvSoSvyypNBx0ZBgjXkK6Be N4FEvrMVwb6OUC70Na30Ft5VUjBmgnh++TBtzy+wP0O9d8SNpbxuK4mO84Zrt2ZSk96X YPo4PBJSKNU1yPsIAhmHZx7THet08uZuY4QXE5ZR7nY7h/butXVF5u6N6ELI+v6yobYc un/Q== X-Gm-Message-State: AHPjjUjoWrKgDXt2NAcp3v8VlO34zNCdhxx8a4ZLgcQNEfIE3to0lXg2 9gbQXl6/Qa6ogbJScThaIP2kc+0AcXc6nT4ZBg== X-Google-Smtp-Source: ADKCNb5KFq+483uTx+YKz5LpWNmO9omulVUsCvYpJfhF96IuPLmOzXeMEnAfirRZUm3/1+LqDNpbUEU4WjdosJUjhdk= X-Received: by 10.202.215.8 with SMTP id o8mr654170oig.247.1504650878880; Tue, 05 Sep 2017 15:34:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.88.139 with HTTP; Tue, 5 Sep 2017 15:34:18 -0700 (PDT) From: Seth Blank Date: Tue, 5 Sep 2017 15:34:18 -0700 Message-ID: To: dmarc@ietf.org Content-Type: multipart/alternative; boundary="001a113d3802259d7a055878d537" Archived-At: Subject: [dmarc-ietf] ARC draft-08 spec section 9.4 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, 05 Sep 2017 22:34:42 -0000 --001a113d3802259d7a055878d537 Content-Type: text/plain; charset="UTF-8" https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-08#section-9.4 There was an earlier thread about the proper way to handle this ( https://mailarchive.ietf.org/arch/msg/dmarc/Mz3xIgdB_OuBUqt9OlaZ9_feUpI). I want to suggest a different direction: Section 9.4 should be removed in its entirety. Returning a 421 tempfail is a bad idea for several operational and security reasons: - it can create generate backscatter - one could craft a legitimately ARC signed message and then pull DNS records resulting in a 421 ddos ping-ponging amongst intermediaries But more importantly, because of the nature of how ARC works and mail servers function, there is no way to handle temporary failures cleanly, especially because (as per the thread I linked to) sometimes delivering a message with arc=fail is better than tossing it back (for instance, when dmarc still passes on final receipt, and you'd otherwise by impeding a legitimate message). If anything, section 9.4 should state that all temporary failures are permanent ARC failures. Messages in this situation MUST be capped with cv=fail and passed along upstream. Stamping the A-R prior to sealing with arc=tempfail could be quite valuable to upstream receivers, but doesn't change the fact that the chain is dead. Seth --001a113d3802259d7a055878d537 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
https://tools.ietf.org/html/draft-ietf-dmarc-arc= -protocol-08#section-9.4

There was an earlier th= read about the proper way to handle this (https://mailarchive.ietf= .org/arch/msg/dmarc/Mz3xIgdB_OuBUqt9OlaZ9_feUpI).

<= div>I want to suggest a different direction:

=C2= =A0 =C2=A0 Section 9.4 should be removed in its entirety.
Returning a 421 tempfail is a bad idea for several operational = and security reasons:
- it can create generate backscatter
<= div>- one could craft a legitimately ARC signed message and then pull DNS r= ecords resulting in a 421 ddos ping-ponging amongst intermediaries
But more importantly, because of the nature of how ARC wor= ks and mail servers function, there is no way to handle temporary failures = cleanly, especially because (as per the thread I linked to) sometimes deliv= ering a message with arc=3Dfail is better than tossing it back (for instanc= e, when dmarc still passes on final receipt, and you'd otherwise by imp= eding a legitimate message).

If anything, section = 9.4 should state that all temporary failures are permanent ARC failures. Me= ssages in this situation MUST be capped with cv=3Dfail and passed along ups= tream. Stamping the A-R prior to sealing with arc=3Dtempfail could be quite= valuable to upstream receivers, but doesn't change the fact that the c= hain is dead.

Seth
--001a113d3802259d7a055878d537-- From nobody Tue Sep 5 16:20:19 2017 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 45CB213219A for ; Tue, 5 Sep 2017 16:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 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_SORBS_SPAM=0.5, 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=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 Nj7oX3z7GQut for ; Tue, 5 Sep 2017 16:20:16 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::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 190EB132195 for ; Tue, 5 Sep 2017 16:20:16 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id t10so9521723vke.0 for ; Tue, 05 Sep 2017 16:20:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fiction.net; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lOVNJM0qfTBnuf3frLvaN3Ogkf8mNVOgf2bS4HrvNw8=; b=IqYScD9lbyF91Ytvx505kTMycQ4jtohHd6GKd+M+llGQk8ftrvzKMervHuKlOfsGh/ ya61TDvX9LCC/J6pJGbPthTo98/x4GTLtLvU6BiHZMqJbMXHJxDgtBK+NGAc0UIz9eD9 xf634xEOOvd9tnoczkkRPS8lsFg/CxbyVI3GrthXYXqzFTQi5oxQ0hlOeq7F9A+begBm UTZ1GYepuwUezaZ+o21jb7cmvlBbg+0+TyrhwUO1DnUBbyOHdruucqj/ULDkhE5akB1n gL9qM/isbKGn+puBXudAkfUW89ZJ6gtBrT5pt7IczSPN8GZiTHx2RQhZcB7PrTAV4ttq /vBg== 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=lOVNJM0qfTBnuf3frLvaN3Ogkf8mNVOgf2bS4HrvNw8=; b=UOSEE4qo12kcD8+lzd10dZUEbRay/aIahbDiIF/LrpHc3LJgWTxj2oYCm+cit1f0dg I93JVWHpCrlYJ0S8l8e5bpt3eyPtvFghVLp7jVlEo5C8tFPfSVPBRvIKayT7/RvvVPht 9+m0FilOmSoNM0HQNLkO/UQvZFj3GNcWa2yUvMseIjoZH+C1nrUizGd4aNhoC8qxLnt3 /qhVwajFtWJWLiUOaNS0H2/KJeoQ+2SET26bq4o5atrXkPlSTtNkmFmBd7yY8UeCbVod NL2iItAcZvI+IGOmZ+IlD4VhNCHYHnh1zA1CKbXAnpQVpgAZI9sAP/5xV3KNLtrlL6Nx +PwQ== X-Gm-Message-State: AHPjjUg+UttOz5dcGesPTj5dV4TEkT52eDqHjWmuNTc7bw/FAI6oFpP9 wiDJVsrfoVKjWQJTExs= X-Received: by 10.31.7.65 with SMTP id 62mr468889vkh.124.1504653615042; Tue, 05 Sep 2017 16:20:15 -0700 (PDT) Received: from mail-ua0-f173.google.com (mail-ua0-f173.google.com. [209.85.217.173]) by smtp.gmail.com with ESMTPSA id 106sm419717uaf.51.2017.09.05.16.20.13 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Sep 2017 16:20:13 -0700 (PDT) Received: by mail-ua0-f173.google.com with SMTP id c27so11086972uah.2 for ; Tue, 05 Sep 2017 16:20:13 -0700 (PDT) X-Google-Smtp-Source: ADKCNb4L5CQcpcNl8sHQm/kj8CBvD7ZVSmrQbLxSBtmfwwfM5pCoY5t+JDrIECzS2QAuRlxTTKP/ajG72J3+qjHoxvc= X-Received: by 10.159.59.17 with SMTP id i17mr472181uah.165.1504653613325; Tue, 05 Sep 2017 16:20:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.135.139 with HTTP; Tue, 5 Sep 2017 16:20:12 -0700 (PDT) In-Reply-To: References: From: Brandon Long Date: Tue, 5 Sep 2017 16:20:12 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Seth Blank Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="f403043c4c9422cda5055879784e" Archived-At: Subject: Re: [dmarc-ietf] ARC draft-08 spec section 9.4 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, 05 Sep 2017 23:20:19 -0000 --f403043c4c9422cda5055879784e Content-Type: text/plain; charset="UTF-8" On Tue, Sep 5, 2017 at 3:34 PM, Seth Blank wrote: > https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-08#section-9.4 > > There was an earlier thread about the proper way to handle this ( > https://mailarchive.ietf.org/arch/msg/dmarc/Mz3xIgdB_OuBUqt9OlaZ9_feUpI). > > I want to suggest a different direction: > > Section 9.4 should be removed in its entirety. > > Returning a 421 tempfail is a bad idea for several operational and > security reasons: > - it can create generate backscatter > more so than a dmarc failure would? > - one could craft a legitimately ARC signed message and then pull DNS > records resulting in a 421 ddos ping-ponging amongst intermediaries > > But more importantly, because of the nature of how ARC works and mail > servers function, there is no way to handle temporary failures cleanly, > especially because (as per the thread I linked to) sometimes delivering a > message with arc=fail is better than tossing it back (for instance, when > dmarc still passes on final receipt, and you'd otherwise by impeding a > legitimate message). > I think arc=tempfail is a valid input to the DMARC decision, and I think it's a good idea for DMARC to upgrade a REJECT to a temp failure based on temp failure of any inputs. As a datapoint, we've upgraded 1.3% of REJECTs in the past week to temp failures, which "fixes" more DMARC false positives than we expect ARC to do (mostly because of the incremental benefit of ARC over our current XOAR scheme). I'm unclear if there is any benefit for this being in the ARC spec, however. It would appear to be a useful addition to the DMARC spec or useful in a BCP for either. > If anything, section 9.4 should state that all temporary failures are > permanent ARC failures. Messages in this situation MUST be capped with > cv=fail and passed along upstream. Stamping the A-R prior to sealing with > arc=tempfail could be quite valuable to upstream receivers, but doesn't > change the fact that the chain is dead. > I pointed this out before, but this is potentially another case where participating in the chain is worse than non-participation. If the status of a hop's arc verification is tempfail, not participating means if you are a non-modifying hop, the next hop may be able to verify the chain. Capping the chain as a failure prevents that. Yes, yes, a DNS failure for one hop is likely to be a failure at the next hop as well, since the hops are temporally similar, and although I say there's always another hop, statistically, we're already talking about the second hop here, and the number goes down quickly from there. Brandon --f403043c4c9422cda5055879784e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Sep 5, 2017 at 3:34 PM, Seth Blank <seth@sethblank.com>= ; wrote:
https://tools.ietf.org/html/draft-ietf-dmarc-arc-= protocol-08#section-9.4

There was an earlie= r thread about the proper way to handle this (ht= tps://mailarchive.ietf.org/arch/msg/dmarc/Mz3xIgdB_OuBUqt9OlaZ9_f= eUpI).

I want to suggest a different direction= :

=C2=A0 =C2=A0 Section 9.4 should be removed in i= ts entirety.

Returning a 421 tempfail is a bad= idea for several operational and security reasons:
- it can crea= te generate backscatter

more so= than a dmarc failure would?
=C2=A0
- one could craft a legitimately ARC signed me= ssage and then pull DNS records resulting in a 421 ddos ping-ponging amongs= t intermediaries

But more importantly, because of = the nature of how ARC works and mail servers function, there is no way to h= andle temporary failures cleanly, especially because (as per the thread I l= inked to) sometimes delivering a message with arc=3Dfail is better than tos= sing it back (for instance, when dmarc still passes on final receipt, and y= ou'd otherwise by impeding a legitimate message).

I think arc=3Dtempfail is a valid input to the DMARC= decision, and I think it's a good idea for DMARC to upgrade a REJECT t= o a temp failure based on temp failure of any inputs.

<= div>As a datapoint, we've upgraded 1.3% of REJECTs in the past week to = temp failures, which "fixes" more DMARC false positives than we e= xpect ARC to do (mostly because of the incremental benefit of ARC over our = current XOAR scheme).

I'm unclear if there is = any benefit for this being in the ARC spec, however.=C2=A0 It would appear = to be a useful addition to the DMARC spec or useful in a BCP for either.
=C2=A0
If= anything, section 9.4 should state that all temporary failures are permane= nt ARC failures. Messages in this situation MUST be capped with cv=3Dfail a= nd passed along upstream. Stamping the A-R prior to sealing with arc=3Dtemp= fail could be quite valuable to upstream receivers, but doesn't change = the fact that the chain is dead.

I pointed this out before, but this is potentially another case where par= ticipating in the chain is worse than non-participation.

If the status of a hop's arc verification is tempfail, not parti= cipating means if you are a non-modifying hop, the next hop may be able to = verify the chain.=C2=A0 Capping the chain as a failure prevents that.=C2=A0=

Yes, yes, a DNS failure for one hop is likely to = be a failure at the next hop as well, since the hops are temporally similar= , and although I say there's always another hop, statistically, we'= re already talking about the second hop here, and the number goes down quic= kly from there.

Brandon


--f403043c4c9422cda5055879784e-- From nobody Tue Sep 5 21:03:04 2017 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 78DA91321DC for ; Tue, 5 Sep 2017 21:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=lSeWNFt4; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=lcTAo/Jo 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 xoWyiqTviEM2 for ; Tue, 5 Sep 2017 21:03:01 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA7E71321A4 for ; Tue, 5 Sep 2017 21:03:00 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id D524420BFD for ; Wed, 6 Sep 2017 00:02:59 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Wed, 06 Sep 2017 00:02:59 -0400 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=9TXa8pIzPSQqqUs/M d9VSihMnNRLU0v81278A2nkXUc=; b=lSeWNFt4jFDs7vGmiROaPIsvgNTkled/P fbBXauRBIiCdTjdrkg2+jOsoRfnPEmqlvSNEIjGQvNkrVQQzPuPsVlYAZm2kSGaM 83dBIynDwsH0skme2Ivoaad/Ddnb4E9iQxQL5d6yCyULGnbdjj8RQOhHNVnKRDJK mBj3G+80CH3Tctmg0WKFwEcWjBZeSoYukUEnHJ1FB7klqYUnP4kdE7HwFCbu5ICr jIIn0W6nSZTBN4XiP6R5tPvKv5KeFnFurQKdYdhVD/6Zr9kl65RepHH2wj8uhieE BALZYibuIdx2UM+vOKYOJkSaCALW7/BeDGG6aOZJgond8ShDKC4eQ== 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=9TXa8p IzPSQqqUs/Md9VSihMnNRLU0v81278A2nkXUc=; b=lcTAo/JopOWAYEzhvwp8JS 8Uh2w2y8SJqh8R/xfNLHQfR6dTvH6ohyRqNh5/ykol4mGYpfYCabNnFgmMZkjBpw vHO0eyqehBoizmnbgNKLbjB/eBQqrER+nWYwJdNJ/2UuIz3AxIAEPb/AUJTOUgG8 1A5KqH2WO44G4Sf4zA5bY/mO3/JbToBuLmQfhfzH/sBVY1hiql0JGtn/Iw5yn78W kawOtNn0WNpQXcgY8u591PxkB0ZJSjvvoulfiYK1aKXxKpl3MNOQiY3Um0Xgfmn6 s9YVbiUsB3b8QQKlFxJ68HDBkDJRShBUx+tRgDpVXGwwJZPvklnciTUt29zJjTiQ == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id ADF589E218; Wed, 6 Sep 2017 00:02:59 -0400 (EDT) Message-Id: <1504670579.3451708.1096424992.78D2CF13@webmail.messagingengine.com> From: Bron Gondwana To: dmarc@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150467057934517082" X-Mailer: MessagingEngine.com Webmail Interface - ajax-f7b75467 Date: Wed, 06 Sep 2017 14:02:59 +1000 In-Reply-To: References: Archived-At: Subject: Re: [dmarc-ietf] ARC draft-08 updates to section 5.1 and WG questions 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, 06 Sep 2017 04:03:02 -0000 This is a multi-part message in MIME format. --_----------=_150467057934517082 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" 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 (except in the DNS tempfail case that Brandon addressed in the other email today) Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_150467057934517082 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
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 (except in the DNS tempfail case that Brandon addressed in the other email today)

Bron.

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


--_----------=_150467057934517082-- From nobody Thu Sep 7 08:20:26 2017 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 E01C7132A65; Thu, 7 Sep 2017 08:20:22 -0700 (PDT) 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.60.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150479762287.5650.14988531094778579592@ietfa.amsl.com> Date: Thu, 07 Sep 2017 08:20:22 -0700 Archived-At: Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-09.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 15:20: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 : Authenticated Received Chain (ARC) Protocol Authors : Kurt Andersen Brandon Long Steven Jones Murray Kucherawy Filename : draft-ietf-dmarc-arc-protocol-09.txt Pages : 46 Date : 2017-09-07 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-09 https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-arc-protocol-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-arc-protocol-09 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 Thu Sep 7 08:23:22 2017 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 F1800132F8D for ; Thu, 7 Sep 2017 08:23:20 -0700 (PDT) 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 4WojH94ps9X9 for ; Thu, 7 Sep 2017 08:23:19 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::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 3664B132F8A for ; Thu, 7 Sep 2017 08:23:19 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id 137so273619wmj.1 for ; Thu, 07 Sep 2017 08:23:19 -0700 (PDT) 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; bh=xHfhMAJRM2/tIgzGfybjdwshTs/y5IDUwGBJaJVuwX4=; b=ZnNnQ0m91Z4iC+0onb5y9bvj3pUBunz2G83ulYeCJJJGeEz41DmqKZvtYgqK4hbKUb aZf4oshY1H6X2b2nZmEwtKXuR0vtQmfC3kYD2m35i9fX6FOkGVF/yy+26acIm4TyWid6 5ILKZHN2jCDNH8fUJpM46oo6wn+p8MzMKTQLw= 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; bh=xHfhMAJRM2/tIgzGfybjdwshTs/y5IDUwGBJaJVuwX4=; b=QxfYh8tndaJ4wPf/i4tuu3t/O4/GX16dpUKl0Hfk93GzugWeMZ1F6G7F1ONKDElb3/ rCONfc7+5ZX9jkzOq2Z9kfJcmrsdxt9r0d9zszJltoH8N8t7701EWtmruPuUBMpcqHSA e6+A+lOm51ejvQ0livyjp74T7bp+1XB2CflMjcngSDxDfNrC8WSRiZOUSaBiwSqwO6BV 7nL3dk6wf0FOxdGwgNVq4li/hH8u7DNWbYV7QLtwrc/qw+xfAEUD6dPDbVe63Ij1ZWnw vLOxAJZVF3EVTQb8awry1/gUyGD5zjghleYK+tUYJd6fEPVzCwmXAVbYGOFn6Giz/UR/ mdQQ== X-Gm-Message-State: AHPjjUjMiwP7amwFOyu9/7KiuGQ2c6h2Q5OwLyoakHAyianrJ47UNOTK 6dYDBnoqE/+skGL9WY25Nku22RYJFa932ikMZQ== X-Google-Smtp-Source: ADKCNb4e61LWyyklW52HH9VkHTttThc+G2ymBsu36No3QWci9xb+RooSCObXkp2tP0eCxktRH37qOpEDJXIYw37QH/M= X-Received: by 10.80.226.77 with SMTP id o13mr2790885edl.102.1504797797237; Thu, 07 Sep 2017 08:23:17 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.80.178.229 with HTTP; Thu, 7 Sep 2017 08:23:16 -0700 (PDT) In-Reply-To: <150479762287.5650.14988531094778579592@ietfa.amsl.com> References: <150479762287.5650.14988531094778579592@ietfa.amsl.com> From: "Kurt Andersen (b)" Date: Thu, 7 Sep 2017 08:23:16 -0700 X-Google-Sender-Auth: kpNcj1PMM5zlbFJ4EnVKgaGoxXM Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="f403043e88ac29e0b705589b0a2d" Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-09.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, 07 Sep 2017 15:23:21 -0000 --f403043e88ac29e0b705589b0a2d Content-Type: text/plain; charset="UTF-8" I've just pushed a new version (-09) of the draft which incorporates the following changes: # v09 * Edits related to Alexey Melnikov's 2017-07-25 message https://mailarchive.ietf.org/arch/msg/dmarc/TJnWqN1HIFpHS0Nhtxq0qnP6EhA * Some changes in response to Dave Crocker's 2017-07-28 message https://mailarchive.ietf.org/arch/msg/dmarc/kZUVpzuOtODrloHfYSl1U1tUSe4 * Remove all of section 9.4 except the last paragraph * Some of Seth's suggestions for section 5.1* incorporated per https://mailarchive.ietf.org/arch/msg/dmarc/xUUbT15vqoBmH7RraJ_pesrd9z0 On Thu, Sep 7, 2017 at 8:20 AM, wrote: > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-09 > https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-arc-protocol-09 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-arc-protocol-09 > --f403043e88ac29e0b705589b0a2d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've just pushed a new vers= ion (-09) of the draft which incorporates the following changes:

# v09

* Edits related to Alexey Melnikov's 2017-07-25 message https://mailarchive.ietf.org/arch/msg/dmarc/TJnWqN1HIFpHS0Nhtxq0qnP6Eh= A
* Some changes in response to Dave Cr= ocker's 2017-07-28 message https://mailarchive.ietf.org/arch/m= sg/dmarc/kZUVpzuOtODrloHfYSl1U1tUSe4
* = Remove all of section 9.4 except the last paragraph
* Some of Seth's suggestions for section 5.1* incorporated per= https://mailarchive.ietf.org/arch/msg/dmarc/xUUbT15vqoBmH7RraJ_pe= srd9z0

On Thu, Sep 7, 2017 at 8:20 = AM, <internet-drafts@ietf.org> wrote:

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-i= etf-dmarc-arc-protocol-09
https://datatracker.ietf.org/<= wbr>doc/html/draft-ietf-dmarc-arc-protocol-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dmarc-arc-protocol-09
--f403043e88ac29e0b705589b0a2d-- From nobody Thu Sep 7 10:11:37 2017 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 70969132F5B for ; Thu, 7 Sep 2017 10:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, 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 W76gJpYVfFbK for ; Thu, 7 Sep 2017 10:11:33 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::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 A070C132F37 for ; Thu, 7 Sep 2017 10:11:33 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id n18so1845778oig.2 for ; Thu, 07 Sep 2017 10:11:33 -0700 (PDT) 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=kKEzhDQ4U6V41EBo6IU6GXBIWPrJ3lxj7yJ2xbraFd4=; b=Ie2zkdvNIO1SMQ93nehOfM0qwTvbOH/uKSH7RqaLbFQ8TivYRBThz4EzFWpA+qBQ0p bYmAjWNWBMwqLyf0BYFYFcrJRdZsitj+wl5jmedgO+NPQcw7habXoYcXkmCDmvlpWIHJ VBfEtJJixVO6WKNT7yRkI/dvsFJCJox30BwKGsioXkJGYFC+bDjipxyDKbFmiYuNUzwQ pGBMWtI6VlzlGmAJGroncyBaFU+IotLPawh1jZ6d0jo9ziRWoS2ybONLhy5Ckbn0RzGa w6mCWXdigZtlQmTnLMz//0RE8ievZ8BUSz7xegKqYkr9O09lCfxjkI19NAXDyLJwwL9p Wxzg== 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=kKEzhDQ4U6V41EBo6IU6GXBIWPrJ3lxj7yJ2xbraFd4=; b=cRoZRKGd/tE3If46P9yRxgrWYNMRfqnoXQgUvpwfAOv1C2FVBR87lMtnQL/OFiaasC FxfSvCdBto9sb3rKRNzYW7Ae+OPlcGWBZxOvElSGp/XHXXDR4/S9SSonp+LA4ewyLOmA lVPljxx9mZFDK/a3Us5PvrP7H70rgWtcCbOVi7TjyDbhSV7l73brOAoxjA6eDQ37IslB 62oSVBEXZnaJzV3UkrAPu+jHQ2oSo9wBIZuGgGG5baqz8sVCd/W8Nj4488RwH91T6T/8 f449K5nku5DabojjdvDfANr/luO5OTJwWHv/fcWL+8LY6Poe/0oWLlDeaof6EUMCT+ka MRag== X-Gm-Message-State: AHPjjUib8Z5KNdMuHANWbu3zmqpMEY/+7ZZ06Qbz1AYS9CWTXIlDmidy 2BBXzk4D94u4F1Z33+ugCV3WwkZZ8OXHPYrA+Q== X-Google-Smtp-Source: AOwi7QD6IsX5SgU+9+/s+UbqYRTjE10y8q/xhse2dm3Hm9h72Law215gYEevoxN8hSz9eS1NHG8+IC7nhL+2uXS/IuI= X-Received: by 10.202.170.20 with SMTP id t20mr41286oie.62.1504804292296; Thu, 07 Sep 2017 10:11:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.78.66 with HTTP; Thu, 7 Sep 2017 10:11:11 -0700 (PDT) In-Reply-To: References: <150479762287.5650.14988531094778579592@ietfa.amsl.com> From: Seth Blank Date: Thu, 7 Sep 2017 10:11:11 -0700 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a113ced164ca06c05589c8d73" Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-09.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, 07 Sep 2017 17:11:35 -0000 --001a113ced164ca06c05589c8d73 Content-Type: text/plain; charset="UTF-8" I'll go over this in more detail and post substantive comments sometime in the next day or so, but at first glance, a crucial change in 5.1 was missed and the draft language still makes a normative change to 7601 ("data SHOULD be added to the normal A-R content") to include data the WG consensus was should not be in the A-R (like smtp.client_id), instead of adding this data to the AAR where the WG consensus was that it does belong. On Thu, Sep 7, 2017 at 8:23 AM, Kurt Andersen (b) wrote: > I've just pushed a new version (-09) of the draft which incorporates the > following changes: > > # v09 > > * Edits related to Alexey Melnikov's 2017-07-25 message > https://mailarchive.ietf.org/arch/msg/dmarc/TJnWqN1HIFpHS0Nhtxq0qnP6EhA > * Some changes in response to Dave Crocker's 2017-07-28 message > https://mailarchive.ietf.org/arch/msg/dmarc/kZUVpzuOtODrloHfYSl1U1tUSe4 > * Remove all of section 9.4 except the last paragraph > * Some of Seth's suggestions for section 5.1* incorporated per > https://mailarchive.ietf.org/arch/msg/dmarc/xUUbT15vqoBmH7RraJ_pesrd9z0 > > On Thu, Sep 7, 2017 at 8:20 AM, wrote: > >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-09 >> https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-arc-protocol-09 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-arc-protocol-09 >> > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --001a113ced164ca06c05589c8d73 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'll go over this in more detail and post substan= tive comments sometime in the next day or so, but at first glance, a crucia= l change in 5.1 was missed and the draft language still makes a normative c= hange to 7601 ("data SHOULD be added to the normal A-R content") = to include data the WG consensus was should not be in the A-R (like smtp.cl= ient_id), instead of adding this data to the AAR where the WG consensus was= that it does belong.

On Thu, Sep 7, 2017 at 8:23 AM, Kurt Andersen (b) <kboth@d= rkurt.com> wrote:
I've just pushed a new version (-09= ) of the draft which incorporates the following changes:

# v09

* Edits related to Alexey Melnikov's 2017-07-25 message https://mailarchive.ietf.org/arch/msg/dmarc/TJnWqN= 1HIFpHS0Nhtxq0qnP6EhA
* Some changes in= response to Dave Crocker's 2017-07-28 message https://mailarchive.ietf.org/arch/msg/dmarc/kZUVpzuOtODrloHfYS= l1U1tUSe4
* Remove all of section 9.4 e= xcept the last paragraph
* Some of Seth'= ;s suggestions for section 5.1* incorporated per https://mailarchive.ietf.org/arch/msg/dmarc/xUUbT15vqoBmH7RraJ_p= esrd9z0

On Thu, Se= p 7, 2017 at 8:20 AM, <internet-drafts@ietf.org> wro= te:

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-i= etf-dmarc-arc-protocol-09
https://datatracker.ietf.org/d= oc/html/draft-ietf-dmarc-arc-protocol-09

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

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


--001a113ced164ca06c05589c8d73-- From nobody Wed Sep 13 08:39:25 2017 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 446BA133052 for ; Wed, 13 Sep 2017 08:39:22 -0700 (PDT) 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 fqXRHR7sjbYN for ; Wed, 13 Sep 2017 08:39:21 -0700 (PDT) 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 D8755127517 for ; Wed, 13 Sep 2017 08:39:20 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id t46so1506830qtj.2 for ; Wed, 13 Sep 2017 08:39:20 -0700 (PDT) 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=ACX117mXyYppflM3gYhaVVvqjWuhza4q8yuaJOqiNns=; b=Al/4dNMK1uTEUIQcglfVDIclk+8VJ5/iqizO5hZalQbBSGVThdvYtsPo6/D6nXUeef QI1+Ne/i4s4C1ipWalcV1POHA41ESCaNWJQEiLr4ROI+j6b49enYLUhprWpWV1lVfk0U yBHrIdIN7ZzP1JWN5tsfjkhqrTtIboAZrgN0iVuo8D1d8iQMM3cWZoNadkzg4rggREtY OI7/exvPthKhUqubrDs3C/EPuKfknhV4lqsO0GZRH/13XZGSgo20fvfOnaETGhCqAl85 3IOmRb8zFuBCMV0Sh2ew2EEmTloCEvH9BjUo2ykzdS4a1V1wWY2xYPF8fckIkmvpKGrs lBsg== 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=ACX117mXyYppflM3gYhaVVvqjWuhza4q8yuaJOqiNns=; b=Z5SjgWJxSrfITPCZY0wFJqIPD36cuOgYimd23/ZGuFuh7DOh00pObu/upe6RhSx7P7 wuX8ZxDB7cwxR5P8q/7mXGC2f2X/51/48Bi/qnoHI6G6fuZQHGW49MowG+PNZPTbG+m3 RJppcBfwSOjTQp2MxPtvH3CVDo4gGZUFXi+N8NzJN1pXS2S9SpSVc6mkzZ7YT0kY8XDP 6q3SWYq298YTO0lawsVtu9MxCTXJj9xrT/sKZNp9ewo/OBSYOFDh7gwYXSLMubtZz63P j9G/od5AbASkR4vjLpGrter+okRQXinKbQjE1bNazx0+beJU2qZDsDArHRC0PD8M9WXU cCQg== X-Gm-Message-State: AHPjjUhFvU5BQEt6UbzOMFRV9XFCBYhiby2Zc7Hsj3RT1yKWxuMvE3Oh Z6KYoTKfRQBhVFtncspdzxGax6cEWKFM X-Google-Smtp-Source: AOwi7QAO7xxznB7EDBdbjnnwUFtw2f+qTs008+A0rWG/PBogzDaEobJlXlTUYBFz/prUb4r2mW9A5SbItBB7ILFzWtQ= X-Received: by 10.200.44.123 with SMTP id e56mr26149321qta.308.1505317159896; Wed, 13 Sep 2017 08:39:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.57.34 with HTTP; Wed, 13 Sep 2017 08:39:19 -0700 (PDT) In-Reply-To: References: <150479762287.5650.14988531094778579592@ietfa.amsl.com> From: "Murray S. Kucherawy" Date: Wed, 13 Sep 2017 08:39:19 -0700 Message-ID: To: Seth Blank Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a113bc880970e46055913f6d4" Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-09.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, 13 Sep 2017 15:39:23 -0000 --001a113bc880970e46055913f6d4 Content-Type: text/plain; charset="UTF-8" On Thu, Sep 7, 2017 at 10:11 AM, Seth Blank wrote: > I'll go over this in more detail and post substantive comments sometime in > the next day or so, but at first glance, a crucial change in 5.1 was missed > and the draft language still makes a normative change to 7601 ("data SHOULD > be added to the normal A-R content") to include data the WG consensus was > should not be in the A-R (like smtp.client_id), instead of adding this data > to the AAR where the WG consensus was that it does belong. > The way those fields are added seems wrong to me. RFC7601 spells all of that out in terms of distinct (but related) ptypes and properties, which are separate things. Adding "header.ds" as a single thing conflicts with the way A-R is defined. At a minimum this should reflect that, though it also brings up the fact that A-R has a registry for these; are we planning to ignore, replace, clone, or augment that registry for this purpose? -MSK --001a113bc880970e46055913f6d4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Sep 7, 2017 at 10:11 AM, Seth Blank <seth@sethbl= ank.com> wrote:
I'll g= o over this in more detail and post substantive comments sometime in the ne= xt day or so, but at first glance, a crucial change in 5.1 was missed and t= he draft language still makes a normative change to 7601 ("data SHOULD= be added to the normal A-R content") to include data the WG consensus= was should not be in the A-R (like smtp.client_id), instead of adding this= data to the AAR where the WG consensus was that it does belong.

The way those fields are added seems wron= g to me.=C2=A0 RFC7601 spells all of that out in terms of distinct (but rel= ated) ptypes and properties, which are separate things.=C2=A0 Adding "= header.ds" as a single thing conflicts with the way A-R is defined.=C2= =A0 At a minimum this should reflect that, though it also brings up the fac= t that A-R has a registry for these; are we planning to ignore, replace, cl= one, or augment that registry for this purpose?

-M= SK
--001a113bc880970e46055913f6d4-- From nobody Wed Sep 13 09:10:40 2017 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 4CFDC132D3F for ; Wed, 13 Sep 2017 09:10:38 -0700 (PDT) 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 lerfdNFT1D1L for ; Wed, 13 Sep 2017 09:10:36 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::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 964171326F6 for ; Wed, 13 Sep 2017 09:10:36 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id t10so776098vke.0 for ; Wed, 13 Sep 2017 09:10:36 -0700 (PDT) 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=buqvn2QgelQEcKTbL2MKtOoo+A75gEFfDoa1p/aOzwE=; b=w5EV6RkFQCwf4vvV9GRzoBvHHmW0nHzsAzBT40eRl69f9udmuEEQqoz04beyqrsvaP ZuoLr/B80/dLPDjOU0Exh8WqvWydURqtS30t5FZyvufj84L5w7gWUm0obvNqGTo31G7r kPpeqyNMVWIfPKiWA6OWw5nvO3vak9/OOAWI+hYFiE+613m/DYlaSwsNul20YNC8jJhz VtA2Fnh7GlUxrePEsVWJy8jUtjoNK2Q3sW+UbahyYuGRfuOJpbtu8o8KHWxs9UE8Hr6n HtJUh6pBZYAhJdjAirUxck2+yWExeC4SaQKlp7zU4dJ5n5P2AdgQelF8JLlTuK1HCWK8 0s2A== 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=buqvn2QgelQEcKTbL2MKtOoo+A75gEFfDoa1p/aOzwE=; b=N8ehzYh1yZDjtnMhbqaOehgBe1qcd8YljKGh80+0ka/m71gAXsQ/4jeUIjNzxw3o7u dsCb75uF44+qDQFWrRitAQgrNXcNMdLLQQadH8aDQgIpfWampxrjfFkYR4JMoqltTLtx wm97u6QnA4arL7WD9bgPZu8CIb5QYR7WT9uDubkGeJOZe/6pTr9DiSc/QlxljEcj2hFX Rtj0EIp2RP8yttKpAMgWmd41V9ofmefNNqKxRHUJ0qTWr8HWiBveoOSF4Z2uCS2gYySV qzd1kUW/dSHHIoU9IintQbrqiX3RgetCmm5ehIuNBVPloclJA4mhFBzEja6Jo1O+60an iNBw== X-Gm-Message-State: AHPjjUh7H0mKT9oizxXDbX36L8bUxKNZsCzQcUb8+Cw6KXpaqCQtCZBf o+k0TawrAYiiyIbfrXRzEtcYNZEe/1jxY0DQX2MXRtW3XOk= X-Google-Smtp-Source: AOwi7QCQwZKwdJlIJ/oD6Ae77UmeUiI/41SmqcL70D1iaaWDFzsLleLzDsuBdjNp5NUSbIbhH/e8VtxtWR5BfiOnYoI= X-Received: by 10.31.169.2 with SMTP id s2mr13081148vke.86.1505319035050; Wed, 13 Sep 2017 09:10:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.3.73 with HTTP; Wed, 13 Sep 2017 09:10:14 -0700 (PDT) In-Reply-To: References: <150479762287.5650.14988531094778579592@ietfa.amsl.com> From: Seth Blank Date: Wed, 13 Sep 2017 09:10:14 -0700 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a114257845bb70805591466d0" Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-09.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, 13 Sep 2017 16:10:38 -0000 --001a114257845bb70805591466d0 Content-Type: text/plain; charset="UTF-8" On Wed, Sep 13, 2017 at 8:39 AM, Murray S. Kucherawy wrote: > > The way those fields are added seems wrong to me. RFC7601 spells all of > that out in terms of distinct (but related) ptypes and properties, which > are separate things. Adding "header.ds" as a single thing conflicts with > the way A-R is defined. At a minimum this should reflect that, though it > also brings up the fact that A-R has a registry for these; are we planning > to ignore, replace, clone, or augment that registry for this purpose? > Yup, that's why I explicitly asked if they were defined correctly in question #4 here: https://mailarchive.ietf.org/arch/msg/dmarc/xUUbT15vqoBmH7RraJ_pesrd9z0 Can the WG please revisit that thread and the open questions. S --001a114257845bb70805591466d0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Sep 13, 2017 at 8:39 AM, Murray S. Kucherawy <superuser@gmail.com> wrote:
The w= ay those fields are added seems wrong to me.=C2=A0 RFC7601 spells all of th= at out in terms of distinct (but related) ptypes and properties, which are = separate things.=C2=A0 Adding "header.ds" as a single thing confl= icts with the way A-R is defined.=C2=A0 At a minimum this should reflect th= at, though it also brings up the fact that A-R has a registry for these; ar= e we planning to ignore, replace, clone, or augment that registry for this = purpose?


Can the WG please revisit that thr= ead and the open questions.

S
--001a114257845bb70805591466d0-- From nobody Wed Sep 13 13:03:08 2017 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 8822A132ED1 for ; Wed, 13 Sep 2017 13:03:06 -0700 (PDT) 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 iD6tFaZGBlsV for ; Wed, 13 Sep 2017 13:03:05 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::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 6313C132EBE for ; Wed, 13 Sep 2017 13:03:05 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id r141so3173279qke.2 for ; Wed, 13 Sep 2017 13:03:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=b87JvFwWJOPaAG+v2Md9BZOITgko4rZ8YLByzMbI5+g=; b=Mp4wZav+le63+4YTqXJEpBJl/rwUcb9j3mHwIwq2whvrftkhkNxdf2v9TqL5YcLR7Q jXAdQr/AWjJtnYNsWLDEZ3fsu4AT7tnU/nye57IeIEqFekjmvdXXZ5cttg36IxMBsUaa 9der1wSlBkMmLtM8iVKI/bfvhY2qInWkPM59Cyu8qxFOIGiZD1BA30r8YWQ+JcUwPmdx f0s+6Ot3YYw3eJBONruhq2OhCb8IpZiB6aQfjnRyDzZ8lL6TpukEC+XU5vPdzydYRxBs sx7JG+SBijpl7M8IN5fKds7qkTwoejrXLxKh4Rc8QlEyqh1NihP8VcYvUYRU4sXE+DeP M/pA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=b87JvFwWJOPaAG+v2Md9BZOITgko4rZ8YLByzMbI5+g=; b=njPjpfRNRCt2PAbsMjxxhrLXHkTjBhqnTjvumpE/9LZA0BYStMDSc04iBWPv5HPXxq wbkBlSaOuzzi3V+p6u0mT9dMlTul2LKD3u619WS3jtR8O88DNpGG/d/sVGr+XxA0sdtw ge9xty9cHYIWJ+sHGFd0zJGrc4+HxNUZBeryReQUt0z9RDwAYnDOUDz5FJiOQZIBdB7W E6QGJpJwY7t6yVVmCYhevwW6OTgJFE091h63utuWrwRbEqRRm9pDwpQnY2A530JILz++ 4WVE2RHPLNSxj3sHvHCh9WYbPumqHVs7zXqIpM5p7rdQR7DpK6BxMlcoHKWNXcbgdtkm t1cQ== X-Gm-Message-State: AHPjjUjJEzEndGoaC7rlGf8o+ACKYNVP4Ckzulw4DUAvbPDN8qE254mw 0mfpibKXV/0hXE3YWtWFTXnfPeKYNJHF X-Google-Smtp-Source: AOwi7QBB0fHCdwivNfnnjYGI5Uj2QkKIBez/4P5YgbgpaoZ1QDEGPkMFXNL3jd2KMnGvUwOo63PEkMUjnNQ9sa43i2w= X-Received: by 10.55.137.66 with SMTP id l63mr26826475qkd.249.1505332983658; Wed, 13 Sep 2017 13:03:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.57.34 with HTTP; Wed, 13 Sep 2017 13:03:03 -0700 (PDT) From: "Murray S. Kucherawy" Date: Wed, 13 Sep 2017 13:03:03 -0700 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0729fcc28111055917a556" Archived-At: Subject: [dmarc-ietf] ARC and "fail" again 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, 13 Sep 2017 20:03:06 -0000 --94eb2c0729fcc28111055917a556 Content-Type: text/plain; charset="UTF-8" At the risk of bringing up the whole "cv=invalid" debate again... When a chain is invalid (say, an AMS is missing), Section 9.3 says to add a seal that only covers itself but uses N+1 for its "i=" value. Could someone propose some informational text for the draft that explains why that decision was made? -MSK --94eb2c0729fcc28111055917a556 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
At the risk of bringing up the whole "cv=3Dinval= id" debate again...

When a chain is invalid (say, an AMS is mis= sing), Section 9.3 says to add a seal that only covers itself but uses N+1 = for its "i=3D" value.=C2=A0 Could someone propose some informatio= nal text for the draft that explains why that decision was made?

-MSK
--94eb2c0729fcc28111055917a556-- From nobody Wed Sep 13 13:12:00 2017 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 3ACAA132ED2 for ; Wed, 13 Sep 2017 13:11:59 -0700 (PDT) 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 hbDSpjeyfoDQ for ; Wed, 13 Sep 2017 13:11:56 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F618132D45 for ; Wed, 13 Sep 2017 13:11:56 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id 189so553728wmh.1 for ; Wed, 13 Sep 2017 13:11:55 -0700 (PDT) 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=na62VU2E4H8yhu5CEAPKXtveYoK8MIgQX+hmEJ5HBGQ=; b=Y84LAD0olbueT6cwnrleR+b6DPW+AXFstGhEE3W7gYhSrI+LXhdf/nPuhhRlcqjo6p T2OdDpJjPZEXxtoJPgZRjTH8Onu0ZR7JJ53nZbV14Xh3EgP8xFZ9tXoIvr7KxZUppPE+ 5QHY/i9U2bYzWhfxugzQWztfBKe+UTYO8QjmM= 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=na62VU2E4H8yhu5CEAPKXtveYoK8MIgQX+hmEJ5HBGQ=; b=VnUzhzYUSLqjpaJuMr6N3KVPAJzfH+XpvjywzuAMkCu1POy3X9I982agNsOlE3t7B2 K5hBkg9ySZ7qEkbg6s/bN5Ki2ptiijLV7/LByYHqi1l0fsg4DH5TQRxf7oY/5l+ctWlg qd53+UWzTuNjgDp2hN4P1dO/S5lkHPLV47cEY+eWGm8WuSvBQFWUPTwbrEela9a24Ecv 9dzTho3HW8eJurhoVp+WvHTpLsPcvOM46yNePPdPgmk1otVVkbDpmOIsaDAR4SqxtsTF RKGNHC4HiKa5XwVoLltiINKNf32bPGtaD6AqxQ843aBiPEV2rf3Zkh/OSds83U9ffaUn Ewdw== X-Gm-Message-State: AHPjjUjGWPVIYUCu3cSZT7fqLL/9pwHjHWkaFNVBXxSxU1Pc/TDipAer CIFWUh1/2OHPd9LdFpcEsjCocCjbULOvu6YkoVppQtZCbAE= X-Google-Smtp-Source: ADKCNb5z3YKQK6EPiKH8+5z+HV70V7cwBXfVW4hE9r2VjxOXgawL9udcwV8vyYFME1UqxCbndZqKQ3dhgxuhuzRz0qc= X-Received: by 10.80.135.157 with SMTP id a29mr8530707eda.112.1505333514281; Wed, 13 Sep 2017 13:11:54 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.80.178.229 with HTTP; Wed, 13 Sep 2017 13:11:53 -0700 (PDT) In-Reply-To: References: From: "Kurt Andersen (b)" Date: Wed, 13 Sep 2017 13:11:53 -0700 X-Google-Sender-Auth: rihRQC0blIE4x4NzKhB6v7RI3k8 Message-ID: To: "Murray S. Kucherawy" Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="f403045c14c463364a055917c51e" Archived-At: Subject: Re: [dmarc-ietf] ARC and "fail" again 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, 13 Sep 2017 20:11:59 -0000 --f403045c14c463364a055917c51e Content-Type: text/plain; charset="UTF-8" On Wed, Sep 13, 2017 at 1:03 PM, Murray S. Kucherawy wrote: > At the risk of bringing up the whole "cv=invalid" debate again... > > When a chain is invalid (say, an AMS is missing), Section 9.3 says to add > a seal that only covers itself but uses N+1 for its "i=" value. Could > someone propose some informational text for the draft that explains why > that decision was made? > Yes, will add such information. In short, the reason for covering only the last ARCset is because it is impossible to determine exactly what the "implicit-h" list would be if the chain is corrupt. That makes it indeterminate as to whether one should believe the "failing" report since validating the signature would be ambiguous. --Kurt --f403045c14c463364a055917c51e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
--f403045c14c463364a055917c51e-- From nobody Wed Sep 13 17:10:25 2017 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 5E8EA132969 for ; Wed, 13 Sep 2017 17:10:24 -0700 (PDT) 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, 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=mailforce.net header.b=PHrzf2Vt; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=QWMsCwhy 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 5x4-L7-ZY6TG for ; Wed, 13 Sep 2017 17:10:22 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAE6413213D for ; Wed, 13 Sep 2017 17:10:22 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 1810F20C0F for ; Wed, 13 Sep 2017 20:10:22 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Wed, 13 Sep 2017 20:10:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailforce.net; 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:x-sasl-enc; s=fm1; bh=se+l6f//qDmxsvb1uR vsyLMxMTGRPaHRrEnUiW3P798=; b=PHrzf2VtI8rXBCSzh6t/mG3RIW33EogAxJ yOaatdlhh/wYpyxf3z6C5f8buFtLA/Pvan6VmQecgR6PLUdpIFHI5VFFYmqF8/QS g7UOwzpjVphCr6BzrYEG2gZWxK999QvN+HFrJ+dx3crJk1T6CsYZ7HQVPPBqFP4A vBY4XH5Hd8xobJfwO8oMw+87n6MhGGIEt3LcFu6yLA5aN570WR3HJKk4Jt3K+DC0 2C0c2sDN3+Z+mishyCL9tgs3OIzasvox0LmcJJgUSBnLGD5mw7Tb611E4YunnQUj 2PXcXiaf4MsfBDMaHO+R8snwh75YJhj0io+cEyCb1XOvdlNJhRqQ== 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:x-sasl-enc; s= fm1; bh=se+l6f//qDmxsvb1uRvsyLMxMTGRPaHRrEnUiW3P798=; b=QWMsCwhy VH6MfuWrFDnS40jPNF1dEQsgl57drYrwW9KR3SYQrYu6qc/lLqN0S/0pRMq9sY/i agr35kURjdbr6EtpV9F2gCbj1EujFP4v/LQhJbpjjS3kQF2/Vay9zfiOgrdCHY8m D7iFrKmH/VZE7MnVYREp+HNgrcYiZEO36puaU7mq4SuMbgWJd/JZH7Wqa4UoBqTh wUuocLeNvspRPZyZ9kRWy0L/iDWnLx35wsC290PNyH9YrgcbW5GxNNtt8UPgoSNZ e84kvlod1I0+2kdszgOiznagUTVQL7YCLFWD7urvwQC/TMlYDnrCYQP8tlPMfvYy cfZkHIYIOjiIGQ== X-ME-Sender: X-Sasl-enc: 3w/1b+RV2DwpgEE2K5FswVnCTS3wz+4EgM0f6g8FmZue 1505347821 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 BCB777FA80 for ; Wed, 13 Sep 2017 20:10:21 -0400 (EDT) References: <150479762287.5650.14988531094778579592@ietfa.amsl.com> From: Stan Kalisch Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (13G36) In-Reply-To: <150479762287.5650.14988531094778579592@ietfa.amsl.com> Message-Id: Date: Wed, 13 Sep 2017 20:10:18 -0400 To: dmarc@ietf.org Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-09.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, 14 Sep 2017 00:10:24 -0000 One nit: Section 13.1, line 730: there's space between "Method" and the co= lon. Thanks, Stan > On Sep 7, 2017, at 11:20 AM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts directo= ries. > This draft is a work item of the Domain-based Message Authentication, Repo= rting & Conformance WG of the IETF. >=20 > Title : Authenticated Received Chain (ARC) Protocol > Authors : Kurt Andersen > Brandon Long > Steven Jones > Murray Kucherawy > Filename : draft-ietf-dmarc-arc-protocol-09.txt > Pages : 46 > Date : 2017-09-07 >=20 > 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. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-protocol/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-09 > https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-arc-protocol-09 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dmarc-arc-protocol-09 >=20 >=20 > Please note that it may take a couple of minutes from the time of submissi= on > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Tue Sep 19 14:56:49 2017 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 6C947132397 for ; Tue, 19 Sep 2017 14:56:48 -0700 (PDT) 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 (2048-bit key) header.d=google.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 7Rs9Pcw36jAp for ; Tue, 19 Sep 2017 14:56:46 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::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 70A0C1321DE for ; Tue, 19 Sep 2017 14:56:46 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id l15so2414178iol.8 for ; Tue, 19 Sep 2017 14:56:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=NuldJ1f6HEdFxe1xQ7Ee0E26+ZQuFrexaPAl2aLHdkA=; b=ixTGWtL06er1RpEIPp3k5eSr6vrBPb2OHLdhoH8RHSCynSRWV6K8tZ9C/mtQxe7eMw 6y+5ZcSxbBg6lPeBDG1gtegTD58qtM++mazh2TMFDPYx14Wv+r1SCRO1V+c/iVXBbXOe nziF5KrlCoKkuAgu8GNWqrB4s8K+hfcSce/JU9G1KH17Wnsa58U6/7QyK1Aio+HYhxz4 CdW5T7D89HbJjr44oIqptd6TX2WdvwZBvb+O0aTpbDYbvf0Da2OWFqtcVMV4nH+DPuC1 D4yqgyu03QC5j5bTkND3ReFzh26PCLqmzjyYZ37k6nVnsQXu8gHc0nq/aeVmxuB5peH9 bLDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=NuldJ1f6HEdFxe1xQ7Ee0E26+ZQuFrexaPAl2aLHdkA=; b=NCXhElTmqpWno8CkX8uI098kOXDgntEOGlalxp03q+liNpe4WA5Lgh32RA/lA/9d9j WQNhkZhvrmRNVIsj2HQC9i58cHQ+uwsOqeEIYwIKwESXO+5A7BzYJp9LHDKKLdj1Rj+r 8z+TbtvS6B4Ltoe4G9ieK1SgnY7zK9+EJvzzu4PBmMz2Cd06jBFPe7xv1VaMhRkH79oU kee4avzh3/RbCwujkItr/ayXETHmomnDeNv3OAc1sNPl0b5Qyoi9BwepWP/h5aIrTLoz onG/FtY/EAduRSH344IHwEpfdNOZQuGn2CMrzf/J6GFQxXLugReIpqGknHQLrv8lTLAx xlMw== X-Gm-Message-State: AHPjjUiT4KxaKw3jAV4+TsNmkMBDIwm3EploghSbk4idrLpLcF29jKe+ 7kmIHwfSWBeteLqBA51EafkapG8IoRg8CpJT+xWSnfY= X-Google-Smtp-Source: AOwi7QBe5rb2jUkgT/Z1l2uaIlSVIfq0xAoZFP0bAyo9rXCf5YxtQt9FamCdVPzkW2HKGytJKM31wUyMqylot38uCWY= X-Received: by 10.107.1.8 with SMTP id 8mr3723641iob.75.1505858205177; Tue, 19 Sep 2017 14:56:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.34.129 with HTTP; Tue, 19 Sep 2017 14:56:44 -0700 (PDT) From: Brandon Long Date: Tue, 19 Sep 2017 14:56:44 -0700 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a113981c667c652055991efae" Archived-At: Subject: [dmarc-ietf] Google and ARC status 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, 19 Sep 2017 21:56:48 -0000 --001a113981c667c652055991efae Content-Type: text/plain; charset="UTF-8" Google is now using ARC results for local policy DMARC passes. This should be visible in your DMARC rua reports as "arc=pass" in the local policy comment field. This should replace most instances in your reports of xoar=pass. There are still some cases where xoar passes and arc does not, mostly because xoar is always the last hop and replaces any existing one, so it works in cases where the arc chain breaks. Ie, arc would need the ability to restart broken chains to be equivalent, though it's not clear that the extra covered cases would be that useful, definitely edge cases. If/when some other major sites like ietf.org enable arc signing, we can add them to the whitelist. Automated trust is going to require a larger rollout to be effective, and we haven't started working on that yet. Brandon --001a113981c667c652055991efae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Automated trust is going to require a larger rollout to b= e effective, and we haven't started working on that yet.

=
Brandon
--001a113981c667c652055991efae-- From nobody Tue Sep 19 16:57:42 2017 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 BD618132944 for ; Tue, 19 Sep 2017 16:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 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_SORBS_SPAM=0.5, 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=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 6TavArum7acp for ; Tue, 19 Sep 2017 16:57:38 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::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 DC3CC132F69 for ; Tue, 19 Sep 2017 16:57:37 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id q80so850207ywg.2 for ; Tue, 19 Sep 2017 16:57:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fiction.net; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=t9g5cUNU/mV7GDiNrFnU8lJQoIwO4JD66TchfFI+TgE=; b=MRHzCFUJcdle1lIDMeAqF+RyuB67e0qUnflQnGgEpNMu3PhugXzFIyvd7uUEp4JOHe aqMDuPNfzJsHcZNMbCqsSmb3qhNIJcHXC3abHO2kLEYx2n6ApksCNktNwllQy+Gfa3In a2x+lud841THOijcjSGjX9JYfvrGfPuzPTlhH3LV+rfNqnwBecLKR8Ga5dhuEK5H6ldr MB2MeB4BtpqPkM5X/RcMqQ+mSF+dI0C0CcE3gi7NZxmGRfCtj622S564mdKtfIzr3SFR wzwCnEAzDs1OUR1DmuICnWYYSeHdkaGfI2WeYMtz/4/1V4AOhdJOq98/jXupH983eRwr 26MQ== 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=t9g5cUNU/mV7GDiNrFnU8lJQoIwO4JD66TchfFI+TgE=; b=IOpbdmGfxTN9S7MXIBQZ2SJQZysZ9D1OEQOu4SrV3JZ1NHkwuGo4lrFv5UIqurmnj5 Bs22y5R55m0rHqrZWgqwBsfFK+ej+UY+LBfhEM98k/zJkrVJmmJzcG7du7cAPg9PeJcc DOFmelTi3sUD/PAQZiPXoJAACHsohrD+7Zcjn6UdVYgxJXAnehPLfd0y76My2THhARIy yK/6iHgoszoIrLk3Zd8kfP7ge1nfZB8cZYP63dNtbgQn7uyLFmiCOv48u8JR2B6dxyP9 CLaKKwCTSdofe8/ABK+lTv1CkPobebuuKmfGPexoP0e3L0N0cJyT8W01LM3SrtUaburw 7k1A== X-Gm-Message-State: AHPjjUiVzDgPsBdOwtMj1vtizX2OJ6d0ruVtxnNn7EJoSXobU/BHqye1 5E0LdAp+enM9KWcyhUY4lnStNHqY X-Received: by 10.37.162.138 with SMTP id c10mr1676876ybi.202.1505865456961; Tue, 19 Sep 2017 16:57:36 -0700 (PDT) Received: from mail-io0-f170.google.com (mail-io0-f170.google.com. [209.85.223.170]) by smtp.gmail.com with ESMTPSA id g72sm256126ywe.26.2017.09.19.16.57.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Sep 2017 16:57:35 -0700 (PDT) Received: by mail-io0-f170.google.com with SMTP id i197so2589953ioe.9 for ; Tue, 19 Sep 2017 16:57:34 -0700 (PDT) X-Google-Smtp-Source: AOwi7QAqR/LiRBEmvKjJZs6E/2E9l8iYXSStfYwwfnFDeBs9isc6imhV/uUQCwSZ7xBK87NwxaGMvjl8SdW1r3Gt/G4= X-Received: by 10.107.10.77 with SMTP id u74mr4689593ioi.243.1505865454352; Tue, 19 Sep 2017 16:57:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.34.129 with HTTP; Tue, 19 Sep 2017 16:57:33 -0700 (PDT) In-Reply-To: References: From: Brandon Long Date: Tue, 19 Sep 2017 16:57:33 -0700 X-Gmail-Original-Message-ID: Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a113eca4e7d53c40559939ff5" Archived-At: Subject: Re: [dmarc-ietf] Google and ARC status 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, 19 Sep 2017 23:57:41 -0000 --001a113eca4e7d53c40559939ff5 Content-Type: text/plain; charset="UTF-8" And again from my non-Google account, hoping I didn't get people kicked off the list again.... On Tue, Sep 19, 2017 at 2:56 PM, Brandon Long wrote: > Google is now using ARC results for local policy DMARC passes. This > should be visible in your DMARC rua reports as "arc=pass" in the local > policy comment field. > > This should replace most instances in your reports of xoar=pass. There > are still some cases where xoar passes and arc does not, mostly because > xoar is always the last hop and replaces any existing one, so it works in > cases where the arc chain breaks. > > Ie, arc would need the ability to restart broken chains to be equivalent, > though it's not clear that the extra covered cases would be that useful, > definitely edge cases. > > If/when some other major sites like ietf.org enable arc signing, we can > add them to the whitelist. > > Automated trust is going to require a larger rollout to be effective, and > we haven't started working on that yet. > > Brandon > --001a113eca4e7d53c40559939ff5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
And again from my non-Google account, hoping I didn't = get people kicked off the list again....=C2=A0

On Tue, Sep 19, 2017 at 2:56 PM, Brandon= Long <blong@google.com> wrote:
Google is now using ARC results for local policy DMAR= C passes.=C2=A0 This should be visible in your DMARC rua reports as "a= rc=3Dpass" in the local policy comment field.

This = should replace most instances in your reports of xoar=3Dpass.=C2=A0 There a= re still some cases where xoar passes and arc does not, mostly because xoar= is always the last hop and replaces any existing one, so it works in cases= where the arc chain breaks.

Ie, arc would need the ability t= o restart broken chains to be equivalent, though it's not clear that th= e extra covered cases would be that useful, definitely edge cases.

If/when some other major sites like ietf.org enable arc signing, we can add them to= the whitelist.

Automated trust is going to requir= e a larger rollout to be effective, and we haven't started working on t= hat yet.

Brandon

--001a113eca4e7d53c40559939ff5-- From nobody Fri Sep 22 14:26:28 2017 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 76127132620 for ; Fri, 22 Sep 2017 14:26:26 -0700 (PDT) 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=eudaemon.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2V65EBAYNco for ; Fri, 22 Sep 2017 14:26:23 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::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 82334132143 for ; Fri, 22 Sep 2017 14:26:23 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id r85so1592883ywg.1 for ; Fri, 22 Sep 2017 14:26:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eudaemon.net; s=dkey; h=from:mime-version:subject:message-id:date:to; bh=cQA59qQyXJhXVkKieEnPd0jvSenPJvcqGPohnvJNpuo=; b=AxJnZdWzOuvJCjxRXWMkgvBFOuRE+SYUO7p2s8Cu5WKFJ8tr69ynIqBNMx4YnwWKAk Z5wkJFoxLPtmNRvaeDiObZ2XP8OO85WL20dqngiJzZ41YD6Txmq5yrovIVGeHBSKwnLC r5m+OCdWh0/NL3jb/Sw3Gk+9EW52mevfwjzC8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=cQA59qQyXJhXVkKieEnPd0jvSenPJvcqGPohnvJNpuo=; b=JpDyNVZiZzharUfYP8IKEecSKaeZMtx1AmDufVBnfWCWWB5T9Qc7fprOv17P2N+EN9 w43Eg3UWseb/ZGUrjmwMaqu5jP8p2Ykfrg7k701zYHFu1MHOuiVbizbp9sLS4jZXrnJP 0xqEteBxH+ZsAOWI0oIS6mNmEjBoxWAAvydLkggins+/YjbHOpDeTTzJgRK+fp4uDwHJ rccLAxxRdlf7EMzLkEuidQh5RGkidRbfTHqNApQmjGGADbrs58kQtQVd1JBD7st0rVWj FPHJOhONK6bDW3zBtOgR8Xsgu2Bc+cxKh/KfZPwtvOZx/tdlWvs6Fs9YuJZhE7JjPgHs JAoQ== X-Gm-Message-State: AHPjjUgqtbq+6JDhHedg/RivX1JjaO0U8FwmoJOiBRmpbqRRB4b6JOEr nNqcucJiALUncE3hYFRHKlny2/67c2g= X-Google-Smtp-Source: AOwi7QDzZwjWHhNoLGLXunxnkjyxFa2HnDhw8Qoy/6u42G3PGgp+/dr6wU0v+qRiFpnpy0SragGvpQ== X-Received: by 10.129.216.5 with SMTP id d5mr321762ywj.406.1506115582481; Fri, 22 Sep 2017 14:26:22 -0700 (PDT) Received: from [192.168.0.3] (208-104-133-98.brvd.dsl.dyn.comporium.net. [208.104.133.98]) by smtp.gmail.com with ESMTPSA id x139sm321194ywd.82.2017.09.22.14.26.21 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Sep 2017 14:26:21 -0700 (PDT) From: Tim Draegen Content-Type: multipart/alternative; boundary="Apple-Mail=_78589DDF-26EF-41CA-A242-2F1F2EB9354E" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <730885BA-C86F-4AAA-89F5-7C6A036AD722@eudaemon.net> Date: Fri, 22 Sep 2017 17:26:20 -0400 To: dmarc X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [dmarc-ietf] Usage Guide interview (ISP) with David Finger @ Seznam.cz 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, 22 Sep 2017 21:26:26 -0000 --Apple-Mail=_78589DDF-26EF-41CA-A242-2F1F2EB9354E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 [This email is part of the series described here: = https://www.ietf.org/mail-archive/web/dmarc/current/msg03671.html = ] Usage Guide draft: = https://www.ietf.org/id/draft-tdraegen-dmarc-usage-guide-00.txt = Background: Seznam.cz is largest mailbox provider in Czech Republic. In = operation since 1995. Started with email in =E2=80=9898. 8 million = (monthly) active accounts. Seznam attempts to support technical = standards. Not a lot of ISPs in Czech Republic; 60 ~million received = daily emails directly to inboxes (not including blocked email). Began = looking at DMARC ~2015, have been using as input into anti-spam, not = 100% applied as per DMARC spec. Experience: Began sending aggregate DMARC reports September 2017. = Forensic reports are to follow. Implementation based on OpenDMARC = library. No storage or logging issues. Capacity verification was = performed beforehand, no issues. =46rom a developer perspective very = lightweight. =46rom project management PoV, constraint was time in terms = of priority against other projects. Private DNS cache experienced no issue. SPF and DKIM checking = already existed. DKIM was required for bulk senders to deliver email = into Seznam since ~3 years ago. DMARC viewed as next step to give = senders picture of traffic. Bulk senders vs primary post (transactional email falls into primary = post). Senders instructed to use DKIM to differentiate between = primary-post/transactional email and bulk email. (Bulk email guidance: = https://fbl.seznam.cz/ ) Began with SPF, recommended for senders but not a requirement like DKIM = is. Primary used as an input into anti-spam. SRS in use for past year. Operational issues: biggest problem - pushing information to senders = that DKIM is required. 6 months preparation time. Senders had trouble = understanding DKIM and what was being asked (including developers). =C2=BD of bulk senders reside in CZ. Bounce messages used to inform = people that DKIM is now required. Help/support desk dealt with issues - = guidance given to deploy DKIM. Couple of months of guidance=E2=80=A6 = still, today, ~ half a million daily messages are bounced. Most ESPs do = not notice that their email us bouncing (!).. That is, not measuring = engagement at all. Maybe the people receiving email do not notice the missing = messages, and so everything is OK. :-7 Malformed email is given a separate signal and dealt with.=20 All DKIM signatures are evaluated. All reported via DMARC. Key length is not an issue due to recent DKIM deployments. (Does OpenDMARC flag short key length issues?). Hadoop used as log collection/data-warehousing. DMARC stack implemented inhouse, no issues with communication of various = DMARC inputs. Hosting? Custom domains can be used with web interface. Forwardings happens. If ARC can supply original authentication results, = that would be useful. IMAP/POP3 is available. No decoration of authenticated email via webmail yet. DMARC will supply = bits to build on and will act as carrot to get more people/institutions = to deploy. Things like DKIM are not very effective in pushing institutions = to deploy. DMARC=E2=80=99s carrot might end up being little green icon = for users to see. (Note carrots are needed as institutions often do not = understand other benefits/requirements). Forensic reports: OpenDMARC has library support to make sure Domain = Owners wants the info. Requirements for GDPR are a big issue and has to = be fully implemented. DMARC viewed as a way for senders to understand = how to secure their own data in better ways. GDPR is required; forensic reports do not bring along any = additional requirements/work load. No whitelists are maintained as exceptions to processing. ~5 years ago = whitelisting was removed and replaced by reputation measures. No = overrides are applied to DMARC policies. Instead, reputation ramps are = best established using SPF, DKIM, and DMARC. Start as small trusted = user, then ramp up. Users ultimately decide whether or not email is = wanted. Support inquiries go to contact address found in XML reports, gets added = to existing help desk. ------------------------ (end)= --Apple-Mail=_78589DDF-26EF-41CA-A242-2F1F2EB9354E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
[This email = is part of the series described here: = https://www.ietf.org/mail-archive/web/dmarc/current/msg03671.ht= ml]


Background: = Seznam.cz is largest mailbox provider in Czech Republic. In operation = since 1995. Started with email in =E2=80=9898. 8 million (monthly) = active accounts. Seznam attempts to support technical standards. Not a = lot of ISPs in Czech Republic; 60 ~million received daily emails = directly to inboxes (not including blocked email). Began looking at = DMARC ~2015, have been using as input into anti-spam, not 100% applied = as per DMARC spec.

Experience: = Began sending aggregate DMARC reports September 2017. Forensic reports = are to follow. Implementation based on OpenDMARC library. No storage or = logging issues. Capacity verification was performed beforehand, no = issues. =46rom a developer perspective very lightweight. =46rom project = management PoV, constraint was time in terms of priority against other = projects.
= Private DNS cache experienced no issue. SPF and = DKIM checking already existed. DKIM was required for bulk senders to = deliver email into Seznam since ~3 years ago. DMARC viewed as next step = to give senders picture of traffic.
Bulk senders vs primary post (transactional email = falls into primary post). Senders instructed to use DKIM to = differentiate between primary-post/transactional email and bulk email. = (Bulk email guidance: https://fbl.seznam.cz/)
Began with = SPF, recommended for senders but not a requirement like DKIM is. Primary = used as an input into anti-spam. SRS in use for past = year.

Operational = issues: biggest problem - pushing information to senders that DKIM is = required. 6 months preparation time. Senders had trouble understanding = DKIM and what was being asked (including developers).

=C2=BD of = bulk senders reside in CZ. Bounce messages used to inform people that = DKIM is now required. Help/support desk dealt with issues - guidance = given to deploy DKIM. Couple of months of guidance=E2=80=A6 still, = today, ~ half a million daily messages are bounced. Most ESPs do not = notice that their email us bouncing (!).. That is, not measuring = engagement at all.
= Maybe the people receiving email do not notice the = missing messages, and so everything is OK. :-7

Malformed = email is given a separate signal and dealt with.
All DKIM signatures are evaluated. All reported = via DMARC.
Key length = is not an issue due to recent DKIM deployments.
(Does = OpenDMARC flag short key length issues?).
Hadoop used as log = collection/data-warehousing.
DMARC stack = implemented inhouse, no issues with communication of various DMARC = inputs.

Hosting? = Custom domains can be used with web interface.
Forwardings happens. If ARC can supply original = authentication results, that would be useful.
IMAP/POP3 is available.
No decoration of authenticated email via webmail = yet. DMARC will supply bits to build on and will act as carrot to get = more people/institutions to deploy.
= Things like DKIM are not very effective in pushing = institutions to deploy. DMARC=E2=80=99s carrot might end up being little = green icon for users to see. (Note carrots are needed as institutions = often do not understand other benefits/requirements).

Forensic = reports: OpenDMARC has library support to make sure Domain Owners wants = the info. Requirements for GDPR are a big issue and has to be fully = implemented. DMARC viewed as a way for senders to understand how to = secure their own data in better ways.
GDPR is = required; forensic reports do not bring along any additional = requirements/work load.


No whitelists are maintained as exceptions to = processing. ~5 years ago whitelisting was removed and replaced by = reputation measures. No overrides are applied to DMARC policies. = Instead, reputation ramps are best established using SPF, DKIM, and = DMARC. Start as small trusted user, then ramp up. Users ultimately = decide whether or not email is wanted.

Support inquiries go to contact address found in = XML reports, gets added to existing help = desk.
------------------------
(end)
= --Apple-Mail=_78589DDF-26EF-41CA-A242-2F1F2EB9354E-- From nobody Mon Sep 25 03:02:00 2017 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 6161E1332CA for ; Mon, 25 Sep 2017 03:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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_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 (1024-bit key) header.d=openfortress.nl 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 5f6NCxbmmrhV for ; Mon, 25 Sep 2017 03:01:56 -0700 (PDT) Received: from lb1-smtp-cloud8.xs4all.net (lb1-smtp-cloud8.xs4all.net [194.109.24.21]) (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 0114A13330C for ; Mon, 25 Sep 2017 03:01:55 -0700 (PDT) Received: from popmini.vanrein.org ([83.161.146.46]) by smtp-cloud8.xs4all.net with ESMTP id wQCzdKz4wb4gvwQD0d6TuG; Mon, 25 Sep 2017 12:01:53 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=openfortress.nl; i=rick@openfortress.nl; q=dns/txt; s=fame; t=1506333703; h=message-id : date : from : mime-version : to : subject : content-type : content-transfer-encoding : date : from : subject; bh=PgHD+sjRMm+9VGTH9DY069wcCn8b46ai6NiEoTomJ+c=; b=ddtSGM9Pl8fy5QGXYjdu/W6BR7D7D+dklfNjRRp4cWizTn/8OyLMPuNA YE11NDnbZlnJxuR0+JPpqWMQT5HvwzD+Xwk2ElfsFHzv+2Eebm4QsXheuu mY6R4c0BMjImksKifjtsEJd/uRl3CQ/x+7X6z1C05bG/YBSZ6+xTcIauE= Received: from airhead.local (unknown [10.0.1.247]) by fame.vanrein.org (Postfix) with ESMTP id 5807319C14; Mon, 25 Sep 2017 10:01:43 +0000 (UTC) Message-ID: <59C8D406.7000707@openfortress.nl> Date: Mon, 25 Sep 2017 12:01:42 +0200 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: "dmarc@ietf.org" X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfIwJ6w7Af3w6c2y61JAEEIWgKUyFjkHSd6TNy2cSycpebfHmUegYGRThxfQ9aiKPeraiS8DYS6cMA0gLc8lVFncI9HpLm6G1VyBjemmQSFTcvZ/zw6XH 1es+JWCWUuWPLBBQsMwr9W15yHXnDJ9q5Is4qDzLAaI45Xp31xD5935s Archived-At: Subject: [dmarc-ietf] Lenient DKIM (new Internet 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, 25 Sep 2017 10:01:58 -0000 Hello DKIM/DMARC list, I would like to propose a method for "fixing" the real-world problems that currently break DKIM. I am aware of the work on ARC, but in comparison this appriach: 1. is much simpler, with a simple cryptographic foundation 2. works without explicit support from message-modifying intermediates 3. locates message parts that have changed [within practical bounds] 4. allows training on acceptable changes for given senders/intermediates 5. pins down rogue senders/intermediates more accurately The idea isn't completely worked out yet, but the approach should be crystal clear from the current text. I believe that this leads to better email user experiences than possible with ARC. I am looking forward to your responses. Please keep me in Cc: if possible? Best wishes, Rick van Rein ARPA2.net / InternetWide.org > *From:* internet-drafts@ietf.org > *Date:* 25 September 2017 at 11:49 > *To:* "Rick van Rein" > *Subject:* New Version Notification for draft-vanrein-dkim-lenient-00.txt > A new version of I-D, draft-vanrein-dkim-lenient-00.txt > has been successfully submitted by Rick van Rein and posted to the > IETF repository. > > Name: draft-vanrein-dkim-lenient > Revision: 00 > Title: Lenient DKIM > Document date: 2017-09-25 > Group: Individual Submission > Pages: 7 > URL: https://www.ietf.org/internet-drafts/draft-vanrein-dkim-lenient-00.txt > Status: https://datatracker.ietf.org/doc/draft-vanrein-dkim-lenient/ > Htmlized: https://tools.ietf.org/html/draft-vanrein-dkim-lenient-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-vanrein-dkim-lenient-00 > > > Abstract: > DKIM is a framework for signed messages, especially for email. While > in transit, changes are sometimes made, and these break the DKIM- > Signature. This specification makes DKIM more lenient, without > changes to its core. It adds leniency towards MIME body rewrites, > removal of alternatives and annotation with bits of text. The > intention is to allow these changes such that they can be clearly > shown to the user, while indicating that the remainder of the > signedmessage is still in tact. > > > > > 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 > From nobody Mon Sep 25 09:00:44 2017 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 172DE1344B6 for ; Mon, 25 Sep 2017 09:00:43 -0700 (PDT) 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 4IvDa6wFIjwf for ; Mon, 25 Sep 2017 09:00:39 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::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 2A4F71344BE for ; Mon, 25 Sep 2017 09:00:36 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id h191so3852191vke.6 for ; Mon, 25 Sep 2017 09:00:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fiction.net; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nfznQAxrxhjW0zzv0PV1e/UJ2K1tNLb06AafShrbfjM=; b=guC15b3+SAouYZkmCksLeI68tIo/eA+NqjkpbbgfCo5p7f2s6YrLPj24EnyuRXFfS4 3BVZEI/B1jbkkTszqUxR9sBlZa5fyZ5azN1n3BRtdWuUNbYyxMY7A36lPkRQ7ww0izn3 +MMKg3fQt0jKOXthJek5FZ+ky+EvGpo4R+s2GOcK8oVNUcJ4O2+I+o1VZM4BpsLRYEP0 NtfDxjkExt2Zkix4LI5fPFPBmLDWixxFXAd1yUiXaV2c2oLnB8wnkCYJhuzGJBgyghhX Wn/ztoigo9W3m7HIAlff64GqsWvgmulb3kTLsrKVuI/HRG6zM8rn3Lcclloj66Y7TUlD pq6Q== 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=nfznQAxrxhjW0zzv0PV1e/UJ2K1tNLb06AafShrbfjM=; b=q9CM6cF4VFcf/fDVVclGKlQYVRqd/deaA9oyJSLjRKuaXo7KzN6jCEaIUKnqLzRil2 uG4rnJDQ8PkNHDzAcW7qJ8pV4G9SYa5Ea9GtoNPFQ0IsC60dPc8Z/MCySDxsaQLGj76g jh56CkFXYHwGbOmI0bsBDBB+nUyZYEavVenA3tezDsXIII3FR7JWJ7kIUr/IoOWgqYqv JY51YGOgioWRLDFauz1EPsFasSSJ7Y1IpYJYmcZxLholrxcd880YmoREYMeaYCQsut2M tMrCEHnLJ6qN1AN2kggd1XkHN6T135GDww5scoWSdi3abUdFw8rr0W3HeQOkZ8phnecz WyOw== X-Gm-Message-State: AHPjjUj3MvVnNkNMUbKJmYOZuht0b9Bpye2IXp4klBRoWIchLvlatcTP 1g/am+0VfZ2KJFaqsWRDsHQ55Fyc X-Received: by 10.31.212.6 with SMTP id l6mr6486532vkg.58.1506355234636; Mon, 25 Sep 2017 09:00:34 -0700 (PDT) Received: from mail-vk0-f43.google.com (mail-vk0-f43.google.com. [209.85.213.43]) by smtp.gmail.com with ESMTPSA id w6sm1230717vkb.37.2017.09.25.09.00.32 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Sep 2017 09:00:32 -0700 (PDT) Received: by mail-vk0-f43.google.com with SMTP id w23so3859208vkw.2 for ; Mon, 25 Sep 2017 09:00:32 -0700 (PDT) X-Google-Smtp-Source: AOwi7QAE/pXERImV5iMTiee8++i1ITV92DDPD5z1Vbhibl2R7EZaeGJCn7gBC/U0KI8FQDbc1mNJ+49wZYLvRb74zzY= X-Received: by 10.31.142.211 with SMTP id q202mr6425028vkd.164.1506355232275; Mon, 25 Sep 2017 09:00:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.69.15 with HTTP; Mon, 25 Sep 2017 09:00:30 -0700 (PDT) Received: by 10.103.69.15 with HTTP; Mon, 25 Sep 2017 09:00:30 -0700 (PDT) In-Reply-To: <59C8D406.7000707@openfortress.nl> References: <59C8D406.7000707@openfortress.nl> From: Brandon Long Date: Mon, 25 Sep 2017 09:00:30 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Rick van Rein Cc: dmarc@ietf.org Content-Type: multipart/alternative; boundary="001a1142fd0a871988055a05a851" Archived-At: Subject: Re: [dmarc-ietf] Lenient DKIM (new Internet 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, 25 Sep 2017 16:00:43 -0000 --001a1142fd0a871988055a05a851 Content-Type: text/plain; charset="UTF-8" This is an interesting sketch, but it doesn't include the hard parts, so it's hard to know if it can provide what is needed. For example, will the rolling hash allow for exact boundaries of changes to be determined? Subjects are pretty short, how does a rolling hash handle that? I'm not familiar with rolling hashes, so perhaps my questions are naive. The mime body canonicalization is odd, what percentage of mail isn't multipart at this point? It also requires that mime canonicalization requires impl of this other spec, which seems more v2ish, though maybe not in formatting. I'd say the mime header canonicalization doesn't go far enough. For example, most mailing lists that are i18n aware are going to decode rfc2047 subjects before adding a subject prefix, and then reencode, which may not be in the same charset, especially if the prefix and subject are in different languages. Another issue we see is in optional things, such as quoting in address and parameter headers. Defining a canonical form for those headers might be necessary to accomplish what you want. There's also smtputf8 downgrades, which would imply taking a utf8 nonencoded subject and encoding it. It's also useful if your system uses a non rfc822 format internally and only gateways to the internet. I think a proper mime canonicalization would be useful on it's own, we've talked about it before internally here at Google. I believe that we discussed something similar to this early on this list, but the challenge is in the details. Brandon On Sep 25, 2017 3:02 AM, "Rick van Rein" wrote: > Hello DKIM/DMARC list, > > I would like to propose a method for "fixing" the real-world problems > that currently break DKIM. I am aware of the work on ARC, but in > comparison this appriach: > > 1. is much simpler, with a simple cryptographic foundation > 2. works without explicit support from message-modifying intermediates > 3. locates message parts that have changed [within practical bounds] > 4. allows training on acceptable changes for given senders/intermediates > 5. pins down rogue senders/intermediates more accurately > > The idea isn't completely worked out yet, but the approach should be > crystal clear from the current text. I believe that this leads to > better email user experiences than possible with ARC. > > I am looking forward to your responses. Please keep me in Cc: if possible? > > > Best wishes, > > Rick van Rein > ARPA2.net / InternetWide.org > > *From:* internet-drafts@ietf.org > > *Date:* 25 September 2017 at 11:49 > > *To:* "Rick van Rein" > > *Subject:* New Version Notification for draft-vanrein-dkim-lenient-00. > txt > > A new version of I-D, draft-vanrein-dkim-lenient-00.txt > > has been successfully submitted by Rick van Rein and posted to the > > IETF repository. > > > > Name: draft-vanrein-dkim-lenient > > Revision: 00 > > Title: Lenient DKIM > > Document date: 2017-09-25 > > Group: Individual Submission > > Pages: 7 > > URL: https://www.ietf.org/internet-drafts/draft-vanrein-dkim- > lenient-00.txt > > Status: https://datatracker.ietf.org/doc/draft-vanrein-dkim- > lenient/ > > Htmlized: https://tools.ietf.org/html/ > draft-vanrein-dkim-lenient-00 > > Htmlized: https://datatracker.ietf.org/ > doc/html/draft-vanrein-dkim-lenient-00 > > > > > > Abstract: > > DKIM is a framework for signed messages, especially for email. While > > in transit, changes are sometimes made, and these break the DKIM- > > Signature. This specification makes DKIM more lenient, without > > changes to its core. It adds leniency towards MIME body rewrites, > > removal of alternatives and annotation with bits of text. The > > intention is to allow these changes such that they can be clearly > > shown to the user, while indicating that the remainder of the > > signedmessage is still in tact. > > > > > > > > > > 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 > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --001a1142fd0a871988055a05a851 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This is an interesting sketch, but it doesn't=C2=A0 i= nclude the hard parts, so it's hard to know if it can provide what is n= eeded.=C2=A0 For example, will the rolling hash allow for exact boundaries = of changes to be determined?=C2=A0 Subjects are pretty short, how does a ro= lling hash handle that?=C2=A0 I'm not familiar with rolling hashes, so = perhaps my questions are naive.

The mime body canonicalization is odd, what percentage of mail isn't = multipart at this point?=C2=A0 It also requires that mime canonicalization = requires impl of this other spec, which seems more v2ish, though maybe not = in formatting.

I'd s= ay the mime header canonicalization doesn't go far enough.=C2=A0 For ex= ample, most mailing lists that are i18n aware are going to decode rfc2047 s= ubjects before adding a subject prefix, and then reencode, which may not be= in the same charset, especially if the prefix and subject are in different= languages.=C2=A0 Another issue we see is in optional things, such as quoti= ng in address and parameter headers.=C2=A0 Defining a canonical form for th= ose headers might be necessary to accomplish what you want.=C2=A0 There'= ;s also smtputf8 downgrades, which would imply taking a utf8 nonencoded sub= ject and encoding it.=C2=A0 It's also useful if your system uses a non = rfc822 format internally and only gateways to the internet.

I think a proper mime canonicalizatio= n would be useful on it's own, we've talked about it before interna= lly here at Google.

I be= lieve that we discussed something similar to this early on this list, but t= he challenge is in the details.

Brandon


On Sep 25, 2017 3:02 AM, "Rick= van Rein" <rick@openfortre= ss.nl> wrote:
Hello DKIM/DMARC list,

I would like to propose a method for "fixing" the real-world prob= lems
that currently break DKIM.=C2=A0 I am aware of the work on ARC, but in
comparison this appriach:

=C2=A01. is much simpler, with a simple cryptographic foundation
=C2=A02. works without explicit support from message-modifying intermediate= s
=C2=A03. locates message parts that have changed [within practical bounds]<= br> =C2=A04. allows training on acceptable changes for given senders/intermedia= tes
=C2=A05. pins down rogue senders/intermediates more accurately

The idea isn't completely worked out yet, but the approach should be crystal clear from the current text.=C2=A0 I believe that this leads to
better email user experiences than possible with ARC.

I am looking forward to your responses.=C2=A0 Please keep me in Cc: if poss= ible?


Best wishes,

Rick van Rein
ARPA2.net / InternetWide.org
> *From:* internet-drafts@ie= tf.org
> *Date:* 25 September 2017 at 11:49
> *To:* "Rick van Rein" <rick@openfortress.nl>
> *Subject:* New Version Notification for draft-vanrein-dkim-lenient-00.= txt
> A new version of I-D, draft-vanrein-dkim-lenient-00.txt
> has been successfully submitted by Rick van Rein and posted to the
> IETF repository.
>
> Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-vanrein-dkim-lenient
> Revision:=C2=A0 =C2=A0 =C2=A000
> Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Lenient = DKIM
> Document date:=C2=A0 =C2=A0 =C2=A0 =C2=A0 2017-09-25
> Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individu= al Submission
> Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 7
> URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-vanrei= n-dkim-lenient-00.txt
> Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-vanrein-dkim-lenient= /
> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0ht= tps://tools.ietf.org/html/draft-vanrein-dkim-lenient-00
> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-vanrein-dkim-= lenient-00
>
>
> Abstract:
>=C2=A0 =C2=A0 DKIM is a framework for signed messages, especially for e= mail.=C2=A0 While
>=C2=A0 =C2=A0 in transit, changes are sometimes made, and these break t= he DKIM-
>=C2=A0 =C2=A0 Signature.=C2=A0 This specification makes DKIM more lenie= nt, without
>=C2=A0 =C2=A0 changes to its core.=C2=A0 It adds leniency towards MIME = body rewrites,
>=C2=A0 =C2=A0 removal of alternatives and annotation with bits of text.= =C2=A0 The
>=C2=A0 =C2=A0 intention is to allow these changes such that they can be= clearly
>=C2=A0 =C2=A0 shown to the user, while indicating that the remainder of= the
>=C2=A0 =C2=A0 signedmessage is still in tact.
>
>
>
>
> 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. >
> The IETF Secretariat
>

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--001a1142fd0a871988055a05a851-- From nobody Mon Sep 25 11:19:29 2017 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 A09CA1344FC for ; Mon, 25 Sep 2017 11:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=Wwjf/OMd; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=KuJBL2t9 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 EkfNFmV07_MO for ; Mon, 25 Sep 2017 11:19:26 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C7141330B2 for ; Mon, 25 Sep 2017 11:19:26 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 610CF21CEA; Mon, 25 Sep 2017 14:19:25 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Mon, 25 Sep 2017 14:19:25 -0400 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:x-sasl-enc; s=fm1; bh=FDqaE9 mC0+WLpTVBnLPuxX6UzuNssspZVadczgVtviQ=; b=Wwjf/OMdPGbtt54JYshN2x +gbkYWiXL4Oabpo+tNO6Us2UTX33kuRGLqvH24T2W6+HFpFGkUi6JUTVGTrM7rt0 NfAUmZ+nwaDXm3Hmhol7EvMbSO/Pb2shLp6FtMoCr1Z9djSxwjup6KDcmoI1Zua1 Ang/lRDBORwAY2v9g/mEkJ0KHSdiJOnxLYd0EDSVHRPGuRG0z2sGHwnt2/Sju61+ EBFYIeRwIa/29Sf0K3J7ODajSE2jI4pGhYe674Emk5B/7uQPNJZfmDG5gAoK8GGp /Fu0iLfnv1a1lvheQM0stsMjPyZZpSAdTjtJfi71B6iqx7v80yuSzIDNE0jh4CZg == 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:x-sasl-enc; s= fm1; bh=FDqaE9mC0+WLpTVBnLPuxX6UzuNssspZVadczgVtviQ=; b=KuJBL2t9 PsEBROQXaSQmEL7uor7KgV15ySotpoOkxXZIiyPlsJqId6BqwKqmmsDCHHB8L0es bIEPNEb02dMrIk2bapJ5KYYm2R0ZatDmyxVQ/FaB18G8BZzFKeVW+r7mjNm9iiFv 7PNhSae1VlfO1fTKvoBBU15tAvItAxYGzpLGtzKk/I0vt0H9WrWXasqYk+oM5tOe M+OQsbfACKRAeeaQt+ffHy0G4rmGSky+w3VWxBhVSYeRRg2vNcoOsPh71vIYSb0t FJCD+dPfwZrdQowwf6UkXqKT6/wpxYfEwLt0jk/U2BNNz0Z19HXTfD4LlVky+xt2 CTm1yEa2N/I/1A== X-ME-Sender: X-Sasl-enc: Alic2BzARdxraaqv1u8RGlt/lE2oVDdNUak6ofb2tZLg 1506363565 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 1A7ED7E193; Mon, 25 Sep 2017 14:19:25 -0400 (EDT) References: <59C8D406.7000707@openfortress.nl> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Cc: dmarc@ietf.org X-Mailer: iPhone Mail (13G36) From: Stan Kalisch Date: Mon, 25 Sep 2017 14:19:22 -0400 To: Brandon Long Archived-At: Subject: Re: [dmarc-ietf] Lenient DKIM (new Internet 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, 25 Sep 2017 18:19:28 -0000 > On Sep 25, 2017, at 12:00 PM, Brandon Long wrote: >=20 >=20 > The mime body canonicalization is odd, what percentage of mail isn't multi= part at this point? iOS Mail (before 11, at least) does 7-bit text/plain mail by default. (If m= emory serves, this has something to do with Japanese SMS providers, although= Japanese obviously isn't 7-bit.) I don't know enough to hazard a guess at w= hat percentage of mail this is. Stan= From nobody Mon Sep 25 19:17:13 2017 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 EDA50132D67 for ; Mon, 25 Sep 2017 19:17:11 -0700 (PDT) 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, 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=mailforce.net header.b=WYM9SN4B; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=QCOtAtBx 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 MsWVZJBKUnXy for ; Mon, 25 Sep 2017 19:17:08 -0700 (PDT) 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 9329A1345EA for ; Mon, 25 Sep 2017 19:17:08 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id CA21F227C1; Mon, 25 Sep 2017 22:17:07 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Mon, 25 Sep 2017 22:17:07 -0400 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:x-sasl-enc; s=fm1; bh=9SA59Q sBayGLVCxggKhZX4aXJw/oxoLA9e7LA+kJD20=; b=WYM9SN4B1S10Rcs9ga8e6t mWIRsaERHXmjnCHdvtyWkXW6ZahWDy5z5xtiqVA+65Qu5nZf4ERJ6TQi0qJZbLRk mXQ3Ej/+qlTcuKeK+DEoAJnqdicdIYn7Xnzttz13YShoblYGzhnLENW5WXNSFnUI nwHqwH5IRkCMuOGbcyJD8WrRfuGuexXl+cSN/BwQlueFUN2oIP1CZDYFPG+j3u39 F4jl/yyQnM3JXLLpqSfemHWxsSk7/RLzdh88ViEi61chg8Ngq2qFASBDeOgWNAPp ckE17gRlOn44gVGf/1z95judh45k1FWRBITIhzDxr9WzRsFfL2fRoAHMWihQK+tQ == 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:x-sasl-enc; s= fm1; bh=9SA59QsBayGLVCxggKhZX4aXJw/oxoLA9e7LA+kJD20=; b=QCOtAtBx aVxbdjvh40kEfIB8x/gYdVAtnaG4XNbQBJA2TNXBiyU5yfcIq0wAtM371+DVSxcs TughP5RQC7X/u/yu2zRcgVR5KzX44vGU5N9r/YJNtqOc06ZBG2FAMCMCl3f/1yJQ Jnq4Scy7FsUWw4Ufvqd+1fgpr6wxMoQJsVcl7w+Ns/JxSh7IeROJiD0+Dsi5V5tJ Fm3CMKW/gwTqBR0L9E7ha1/T/azQkwFAwF4csiHiUqE/VW+dombzNw/AwppEOFIl lB6NZmF5JZN+mUkXqnjHtZBFRJH3i5R01zcEyzeSGdtLe9/AXaJoTSeMwa4w4qn9 02nlOYzcsu+Tjw== X-ME-Sender: X-Sasl-enc: /nJcKsgy7pOPxge0ejXKlxMVcnQfmpFlq1ncosqYp1f/ 1506392227 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 851967E446; Mon, 25 Sep 2017 22:17:07 -0400 (EDT) References: <59C8D406.7000707@openfortress.nl> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <4F7D5146-B6EE-451C-ACA6-8F3EC7A1A213@glyphein.mailforce.net> Cc: dmarc@ietf.org X-Mailer: iPhone Mail (13G36) From: Stan Kalisch Date: Mon, 25 Sep 2017 22:17:05 -0400 To: Brandon Long Archived-At: Subject: Re: [dmarc-ietf] Lenient DKIM (new Internet 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: Tue, 26 Sep 2017 02:17:12 -0000 I apologize for this post. I was in a car accident, and it's affecting me m= ore than I thought=E2=80=94you're obviously talking about MIME *bodies*. Ag= ain, my apologies to the list. Stan > On Sep 25, 2017, at 2:19 PM, Stan Kalisch wr= ote: >=20 >=20 >> On Sep 25, 2017, at 12:00 PM, Brandon Long wrote: >>=20 >>=20 >> The mime body canonicalization is odd, what percentage of mail isn't mult= ipart at this point? >=20 > iOS Mail (before 11, at least) does 7-bit text/plain mail by default. (If= memory serves, this has something to do with Japanese SMS providers, althou= gh Japanese obviously isn't 7-bit.) I don't know enough to hazard a guess a= t what percentage of mail this is. >=20 >=20 > Stan From nobody Tue Sep 26 07:57:25 2017 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 2F9BE1326F6 for ; Tue, 26 Sep 2017 07:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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_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 (1024-bit key) header.d=openfortress.nl 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 pzIHenQq3kvO for ; Tue, 26 Sep 2017 07:57:21 -0700 (PDT) Received: from lb3-smtp-cloud9.xs4all.net (lb3-smtp-cloud9.xs4all.net [194.109.24.30]) (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 51CA61201F8 for ; Tue, 26 Sep 2017 07:57:20 -0700 (PDT) Received: from popmini.vanrein.org ([83.161.146.46]) by smtp-cloud9.xs4all.net with ESMTP id wrIQdKPDXnIXbwrIRdmelM; Tue, 26 Sep 2017 16:57:18 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=openfortress.nl; i=rick@openfortress.nl; q=dns/txt; s=fame; t=1506437828; h=message-id : date : from : mime-version : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding : date : from : subject; bh=w/udKxcDZrOUdbpbj7inRL7fJVDvYrsM8hqwb4JyZcs=; b=pQUhjDcA2Dge5W3K3NX7XlXTyXS3p7ahiTDLhwdckkfNv82oRM8KCodS t01X7Lx7ciTEdhkD19EOfESdw5sEvSba+8rx9qjP2flGavYSkRrx4ePoEx yKTvp++2fyxgV3ZEPT3/HGBfeWPQIb4vQIlG26BFXrPTl0o0hkY40OzNE= Received: from airhead.local (phantom.vanrein.org [83.161.146.46]) by fame.vanrein.org (Postfix) with ESMTPA id D98C31A3E7; Tue, 26 Sep 2017 14:57:08 +0000 (UTC) Message-ID: <59CA6AC3.2080207@openfortress.nl> Date: Tue, 26 Sep 2017 16:57:07 +0200 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: dmarc@ietf.org CC: Brandon Long References: <59C8D406.7000707@openfortress.nl> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfDWy9yJf8EVaxVXpVxwmtPtDS4XTnALfXp8apWEb8JWmooXS1o+gnx77SKHzFROQ2D3w7ZWNVGsXH1PVS4rvKAJVMfhgrpS/DUjlAI6moj+98KIQbaDw w1SL3/f5n5+13yHGWil6THa7WU4NIJ5isfDLJ9LOfra2DbY1Sf0552IbU9NfW5DsW4OGmvhFh8ZZWzVhMVJ5YMRzVQuCCCS3OCw= Archived-At: Subject: Re: [dmarc-ietf] Lenient DKIM (new Internet 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: Tue, 26 Sep 2017 14:57:24 -0000 Hi, Thanks to Brandon for reading, and raking up the past :) It does sound like the rolling checksum is a new idea, so let me explain why I think it is useful, and note that you may know it from RSync. It helps in efficiently detecting the original text within an extended new text. If we have an old text (body or header: size doesn't matter) of size N, and a new one of size N+M, then computing checksums or hashes over all possible embeddings of the original in the new text would normally take O(N*M) elementary computations (such as adding a character to a checksum). With a rolling hash, you compute a checksum over the first N characters, and roll forward by one position in two elementary computations: addition of the next character and removing the one at the beginning; the complexity of searching for the text is now O(N+M), so in the order of the total text size. This is used as a hint that it would be useful to attempt a secure hash algorithm on the portion of a text that matches the checksum. This explains why the proposed DKIM-Signed-Content header holds: - the location of the text (body, header, or something nested) - the size N of the signed/original text - the outcome of a rolling checksum (perhaps 32 bits) - the outcome of a secure hash (to check after the hint) > will the rolling hash allow for exact boundaries of changes to be > determined? Subjects are pretty short, how does a rolling hash handle > that? No problems there. The limitation is that texts may be added before and after the original text, but nothing can be stripped. > > The mime body canonicalization is odd, what percentage of mail isn't > multipart at this point? Interesting. I though that it was quite sensible to reduce the MIME-representation of binary content to its original binary form before signing. The idea of multipart, which I may need to describe more accurately, is that the individual body parts get their own DKIM-Signature, and are then combined (following the MIME hierarchy) to form the overall DKIM-Signature for the message. By including Content-ID and Message-ID logically, it is possible to always distinguish between a body part and the full email. > It also requires that mime canonicalization requires impl of this > other spec, which seems more v2ish, though maybe not in formatting. > There is no reason why one couldn't sign separately with relaxed/relaxed and mime/mime canonicalisation. This would allow for a transition period. Even with just mime/mime, there is currently no punishment (but also no benefit) for mail parties that don't recognise the DKIM-Signature due to the new canonicalisation algorithm. The reason why this may not be so v2 as you suggest is that the dependency on support by intermediate mail facilities is replaced by a dependency on support in end points. Note that I'm not talking software support, but actual deployment. > I'd say the mime header canonicalization doesn't go far enough. Thank you, I tend to agree. I had considered character sets as mere interpretations of binary content, but was unsure if they were actually rewritten in passing. > For example, most mailing lists that are i18n aware are going to > decode rfc2047 subjects before adding a subject prefix, and then > reencode, which may not be in the same charset, especially if the > prefix and subject are in different languages. A starting charset may be recognised of course, and the number of original forms would be very limited and may be iterable? This raises concerns of potential loss of information due to incomplete / incorrect rewrites, however. > Another issue we see is in optional things, such as quoting in address > and parameter headers. Defining a canonical form for those headers > might be necessary to accomplish what you want. This would be specific to the MIME-headers, I suppose. Yes, a canonical form would then be a useful addition to the MIME header canonicalisation prescription. The list of headers in use there is limited, so it would be some work desscribing it, but not impossible, as far as I can tell. A predefined order for parameters, always using quotes, only escape when it is required, never mentioning default values, that sort of thing. > There's also smtputf8 downgrades, which would imply taking a utf8 > nonencoded subject and encoding it. It's also useful if your system > uses a non rfc822 format internally and only gateways to the internet. These are indeed pesky corner cases :-S so thanks for pointing them out right away. I am tempted to think that a limited number of alternative representations for the Subject are possible, and could be iterated over to recognise the header properly. Always mapping characters to the largest set spanning the current use case could help; that would be possible in the before and after case and lead to the same canonical format. [I may however be naive about i18n and especially what overlap character sets have. Please tell me if that is the case.] > I think a proper mime canonicalization would be useful on it's own, > we've talked about it before internally here at Google. Thanks. > I believe that we discussed something similar to this early on this > list, but the challenge is in the details. You certainly convinced me of that. If you have anything to add to the former, then by all means let me know. It is extremely useful to know what I'm heading for when deciding to get into this or not. Also, if the list thinks this is not a fruitful endeavour, then I welcome further critiques :) Thanks, -Rick From nobody Tue Sep 26 15:59:23 2017 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 92959133070 for ; Tue, 26 Sep 2017 15:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUX5F4IYM3AD for ; Tue, 26 Sep 2017 15:59:20 -0700 (PDT) Received: from gal.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (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 B2F8F13202D for ; Tue, 26 Sep 2017 15:59:19 -0700 (PDT) Received: (qmail 71612 invoked from network); 26 Sep 2017 22:59:18 -0000 Received: from unknown (64.57.183.53) by gal.iecc.com with QMQP; 26 Sep 2017 22:59:18 -0000 Date: 26 Sep 2017 22:58:56 -0000 Message-ID: <20170926225856.13967.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org Cc: rick@openfortress.nl In-Reply-To: <59C8D406.7000707@openfortress.nl> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Lenient DKIM (new Internet 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: Tue, 26 Sep 2017 22:59:21 -0000 In article <59C8D406.7000707@openfortress.nl> you write: >I am looking forward to your responses. Please keep me in Cc: if possible? I hate to be totally negative, but this draft revives a lot of things that we considered and rejected when we did DKIM. Marking content in an MUA is a WKBI*. There is no reason to believe that users would understand content marking or would make reasonable decisions based on it. As a general rule, anything that puts security policy in the hands of end users doesn't work. Think of all the browser bad SSL cert warnings you've clicked through. Also, there are more ways to change content that anyone can describe. Some of the harder to describe are recoding between 7 and 8 bit and base64, reducing the size and resolution of images (common on phones) and reordering MIME parts. Finally, it is pretty clear from the ARC work that big mail systems are more interested in telling recipient systems the identities of the parties that handled a message than how it changed or whether any of those parties thought the changes were a good idea. For another rejected approach see my DKIM conditional signatures, which let senders authorize intermediaries to modify and resign messages. https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/ R's, John * - Well Known Bad Idea From nobody Thu Sep 28 13:18:32 2017 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 2756913494A for ; Thu, 28 Sep 2017 13:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 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, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 k4jUzNbNAa6C for ; Thu, 28 Sep 2017 13:18:28 -0700 (PDT) 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 9F65613491D for ; Thu, 28 Sep 2017 13:18:28 -0700 (PDT) Received: by mail-ua0-x233.google.com with SMTP id f46so1175085uae.1 for ; Thu, 28 Sep 2017 13:18:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fiction.net; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=feBsYdpJLsbwe9ao8sooH0qPzk90d28CHLZy319ZIF8=; b=KJqVA1a+ThVhaI0nPsfHQcLkazQSZNc1YJYdL/VdAIr7etPXnRynaH2uIO90UcsWmC RhCQR8sVFlIfCWL+g94oW7asHhwONT5ZwfDF+5u7zDAhdCo9BiJLX4pjPBHDuJQhjCyn SFZqabXgcbCWgxpOF87HNLufOur+pjc9DpWnh6Aua0leu1TnR9rtnCaduna9NYbPj/od zhRUMjJMncs9OMzrkId6qYyhftz8D0lHq84h0eNO+g3tx2PsDE1Se+D7tEz30RGIu/6x yya8ZBKh/agaV3eW8pvVHI29xf9sjj64U5JJcFjbM3BuaWAZfgIwCRHZhJGHAedL/ezJ 8o4g== 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=feBsYdpJLsbwe9ao8sooH0qPzk90d28CHLZy319ZIF8=; b=TRlVjMC/tiH5P7PiagXwHqBbV8JTMIxw+HKzfFHO1kWZ7Qc/zU9OqzcvCWrJc92r5Z dtmpiQeamozZ5D51mWqFXxghnREhVBwJwif/Y4jL+9jG/WwGEBU0gLu0P14grfb70/0K ytA4WKFX/rg5BszjJf1XB+feQzdN/TNmSCmMrvtnwWUuA6Dm6mEvFyacdhA6hwSCofPG 0yyzERWJpcE8hKz4IlHBgAwqOlueGq80y70KehVxBdBKB+OAFDzemj86IbWVvdKzM57e Eiqs9myof2NcfkA/tnLlGWHIySBlYWYKe6WUK/OeCyYa0O6Uny1XGjiOJDd4V61dL32e rYhA== X-Gm-Message-State: AHPjjUgkIUal88Y/Y6TeOcSwTrC7XG9Sz8NwEduMQh/vfdmYHV3Ugc/E gndbsd/PEHtZul/Xb5bmhw1UN23z X-Received: by 10.176.21.228 with SMTP id j33mr3846107uae.55.1506629907289; Thu, 28 Sep 2017 13:18:27 -0700 (PDT) Received: from mail-vk0-f53.google.com (mail-vk0-f53.google.com. [209.85.213.53]) by smtp.gmail.com with ESMTPSA id d137sm715276vkf.22.2017.09.28.13.18.26 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Sep 2017 13:18:26 -0700 (PDT) Received: by mail-vk0-f53.google.com with SMTP id i1so1415694vke.12 for ; Thu, 28 Sep 2017 13:18:26 -0700 (PDT) X-Google-Smtp-Source: AOwi7QAIz58E/B8yObjKRg+S0QcrodkrUetM/Pd0Aty0194QlifOmwuiXFKJBBLddcJpv0+4dahP0qm6RrDB5xTVfNM= X-Received: by 10.31.176.132 with SMTP id z126mr3119018vke.95.1506629905715; Thu, 28 Sep 2017 13:18:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.69.15 with HTTP; Thu, 28 Sep 2017 13:18:25 -0700 (PDT) In-Reply-To: <20170926225856.13967.qmail@ary.lan> References: <59C8D406.7000707@openfortress.nl> <20170926225856.13967.qmail@ary.lan> From: Brandon Long Date: Thu, 28 Sep 2017 13:18:25 -0700 X-Gmail-Original-Message-ID: Message-ID: To: John Levine Cc: "dmarc@ietf.org" , Rick van Rein Content-Type: multipart/alternative; boundary="001a114411b6575208055a459ca8" Archived-At: Subject: Re: [dmarc-ietf] Lenient DKIM (new Internet 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: Thu, 28 Sep 2017 20:18:31 -0000 --001a114411b6575208055a459ca8 Content-Type: text/plain; charset="UTF-8" On Tue, Sep 26, 2017 at 3:58 PM, John Levine wrote: > In article <59C8D406.7000707@openfortress.nl> you write: > >I am looking forward to your responses. Please keep me in Cc: if > possible? > > I hate to be totally negative, but this draft revives a lot of things > that we considered and rejected when we did DKIM. > > Marking content in an MUA is a WKBI*. There is no reason to believe > that users would understand content marking or would make reasonable > decisions based on it. As a general rule, anything that puts security > policy in the hands of end users doesn't work. Think of all the > browser bad SSL cert warnings you've clicked through. > Knowing what changed is actually something that could go into a spam filter decision, however. It may be more complicated than arc. And we did have an example proposal that foundered on the deletion case. https://www.ietf.org/mail-archive/web/dmarc/current/msg01444.html One could also make a spam/phishing decision and show the original, forcing the user to click to see the modified version. In most mailing list cases, the subject/footer is mostly barely useful (quick, does this mailing list have a footer?). Ie, one could spam score both the original and the modified version, and make choices based on the difference. > Also, there are more ways to change content that anyone can describe. > Some of the harder to describe are recoding between 7 and 8 bit and > base64, reducing the size and resolution of images (common on phones) > and reordering MIME parts. > There is an obvious question of "handles everything" vs "handles the 99-percentile case better". Ie, a mechanism that explicitly handled subject prefixes and footers might do a better job than ARC, it might have better adoption and fewer deployment headaches, even as it allows some set of modifications to fail. It might also be harder to Also, among what you're talking about, I think the 7/8/base64 stuff would be covered by his MIME canonicalization. Although I've seen web proxies or clients which resize photos, I don't think I've ever seen an MTA do it... which doesn't mean they couldn't, but I'm not sure it's a use case we have to try and handle. Ie, I would have been happy to have changed Google Groups to allow DKIM signed mail to pass through, but we feel that current anti-spam laws mean we have to include an unsub link. We would have routed out any of the other types of changes you're talking about because DKIM passing to get the mail through is more important. Finally, it is pretty clear from the ARC work that big mail systems > are more interested in telling recipient systems the identities of the > parties that handled a message than how it changed or whether any of > those parties thought the changes were a good idea. > Google was the one with the previous diff based proposal, I would have been happy to avoid the "who" question if we could have done something more exact. Brandon --001a114411b6575208055a459ca8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Sep 26, 2017 at 3:58 PM, John Levine <johnl@taugh.com> wrote:
In a= rticle <59C8D406.7000707@openfortress.nl> you write:
>I am looking forward to your responses.=C2=A0 Please keep me in Cc: if = possible?

I hate to be totally negative, but this draft revives a lot of thing= s
that we considered and rejected when we did DKIM.

Marking content in an MUA is a WKBI*.=C2=A0 There is no reason to believe that users would understand content marking or would make reasonable
decisions based on it.=C2=A0 As a general rule, anything that puts security=
policy in the hands of end users doesn't work.=C2=A0 Think of all the browser bad SSL cert warnings you've clicked through.
<= div>
Knowing what changed is actually something that could go= into a spam filter decision, however.

It may be m= ore complicated than arc.=C2=A0 And we did have an example proposal that fo= undered on the deletion case.


One could also make a spam/phishing decision and show the original, = forcing the user to click to see the modified version.=C2=A0 In most mailin= g list cases, the subject/footer is mostly barely useful (quick, does this = mailing list have a footer?).=C2=A0 Ie, one could spam score both the origi= nal and the modified version, and make choices based on the difference.
=C2=A0
Also, there are more ways to change content that anyone can describe.
Some of the harder to describe are recoding between 7 and 8 bit and
base64, reducing the size and resolution of images (common on phones)
and reordering MIME parts.

There is an = obvious question of "handles everything" vs "handles the 99-= percentile case better".

Ie, a mechanism that= explicitly handled subject prefixes and footers might do a better job than= ARC, it might have better adoption and fewer deployment headaches, even as= it allows some set of modifications to fail.=C2=A0 It might also be harder= to=C2=A0

Also, among what you're talking abou= t, I think the 7/8/base64 stuff would be covered by his MIME canonicalizati= on.=C2=A0 Although I've seen web proxies or clients which resize photos= , I don't think I've ever seen an MTA do it... which doesn't me= an they couldn't, but I'm not sure it's a use case we have to t= ry and handle.=C2=A0

Ie, I would have been happy t= o have changed Google Groups to allow DKIM signed mail to pass through, but= we feel that current anti-spam laws mean we have to include an unsub link.= =C2=A0 We would have routed out any of the other types of changes you'r= e talking about because DKIM passing to get the mail through is more import= ant.

Finally, it is pretty clear from the ARC work that big mail systems
are more interested in telling recipient systems the identities of the
parties that handled a message than how it changed or whether any of
those parties thought the changes were a good idea.
Google was the one with the previous diff based proposal, I wo= uld have been happy to avoid the "who" question if we could have<= /div>
done something more exact.

Brandon
=
--001a114411b6575208055a459ca8-- From nobody Thu Sep 28 22:54:10 2017 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 9DD1B1344E7 for ; Thu, 28 Sep 2017 22:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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_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 (1024-bit key) header.d=openfortress.nl 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 QJ_hAyZkPR8F for ; Thu, 28 Sep 2017 22:54:05 -0700 (PDT) Received: from lb2-smtp-cloud9.xs4all.net (lb2-smtp-cloud9.xs4all.net [194.109.24.26]) (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 C4BA1133078 for ; Thu, 28 Sep 2017 22:54:02 -0700 (PDT) Received: from popmini.vanrein.org ([83.161.146.46]) by smtp-cloud9.xs4all.net with ESMTP id xoFKdqsXcnIXbxoFLdylzd; Fri, 29 Sep 2017 07:54:00 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=openfortress.nl; i=rick@openfortress.nl; q=dns/txt; s=fame; t=1506664432; h=message-id : date : from : mime-version : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding : date : from : subject; bh=4dPmTJFM6i6ur1S4kTnDnrR4goDUBT4zXYUi51GU4ss=; b=qeKCdOhti5KJFMevva2pEC60fusLTWlPA9kXrUXbccuT+usukdMaECFj HB1fRPOPk1ig7MRh0THwZJjjW4HsTnysUTjYd4kr98Pe44W/KLDiJHwO59 NIOJCEToacirvBwlBIFOQWJFcmpKUHXZ0jskTf57HQrDq7xkw1oGHYUEM= Received: from airhead.local (phantom.vanrein.org [83.161.146.46]) by fame.vanrein.org (Postfix) with ESMTPA id D47771A5A5; Fri, 29 Sep 2017 05:53:51 +0000 (UTC) Message-ID: <59CDDFEE.40104@openfortress.nl> Date: Fri, 29 Sep 2017 07:53:50 +0200 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: John Levine CC: dmarc@ietf.org References: <20170926225856.13967.qmail@ary.lan> In-Reply-To: <20170926225856.13967.qmail@ary.lan> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-CMAE-Envelope: MS4wfJ3++tcPMd2CIhyrmz2zhDUrJD6+6yVxbNG0qT0LSVzScTcZd1cdJctHSslSC035fB+iRzQXKIiYv8udrxkMqSXz8K6btNxbZLgx9zf9r7Ek76XYNnoV FTqwd3OOPgtbEsvRbhI2xwB2S22xR3gwW0Iue654C7MQ18S76rRVI4XZCUhgNFk1oWsGAuLB6JQObEf5Uz9RU27HTyEBdU1tUqs= Archived-At: Subject: Re: [dmarc-ietf] Lenient DKIM (new Internet 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: Fri, 29 Sep 2017 05:54:10 -0000 Hello, Thanks to John for reading the draft proposal. > Marking content in an MUA is a WKBI*. There is no reason to believe > that users would understand content marking or would make reasonable > decisions based on it. Hmm. The idea was founded on the common reliance of yellow/green bars to indicate website safety. I was not aware that it was considered WKBI; is there a place where I can learn what others have (so conclusively) said on the matter? This takes away one of two reasons to learn through rolling checksums about what is original and what has changed; automated content judgement can still benefit from seeing "that same ol' change" be made. > As a general rule, anything that puts security > policy in the hands of end users doesn't work. Think of all the > browser bad SSL cert warnings you've clicked through. I like the control, but I agree that this is not for everyone. > Also, there are more ways to change content that anyone can describe. > Some of the harder to describe are recoding between 7 and 8 bit and > base64, reducing the size and resolution of images (common on phones) > and reordering MIME parts. This is the sort of thing I was pitching for with this draft. Not everything is so trivial that I would say they need no DKIM or ARC re-signing. * 7/8 bit and base64: I think this can be covered by mapping most body parts to their binary form; and by canonicalising text/* specially by mapping it to Unicode in a UTF-8 representation. This misses out on mapping between =C3=9F and ss, but I am willing to accept that language-specifics are changes to content that require DKIM re-signing. * changes to size and resolution constitute change to the content and would require DKIM re-signing. I'd suspect this kind of transformation to be done near the recipient, so explicit trust in the transforming party may be setup explicitly? * reordering of MIME parts in a multipart/* would be recognised by this mechanism, because they are independently signed and listed as sub-parts. MUAs (or MTA spam filters) may judge that they like this, or not. > Finally, it is pretty clear from the ARC work that big mail systems > are more interested in telling recipient systems the identities of the > parties that handled a message than how it changed or whether any of > those parties thought the changes were a good idea. The ARC draft states clearly that it is difficult to pin down the culprit if the content does not validate. This problem does not exist in my proposal. It is clear that ARC addresses large mail providers, but it almost seems like only those are on its mind: parsing ARC is complex, especially because it involves taking charge over message in reputation intermediate systems. When such intermediates check (for spam, say) less accurately than the end systems on which they land, these intermediates will be discredited and effectively pushed off the Internet= . I also should add that the cryptographic design of ARC isn't clear to me. I pointed out to the ARC authors that there is a lot of *how* but little or no *why* to underpin what feels to me like a rather complex set of computations, given its intentions. After reading the ARC draft, my crypto-savvy head lacks the usual clear understanding of what is needed to do ARC well, and that worries me. > For another rejected approach see my DKIM conditional signatures, which > let senders authorize intermediaries to modify and resign messages. > > https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/ > This proposal is technically different, but maybe you are thinking of the comments on it? Please note that the proposed DKIM-Signed-Content is a helpful extra field, not a mandated extension. Thanks, -Rick From nobody Thu Sep 28 23:22:56 2017 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 3B0C8134721 for ; Thu, 28 Sep 2017 23:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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_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 (1024-bit key) header.d=openfortress.nl 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 xmCG4yaCKqy6 for ; Thu, 28 Sep 2017 23:22:53 -0700 (PDT) Received: from lb2-smtp-cloud9.xs4all.net (lb2-smtp-cloud9.xs4all.net [194.109.24.26]) (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 8281E134A3F for ; Thu, 28 Sep 2017 23:22:52 -0700 (PDT) Received: from popmini.vanrein.org ([83.161.146.46]) by smtp-cloud9.xs4all.net with ESMTP id xohFdr6zTnIXbxohGdyqmq; Fri, 29 Sep 2017 08:22:51 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=openfortress.nl; i=rick@openfortress.nl; q=dns/txt; s=fame; t=1506666163; h=message-id : date : from : mime-version : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding : date : from : subject; bh=jgbGfaq8yx3o1QWAtVngDi3uUzBs40VSGXbkdj4aUmo=; b=ez0xcKIwHM7jsEgXrE7tG9oR32lipkM7caY/z6nbGcLV5ukcH18sgYHr 784rpylEoy/eIA4W37EkpgsTQs2WTfhe9n7LqNVsiyelh0B43QJx+y+KpV GpaiZpqwLKRytqsfvWSijfamqh44xYT5tYHlmMYgnLcAozhUBCgqO0DAU= Received: from airhead.local (phantom.vanrein.org [83.161.146.46]) by fame.vanrein.org (Postfix) with ESMTPA id 9F8EA1A5B0; Fri, 29 Sep 2017 06:22:42 +0000 (UTC) Message-ID: <59CDE6B1.4040905@openfortress.nl> Date: Fri, 29 Sep 2017 08:22:41 +0200 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Brandon Long , John Levine CC: "dmarc@ietf.org" References: <59C8D406.7000707@openfortress.nl> <20170926225856.13967.qmail@ary.lan> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfKgftR9otee3q8YS/wMnpouMBT+BjEz8+3LfaYcxDe3MrwwWyggLrM4qew+C9V1BgeLecDBVb1QZPjjd2VCVPAkkNNwB4P6fc2ASc1SXj3RZ1h2pfL9E 9LPT0a8EYFXAXtjx3PFGksVCsFHWs7oqDpnDmD7M+cDRZMIUa0PLJVF71Zdz1F8zq/CBz0QraDJVevVQTIvgJ7OasknSkRpez+WqVfqFYWeKsdQ+GMJAn5Yk Archived-At: Subject: Re: [dmarc-ietf] Lenient DKIM (new Internet 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: Fri, 29 Sep 2017 06:22:55 -0000 Hi, > Also, among what you're talking about, I think the 7/8/base64 stuff > would be covered by his MIME canonicalization. Since most MIME content is binary, it would be helpfulto canonicalise individual body parts to their binary/pristine form. My current thinking is that even message/* is binary, and I can think of reasons why message/rfc822 should not be mangled in transit, but I'm not sure if this is realistic. Where MIME content is text/*, I had to learn more about i18n. Unicode was made to solve these riddles, by offering a place to all the characters in the world [but not their renderings]. For characters with more than one code, Unicode has the notion of canonical equivalence. And where characters may be decomposed into sequences, it has a more lenient equivalence notion of compatibility. The former should be no issue for DKIM, the latter may be. Defining equivalence through compatibility works for human texts but may be dangerous for accurate content like program fragments and URIs, except that the common limitation of these uses to ASCII solves these dangers. The stringprep profiles, including SASLprep which looks very email-suitable, would be able to handle all this. Software support already exists, of course. Finally, the nested nature of MIME content allows the recognition of failures. All that needs to be done is add a DKIM-Signature to the body parts, and have a mechanism for describing their compositions in a change-detectable manner (and sign for that mechanism too). > Although I've seen web proxies or clients which resize photos, I don't > think I've ever seen an MTA do it... which doesn't mean they couldn't, > but I'm not sure it's a use case we have to try and handle. Anything of this kind would know that delivery is to a particular class of MUA, so it would be near the recipient, where trust has a different organisation. -Rick From nobody Fri Sep 29 08:23:20 2017 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 A84211321C9 for ; Fri, 29 Sep 2017 08:23:17 -0700 (PDT) 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=jRHfLWz6; dkim=pass (1536-bit key) header.d=taugh.com header.b=i64KPU2y 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 0pe63V66HqNM for ; Fri, 29 Sep 2017 08:23:16 -0700 (PDT) Received: from gal.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (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 1EC73132396 for ; Fri, 29 Sep 2017 08:23:16 -0700 (PDT) Received: (qmail 39039 invoked from network); 29 Sep 2017 15:23:15 -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=987d.59ce6563.k1709; bh=xMPmvxfI2/BPe95khHnESKFHRlrS/RLLwPoCDTVKqc4=; b=jRHfLWz6RCGbh6m90BMTJEkJsGxUguaMsw8preShuTbk+rr+Y6U1eMgWFmTrmXSSPFjK5Ct9D3LrgfojKYyNwrSwv1NTu8xDqEN+UFJJFHSItNghSNY2Ss4ZVgcVwL92Jiyr6t16JKd94dadRroF0X39Bf5qlFFGuOj8qKKPNkMOFSQJfiw3aoWCeWrooBe4dRklrIMAKaOnZkfWjwkHSqUQmvT+Wi5MIDskBbScXd5O+AOOUgdcFYyG1HoAyTKO 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=987d.59ce6563.k1709; bh=xMPmvxfI2/BPe95khHnESKFHRlrS/RLLwPoCDTVKqc4=; b=i64KPU2yUnKr2V1iTschrX8RBDqjmK18JgjxwL5TqjB7X5xBk491XRCk8RcYvM6p8C6EMqySQbnRxJpxeOOL662fyoCBj2T4/UbNAdjF2mrrbS4lgYXgQU7FI2cyMLS5QTKyNiXmHCgBdcrt9TWlyujY3nTXYTByDONGHvEVWR2HxQZtx4C7NPYQz0KTB5E4dlnFthq9kfCjp9ELGcUjBwkkxVRtLNRK4qY6uKW1ILKT7saAuBIsdLZjJhwDqMvA 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; 29 Sep 2017 15:23:14 -0000 Date: 29 Sep 2017 08:23:13 -0700 Message-ID: From: "John R Levine" To: "Rick van Rein" Cc: dmarc@ietf.org In-Reply-To: <59CDDFEE.40104@openfortress.nl> References: <20170926225856.13967.qmail@ary.lan> <59CDDFEE.40104@openfortress.nl> 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] Lenient DKIM (new Internet 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: Fri, 29 Sep 2017 15:23:18 -0000 On Fri, 29 Sep 2017, Rick van Rein wrote: > Thanks to John for reading the draft proposal. > >> Marking content in an MUA is a WKBI*. There is no reason to believe >> that users would understand content marking or would make reasonable >> decisions based on it. > > Hmm. The idea was founded on the common reliance of yellow/green bars > to indicate website safety. I was not aware that it was considered > WKBI; is there a place where I can learn what others have (so > conclusively) said on the matter? But web sites don't color parts of a page green and parts red. There might be something in a SOUPS proceeding, and I know this came up multiple times back when we were rejecting more complex canonicalizations. The relevant question is more like, given that users do a bad job of using a single bit of "this web site is dangerous", why is there any reason to think they'd do even as well with more complex warnings. > It is clear that ARC addresses large mail providers, but it almost seems > like only those are on its mind: parsing ARC is complex, especially > because it involves taking charge over message in reputation > intermediate systems. When such intermediates check (for spam, say) > less accurately than the end systems on which they land, these > intermediates will be discredited and effectively pushed off the Internet. You say that like it's a bad thing. If your mailing list is so poorly configured that it gushes spam, I don't want its mail. R's, John From nobody Fri Sep 29 08:56:36 2017 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 4AC8F133187 for ; Fri, 29 Sep 2017 08:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=kitterman.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OmPPsFft3Lbl for ; Fri, 29 Sep 2017 08:56:22 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED5401331E3 for ; Fri, 29 Sep 2017 08:56:21 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 8C987C402AE for ; Fri, 29 Sep 2017 10:56:20 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2001409; t=1506700580; bh=q+Ij6Kr0iK/0ncH+f+MKiouQDVMW+yf0gsgsRTDVdGQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=SpcqXMV3pyneYoLfxxs/7nkG/IcfbihyW5PTX4WhVqBaqgJETO7fL/V1KSs8dr6Rh K9pUek7G1xSOz8yV5cFvxz6jWpdqLd1w5MFHf4ZkYymQGdg+KZ3d0SzRkhdoqTpUI3 EQX+wvvv45I3Vjtyb3FE7UWqGiRyCyK6jD+G5tFw= From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 29 Sep 2017 11:56:19 -0400 Message-ID: <3942982.pm2zWRk9M4@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-125-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <59CDDFEE.40104@openfortress.nl> References: <20170926225856.13967.qmail@ary.lan> <59CDDFEE.40104@openfortress.nl> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Archived-At: Subject: Re: [dmarc-ietf] Lenient DKIM (new Internet 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: Fri, 29 Sep 2017 15:56:28 -0000 On Friday, September 29, 2017 07:53:50 AM Rick van Rein wrote: > > Also, there are more ways to change content that anyone can describ= e. > > Some of the harder to describe are recoding between 7 and 8 bit and= > > base64, reducing the size and resolution of images (common on phone= s) > > and reordering MIME parts. >=20 > This is the sort of thing I was pitching for with this draft. Not > everything is so trivial that I would say they need no DKIM or ARC > re-signing. >=20 > * 7/8 bit and base64: I think this can be covered by mapping most bo= dy > parts to their binary form; and by canonicalising text/* specially by= > mapping it to Unicode in a UTF-8 representation. This misses out on > mapping between =DF and ss, but I am willing to accept that > language-specifics are changes to content that require DKIM re-signin= g. >=20 > * changes to size and resolution constitute change to the content an= d > would require DKIM re-signing. I'd suspect this kind of transformati= on > to be done near the recipient, so explicit trust in the transforming > party may be setup explicitly? >=20 > * reordering of MIME parts in a multipart/* would be recognised by t= his > mechanism, because they are independently signed and listed as > sub-parts. MUAs (or MTA spam filters) may judge that they like this,= or > not. Making DKIM signing MIME aware was specifically rejected during DKIM=20= development due to implementation complexity. It didn't magically get = easier=20 in the mean time. For the implementation I help maintain, dkimpy, larg= e=20 portions of the existing code would have to be thrown out and re-writte= n=20 (integrating ARC into the code base was relatively minor compared to th= is). If you've made it MIME aware, I think you've changed it enough it's no = longer=20 DKIM and you should call it something else (and I'm pretty sure I'd nev= er=20 implement it). Scott K From nobody Fri Sep 29 09:04:42 2017 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 82E55133187 for ; Fri, 29 Sep 2017 09:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=otoh.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L0FfSNHtMPoj for ; Fri, 29 Sep 2017 09:04:38 -0700 (PDT) Received: from suricate.otoh.org (suricate.otoh.org [173.11.101.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 482B3132CE7 for ; Fri, 29 Sep 2017 09:04:38 -0700 (PDT) Received: from [10.72.209.114] (unknown [209.131.62.149]) (Authenticated sender: zwicky) by suricate.otoh.org (Postfix) with ESMTPSA id D0CCC91AF; Fri, 29 Sep 2017 16:04:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=otoh.org; s=2014-12-30; t=1506701077; r=y; bh=BvCaTRpoJsqLD5KGA38+hYHXfxzWjFJP+pPMbn4dOtc=; h=Subject:From:In-Reply-To:Date:Cc:References:To; z=Subject:=20Re:=20[dmarc-ietf]=20Lenient=20DKIM=20(new=20Internet= 20Draft)|From:=20Elizabeth=20Zwicky=20|In-Reply-T o:=20<59CDE6B1.4040905@openfortress.nl>|Date:=20Fri,=2029=20Sep=20 2017=2009:04:36=20-0700|Cc:=20Brandon=20Long=20 ,=20John=20Levine=20,=0D=0A=20"dmarc@ietf.org"=20 |References:=20<59C8D406.7000707@openfortress.nl>= 20<20170926225856.13967.qmail@ary.lan>=20=20<59CDE6B1.4040905@op enfortress.nl>|To:=20Rick=20van=20Rein=20; b=Finm6i3aelQZMAX1LkD7cEmSuQtzqdUcKIeZ8mU9Yxwh5uhbWrfoGAWw+X0cop6B7 t/qeHLOiKc5C+xLtfbJwbenlrL2OPhB9St62MdwN0/GBbqMA8Bi5B+OdYtZVORtUrN EKDriHeK9c6GR16H0LCq4mzzT4dDA5k7b07GyMa4= Content-Type: multipart/alternative; boundary=Apple-Mail-E4EAF8F1-85AD-43DA-AF65-8110EA3FB54E Mime-Version: 1.0 (1.0) From: Elizabeth Zwicky X-Mailer: iPhone Mail (15A402) In-Reply-To: <59CDE6B1.4040905@openfortress.nl> Date: Fri, 29 Sep 2017 09:04:36 -0700 Cc: Brandon Long , John Levine , "dmarc@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: References: <59C8D406.7000707@openfortress.nl> <20170926225856.13967.qmail@ary.lan> <59CDE6B1.4040905@openfortress.nl> To: Rick van Rein Archived-At: Subject: Re: [dmarc-ietf] Lenient DKIM (new Internet 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: Fri, 29 Sep 2017 16:04:40 -0000 --Apple-Mail-E4EAF8F1-85AD-43DA-AF65-8110EA3FB54E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable http://www.usablesecurity.org/emperor/ Is the most classic paper on the complete uselessness of icons. You=E2=80=99= ll note that browsers have changed to putting up intrusive pages with unobtr= usive ways to continue, among other options, instead of showing broken lock i= cons.=20 Elizabeth=20 Zwicky@otoh.org > On Sep 28, 2017, at 11:22 PM, Rick van Rein wrote: >=20 > Hi, >=20 >> Also, among what you're talking about, I think the 7/8/base64 stuff >> would be covered by his MIME canonicalization. >=20 > Since most MIME content is binary, it would be helpfulto canonicalise=20 > individual body parts to their binary/pristine form. My current > thinking is that even message/* is binary, and I can think of reasons > why message/rfc822 should not be mangled in transit, but I'm not sure if > this is realistic. >=20 > Where MIME content is text/*, I had to learn more about i18n. Unicode > was made to solve these riddles, by offering a place to all the > characters in the world [but not their renderings]. For characters with > more than one code, Unicode has the notion of canonical equivalence.=20 > And where characters may be decomposed into sequences, it has a more > lenient equivalence notion of compatibility. The former should be no > issue for DKIM, the latter may be. Defining equivalence through > compatibility works for human texts but may be dangerous for accurate > content like program fragments and URIs, except that the common > limitation of these uses to ASCII solves these dangers. The stringprep > profiles, including SASLprep which looks very email-suitable, would be > able to handle all this. Software support already exists, of course. >=20 > Finally, the nested nature of MIME content allows the recognition of > failures. All that needs to be done is add a DKIM-Signature to the body > parts, and have a mechanism for describing their compositions in a > change-detectable manner (and sign for that mechanism too). >=20 >> Although I've seen web proxies or clients which resize photos, I don't >> think I've ever seen an MTA do it... which doesn't mean they couldn't, >> but I'm not sure it's a use case we have to try and handle. >=20 > Anything of this kind would know that delivery is to a particular class > of MUA, so it would be near the recipient, where trust has a different > organisation. >=20 > -Rick >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc --Apple-Mail-E4EAF8F1-85AD-43DA-AF65-8110EA3FB54E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

http://www.usablesecurity.org/emperor/

Is the most classic paper on the complete uselessness of icons. You= =E2=80=99ll note that browsers have changed to putting up intrusive pages wi= th unobtrusive ways to continue, among other options, instead of showing bro= ken lock icons. 

Elizabeth 


On Sep 28, 2= 017, at 11:22 PM, Rick van Rein <= rick@openfortress.nl> wrote:

<= div>Hi,

Als= o, among what you're talking about, I think the 7/8/base64 stuff
<= /blockquote>
would be covered by his MIME can= onicalization.

Since most MIME= content is binary, it would be helpfulto canonicalise
indi= vidual body parts to their binary/pristine form.  My current
= thinking is that even message/* is binary, and I can think of reasons<= /span>
why message/rfc822 should not be mangled in transit, but I'm= not sure if
this is realistic.

<= span>Where MIME content is text/*, I had to learn more about i18n.  Uni= code
was made to solve these riddles, by offering a place to= all the
characters in the world [but not their renderings].=  For characters with
more than one code, Unicode has t= he notion of canonical equivalence.
And where characters ma= y be decomposed into sequences, it has a more
lenient equiva= lence notion of compatibility.  The former should be no
issue for DKIM, the latter may be.  Defining equivalence through
compatibility works for human texts but may be dangerous for accu= rate
content like program fragments and URIs, except that th= e common
limitation of these uses to ASCII solves these dang= ers.  The stringprep
profiles, including SASLprep which= looks very email-suitable, would be
able to handle all this= .  Software support already exists, of course.
<= br>Finally, the nested nature of MIME content allows the recognition o= f
failures.  All that needs to be done is add a DKIM-Si= gnature to the body
parts, and have a mechanism for describi= ng their compositions in a
change-detectable manner (and sig= n for that mechanism too).

Although I've seen web proxies or clients which resize photos, I d= on't
think I've ever s= een an MTA do it... which doesn't mean they couldn't,
but I'm not sure it's a use case we have to= try and handle.

Anything of t= his kind would know that delivery is to a particular class
o= f MUA, so it would be near the recipient, where trust has a different=
organisation.

-Rick

_______________________________________________dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
= --Apple-Mail-E4EAF8F1-85AD-43DA-AF65-8110EA3FB54E-- From nobody Fri Sep 29 09:11:23 2017 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 C71AA1331C1 for ; Fri, 29 Sep 2017 09:11:22 -0700 (PDT) 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 0-xXQlxOlDqH for ; Fri, 29 Sep 2017 09:11:21 -0700 (PDT) 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 9F98B132F76 for ; Fri, 29 Sep 2017 09:11:21 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id o77so96160qke.9 for ; Fri, 29 Sep 2017 09:11:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=twOx2BPfNxmjGZU/lGqFr7fjEEqFYUikd9OYH+fK3gY=; b=lvMi4GGytaKs2BeeECKtdNV7TT87qnaYQD8O9cRp1wo+eg2sys3kBGNFrND4YcrDyC YfJTGPssSWauP+InhMAkwmxbu51+V8raznigCp89o2bYUBaqri0hIb7Mm44Lt6otqjWZ NgrBta203V6mHyM5eky9pw2gRjjXa58xIoJ5gmD5z6wmUNiGp7vKMfEhh5bh9OHvi5jM vvIJTKHGJ/xzz6dwg29C4aIWoQhp7rnmCLPuvpV3rJq0by1WQtBFiQGMvPpBk5uq5kKR 4nZbTZKhp5VYqd0TFkA5x8jhAiQ3+V4gsZ+ORth8hAuXrWKEmbcJydUijMheRzkDPOzn R/Cg== 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=twOx2BPfNxmjGZU/lGqFr7fjEEqFYUikd9OYH+fK3gY=; b=tAYJdBruPz2fXg8x1AdtPq6/nIm5FOwmUUG8H8Ysn1jNf7zD+d3UxkDFCarmHXcqII 5VFCXYpZS0fr9iWjMNPaKFXVKnin0VMLQE70gSldRn5TlVuWDial3S3J+6FPZOMQXisg 9I+nQsUvzehCCv8yFTgoEkadfuUxROuBOYkgCtX5tMLvBThz01/21bLSJ+N6fIA9qaXY T7qZ/mW2tDSFw1ute8O+kJFSP477N9nJdh1cSUmPEBHRe1er1WBvWw4hkAuvNhHE/5VB UI2F7SrwaD//SQHQSe8wFbU7z6A8hpdkZfJSHsoFlhXH83clWI/+wC+BWS6oNuo5YGrV Yn+g== X-Gm-Message-State: AMCzsaVdmz2Wnb/QCNl2/E1Go9siXqKibo63ko/FsX7Z65lclyDlD1u2 om9g7u6agAUyar0XJXJAVEYbbihIhDc2fTfKnrE= X-Google-Smtp-Source: AOwi7QDFWi+n9VY0airfycveIgiAT3bs7VmqHnCXmGDvg6ZVA3I/A4cSMrMlXqxPRLWAWA1Z1ZutbzJvZG4Ufie88b0= X-Received: by 10.55.16.198 with SMTP id 67mr4052099qkq.116.1506701480439; Fri, 29 Sep 2017 09:11:20 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 10.237.51.195 with HTTP; Fri, 29 Sep 2017 09:11:20 -0700 (PDT) From: Barry Leiba Date: Fri, 29 Sep 2017 12:11:20 -0400 X-Google-Sender-Auth: 99R8pRPaSie5BE6WS2zcj2MLpjc Message-ID: To: "dmarc@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [dmarc-ietf] Do we need a session in Singapore? 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, 29 Sep 2017 16:11:23 -0000 I've been meaning to probe about this for a while, but I'm being a bad chair and didn't do it, and now today is the deadline for requesting slots. So... I'm going to request a 1-hour slot, which we can change or cancel later (but it's better to get into the scheduling process than to ask people to scramble around later). I'll do that right after I send this. Now: Do we need a slot? What do we need to talk about in person that merits taking up a slot? Please discuss this and let's decide soon. Barry, bad chair From nobody Fri Sep 29 09:13:17 2017 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 1A51A1331D9; Fri, 29 Sep 2017 09:13:15 -0700 (PDT) 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.63.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150670159510.14242.3589294783257892829.idtracker@ietfa.amsl.com> Date: Fri, 29 Sep 2017 09:13:15 -0700 Archived-At: Subject: [dmarc-ietf] dmarc - New Meeting Session Request for IETF 100 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: Fri, 29 Sep 2017 16:13:15 -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: jmap dcrup uta dispatch People who must be present: Ned Freed Barry Leiba Alexey Melnikov Tim Draegen Kurt Andersen Resources Requested: Experimental Room Setup (U-Shape and classroom, subject to availability) Special Requests: --------------------------------------------------------- From nobody Fri Sep 29 15:19:33 2017 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 8DC37134300 for ; Fri, 29 Sep 2017 15:19:32 -0700 (PDT) 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 vMWhnAa7NbXS for ; Fri, 29 Sep 2017 15:19:28 -0700 (PDT) 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 C3BCA1201F8 for ; Fri, 29 Sep 2017 15:19:27 -0700 (PDT) Received: by mail-lf0-x22e.google.com with SMTP id q132so951971lfe.5 for ; Fri, 29 Sep 2017 15:19:27 -0700 (PDT) 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=spL3xXPCOhfP/KMXbVJE2p9rP0fH6ryHcwD45F17Zls=; b=MtmyFZCUpNpdKnLFGvimKprax66+IEFs7Qi1qxhyJ73hoHwT6xbaezv1EREHU/8B6V mfhZzP/sB0KRTjl9bcRA6uweHedRpPGgN7+i3tRe+mbEOuo+BXPdU0gtycDfawD94poq XRHzeQIvQoX4m9NfjmkE7QFzXsPDaeI2t5WUk= 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=spL3xXPCOhfP/KMXbVJE2p9rP0fH6ryHcwD45F17Zls=; b=QtrMVo0fKpwrdgnDCOfQUGa1nmN9IMTH83He1sereXQ+jJyTx39+HzeVxwZA9BE8Cr evatdkZcwHwVApQUxN3y4vnECbAWaAPBNj72p9y4Vdnv0cwUPCmKyHNtaXjQiCsk8NCK aOO+3PHsYjZiNxjOGKI0fEBvWBSg2BHfm5zb7h255ASEPvC2MHGolg7u0/n4IbTD00zn FqbsB9nxKKDMsa8Me1Yfq9gQczOMHxhrICqjkbRVuz8jEJ/K3wLtLUWKqTFJ6QpTZrYH dChaJCskINmuwq5PFqjUAe753A3iOC/JCCJtH5EgmE/Xn2q8e30+RJyYNjNA0LlSdLKr 9/bg== X-Gm-Message-State: AMCzsaWHIKKbK8QXyk3IumBcHJgYqpMKMd5WN/X5o4z1wwA/H4M1gHY+ DaaW9pDkzCaWXZrYZm+b8wzaBZXGzn8uLt3zQYvQaHI9 X-Google-Smtp-Source: AOwi7QCA/JnQluP6Y+1lRkANeiq7ZvvnR9jSXRwQOz4ir2UDKnRZrCZe+Kiwy1VF+jVgE9/c4hqEjc575m7UgPLyzoc= X-Received: by 10.25.196.70 with SMTP id u67mr1857102lff.144.1506723565941; Fri, 29 Sep 2017 15:19:25 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.25.227.75 with HTTP; Fri, 29 Sep 2017 15:19:25 -0700 (PDT) In-Reply-To: <59CDDFEE.40104@openfortress.nl> References: <20170926225856.13967.qmail@ary.lan> <59CDDFEE.40104@openfortress.nl> From: "Kurt Andersen (b)" Date: Fri, 29 Sep 2017 15:19:25 -0700 X-Google-Sender-Auth: Z-UbQbkl-F93B0nt1jyWYaZcecE Message-ID: To: Rick van Rein Cc: John Levine , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a114b1f90ec4cce055a5b6aca" Archived-At: Subject: Re: [dmarc-ietf] Lenient DKIM (new Internet 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: Fri, 29 Sep 2017 22:19:32 -0000 --001a114b1f90ec4cce055a5b6aca Content-Type: text/plain; charset="UTF-8" On Thu, Sep 28, 2017 at 10:53 PM, Rick van Rein wrote: > > I also should add that the cryptographic design of ARC isn't clear to > me. I pointed out to the ARC authors that there is a lot of *how* but > little or no *why* to underpin what feels to me like a rather complex > set of computations, given its intentions. Your request for better clarity on this point has not been ignored, but we are still working on effective ways to express both the intentions and the design. --Kurt --001a114b1f90ec4cce055a5b6aca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Sep 28, 2017 at 10:53 PM, Rick van Rein <rick@openfortress.nl= > wrote:

I also should add that the cryptographic design of ARC isn't clear to me.=C2=A0 I pointed out to the ARC authors that there is a lot of *how* but=
little or no *why* to underpin what feels to me like a rather complex
set of computations, given its intentions.=C2=A0=C2=A0
Your request for better clarity on this point has not been igno= red, but we are still working on effective ways to express both the intenti= ons and the design.

--Kurt=C2=A0

--001a114b1f90ec4cce055a5b6aca-- From nobody Fri Sep 29 15:24:53 2017 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 88D12134222 for ; Fri, 29 Sep 2017 15:24:44 -0700 (PDT) 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 1R0_SoD7mKrT for ; Fri, 29 Sep 2017 15:24:42 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B33BA1201F8 for ; Fri, 29 Sep 2017 15:24:41 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id 23so941779lfs.10 for ; Fri, 29 Sep 2017 15:24:41 -0700 (PDT) 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=zBVjsm+qwJDJnAUMiay/nI7Emuwbj67Ew0RdhRnfAtA=; b=C+V2ItuF5xp7xzuzflmgxvWxT/S1W1HQ8F+ba4KnOpAjtmRRVa5keb0XOuzR6dQg1q NN9qF7hldIgC5cbRcwBjCWddukaC/BZW93sfJpi4KguaETs/CIFVvft7Efy+HoS/m6pw ZWhLDjMkYi2D72voTCC+kjm8dyHjrdw0/jVAo= 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=zBVjsm+qwJDJnAUMiay/nI7Emuwbj67Ew0RdhRnfAtA=; b=DsNkFWEuWcqeIiL/7MEIMD5LYXLY0sVVMZIW8SzZwjC1YJndk4s+NZ1FpzUHQFIBOy /UqjaYTs6DRs7FXaDGTIlmnvANjHLTS72UJMvJhAhUSKTN5HY5V5TVEtCORJbfsMLbMG S+AsLBc8+QVs0AbKLQ6sNJJXAT8LqyAI2G1u9PzwXOrQ3lrqc/Sq5PMAvU4lrySto0yB ae1riW/kJksFdz66dEnZHpSxRJqzhdRmf97h7Y2j1Z22zWhl4obyMVl0j5Rs6/MPqvbY BaSzUHEOFOczx5vzeUXIY0ir00DKAcN8lucUpxuhAaK9+/5PPOFp8piD8PI6cYVRNTtB 5iEw== X-Gm-Message-State: AHPjjUiW8VXEdZvenBWPjkPagrpLCrT51AisTeDqBUu1ZBS4uaPcgyZG PktmaXFbwj+N8U6IsmOlTOiZdH2hJa4JBDJDfeTlcg== X-Google-Smtp-Source: AOwi7QAF4FZsjVoe8TORzS7GJejnKyP/G/XZg2HLFd731XJxYZDsmOIXiU23C4Ttnq8HDVFjI7YKzSOqlBBujqTarhk= X-Received: by 10.25.190.74 with SMTP id o71mr1734446lff.216.1506723879778; Fri, 29 Sep 2017 15:24:39 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.25.227.75 with HTTP; Fri, 29 Sep 2017 15:24:39 -0700 (PDT) In-Reply-To: References: From: "Kurt Andersen (b)" Date: Fri, 29 Sep 2017 15:24:39 -0700 X-Google-Sender-Auth: 3FC1JcXqGrt_E7JhAlLENPAFnjw Message-ID: To: Barry Leiba Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c1a1f48a12721055a5b7da5" Archived-At: Subject: Re: [dmarc-ietf] Do we need a session in Singapore? 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, 29 Sep 2017 22:24:44 -0000 --94eb2c1a1f48a12721055a5b7da5 Content-Type: text/plain; charset="UTF-8" On Fri, Sep 29, 2017 at 9:11 AM, Barry Leiba wrote: > > Do we need a slot? What do we need to talk about in person that > merits taking up a slot? Please discuss this and let's decide soon. > > I don't think we need one. If one does get scheduled, I would only be able to participate (remotely) on or after Wednesday (Pacific time). It looks like I could not get to Singapore for a real F2F until Thursday given flight schedules so I'm not sure if that would be worthwhile. --Kurt --94eb2c1a1f48a12721055a5b7da5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --94eb2c1a1f48a12721055a5b7da5-- From nobody Sat Sep 30 12:58:54 2017 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 2F6411330B3 for ; Sat, 30 Sep 2017 12:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.82 X-Spam-Level: X-Spam-Status: No, score=-0.82 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (1024-bit key) header.d=openfortress.nl 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 8sTd1T_k6lW7 for ; Sat, 30 Sep 2017 12:58:47 -0700 (PDT) Received: from lb1-smtp-cloud9.xs4all.net (lb1-smtp-cloud9.xs4all.net [194.109.24.22]) (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 C152B133065 for ; Sat, 30 Sep 2017 12:58:46 -0700 (PDT) Received: from popmini.vanrein.org ([83.161.146.46]) by smtp-cloud9.xs4all.net with ESMTP id yNuLd8ohLnIXbyNuMd4MRE; Sat, 30 Sep 2017 21:58:44 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=openfortress.nl; i=rick@openfortress.nl; q=dns/txt; s=fame; t=1506801515; h=message-id : date : from : mime-version : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding : date : from : subject; bh=TQgJ4mRdNIJg0BdT29JQ7cR4uGs9ZNiklwy0mFLTTms=; b=c+uc/P/qOI2xZ3fRGqJ05iID6VjLIVP7YY2c81IyppNBTqta7zlNZvwa DE5YUnrQmoEpHCYp6BlcPx2R5o/F5WPCnx+Kkutr0Om3wtm7j2Dt6Yreh5 7FrJaCyzz41QD3okJHJLi1NyXE2gejTqPBHeQbp9lxyCMW8v9pP9O6Z9k= Received: from airhead.local (phantom.vanrein.org [83.161.146.46]) by fame.vanrein.org (Postfix) with ESMTPA id 7B18C1A7B8; Sat, 30 Sep 2017 19:58:34 +0000 (UTC) Message-ID: <59CFF769.1040103@openfortress.nl> Date: Sat, 30 Sep 2017 21:58:33 +0200 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Elizabeth Zwicky , John Levine CC: "dmarc@ietf.org" References: <59C8D406.7000707@openfortress.nl> <20170926225856.13967.qmail@ary.lan> <59CDE6B1.4040905@openfortress.nl> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfD6vlbjnd1GbsmlvENSjYHQd4wr2Ctva1VAzDh3tH8MroqFSZys5jRyIPolX8R09qEx9J4E7fk6R54sEE49jsQUfdmflW3SdtumaVYjaXQqphkqumBFX /2Tlu76MsZohHlSwPryUxEwC8MM0duMm+e6Xk5btcxdp2bz6RhxdrdEtnaDKsUXYy/nkq7BBV1/bGrnjFgHPdr1PHRYj5Awy4s+K8Na4i77IycfKahYpHO6V Archived-At: Subject: Re: [dmarc-ietf] Lenient DKIM (new Internet 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: Sat, 30 Sep 2017 19:58:52 -0000 Hi, > http://www.usablesecurity.org/emperor/ > Thanks for this horror story. Mind-numbing, but useful work. I shall remove the reason of "security painting" by MUAs from the text. What remains is automated content processing (spam filtering) which still appears to be a sufficiently good reason on its own. It still appears to me that most of the difficult cases can be remedied in the proposed [but currently somewhat undefined] c=mime/mime specification. Thanks, -Rick From nobody Sat Sep 30 13:07:36 2017 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 57B30133342 for ; Sat, 30 Sep 2017 13:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=rPPGWcKE; dkim=pass (1536-bit key) header.d=taugh.com header.b=BQ6hxBLp 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 pdORN9fQ-fBI for ; Sat, 30 Sep 2017 13:07:33 -0700 (PDT) Received: from gal.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (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 A7D4C133065 for ; Sat, 30 Sep 2017 13:07:33 -0700 (PDT) Received: (qmail 97545 invoked from network); 30 Sep 2017 20:07:32 -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=17d05.59cff984.k1709; bh=xwmV5Qt1pScPU5RQqGg6gRNKPdTau2ptKEx08hUbG1g=; b=rPPGWcKETDDVdVY5FeUK5L49bFnhAh0IvtsdClrkH+VjlolbgIWNT7bxCROY3z4t/cYZqDwnGNfCEWgMw1/Ew/Rs7/N8HC+SNFti9tZKV1IfZd17CjHagyMN12Ppz9GwlPxjf5JPEeF1W9GqjKxWT8EdaxOh2ofFDZFbiLZ3Z9kwNDxxo1PqXYbggwXW3dcqZQzaNaTmGHN74KCaHINIDiC71lhUCFnf8GVWddX3qAWLL8ifS5a8cYaZEU9j5k4L 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=17d05.59cff984.k1709; bh=xwmV5Qt1pScPU5RQqGg6gRNKPdTau2ptKEx08hUbG1g=; b=BQ6hxBLppCIBQVBLbVS7MefyjA0WLqJPCZnDNdBNzlUHStd1ePRceXcpf5m/SA6aHpIp0aYQatFqvIjSB0f93FTaicFvcoo7T1DlZzv4VwwaSfsq+j6NNvrAO3l6lRMZnFg2vnj4zIrUTF87qHe4v3HEiA53B0gq5EhjoBLsbx0tG9Si7E7WPJh9MZwCb91i4vztE1rAKSl8yZk9Bn+rNpUYp+uZsOXBFBxD963zVaL2hHmIYQL99K07OeK7Q4Kd 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; 30 Sep 2017 20:07:32 -0000 Date: 30 Sep 2017 16:07:31 -0400 Message-ID: From: "John R Levine" To: "Rick van Rein" Cc: "dmarc@ietf.org" In-Reply-To: <59CFF769.1040103@openfortress.nl> References: <59C8D406.7000707@openfortress.nl> <20170926225856.13967.qmail@ary.lan> <59CDE6B1.4040905@openfortress.nl> <59CFF769.1040103@openfortress.nl> 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] Lenient DKIM (new Internet 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: Sat, 30 Sep 2017 20:07:35 -0000 > I shall remove the reason of "security painting" by MUAs from the text. > What remains is automated content processing (spam filtering) which > still appears to be a sufficiently good reason on its own. It still > appears to me that most of the difficult cases can be remedied in the > proposed [but currently somewhat undefined] c=mime/mime specification. This really needs some prototype implementations to see if it's technically workable. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly