From nobody Thu May 5 06:57:32 2016 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 578DC12D900 for ; Thu, 5 May 2016 06:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, 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 kWBkQmQhyK6a for ; Thu, 5 May 2016 06:57:24 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002: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 EFA9D12D854 for ; Thu, 5 May 2016 06:54:40 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id t10so140246423ywa.0 for ; Thu, 05 May 2016 06:54:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eudaemon.net; s=dkey; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=MxaNawM0VjX2DHEGigYueT+87jM1Vf65gV6P8dUqmKs=; b=caI8b8V61PZo0DkCs1s6MNjv9tTQB3RfAEtuG1pnSP9eUe1BrVqr3Zrls43eB04cd7 aBVvrTonqeIwzuFFWzqt+vsD1ngKq3YOEGBJ/JosXd9hcSrDOIHQsz0mVO7dYJcrVqq9 0t3YFHDGf0hwNrRVbEONR2pnF8VkGDmpGN6DA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=MxaNawM0VjX2DHEGigYueT+87jM1Vf65gV6P8dUqmKs=; b=gtqPzKeY/HpbsVh15mFAU5biB9Yf9XChGBsW2htOzwdsV7waYYNqkmyj7xCNzrode+ HYuYQ9ggJGwlRgLchPeVr3NlwdtoOTq6l9y+LIwcMeNG11dbVp/KLNmCbiaAomcgQBht nkPz84hqt5HxnV8ECuWxUTmCsbe0n1hqYdCTKtLZbXJZGo7DJ/PV5ADr1l8aYZLI9ylR rKg5/PucJ8+oMfkp3H0zhSR3slq6PujM1depG7Bcx79KIv3EF+E7B+orQ6mlCz9r5urA bjyBu4h+t56dS/vUDwwD+mpZsAfOuAFucHKYZ4RKH+LDUJPHdrIQAtshaX8l7FcrglRZ gsSQ== X-Gm-Message-State: AOPr4FVhwugVdJuKLDIhcCRpXdFVs4mKIdb9L4YD4XCRPqs+x2kGzwVQe6KmIl2eC71Ukg== X-Received: by 10.13.204.69 with SMTP id o66mr8261534ywd.168.1462456480135; Thu, 05 May 2016 06:54:40 -0700 (PDT) Received: from [192.168.1.2] ([67.58.115.15]) by smtp.gmail.com with ESMTPSA id l186sm5527945ywe.29.2016.05.05.06.54.39 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 May 2016 06:54:39 -0700 (PDT) From: Tim Draegen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Thu, 5 May 2016 09:54:39 -0400 To: dmarc Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [dmarc-ietf] phase 1 is done X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 05 May 2016 13:57:31 -0000 This working group's "phase 1" is now done. The Chairs will be shepherding the phase 1 interoperability draft: https://trac.tools.ietf.org/html/draft-ietf-dmarc-interoperability The WG will now move ahead to phase 2: https://trac.tools.ietf.org/wg/dmarc/trac/wiki/MilestoneTwoWiki When discussing methods and techniques that address an interoperability = issue, please explicitly reference the issue from the = draft-ietf-dmarc-interoperability draft. This will allow for easier = tracking of issues & proposed fixes by volunteers a lot easier. =3D- Tim From nobody Tue May 10 10:21:59 2016 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 C039212D77A for ; Tue, 10 May 2016 10:21:57 -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 voZljjL2Z-zg for ; Tue, 10 May 2016 10:21:55 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::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 483BE12D13E for ; Tue, 10 May 2016 10:21:52 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id 190so24386620iow.1 for ; Tue, 10 May 2016 10:21:52 -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:date:message-id:subject :from:to; bh=3jkk+gsNrjtxvCPNlhF0tuZF//uooJa5QacvC7sjZrE=; b=K1QuKuxQvsB4fLczfOUMlHWxBlyURRSwFRlP3a88jQyBRvwunKtdglMNapJh7S1mln 2OSbsAphIXIxGdbcdQMwR+yEE/oDFPKAJ52nBVGwztyaxSuYfgtIy1GCx3MbT5YUp4xL izPwSULgvhIzyUHVOVASocqARtoqlXvv2WAG4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to; bh=3jkk+gsNrjtxvCPNlhF0tuZF//uooJa5QacvC7sjZrE=; b=HF9r9dQTJeqmG0irBwyQWBs/1Jma4JFKZB/ec4kmB+mBYbNMmEhb5v3bLleAboc2X/ igWsPopz7EnG4g5dnBwCv870CFWEamaPg0/l/Sy6SBKQ4LENUvGZvIWzxIbG008+T+tD Ix5gKR1PxEwf42MuzbF2T5X4YwvT94f3kaxvqkuVAQEH5KVq2dzUGk/y5gKRpGy0mKgL aVWs9EyUbGh4kE7jJ9UV6F29POqADEij+CtdOAOBWJUDlEj5tjCSULEWWsPz/zX6OHaJ db5rSANVCosjRQrRQ3nSHvx+MXwC/i9QgWm/xYnO19D8Hquw09Htvo44OXffgkHUH9or zX4A== X-Gm-Message-State: AOPr4FWNKJ/2pLEUfcXqxmzO2Jm9KeE6CP8YFmVN0hxe/EWEKV/74Za9WmR2CCgr/lFWzReEjn1wTKUPil0ReA== MIME-Version: 1.0 X-Received: by 10.36.26.134 with SMTP id 128mr2035308iti.28.1462900911495; Tue, 10 May 2016 10:21:51 -0700 (PDT) Sender: kurta@drkurt.com Received: by 10.107.20.202 with HTTP; Tue, 10 May 2016 10:21:51 -0700 (PDT) In-Reply-To: References: Date: Tue, 10 May 2016 10:21:51 -0700 X-Google-Sender-Auth: sfl8B4R0x-V8tL24I7hWkUxlSYM Message-ID: From: "Kurt Andersen (b)" To: dmarc Content-Type: multipart/alternative; boundary=001a1143c50e2bfb3505328029c8 Archived-At: Subject: Re: [dmarc-ietf] phase 1 is done X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 10 May 2016 17:21:58 -0000 --001a1143c50e2bfb3505328029c8 Content-Type: text/plain; charset=UTF-8 On Thu, May 5, 2016 at 6:54 AM, Tim Draegen wrote: > The WG will now move ahead to phase 2: > > https://trac.tools.ietf.org/wg/dmarc/trac/wiki/MilestoneTwoWiki > > When discussing methods and techniques that address an interoperability > issue, please explicitly reference the issue from the > draft-ietf-dmarc-interoperability draft. This will allow for easier > tracking of issues & proposed fixes by volunteers a lot easier. > I would like to officially propose, and ask for the WG's support of adopting https://datatracker.ietf.org/doc/draft-andersen-arc/ and the corresponding, but separate usage recommendations https://datatracker.ietf.org/doc/draft-jones-arc-usage/ as standards-track documents within the WG to help mitigate the interoperability problems that were cataloged. Specifically, in draft -09 of the interop document, I had cited ARC in section 4.2 as an instance of a "[m]echanism[s] to extend Authentication-Results [RFC7601] to multiple hops. . ." ( https://trac.tools.ietf.org/html/draft-ietf-dmarc-interoperability-09#section-4.2) but subsequently abstracted that "work in progress" out of the document to honor our milestone framework. --Kurt Andersen --001a1143c50e2bfb3505328029c8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, May 5, 2016 at 6:54 AM, Tim Draegen <tim@eudaemon.net> wr= ote:
The WG will now move ahead to phase 2:

=C2=A0 https://trac.tools.ietf.org/wg= /dmarc/trac/wiki/MilestoneTwoWiki

When discussing methods and techniques that address an interoperability iss= ue, please explicitly reference the issue from the draft-ietf-dmarc-interop= erability draft.=C2=A0 This will allow for easier tracking of issues & = proposed fixes by volunteers a lot easier.

<= div>I would like to officially propose, and ask for the WG's support of= adopting = https://datatracker.ietf.org/doc/draft-andersen-arc/ and the correspond= ing, but separate usage recommendations https://datatracker.ietf.org/doc/draft-jon= es-arc-usage/ as standards-track documents within the WG to help mitiga= te the interoperability problems that were cataloged.

<= div>Specifically, in draft -09 of the interop document, I had cited ARC in = section 4.2 as an instance of a "[m]echanism[s] to extend Authenticati= on-Results [RFC7601] to multiple hops. . ." (https:= //trac.tools.ietf.org/html/draft-ietf-dmarc-interoperability-09#section-4.2= ) but subsequently abstracted that "work in progress" out of = the document to honor our milestone framework.

--K= urt Andersen
--001a1143c50e2bfb3505328029c8-- From nobody Tue May 10 10:23:26 2016 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 6757A12D786 for ; Tue, 10 May 2016 10:23:19 -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 tQp1-tBO3Y7X for ; Tue, 10 May 2016 10:23:17 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001: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 36CFA12D533 for ; Tue, 10 May 2016 10:23:17 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id i75so19052003ioa.3 for ; Tue, 10 May 2016 10:23:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:date:message-id:subject:from:to; bh=UypNsYTM8VuwaBeeLVv7lRqmm/smtLN+kEUPXAuM12Y=; b=NgO80uELkLe8URbcKc7BiQSG31r3AoihS41pSkdIoHL+fx69kanfvj5RQkCvloMSbs h06i31Zb6XWD64mOSD7CGv+ixZL2eVCcNfv97vOxlDpDwSRD51N05kcRHKb7JavL/q31 Xg1lf+rt8bFJU2npMUR1bd9OVjLRf1QCkWHBc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to; bh=UypNsYTM8VuwaBeeLVv7lRqmm/smtLN+kEUPXAuM12Y=; b=UxVrBcS/xsL89QRCwEoht5YI9JCZIK4WJ/6q+WBusuI6LfsD7V7c1hxB5HoFvQ29W8 11KgIp7+h3N4SWHNb7mfmaj200mplOJ9RIbVoczAkFcH5nH1G3c8Ylox+O52nDBFwU4H c2QGEzX1btMQF4UmDEBF6MNCaIjFSLXRLn2WJWLTr4haKTTdVwLQgWKnp6oM4YCYOZ4C gQjRxpRCc7Y5xSgk7ssDoNDQvvLrbZEVD7HeW7wpHeHKQOL0mossLbuZeNCra0stusmC X2UpDuF4akU/1JlAZcdbHizHMSGpahNzN/ozUJQwlWenvBBvSPr+Wl0Doz2U1PEqvzLe cb/Q== X-Gm-Message-State: AOPr4FVocj7SpBdFwDmsWsZ9abzp288GS/19g+Ll9C4b/5mI6IH6aIkcmEC5D5PmUdELDBXTWw4G5LywJXKA4g== MIME-Version: 1.0 X-Received: by 10.36.79.150 with SMTP id c144mr2038925itb.28.1462900996576; Tue, 10 May 2016 10:23:16 -0700 (PDT) Sender: kurta@drkurt.com Received: by 10.107.20.202 with HTTP; Tue, 10 May 2016 10:23:16 -0700 (PDT) Date: Tue, 10 May 2016 10:23:16 -0700 X-Google-Sender-Auth: FmVWAWBKfVCas2aBZEZWxrm5KyM Message-ID: From: "Kurt Andersen (b)" To: dmarc Content-Type: multipart/alternative; boundary=001a11447e523e34230532802e8b Archived-At: Subject: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 10 May 2016 17:23:19 -0000 --001a11447e523e34230532802e8b Content-Type: text/plain; charset=UTF-8 Updated the subject line to start a new thread. . .sorry for the confusion. On Tue, May 10, 2016 at 10:21 AM, Kurt Andersen (b) wrote: > On Thu, May 5, 2016 at 6:54 AM, Tim Draegen wrote: > >> The WG will now move ahead to phase 2: >> >> https://trac.tools.ietf.org/wg/dmarc/trac/wiki/MilestoneTwoWiki >> >> When discussing methods and techniques that address an interoperability >> issue, please explicitly reference the issue from the >> draft-ietf-dmarc-interoperability draft. This will allow for easier >> tracking of issues & proposed fixes by volunteers a lot easier. >> > > I would like to officially propose, and ask for the WG's support of > adopting https://datatracker.ietf.org/doc/draft-andersen-arc/ and the > corresponding, but separate usage recommendations > https://datatracker.ietf.org/doc/draft-jones-arc-usage/ as > standards-track documents within the WG to help mitigate the > interoperability problems that were cataloged. > > Specifically, in draft -09 of the interop document, I had cited ARC in > section 4.2 as an instance of a "[m]echanism[s] to extend > Authentication-Results [RFC7601] to multiple hops. . ." ( > https://trac.tools.ietf.org/html/draft-ietf-dmarc-interoperability-09#section-4.2) > but subsequently abstracted that "work in progress" out of the document to > honor our milestone framework. > > --Kurt Andersen > --001a11447e523e34230532802e8b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Updated the subject line to sta= rt a new thread. . .sorry for the confusion.

On Tue, May 10, 2016 at 10:21 AM, Kurt Andersen (b) &= lt;kboth@drkurt.com> wrote:
On Thu,= May 5, 2016 at 6:54 AM, Tim Draegen <tim@eudaemon.net> wrote= :
The WG will now move ahead to phase 2:

=C2=A0 https://trac.tools.ietf.org/wg= /dmarc/trac/wiki/MilestoneTwoWiki

When discussing methods and techniques that address an interoperability iss= ue, please explicitly reference the issue from the draft-ietf-dmarc-interop= erability draft.=C2=A0 This will allow for easier tracking of issues & = proposed fixes by volunteers a lot easier.

<= /span>
I would like to officially propose, and ask for the WG's sup= port of adopting https://datatracker.ietf.org/doc/draft-andersen-ar= c/ and the corresponding, but separate usage recommendations https://datatracker.ietf.org/doc/draft-jones-arc-usage/ as standards-t= rack documents within the WG to help mitigate the interoperability problems= that were cataloged.

Specifically, in draft -09 o= f the interop document, I had cited ARC in section 4.2 as an instance of a = "[m]echanism[s] to extend Authentication-Results [RFC7601] to multiple= hops. . ." (https://trac.tools.i= etf.org/html/draft-ietf-dmarc-interoperability-09#section-4.2) but subs= equently abstracted that "work in progress" out of the document t= o honor our milestone framework.

--Kurt Andersen

--001a11447e523e34230532802e8b-- From nobody Tue May 10 11:09:05 2016 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 7A7A112D5A0 for ; Tue, 10 May 2016 11:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.997 X-Spam-Level: X-Spam-Status: No, score=-2.997 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, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=crash.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 ZHQzOG90j8vV for ; Tue, 10 May 2016 11:09:00 -0700 (PDT) Received: from segv.crash.com (segv.crash.com [IPv6:2001:470:1:1e9::4415]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8272912D567 for ; Tue, 10 May 2016 11:08:57 -0700 (PDT) Received: from abort.crash.com (70-36-157-26.dsl.static.fusionbroadband.com [70.36.157.26]) (authenticated bits=0) by segv.crash.com (8.14.5/8.14.5/cci-colo-1.6) with ESMTP id u4AI8ix3041109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 10 May 2016 11:08:50 -0700 (PDT) (envelope-from smj@crash.com) X-DKIM: OpenDKIM Filter v2.4.3 segv.crash.com u4AI8ix3041109 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=201506-2k; t=1462903730; bh=M9fi6EpwgySasf0TrslvR0mlp97tiMVbztbgGH+HHH4=; h=Subject:To:References:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type; b=rufhlQg97nJ7M9jKpplRzkIWfvH6JkZ+XGRO2XfrYxv6I9ZKl9qSQiiPsgbBQ24JJ nboo5n40J8ps/DX1ZoDc3rgqVSaOo92jSRQF3TzFGD56W6ykjeV9yLGKc5ysD3yr3S WSmNN7sc7bBj6ZY+86FTazQGsEpvaei8o3SjEQZvJOimNGd1l/nK2qgHYWWDKzZvsU SQDR8p/PRUHbJIEfKrgrleJ3OAUhaVwxj68Hu04mgNZ7G1BnaOjk1y5O/FW0At3ITW eqsOQqLm61+M3wIqv1y3RkuU1ZYwYRqoO6l0EX1dM9tO2rJHGoEITzV9/jIzH+VCMj wOpq1xlqzHJ4g== X-Authentication-Warning: segv.crash.com: Host 70-36-157-26.dsl.static.fusionbroadband.com [70.36.157.26] claimed to be abort.crash.com To: dmarc@ietf.org References: From: Steven M Jones X-Enigmail-Draft-Status: N1110 Organization: Crash Computing Message-ID: <573223B0.3010709@crash.com> Date: Tue, 10 May 2016 11:08:48 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------030709060403000603010103" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (segv.crash.com [72.52.75.15]); Tue, 10 May 2016 11:08:50 -0700 (PDT) Archived-At: Subject: Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 10 May 2016 18:09:04 -0000 This is a multi-part message in MIME format. --------------030709060403000603010103 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 05/10/2016 10:23, Kurt Andersen (b) wrote: > Updated the subject line to start a new thread. . .sorry for the > confusion. > > On Tue, May 10, 2016 at 10:21 AM, Kurt Andersen (b) > wrote: > > On Thu, May 5, 2016 at 6:54 AM, Tim Draegen > wrote: > > The WG will now move ahead to phase 2: > > https://trac.tools.ietf.org/wg/dmarc/trac/wiki/MilestoneTwoWiki > > When discussing methods and techniques that address an > interoperability issue, please explicitly reference the issue > from the draft-ietf-dmarc-interoperability draft. This will > allow for easier tracking of issues & proposed fixes by > volunteers a lot easier. > > > I would like to officially propose, and ask for the WG's support > of adopting https://datatracker.ietf.org/doc/draft-andersen-arc/ > and the corresponding, but separate usage recommendations > https://datatracker.ietf.org/doc/draft-jones-arc-usage/ as > standards-track documents within the WG to help mitigate the > interoperability problems that were cataloged. > > Specifically, in draft -09 of the interop document, I had cited > ARC in section 4.2 as an instance of a "[m]echanism[s] to extend > Authentication-Results [RFC7601] to multiple hops. . ." > (https://trac.tools.ietf.org/html/draft-ietf-dmarc-interoperability-09#section-4.2) > but subsequently abstracted that "work in progress" out of the > document to honor our milestone framework. > +1 I'd like to reinforce this call. ARC has great promise, but we're just completing and testing initial implementations. There are frequent discussions of specification changes (on arc-discuss and elsewhere), which shows that there's substantive work to be done - and that work can only benefit from the broader community that an IETF WG represents. --Steve. Steven M Jones DMARC.org e: smj@dmarc.org, smj@crash.com --------------030709060403000603010103 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 05/10/2016 10:23, Kurt Andersen (b) wrote:
Updated the subject line to start a new thread. . .sorry for the confusion.

On Tue, May 10, 2016 at 10:21 AM, Kurt Andersen (b) <kboth@drkurt.com> wrote:
On Thu, May 5, 2016 at 6:54 AM, Tim Draegen <tim@eudaemon.net> wrote:
The WG will now move ahead to phase 2:

  https://trac.tools.ietf.org/wg/dmarc/trac/wiki/MilestoneTwoWiki

When discussing methods and techniques that address an interoperability issue, please explicitly reference the issue from the draft-ietf-dmarc-interoperability draft.  This will allow for easier tracking of issues & proposed fixes by volunteers a lot easier.
I would like to officially propose, and ask for the WG's support of adopting https://datatracker.ietf.org/doc/draft-andersen-arc/ and the corresponding, but separate usage recommendations https://datatracker.ietf.org/doc/draft-jones-arc-usage/ as standards-track documents within the WG to help mitigate the interoperability problems that were cataloged.

Specifically, in draft -09 of the interop document, I had cited ARC in section 4.2 as an instance of a "[m]echanism[s] to extend Authentication-Results [RFC7601] to multiple hops. . ." (https://trac.tools.ietf.org/html/draft-ietf-dmarc-interoperability-09#section-4.2) but subsequently abstracted that "work in progress" out of the document to honor our milestone framework.

+1

I'd like to reinforce this call. ARC has great promise, but we're just completing and testing initial implementations. There are frequent discussions of specification changes (on arc-discuss and elsewhere), which shows that there's substantive work to be done - and that work can only benefit from the broader community that an IETF WG represents.

--Steve.

Steven M Jones
DMARC.org
e: smj@dmarc.org, smj@crash.com



--------------030709060403000603010103-- From nobody Tue May 10 11:48:53 2016 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 EED4812D831 for ; Tue, 10 May 2016 11:48:51 -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, FREEMAIL_FROM=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 GYbxie9S3ke1 for ; Tue, 10 May 2016 11:48:50 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC0F512D82E for ; Tue, 10 May 2016 11:48:49 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id c189so9075781pfb.3 for ; Tue, 10 May 2016 11:48:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=yinBSl+Ch8Y6WH8sw3f/GsEAbZ4jcHvCrhx6bgo+ZCY=; b=UhHijSH64Ltv5yMEuLjNoGSFEzEL/+wXTiYnH0R9S3IniJSkNfL4yChmqONT5C1jIW FIJZLWGcrQkTyPomVks93DqdnFcbAR3kgdJnASChrX5WLWEExkmNF/Zc47WNw+pKmnyp 0mID3HVsxyjPe6mNsRnPwDPavOSuCKRBLOytRpD3/RxuGfB7T/KKuQPdsmCz1qydtHcW PCbtAV+6KOiQdbt0qhrQg6RSa2lfo7lYiQI3SzUU5xMm8EGML6kuLENzaWclt8+ycxSW xLOWky8yV/ZhTE0wJ9BLkpYK0tVHAKdFdSsWq3wuJrSbCYFw+xDVxbqWF4UmdUrd9mTV ggHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=yinBSl+Ch8Y6WH8sw3f/GsEAbZ4jcHvCrhx6bgo+ZCY=; b=jomNp7+zZpFBEvpclhPqYC55eeipDhdYSv6swLDDZE4MebRhjPP9jk2W/VZXIN6yle IMr/FEywJEmgSFKq/DukFfRORJIK8kkwtCYaGmZBa0d1m++fjtnpEHkTcBkuhnLQRWR+ bs81A+0wXVkNres4WpAidIwT0qK59Y52zXE3xnrgUzhvFzIqJJ0TXtA+jN0O6lrCcSMv 5cS2urpcXM1xU1tzWtEBVCLhSYJhZGbiYQx7yq/pqeMVfiVPP0kgTPDHsbC/7i5kXCJW CA0k89h9JTM69sLArtAYrhh1eFN8kzw9QVob0CIu0mDbnEf89MZ2jaupsNzi/2ZE4kBU rfag== X-Gm-Message-State: AOPr4FV5MTYPp3R9b6NL6nnUu3wPrDhDWV39cRclgUQfkTDZmPkohuV7JIqpxaIhLLSXPA== X-Received: by 10.98.23.211 with SMTP id 202mr60773482pfx.122.1462906129550; Tue, 10 May 2016 11:48:49 -0700 (PDT) Received: from [192.168.194.60] ([156.39.191.12]) by smtp.gmail.com with ESMTPSA id g70sm6270879pfb.7.2016.05.10.11.48.48 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 May 2016 11:48:48 -0700 (PDT) To: Steven M Jones , dmarc@ietf.org References: <573223B0.3010709@crash.com> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <57322CFF.50208@gmail.com> Date: Tue, 10 May 2016 11:48:31 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <573223B0.3010709@crash.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 10 May 2016 18:48:52 -0000 On 5/10/2016 11:08 AM, Steven M Jones wrote: > which shows that there's substantive work to be done - and that work can > only benefit from the broader community that an IETF WG represents. Perhaps it will aid consideration if a candidate list of such work is offered? A summary of issues raised in those discussions, so far. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue May 10 14:03:43 2016 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 27F4612D154 for ; Tue, 10 May 2016 14:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.696 X-Spam-Level: X-Spam-Status: No, score=-3.696 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, RP_MATCHES_RCVD=-0.996, SPF_PASS=-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 ree0GI3h6bTG for ; Tue, 10 May 2016 14:03: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 4BDD812D0B4 for ; Tue, 10 May 2016 14:03:36 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id f66so32838713vkh.2 for ; Tue, 10 May 2016 14:03:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=AZwL6UCQyhMBAVZkKUGqDglNG1UphLoZjZrNRXvEjFI=; b=P8J9Vir+bhOD9Ukk2MshFaW3MnH4F1a22mhYlt8xKElS+cGx7glK83xXryNJ16ZEWK UkQo2JQTWDjDx4Qwla+3wuuRrxn7g7xdG2SEb7QCcg5Ye4s+tB0AgKYyH3SRnzT8TKkx 0KgDTB0MnXgQT9kejw4oln+plorIFIL7tIUPgCsKuuDnw3ZWHoG3YuqNPX77gOh998Jf 6OccN5ug7Pq+yUpb924LGUZ32YlhbJNkJJwl+0erwunaI4vhb6GFLX+qe17ATwHIIi/u y06haEtwI7J4M+T0XjxHlBZBnBsnF4/9+p1YHfWXfhxgzLg4EHSvELPt9r9hj1DUlA/I hPVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=AZwL6UCQyhMBAVZkKUGqDglNG1UphLoZjZrNRXvEjFI=; b=cC2iLWJtVTFdXQJG3ZZwnh1E3n81mQEWtVYz5eB7gcLJpmRg2rkjp5ri4AhTqGEVpb 7GWprLIqY7o8Y53eIsjDvzB9SF24BXCrkM8VQs0MAJwcSZ+H6+dT0RnB0s82RF7Nbedj Lo3R6smff2db7E3r26ILqtOB+OLQSYG3Hr+Hhlx3hlnPEz+/KPcdjq74Vu2Xq2Jze2nE nH2BJb1EqKEnBiT7VkcumW9C6WPeZaBokX7BcpnTQhFhuKYGlJKIQPQNAoL1jIVVnDor IVSqubH1pBjXYFLT/kjG6/MCTGVYwpYSwU80dii9u58ee55wsSHItm+TRtT6GemlwxlT 6hHg== X-Gm-Message-State: AOPr4FXG6shU1724byadi2gxBrQYwSNk8cWTowV3Yoy2aXm9lXMRf+vZ6KnY9Fbt4u7oEQo5mQyjYZo+41kzmmGN MIME-Version: 1.0 X-Received: by 10.176.64.231 with SMTP id i94mr25296760uad.66.1462914215216; Tue, 10 May 2016 14:03:35 -0700 (PDT) Received: by 10.31.65.138 with HTTP; Tue, 10 May 2016 14:03:34 -0700 (PDT) In-Reply-To: <57322CFF.50208@gmail.com> References: <573223B0.3010709@crash.com> <57322CFF.50208@gmail.com> Date: Tue, 10 May 2016 14:03:34 -0700 Message-ID: From: Brandon Long To: Dave Crocker Content-Type: multipart/alternative; boundary=94eb2c1237dc23145105328342c1 Archived-At: Cc: "dmarc@ietf.org" , Steven M Jones Subject: Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 10 May 2016 21:03:42 -0000 --94eb2c1237dc23145105328342c1 Content-Type: text/plain; charset=UTF-8 On Tue, May 10, 2016 at 11:48 AM, Dave Crocker wrote: > On 5/10/2016 11:08 AM, Steven M Jones wrote: > >> which shows that there's substantive work to be done - and that work can >> only benefit from the broader community that an IETF WG represents. >> > > > Perhaps it will aid consideration if a candidate list of such work is > offered? A summary of issues raised in those discussions, so far. One thing we still need to determine is how to make arc forward compatible with changes, the most obvious of which is that it currently relies on rsa-sha256 for its signatures, we need to determine how to make it possible to transition to a new signature algorithm. I also brought up to a smaller group as we were discussing what is the payload for arc, whether we are content with the payload being just the ARC-Authentication-Results header. ARC provides a mechanism for passing forward verifiable information, and the content is the AAR. I worry that folks may try to extend the AAR to other things in order to take advantage of that. I'm not sure if that means we should consider changes to that or not. Brandon --94eb2c1237dc23145105328342c1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, May 10, 2016 at 11:48 AM, Dave Crocker <dcrocker@gmail.com> wrote:
On 5= /10/2016 11:08 AM, Steven M Jones wrote:
which shows that there's substantive work to be done - and that work ca= n
only benefit from the broader community that an IETF WG represents.


 Perhaps it will aid consideration if a candidate list of such work is offer= ed?=C2=A0 A summary of issues raised in those discussions, so far.

One thing we still need to determine is how to make= arc forward compatible with changes, the most obvious of which is that it = currently relies on rsa-sha256 for its signatures, we need to determine how= to make it possible to transition to a new signature algorithm.
=
I also brought up to a smaller group as we were discussing w= hat is the payload for arc, whether we are content with the payload being j= ust the ARC-Authentication-Results header.=C2=A0 ARC provides a mechanism f= or passing forward verifiable information, and the content is the AAR.=C2= =A0 I worry that folks may try to extend the AAR to other things in order t= o take advantage of that.=C2=A0 I'm not sure if that means we should co= nsider changes to that or not.

Brandon
=
--94eb2c1237dc23145105328342c1-- From nobody Tue May 10 16:14:02 2016 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 7520512D116 for ; Tue, 10 May 2016 16:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.696 X-Spam-Level: X-Spam-Status: No, score=-3.696 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, RP_MATCHES_RCVD=-0.996, SPF_PASS=-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 JcDbnWgqXOdd for ; Tue, 10 May 2016 16:13:58 -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 474C012B056 for ; Tue, 10 May 2016 16:13:58 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id m188so36188307vka.1 for ; Tue, 10 May 2016 16:13:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=gLQL0m01MYv3MmBZGrFQ6BDabewZDN5bk21/ZeSU2d4=; b=KNsjsVMJOx6uFA5cG4ZzmgfdgwOTaubKJ8egm2vjitfCRVvralJzdBJ9jmc+Mv6jtG qgoKEpdsv7Z6qKQQxgkZ/QBtYLEmW2qnF6oK779Ix+cxCdjmm1JmxAAFKL+P4FwGvsrC sEqAjdyFyIcd+Mz58x/P+ELcb2j9nW40iVpBPac9yubfCN1vUvTIgpDCwmiu4UEb7vvD FXFu+VGZkaG9kIq2FbxGtqkTUnrHCozKPR+QYaHDF2nBj7g3jWSIwNkNj2JMnJ+RMtNY 44VfyhgtMqUkLZquvTj1kAJyXR5G2Ggg5rlIoMpcftSJHPQcVA20hwFW9z3DM6v0eqq3 AJGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=gLQL0m01MYv3MmBZGrFQ6BDabewZDN5bk21/ZeSU2d4=; b=D/MSZlrdlOXvFWPYG94roBOL2wVlqEdsUxeHsZsuu+da+lHNaCbP2oeWbgpsBIrRVv rWhSf2m5xUu9A7o7fKwz7xgGBn2dZ8j5UahU1T57FSFly8hqtgm+Cam5fsg+sFNnYcpj FPPehYFV9y1YqGNQWDKtxFgtfVdDVYQsuNvspZRZcSNmZcmyEbrNbZc40HV56zt9TDAN Wy6rVTCx4jZUL0vx5bBy2xitWU8s/hydXOg0v+Fc8tT2RK9lakFOp0f0m8UUrJyp/Rol c0vvkmowMigkIrIOimRReGKhUwSe5WDnLomv5nir3TDoI9r/Pywi1D7ksKxCx1QCITec T0hw== X-Gm-Message-State: AOPr4FUpQeryIaONtTr0fPtIDC5VQ/Y1fHjKWUgvbJrTassgZCHJnUEAC3oUYx9t5VdxYiHplhuiWuVCsZ34d9v0 MIME-Version: 1.0 X-Received: by 10.159.38.75 with SMTP id 69mr53344uag.139.1462922037081; Tue, 10 May 2016 16:13:57 -0700 (PDT) Received: by 10.31.65.138 with HTTP; Tue, 10 May 2016 16:13:56 -0700 (PDT) In-Reply-To: References: <573223B0.3010709@crash.com> <57322CFF.50208@gmail.com> Date: Tue, 10 May 2016 16:13:56 -0700 Message-ID: From: Brandon Long To: Dave Crocker Content-Type: multipart/alternative; boundary=001a113e4aa85bc6d505328514c9 Archived-At: Cc: "dmarc@ietf.org" , Steven M Jones Subject: Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 10 May 2016 23:14:00 -0000 --001a113e4aa85bc6d505328514c9 Content-Type: text/plain; charset=UTF-8 Another question to consider that relates to DMARC directly (and I admit to being rather off the cuff at this point): Some folks say that DMARC works well for transactional domains, and not so well when applied to end user / general purpose domains. Should DMARC add a policy setting for whether the domain owner feels that ARC should be used to bypass regular DMARC evaluation? Almost like a "strict" vs "not strict". High enough value targets may not want to allow any message modification. Of course, most high value targets still use their domains for multiple purposes (ie, corporate mail on transactional domains), so maybe this is a bad idea. Brandon On Tue, May 10, 2016 at 2:03 PM, Brandon Long wrote: > > > On Tue, May 10, 2016 at 11:48 AM, Dave Crocker wrote: > >> On 5/10/2016 11:08 AM, Steven M Jones wrote: >> >>> which shows that there's substantive work to be done - and that work can >>> only benefit from the broader community that an IETF WG represents. >>> >> >> >> Perhaps it will aid consideration if a candidate list of such work is >> offered? A summary of issues raised in those discussions, so far. > > > One thing we still need to determine is how to make arc forward compatible > with changes, the most obvious of which is that it currently relies on > rsa-sha256 for its signatures, we need to determine how to make it possible > to transition to a new signature algorithm. > > I also brought up to a smaller group as we were discussing what is the > payload for arc, whether we are content with the payload being just the > ARC-Authentication-Results header. ARC provides a mechanism for passing > forward verifiable information, and the content is the AAR. I worry that > folks may try to extend the AAR to other things in order to take advantage > of that. I'm not sure if that means we should consider changes to that or > not. > > Brandon > > --001a113e4aa85bc6d505328514c9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Another question to consider that relates to DMARC directl= y (and I admit to being rather off the cuff at this point):

<= div>Some folks say that DMARC works well for transactional domains, and not= so well when applied to end user / general purpose domains.

=
Should DMARC add a policy setting for whether the domain owner f= eels that ARC should be used to bypass regular DMARC evaluation?
=
Almost like a "strict" vs "not strict".= =C2=A0 High enough value targets may not want to allow any message modifica= tion.

Of course, most high value targets still use= their domains for multiple purposes (ie, corporate mail on transactional d= omains), so maybe this is a bad idea.

Brandon

On Tue, Ma= y 10, 2016 at 2:03 PM, Brandon Long <blong@google.com> wrote:=


On Tue, May 10, 201= 6 at 11:48 AM, Dave Crocker <dcrocker@gmail.com> wrote:
=
On 5/10/2016 11:08 AM, Steven M Jones = wrote:
which shows that there's substantive work to be done - and that work ca= n
only benefit from the broader community that an IETF WG represents.


 Perhaps it will aid consideration if a candidate list of such work is offer= ed?=C2=A0 A summary of issues raised in those discussions, so far.

One thing we still need to determine is how = to make arc forward compatible with changes, the most obvious of which is t= hat it currently relies on rsa-sha256 for its signatures, we need to determ= ine how to make it possible to transition to a new signature algorithm.

I also brought up to a smaller group as we were discu= ssing what is the payload for arc, whether we are content with the payload = being just the ARC-Authentication-Results header.=C2=A0 ARC provides a mech= anism for passing forward verifiable information, and the content is the AA= R.=C2=A0 I worry that folks may try to extend the AAR to other things in or= der to take advantage of that.=C2=A0 I'm not sure if that means we shou= ld consider changes to that or not.

Brandon


--001a113e4aa85bc6d505328514c9-- From nobody Tue May 10 17:23:32 2016 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 8D18712D50C for ; Tue, 10 May 2016 17:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 LArDO1ULCmOp for ; Tue, 10 May 2016 17:23:29 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06B9E12D5DA for ; Tue, 10 May 2016 17:23:26 -0700 (PDT) Received: (qmail 42497 invoked from network); 11 May 2016 00:23:27 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 11 May 2016 00:23:27 -0000 Date: 11 May 2016 00:23:03 -0000 Message-ID: <20160511002303.14397.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: blong@google.com Subject: Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 11 May 2016 00:23:31 -0000 >Should DMARC add a policy setting for whether the domain owner feels that >ARC should be used to bypass regular DMARC evaluation? Please, no. One approach to what we can oversimplify as the mailing list problem is to do it from the sending end, with the sender using something like conditional double signatures to say mutated messages are OK. The other is to provide data that the recipient can use to decide these mutations are OK. ARC is definitely in the latter camp, and it would be painful to have both ends arguing about how OK stuff is. R's, John From nobody Tue May 10 17:32:22 2016 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 0CE3112B033 for ; Tue, 10 May 2016 17:32:21 -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, FREEMAIL_FROM=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 qSnL0SiFv1aF for ; Tue, 10 May 2016 17:32:19 -0700 (PDT) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A4DE12B02B for ; Tue, 10 May 2016 17:32:19 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id 77so11403655pfv.2 for ; Tue, 10 May 2016 17:32:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=IxNJiUDlyzUMkFYOTNqipD9xmjS7NAxgvk/EZL4h1K4=; b=kTOX86241X1oBwWeqR+NuMscxSJDCyfCPdn4C9SMgSpW0GloSJHdB443v2zEAbWgox nuPiu58Eh0LxAMfZbUbuxc7TtFQB1tNbp/QBgK7GJ/p8DBTa9loz84QKcXaFbXBpIBRW ivW3M++EghWgKrLvtLUu855SOtOS/gEPaS0W2MKQFFH4C+6bNmkQe0q8LpPKSKxqIxD7 dhsoweko2kORxBgTfG35AtoBuDpyUX3L5BSQBuRl5p94d36whoqPtBEFEOum0fPPU57v 9HcX+h4b3IYmNSN3QAWs5cC3lehi5BkmxB1ScDrtiNugKw+f8lAifDKCF9Jw1NPpiaff ltDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=IxNJiUDlyzUMkFYOTNqipD9xmjS7NAxgvk/EZL4h1K4=; b=hRiXFvOyJjzn+/p5FLnetCOTT5DdhtP3dPrV89DRf++1iFtNsx6ccnsHtrKGTsuwJr Fd58g22QhaPs39wSYCTjVz2zfwOBnl7Y3mImPb7tgMkhirIIPp30gnD3SQ2WE6F8O+RC lIwiVLX8kKJS0BSuJRpXeY/M4x7pdCf7H54UoDsXATwhOys9eupvh+1GN8Zdwc9g+sLM wowc7lDxSqdRI+TKa9eNpE10FUD/EFbSzRRpKmZvZBAIHqpzTiNMWeSApmqxtAXK6vZK v+y25ogdKcPrgyuI8JnnwJKgZ5pBD/bNMGwTpqzo2+1c7Tx1+sgY1l42CEvJjNYZZWYf pFqQ== X-Gm-Message-State: AOPr4FWT5DXK1lGfPNOXHevhrgMbiVQzdMp2EKoGlBbb2hW909sGK7GIv7UBWkr8y/F1Xw== X-Received: by 10.98.20.197 with SMTP id 188mr624407pfu.144.1462926739124; Tue, 10 May 2016 17:32:19 -0700 (PDT) Received: from [192.168.194.60] ([156.39.191.12]) by smtp.gmail.com with ESMTPSA id g27sm7180133pfd.25.2016.05.10.17.32.17 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 May 2016 17:32:17 -0700 (PDT) To: John Levine , dmarc@ietf.org References: <20160511002303.14397.qmail@ary.lan> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <57327D81.6050306@gmail.com> Date: Tue, 10 May 2016 17:32:01 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20160511002303.14397.qmail@ary.lan> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: blong@google.com Subject: Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 11 May 2016 00:32:21 -0000 On 5/10/2016 5:23 PM, John Levine wrote: >> Should DMARC add a policy setting for whether the domain owner feels that >> ARC should be used to bypass regular DMARC evaluation? > > Please, no. One approach to what we can oversimplify as the mailing > list problem is to do it from the sending end, with the sender using > something like conditional double signatures to say mutated messages > are OK. The other is to provide data that the recipient can use > to decide these mutations are OK. > > ARC is definitely in the latter camp, and it would be painful to > have both ends arguing about how OK stuff is. I have a mixed reaction. Simplicity is a strong draw, putting me in John's camp. On the other hand, for purely transactional domains, it could be simpler for the recipient to be able to easily find that ARC-ish mechanisms are not authorized. ARC, ultimately, relies on having the receiver trust assertions made by the first ARC signer. Things get easier for the receiver if they see a statement by the domain owner saying "don't bother with ARC". But yeah, it's another bit of mechanism. So the question is just how much meaningful benefit is there likely to be? I can't answer that. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue May 10 17:45:59 2016 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 B218C12D17A for ; Tue, 10 May 2016 17:45:58 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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=dlPcPlpV; dkim=pass (1536-bit key) header.d=taugh.com header.b=bQvLudWh 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 5fJwMBln0PND for ; Tue, 10 May 2016 17:45:57 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 202DE12D0E8 for ; Tue, 10 May 2016 17:45:57 -0700 (PDT) Received: (qmail 46681 invoked from network); 11 May 2016 00:45:57 -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=b657.573280c5.k1605; bh=6ipmRuYMYUVJerQCGzgdyH5SyAyeL/fDvbAJpHJ2h2g=; b=dlPcPlpVx71w12WfQ7ES9fHIoqtW0nDzcZ3X3Es3fdz48ICKkBMFeRtiX1hgdlBk8fyZ12av44CFZKdudzCqVJNrd1HGiyd68H3fF3bKf5vyw4sRXWO3TJM9AFxMJF1Yej2foY+lJObSN572nmmooGVYXcQwB+amnGhugXHCvw+oz+/ITqn48yQBBvTXyqGmYgvHgJ6u0OGs9SVoK1BrPKSLWx4lBipWbai1nBZcKN8I+tL+nwmG45Iq+RUI6tZJ 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=b657.573280c5.k1605; bh=6ipmRuYMYUVJerQCGzgdyH5SyAyeL/fDvbAJpHJ2h2g=; b=bQvLudWhusuyq7usVSQfr6LncmKmBZjry+02+5cA6aqtgaHjatuWFMR3lAKy9yPft0iJ9bENKz4uFDRJ78G8B43Up2ymv1b6kpvQumdm4PS+MXuYMIq074O4zTzEwPlHbCe5dpBCWt6Xh3yIZVmmoL0aUIwj1B7wIcYUY2zRMqak3LJgjEpz6cYTwo5aHLKH5Fyyff+zD0EtC7L+e6eeak3F8PRsQGpj7UGUdjLK0mKWRaknhrazLI0wxXSuJc8H 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.0/X.509/SHA1) via TCP6; 11 May 2016 00:45:57 -0000 Date: 10 May 2016 20:45:55 -0400 Message-ID: From: "John R Levine" To: "Dave Crocker" In-Reply-To: <57327D81.6050306@gmail.com> References: <20160511002303.14397.qmail@ary.lan> <57327D81.6050306@gmail.com> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 11 May 2016 00:45:59 -0000 > On the other hand, for purely transactional domains, it could be simpler for > the recipient to be able to easily find that ARC-ish mechanisms are not > authorized. As is invariably the case here, except sometimes. It is my impression that there are forwarders that break DMARC signatures (MS Exchange is often cited) even for a message resent to a single address. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Tue May 10 20:15:46 2016 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 65ED212D5B5 for ; Tue, 10 May 2016 20:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.696 X-Spam-Level: X-Spam-Status: No, score=-3.696 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, RP_MATCHES_RCVD=-0.996, SPF_PASS=-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 N5mbhjvgVzYc for ; Tue, 10 May 2016 20:15:42 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::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 8292912D18D for ; Tue, 10 May 2016 20:15:36 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id f66so41124608vkh.2 for ; Tue, 10 May 2016 20:15:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=eWg7R1cijmpAu6arrkCskeiPW8SOlbJuVPqZSCogceY=; b=ZuioZZdVdAkLWcTepO6mqxz08aaxWkM6S0HjrQ7tgccTBx/dduaZD2kMPAbleRD3Mn D6HSBzpx1TcuHBursrG+1IYEsdtcqpyB6BRMebo9mUC1VZ2zUJb27p7fyTM98RwW9kpV Jj2ebu6uw2Tggi9bzHyp6b0gzFIjdf5nOSPLHVuNTsdfoksSPPjw4s5NR2qLdabN4dzE R0Aq5OGVPdpiL3Corbwz5JchJZN4Ko+2PV1FMZ08XGiybgBwgSMNoyAhcHSJCKjqBAJS Cgo7h+5FgTbp8h4fHd2IaHSTzPm4hl92SNJltoIHe3meFeu6871eLr6C60wyvruKwgih DpRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=eWg7R1cijmpAu6arrkCskeiPW8SOlbJuVPqZSCogceY=; b=DCWf4WoY/VIT8JU0NAbQbG/OYrvvuloGGoHVIO102wIcu0T6/TnCaHPua23Z55AvI4 /PUGJ4XYGG0bNidV82f/HEwOx7jF+7tJDeEpa/GCo2gY1W9DbmR0IIE6LE1BokjTW8Ur LZB7TGMsqhEYgxWneaa3p+cJHbUtMOqE2SOr6cMNhokT4c0UHRSG/kNZLytdz+uYNKs6 dWjWW6A57KywDHgZhOPoQtB8sG+52PidPCXnqZZcg0AmSkaDBy3VOEUK2xWjS1Jex2f3 CnGEn4GRMmBvLxH8kIbafPepGC3+GYjCS4lDdQwlFLFVt41Wi6dqqc+NPyNF6pxoEczp phlg== X-Gm-Message-State: AOPr4FU8lHIjsgewvI3cz1P6cfh2DU4unHWXVQX59r8gVn04eH5GLoF2BaCtQRDgdwPb6jSqH4VBYC77LliUb0dc MIME-Version: 1.0 X-Received: by 10.31.217.7 with SMTP id q7mr482846vkg.134.1462936535466; Tue, 10 May 2016 20:15:35 -0700 (PDT) Received: by 10.31.65.138 with HTTP; Tue, 10 May 2016 20:15:35 -0700 (PDT) In-Reply-To: References: <20160511002303.14397.qmail@ary.lan> <57327D81.6050306@gmail.com> Date: Tue, 10 May 2016 20:15:35 -0700 Message-ID: From: Brandon Long To: John R Levine Content-Type: multipart/alternative; boundary=94eb2c07c41086e88b0532887478 Archived-At: Cc: Dave Crocker , "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 11 May 2016 03:15:44 -0000 --94eb2c07c41086e88b0532887478 Content-Type: text/plain; charset=UTF-8 My worry is that if DMARC started as a private mechanism for high value targets and large msps to collaborate to lower the risk of phishing for their shared users, and I don't want ARC to be perceived as breaking that. I don't want MSPs to have to come up with private lists of high value targets again, or there being yet another policy enforcement standard for "no, I really mean it this time". And yes, you're absolutely correct that there is an installed base of poor forwarders, though I'm not clear if those can be fixed with ARC but not by actually making forwarding work correctly in the first place. Theoretically, some appliance or outbound gateway could blindly add an ARC header to resolve it, I guess, or a pair of inbound/outbound gateways, to work around the broken internal server. Anyways, it's food for thought, especially in regards to how arc and dmarc intersect. Brandon On Tue, May 10, 2016 at 5:45 PM, John R Levine wrote: > On the other hand, for purely transactional domains, it could be simpler >> for the recipient to be able to easily find that ARC-ish mechanisms are not >> authorized. >> > > As is invariably the case here, except sometimes. It is my impression > that there are forwarders that break DMARC signatures (MS Exchange is often > cited) even for a message resent to a single address. > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --94eb2c07c41086e88b0532887478 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My worry is that if DMARC started as a private mechanism f= or high value targets and large msps to collaborate to lower the risk of ph= ishing for their shared users, and I don't want ARC to be perceived as = breaking that.

I don't want MSPs to have to come up = with private lists of high value targets again, or there being yet another = policy enforcement standard for "no, I really mean it this time".=

And yes, you're absolutely correct that there= is an installed base of poor forwarders, though I'm not clear if those= can be fixed with ARC but not by actually making forwarding work correctly= in the first place.=C2=A0 Theoretically, some appliance or outbound gatewa= y could blindly add an ARC header to resolve it, I guess, or a pair of inbo= und/outbound gateways, to work around the broken internal server.

Anyways, it's food for thought, especially in regards t= o how arc and dmarc intersect.

Brandon
=

On Tue, May 10, 2= 016 at 5:45 PM, John R Levine <johnl@taugh.com> wrote:
On the other hand, for purely transactional domains, it could be simpler fo= r the recipient to be able to easily find that ARC-ish mechanisms are not a= uthorized.

 As is invariably the case here, except sometimes.=C2=A0 It is my impression= that there are forwarders that break DMARC signatures (MS Exchange is ofte= n cited) even for a message resent to a single address.

Regards,
John Levine, johnl@tau= gh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.


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

--94eb2c07c41086e88b0532887478-- From nobody Wed May 11 04:55:09 2016 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 E788112D9F3 for ; Wed, 11 May 2016 04:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.298 X-Spam-Level: X-Spam-Status: No, score=-5.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-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=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQG4Ljece1ek for ; Wed, 11 May 2016 04:55:06 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59D0712D9EA for ; Wed, 11 May 2016 04:55:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1462967700; bh=1Mrykr2Oea6IgkS9FMDGahoh3kC1a6szvbl1O8pPnKg=; l=3562; h=References:From:To:Date:In-Reply-To; b=X6Zafb3zgfutSpKMJUK/rLl18DhAyjenpSJ3J6fcSusLEJZfqMi8nADse6KwpsOo4 NYJbqXjvfOs7veXYH4JqBcJHr5H4onjkd8pFZLJiU0W7T1EcBHyKNUE4qM1MmQCVdC gZ1007rWyytFrLZONSUf+hsh51wDdwMoTZRiIVs0= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.88] (pcale.tana [172.25.197.88]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Wed, 11 May 2016 13:55:00 +0200 id 00000000005DC033.0000000057331D94.00004AE6 References: <20160511002303.14397.qmail@ary.lan> <57327D81.6050306@gmail.com> From: Alessandro Vesely To: "dmarc@ietf.org" Message-ID: <57331D94.2010004@tana.it> Date: Wed, 11 May 2016 13:55:00 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 11 May 2016 11:55:09 -0000 It would be silly to deny that ARC is about indirect mail flows. The reason it is perceived to be in the wrong camp is that DMARC focuses on originators of email, while ARC requires no changes for them. A possible tweak is to introduce an ARC-0, zero for originator, an optional ARC set with i=0: ARC-0 is substantially equivalent to a weak signature. The ARC-Seal field proves that the originator was involved. ARC-Message-Signature is expected to be broken by forwarders. ARC-Authentication-Results may contain just an auth stanza, with a possibly redacted authenticated identity. Malicious self-styled forwarders can abuse ARC-0 in the same manner that they can abuse weak signatures. The functional difference w.r.t. conditional signatures is that the latter require the forwarding "trusted" domain to be explicitly mentioned by the first signer. That would increase security if we could devise methods to avoid being fooled by wannabe phishers who pretend to be MLMs in order to swindle a conditionally signed message out of our servers. Formal differences include not requiring a new DKIM version, but requiring a DMARC authorization for (some forms of) ARC. ARC-0 is to be added to every submitted message, or limited to addresses suspected to result in indirect mail flows. A message signed that way can be (ab)used to illicitly impersonate an authenticated user of the signing domain. Therefore, ARC-0 should only be added by low risk targets. When such a domain sees good feedback, it can publish a strict DMARC policy even though its mail is not purely transactional. jm2c Ale On Wed 11/May/2016 05:15:35 +0200 Brandon Long wrote: > My worry is that if DMARC started as a private mechanism for high value > targets and large msps to collaborate to lower the risk of phishing for > their shared users, and I don't want ARC to be perceived as breaking that. > > I don't want MSPs to have to come up with private lists of high value > targets again, or there being yet another policy enforcement standard for > "no, I really mean it this time". > > And yes, you're absolutely correct that there is an installed base of poor > forwarders, though I'm not clear if those can be fixed with ARC but not by > actually making forwarding work correctly in the first place. > Theoretically, some appliance or outbound gateway could blindly add an ARC > header to resolve it, I guess, or a pair of inbound/outbound gateways, to > work around the broken internal server. > > Anyways, it's food for thought, especially in regards to how arc and dmarc > intersect. > > Brandon > > On Tue, May 10, 2016 at 5:45 PM, John R Levine wrote: > >> On the other hand, for purely transactional domains, it could be simpler >>> for the recipient to be able to easily find that ARC-ish mechanisms are not >>> authorized. >>> >> >> As is invariably the case here, except sometimes. It is my impression >> that there are forwarders that break DMARC signatures (MS Exchange is often >> cited) even for a message resent to a single address. >> >> Regards, >> John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY >> Please consider the environment before reading this e-mail. >> >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > From nobody Wed May 11 05:33:04 2016 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 222FC12D677 for ; Wed, 11 May 2016 05:33:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.895 X-Spam-Level: X-Spam-Status: No, score=-2.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RP_MATCHES_RCVD=-0.996] 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 RMYbC405QESd for ; Wed, 11 May 2016 05:33:00 -0700 (PDT) Received: from turnbull.sk.tsukuba.ac.jp (turnbull.sk.tsukuba.ac.jp [130.158.96.25]) (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 276E012D17E for ; Wed, 11 May 2016 05:32:59 -0700 (PDT) Received: from steve by turnbull.sk.tsukuba.ac.jp with local (Exim 4.87) (envelope-from ) id 1b0TKJ-0004nD-Mw; Wed, 11 May 2016 21:33:19 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22323.9871.678573.858468@turnbull.sk.tsukuba.ac.jp> Date: Wed, 11 May 2016 21:33:19 +0900 From: "Stephen J. Turnbull" To: Dave Crocker In-Reply-To: <57327D81.6050306@gmail.com> References: <20160511002303.14397.qmail@ary.lan> <57327D81.6050306@gmail.com> X-Mailer: VM 8.2.0b under 21.5 (beta34) "kale" e1ed68423813 XEmacs Lucid (x86_64-apple-darwin15.4.0) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: steve@turnbull.sk.tsukuba.ac.jp X-SA-Exim-Scanned: No (on turnbull.sk.tsukuba.ac.jp); SAEximRunCond expanded to false Archived-At: Cc: blong@google.com, dmarc@ietf.org, John Levine Subject: Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 11 May 2016 12:33:03 -0000 Dave Crocker writes: > On 5/10/2016 5:23 PM, John Levine wrote: > >> Should DMARC add a policy setting for whether the domain owner feels that > >> ARC should be used to bypass regular DMARC evaluation? > > > > Please, no. One approach to what we can oversimplify as the mailing > > list problem is to do it from the sending end, with the sender using > > something like conditional double signatures to say mutated messages > > are OK. The other is to provide data that the recipient can use > > to decide these mutations are OK. > > > > ARC is definitely in the latter camp, and it would be painful to > > have both ends arguing about how OK stuff is. +1 In practice, after April 2014, nobody who thinks about the issue is going to take DMARC policies with less than a grain of salt anyway. Of course they're going to take them *seriously*, but several large sites were already taking "p=reject" as "strong advice" rather than a command *before* AOL and Yahoo! started applying p=reject to mail flows containing millions of non-transactional messages. ARC is going to get slow uptake anyway, from the point of view of mailing list owners. We're going to depend on people trusting our signature more than Yahoo!'s in any case. > ARC, ultimately, relies on having the receiver trust assertions made by > the first ARC signer. Things get easier for the receiver if they see a > statement by the domain owner saying "don't bother with ARC". Why do you think so? As far as I can see, you (as receiver) end up in the same boat as with "p=reject": it's going to be applied to non-transactional mail flows that your users want to receive, and you're not going to deny them if you assess that the risk is low based on other evidence. An ARC Seal from a site with a high trust level surely makes a big difference there. Steve From nobody Wed May 11 07:00:31 2016 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 8E06612D5C7 for ; Wed, 11 May 2016 07:00:30 -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 EiHSYzgtlVut for ; Wed, 11 May 2016 07:00:28 -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 4625F12B006 for ; Wed, 11 May 2016 07:00:28 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id g133so43170562ywb.2 for ; Wed, 11 May 2016 07:00:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=QkJSLKNTK7c9GpKjKISc7GREmYO8vWCkGPiNbgjyYcE=; b=xJ3vyMhlv5yTq5Lg2WmEEu6f4RWy+QvMi497+gJcZp0gZGf1UEtQwBcaiHmu0GpW5a DW1Yz2ilxMZAyxqN2At1fvpHCU5eYwaDOuio2yUMCNxIGQznB04WcLQaPmkYneC4z9TH bDv3BT/lC+8xGvyjXmrIUYxHPRSD7aFrUTdy+YsVSpRO3OTIFBjTAjojuI096wESUN/p WnMzjBXCV4r6257hMFwZPuMp5X3tGLyOwgqx0tOCf/4UfOu3Zj8OGgpn/f6XLKKHMKKN DvXX8tSKvnJ8eiIIjRg1jCD3pcur/AngJWwrRWf9m/oGWNdZwyQA4BUrf0DMsS54eq7a zrfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=QkJSLKNTK7c9GpKjKISc7GREmYO8vWCkGPiNbgjyYcE=; b=VhuIJwiimZh8d6FMRX331qiSQgglBvGPJkLXhw+iVY68IbiEEbLAh/Ay4DoIRTt6o1 KuBQo3r6yYobUA9UVKyCYDV7Mdi/nQF5KKOSRQc7QOnOIg9bBfOWA310Qa+cPbtwR1wu 0XELRCBi2nmemzbNKLNc1A4xfnM9v35oI1q2kDhh9Frd4en/1e7hTJ9GB0sYMiSj/wBt Vt/bVkuh4ec8jImJZLnKqNY6XBojB75N8BSq1eLEZE6hLLOnHfLyEthUnQ0vrVQo4dft zZEQ1dkW4bTvzCC34r+s0/XIcHRzfdzgp603K4h1NVdSke/PjhxM+onF83gHY0OE59U/ Z+vg== X-Gm-Message-State: AOPr4FUTGCHMNesqDb8/n2X09mIH8wcSwzC20/RL5kHR28KqD61mKbCMoQTT1cqe/x9NftcgBOM3GwLCb33ewQ== MIME-Version: 1.0 X-Received: by 10.129.80.11 with SMTP id e11mr1773136ywb.197.1462975227557; Wed, 11 May 2016 07:00:27 -0700 (PDT) Received: by 10.37.103.215 with HTTP; Wed, 11 May 2016 07:00:27 -0700 (PDT) In-Reply-To: <57331D94.2010004@tana.it> References: <20160511002303.14397.qmail@ary.lan> <57327D81.6050306@gmail.com> <57331D94.2010004@tana.it> Date: Wed, 11 May 2016 07:00:27 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: multipart/alternative; boundary=001a1147d2b2c0fd050532917618 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 11 May 2016 14:00:30 -0000 --001a1147d2b2c0fd050532917618 Content-Type: text/plain; charset=UTF-8 On Wed, May 11, 2016 at 4:55 AM, Alessandro Vesely wrote: > It would be silly to deny that ARC is about indirect mail flows. The > reason it > is perceived to be in the wrong camp is that DMARC focuses on originators > of > email, while ARC requires no changes for them. A possible tweak is to > introduce an ARC-0, zero for originator, an optional ARC set with i=0: > Perhaps I'm misunderstanding, but doesn't an i=0 ARC set represent a verification by the originator of its own mail? > ARC-0 is substantially equivalent to a weak signature. The ARC-Seal field > proves that the originator was involved. ARC-Message-Signature is > expected to > be broken by forwarders. ARC-Authentication-Results may contain just an > auth > stanza, with a possibly redacted authenticated identity. > Doesn't the i=1 ARC set also prove the originator was involved? -MSK --001a1147d2b2c0fd050532917618 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, May 11, 2016 at 4:55 AM, Alessandro Vesely <vesely@t= ana.it> wrote:
It would be silly to deny that AR= C is about indirect mail flows.=C2=A0 The reason it
is perceived to be in the wrong camp is that DMARC focuses on originators o= f
email, while ARC requires no changes for them.=C2=A0 A possible tweak is to=
introduce an ARC-0, zero for originator, an optional ARC set with i=3D0:

Perhaps I'm misunderstanding, but doe= sn't an i=3D0 ARC set represent a verification by the originator of its= own mail?
=C2=A0
ARC-0 is substantially equivalent to a weak signature.=C2=A0 The ARC-Seal f= ield
proves that the originator was involved.=C2=A0 ARC-Message-Signature is exp= ected to
be broken by forwarders.=C2=A0 ARC-Authentication-Results may contain just = an auth
stanza, with a possibly redacted authenticated identity.

Doesn't the i=3D1 ARC set also prove the originator w= as involved?
=C2=A0
-MSK
--001a1147d2b2c0fd050532917618-- From nobody Wed May 11 08:29:29 2016 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 F05B212D70C for ; Wed, 11 May 2016 08:29:21 -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 jB6Hj6NqpJ2v for ; Wed, 11 May 2016 08:29:19 -0700 (PDT) Received: from mail-io0-x243.google.com (mail-io0-x243.google.com [IPv6:2607:f8b0:4001:c06::243]) (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 C001B12D718 for ; Wed, 11 May 2016 08:29:19 -0700 (PDT) Received: by mail-io0-x243.google.com with SMTP id x35so6451776ioi.0 for ; Wed, 11 May 2016 08:29: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:date:message-id:subject :from:to:cc; bh=BecdBSmHwqMXyqST7n+ZAcjDUSA8pNqBPF4zZSejK1M=; b=U2CZfjI2j8ZDqjVM40EszDKJ02kQev5CxZv7GQUInzp2qvP0YQhSwkobTHl9ylhd+s Ymo1fARbarf8xZRy74blWnWHtCdZeOiXydmgssihFktFErs3A7dJXr4o2xlX426Xm6sa 2F71tdMDsVy2awQUx8aleDFiQES2zgFaJOkHw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=BecdBSmHwqMXyqST7n+ZAcjDUSA8pNqBPF4zZSejK1M=; b=TPN+YVS8XXC4uTWRq17uQJALoPROau/I1PidbrUtfYsDE3In9dvf1B9bViB2Hb2IGz X4e75lXiyIfM1NasOQJp7ngEyvy5Onnuc0sJPkg8vXo4g/BbswodQxUrl8fEXW3RGBQK MdHcFeWAeUGcK6FFwXywAcwgm2Gu0dBLaw9RoDXWCqtR6MsDS1wQi8V6WWlLTsPBt3aJ 6BcOrBAMk6zOV6c2WtHyhuQmOHafMfBQnb4VpFogQL46u+dkIjOTy18AhP3+9kHQ3sH3 4jcqwBs0gZPJ2XQyRcrBZhSWLufz2rCZyLqw0BDWeNxYjX5w1nPwQpUTfmeEbdE+3KLM Nhzg== X-Gm-Message-State: AOPr4FXvUdnJ2yVQTa4tPgOvUO73xL+HipeUg1zN+zlY5IiHTCSQaMaHaWtsnMRLgHbJ2UGsf1LvnMdsXmxJSg== MIME-Version: 1.0 X-Received: by 10.36.110.143 with SMTP id w137mr5438850itc.37.1462980558996; Wed, 11 May 2016 08:29:18 -0700 (PDT) Sender: kurta@drkurt.com Received: by 10.107.20.202 with HTTP; Wed, 11 May 2016 08:29:18 -0700 (PDT) In-Reply-To: References: <20160511002303.14397.qmail@ary.lan> <57327D81.6050306@gmail.com> <57331D94.2010004@tana.it> Date: Wed, 11 May 2016 08:29:18 -0700 X-Google-Sender-Auth: tz00Dp3wnYek8H83CN7LwrrJlwg Message-ID: From: "Kurt Andersen (b)" To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=001a114c457c885eb5053292b45c Archived-At: Cc: "dmarc@ietf.org" , ARC Discussion , Alessandro Vesely Subject: Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 11 May 2016 15:29:22 -0000 --001a114c457c885eb5053292b45c Content-Type: text/plain; charset=UTF-8 On Wed, May 11, 2016 at 7:00 AM, Murray S. Kucherawy wrote: > On Wed, May 11, 2016 at 4:55 AM, Alessandro Vesely wrote: > >> It would be silly to deny that ARC is about indirect mail flows. The >> reason it >> is perceived to be in the wrong camp is that DMARC focuses on originators >> of >> email, while ARC requires no changes for them. A possible tweak is to >> introduce an ARC-0, zero for originator, an optional ARC set with i=0: >> > > Perhaps I'm misunderstanding, but doesn't an i=0 ARC set represent a > verification by the originator of its own mail? > The concept of an AS[0] set of headers was debated and deemed, as suggested by Murray, to just be a repetition of the DKIM signature assertion. As such, it doesn't really add any utility. There have been suggestions on the arc-discuss list that, perhaps, AS[0] could be used as an assertion "on behalf of" some other domain that the message submitter was known to the sending ADMD (as mentioned below under "authenticated identity"). The biggest problem with that, is whether anyone should trust such purported authentication claims. I doubt that anyone with minimal exposure to security issues would find that appealing. > ARC-0 is substantially equivalent to a weak signature. The ARC-Seal field >> proves that the originator was involved. ARC-Message-Signature is >> expected to >> be broken by forwarders. ARC-Authentication-Results may contain just an >> auth >> stanza, with a possibly redacted authenticated identity. >> > > Doesn't the i=1 ARC set also prove the originator was involved? > Yes, AS[1] testifies to the Authenticated-Results of receiving the message from the originator. --Kurt --001a114c457c885eb5053292b45c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, May 11, 2016 at 7:00 AM, Murray S. Kucherawy <superuser@gmail.com> wrote:
On Wed, May 11, 2016 at 4:55 AM, Alessandro Vesely <vesely@tan= a.it> wrote:
It would= be silly to deny that ARC is about indirect mail flows.=C2=A0 The reason i= t
is perceived to be in the wrong camp is that DMARC focuses on originators o= f
email, while ARC requires no changes for them.=C2=A0 A possible tweak is to=
introduce an ARC-0, zero for originator, an optional ARC set with i=3D0:

Perhaps I'm misunderstanding, = but doesn't an i=3D0 ARC set represent a verification by the originator= of its own mail?

The concept of an AS[0] set of headers was debated and deemed, as sugges= ted by Murray, to just be a repetition of the DKIM signature assertion. As = such, it doesn't really add any utility. There have been suggestions on= the arc-discuss list that, perhaps, AS[0] could be used as an assertion &q= uot;on behalf of" some other domain that the message submitter was kno= wn to the sending ADMD (as mentioned below under "authenticated identi= ty"). The biggest problem with that, is whether anyone should trust su= ch purported authentication claims. I doubt that anyone with minimal exposu= re to security issues would find that appealing.
=C2=A0=C2=A0
Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 11 May 2016 16:00:40 -0000 I'm pulling the arc-discuss list back off the distribution for this message (and it's probably a good idea to alert people when you add a new mailing list to an ongoing discussion). Kurt's original message asked whether the DMARC working group... 1. ...wants to work on the ARC spec, using https://datatracker.ietf.org/doc/draft-andersen-arc/ as a starting point, and 2. ...also wants to work on ARC usage recommendations, using https://datatracker.ietf.org/doc/draft-jones-arc-usage/ as a starting point. It certainly seems that the working group is interested in discussing ARC, as I can judge from the discussion in the short time since Kurt's proposal. So let's go back and get a proper answer: Does anyone object to having the DMARC working group take on this work? Does anyone object to using the two documents above as starting points for that work? Does anyone have an alternative proposal? Please respond to this list, , by 20 May. Barry, for the DMARC chairs On Wed, May 11, 2016 at 11:29 AM, Kurt Andersen (b) wrote: > On Wed, May 11, 2016 at 7:00 AM, Murray S. Kucherawy > wrote: >> >> On Wed, May 11, 2016 at 4:55 AM, Alessandro Vesely wrote: >>> >>> It would be silly to deny that ARC is about indirect mail flows. The >>> reason it >>> is perceived to be in the wrong camp is that DMARC focuses on originators >>> of >>> email, while ARC requires no changes for them. A possible tweak is to >>> introduce an ARC-0, zero for originator, an optional ARC set with i=0: >> >> >> Perhaps I'm misunderstanding, but doesn't an i=0 ARC set represent a >> verification by the originator of its own mail? > > > The concept of an AS[0] set of headers was debated and deemed, as suggested > by Murray, to just be a repetition of the DKIM signature assertion. As such, > it doesn't really add any utility. There have been suggestions on the > arc-discuss list that, perhaps, AS[0] could be used as an assertion "on > behalf of" some other domain that the message submitter was known to the > sending ADMD (as mentioned below under "authenticated identity"). The > biggest problem with that, is whether anyone should trust such purported > authentication claims. I doubt that anyone with minimal exposure to security > issues would find that appealing. > >>> >>> ARC-0 is substantially equivalent to a weak signature. The ARC-Seal >>> field >>> proves that the originator was involved. ARC-Message-Signature is >>> expected to >>> be broken by forwarders. ARC-Authentication-Results may contain just an >>> auth >>> stanza, with a possibly redacted authenticated identity. >> >> >> Doesn't the i=1 ARC set also prove the originator was involved? > > > Yes, AS[1] testifies to the Authenticated-Results of receiving the message > from the originator. > > --Kurt > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > From nobody Wed May 11 09:54:24 2016 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 6A74412D0C3 for ; Wed, 11 May 2016 09:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.298 X-Spam-Level: X-Spam-Status: No, score=-5.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-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=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CgtO6g12e8Su for ; Wed, 11 May 2016 09:54:22 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD56912D507 for ; Wed, 11 May 2016 09:54:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1462985659; bh=NqXEkwzpr9TcFgbsMTCNTf8TmVXe43YHhIcr75LqWrA=; l=850; h=To:References:Cc:From:Date:In-Reply-To; b=ZBjdduhXvWwpmSz2vaoG8iFvKn/Ii67UQI0fB4BFg6aQcCafk4laZ/Yx7kyB7k3WC bsGvWfyZ69L95fyXnTl0EU0VHt7j1wN2Xa4KD4MLkJieYVrv+GezSJ7zy241l0Gq2k wBW7pjpcTQIR3JHQ/DOhjxNP4V/+JOopYrYpdu6k= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.88] (pcale.tana [172.25.197.88]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Wed, 11 May 2016 18:54:19 +0200 id 00000000005DC044.00000000573363BB.00005F12 To: "Kurt Andersen (b)" , "Murray S. Kucherawy" References: <20160511002303.14397.qmail@ary.lan> <57327D81.6050306@gmail.com> <57331D94.2010004@tana.it> From: Alessandro Vesely Message-ID: <573363BB.9030701@tana.it> Date: Wed, 11 May 2016 18:54:19 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: "dmarc@ietf.org" , ARC Discussion Subject: Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 11 May 2016 16:54:23 -0000 On Wed 11/May/2016 17:29:18 +0200 Kurt Andersen (b) wrote: > On Wed, May 11, 2016 at 7:00 AM, Murray S. Kucherawy wrote: >> On Wed, May 11, 2016 at 4:55 AM, Alessandro Vesely wrote: [... assume ARC-Seal: i=0 still verifies ...] >>> ARC-0 is substantially equivalent to a weak signature. The ARC-Seal >>> field proves that the originator was involved. ARC-Message-Signature >>> is expected to be broken by forwarders. ARC-Authentication-Results may >>> contain just an auth stanza, with a possibly redacted authenticated >>> identity. >> >> Doesn't the i=1 ARC set also prove the originator was involved? No, it doesn't. > Yes, AS[1] testifies to the Authenticated-Results of receiving the message > from the originator. That only proves the first receiver was involved. A final receiver may trust its results or not. Ale From nobody Wed May 11 10:10:02 2016 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 4489912D0EE for ; Wed, 11 May 2016 10:10:01 -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 JOpPByQcr2Oi for ; Wed, 11 May 2016 10:09:58 -0700 (PDT) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62BD412D522 for ; Wed, 11 May 2016 10:09:46 -0700 (PDT) Received: by mail-ig0-x22a.google.com with SMTP id lr7so38525910igb.1 for ; Wed, 11 May 2016 10:09:46 -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:date:message-id:subject :from:to:cc; bh=V45OypAwsSAKZGyZ1NnApLczMBdGuet6inF4kFfX/Hk=; b=LajnNaGMApk9EC/M0wScUskPre/IACBdWaylIw1/w12ynYk5gKYwn+gWG/jaMQqR5E p8Cf+Qff2XAAISMjfeSapoFPIuHCz33sL/syxx5f2f0137VZPPAV44+n2aMyiml3fTCu z0hsqORRsrm9dXkMG6XfKYV7Ad1ypODBPe+o4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=V45OypAwsSAKZGyZ1NnApLczMBdGuet6inF4kFfX/Hk=; b=lVgZLqjm9PrMreEzaPdgzugnw5L15T4DnVqGtpJ4g2dkz2CsnPktYiota6UGZiOU4H L0jhmtwW4hlsVo4N12atGvKEk1kIwlLi2AqZ9JdoGCaiK9UClPP694wkNjbpkWpxz3Qb I3smUJzS/HyavfhBF61XdCOLiRhHEMMjMTGaA7sWmmLvs9I3uF/RKhyx+dSrJi1QVRiB NHxWMAFodg4ubJ4psq+fhleetdDGaykzY1igmWMJPW4cPlOBzwuR4sDMGCahAASsI1ME 6Eismpm+drbJdJN547s8ccdilq0gODJzmhyei1ESVlLhyCYoHTtqxHvfIB+THdch9Ne9 0wEw== X-Gm-Message-State: AOPr4FUjV4LFg14/zgydFCqW2/KRG8BUuWSVrtC6DUi/rJ4jZ72y4z0tNfSAmE720M+AcIbysSR6mqHve6sLLw== MIME-Version: 1.0 X-Received: by 10.50.155.6 with SMTP id vs6mr22967730igb.79.1462986585697; Wed, 11 May 2016 10:09:45 -0700 (PDT) Sender: kurta@drkurt.com Received: by 10.107.20.202 with HTTP; Wed, 11 May 2016 10:09:45 -0700 (PDT) In-Reply-To: <573363BB.9030701@tana.it> References: <20160511002303.14397.qmail@ary.lan> <57327D81.6050306@gmail.com> <57331D94.2010004@tana.it> <573363BB.9030701@tana.it> Date: Wed, 11 May 2016 10:09:45 -0700 X-Google-Sender-Auth: zeWYtFJ7X3_w9skH9Rg4Ul6e0RE Message-ID: From: "Kurt Andersen (b)" To: Alessandro Vesely Content-Type: multipart/alternative; boundary=001a1133bd78c0a1cf0532941b9c Archived-At: Cc: "dmarc@ietf.org" , "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 11 May 2016 17:10:01 -0000 --001a1133bd78c0a1cf0532941b9c Content-Type: text/plain; charset=UTF-8 Removing arc-discuss per suggestion from Barry. On Wed, May 11, 2016 at 9:54 AM, Alessandro Vesely wrote: > On Wed 11/May/2016 17:29:18 +0200 Kurt Andersen (b) wrote: > > On Wed, May 11, 2016 at 7:00 AM, Murray S. Kucherawy wrote: > > [... assume ARC-Seal: i=0 still verifies ...] > > > Doesn't the i=1 ARC set also prove the originator was involved? > > No, it doesn't. > > > Yes, AS[1] testifies to the Authenticated-Results of receiving the > message > > from the originator. > > That only proves the first receiver was involved. A final receiver may > trust > its results or not. > What would an AS[0] assertion provide that would not be already asserted by the originator's DKIM-Signature? If AS[1] is untrustworthy (using the term advisedly), but AS[0] still verifies, then presumably the original DKIM-Signature would also still verify and ARC-based information is not needed to have a pass for the DMARC evaluation. --Kurt --001a1133bd78c0a1cf0532941b9c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Remo= ving arc-discuss per suggestion from Barry.

On Wed, May 11, 2016 at 9:54 AM, Ales= sandro Vesely <vesely@tana.it> wrote:
On Wed 11/May/2016 17:29:18 +0200 Kurt Andersen (b) wrote:
> On Wed, May 11, 2016 at 7:00 AM, Murray S. Kucherawy wrote:

[... assume ARC-Seal: i=3D0 still verifies ...]

> Doesn't the i=3D1 ARC set also prove the originator was involved?<= br>
No, it doesn't.

> Yes, AS[1] testifies to the Authenticated-Results of receiving the mes= sage
> from the originator.

That only proves the first receiver was involved.=C2=A0 A final rece= iver may trust
its results or not.

What would an AS[0]= assertion provide that would not be already asserted by the originator'= ;s DKIM-Signature?

If AS[1] is untrustworthy (usin= g the term advisedly), but AS[0] still verifies, then presumably the origin= al DKIM-Signature would also still verify and ARC-based information is not = needed to have a pass for the DMARC evaluation.=C2=A0

<= div>--Kurt
=C2=A0

--001a1133bd78c0a1cf0532941b9c-- From nobody Wed May 11 11:40:12 2016 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 306D812D548 for ; Wed, 11 May 2016 11:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.298 X-Spam-Level: X-Spam-Status: No, score=-5.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-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=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0v7stor9vTP for ; Wed, 11 May 2016 11:40:09 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59D6112D554 for ; Wed, 11 May 2016 11:40:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1462992006; bh=MZt14dgt8uc/glWd2EWu7yjgMMzWRuvyLy1/3O/Urus=; l=2079; h=To:References:Cc:From:Date:In-Reply-To; b=v7ihMI7DJ9YRdHoFFZoqwY6EInVjNUBEm8DYWNZb+OwuUf6Rry4AmigAynro39skh Gx3cLku2SXoQVy66cf3+sgfQ1zgCMCogwtTaUO8qC5nFfDbXuoRPvie5dIuUCBSBpM OE5wHJtP10AT/j2gBegjURq8P02RWKDAuj5KQV/Q= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.88] (pcale.tana [172.25.197.88]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Wed, 11 May 2016 20:40:06 +0200 id 00000000005DC044.0000000057337C86.00006434 To: "Kurt Andersen (b)" References: <20160511002303.14397.qmail@ary.lan> <57327D81.6050306@gmail.com> <57331D94.2010004@tana.it> <573363BB.9030701@tana.it> From: Alessandro Vesely Message-ID: <57337C86.60300@tana.it> Date: Wed, 11 May 2016 20:40:06 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: "dmarc@ietf.org" , "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 11 May 2016 18:40:11 -0000 On Wed 11/May/2016 19:09:45 +0200 Kurt Andersen (b) wrote: > Removing arc-discuss per suggestion from Barry. > > On Wed, May 11, 2016 at 9:54 AM, Alessandro Vesely wrote: >> On Wed 11/May/2016 17:29:18 +0200 Kurt Andersen (b) wrote: >>> On Wed, May 11, 2016 at 7:00 AM, Murray S. Kucherawy wrote: >> >> [... assume ARC-Seal: i=0 still verifies ...] >> >>> Doesn't the i=1 ARC set also prove the originator was involved? >> >> No, it doesn't. >> >>> Yes, AS[1] testifies to the Authenticated-Results of receiving the >>> message from the originator. >> >> That only proves the first receiver was involved. A final receiver may >> trust its results or not. > > What would an AS[0] assertion provide that would not be already asserted by > the originator's DKIM-Signature? Nothing, except that the originator's DKIM-Signature is broken after MLM processing. In that respect, ARC-Seal is similar to weak signatures. > If AS[1] is untrustworthy (using the term advisedly), but AS[0] still > verifies, then presumably the original DKIM-Signature would also still > verify and ARC-based information is not needed to have a pass for the DMARC > evaluation. If the body was altered the original DKIM-Signature is broken. If AS(0) is good --which is possible since it didn't sign the body-- and rfc5322.from matches the AS(0) signer, can we then bypass DMARC validation? To address Brandon's concern, high value targets should never produce an AS(0) in the first place. Spammers can grab a recent ARC-0 set from any message emitted by a general purpose domain deploying this technique, let's call it hmail. Then they craft a message with: * the grabbed ARC-0, * From: user@hmail.example, and * ARC set signed by themselves, including faked ARC-Authentication-Results. W.r.t. what happened before hmail published p=reject, spammers face the additional difficulty of getting a fresh ARC-0 every day, but hmail know which messages such ARC-0 was being grabbed from. Admittedly not much, but maybe can be improved. Ale From nobody Wed May 11 13:35:06 2016 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 E6BA512D0FF for ; Wed, 11 May 2016 13:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 bwQPbSEXMs66 for ; Wed, 11 May 2016 13:35:02 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AEAE12B078 for ; Wed, 11 May 2016 13:35:02 -0700 (PDT) Received: (qmail 3930 invoked from network); 11 May 2016 20:35:03 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 11 May 2016 20:35:03 -0000 Date: 11 May 2016 20:34:39 -0000 Message-ID: <20160511203439.18013.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: blong@google.com Subject: Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 11 May 2016 20:35:04 -0000 >My worry is that if DMARC started as a private mechanism for high value >targets and large msps to collaborate to lower the risk of phishing for >their shared users, and I don't want ARC to be perceived as breaking that. > >I don't want MSPs to have to come up with private lists of high value >targets again, or there being yet another policy enforcement standard for >"no, I really mean it this time". I see your point, but I don't have much hope. DMARC worked great as a way to say "I'm a phish target", less great when repurposed to outsource the pain of some providers' security failures. No matter what we say, there will always be people who believe that the strictest possible option is most secure, then blame everyone else when the predictable screwups happen. So I don't think you can trust people's self-assertion of "I really mean it." Also, keep in mind that DMARC is supposed to be an anti-phishing technology. If some nitwit puts a mailing list's address on his Paypal account or the contact address for ordering some slinky underwear, and ARC allows the notices to go out through the list, so what? It's certainly stupid, it might be embarassing, but nobody's been phished. R's, John From nobody Wed May 11 13:35:35 2016 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 75AB712D0FF for ; Wed, 11 May 2016 13:35:33 -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 QeD-tooOPgoP for ; Wed, 11 May 2016 13:35:30 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8863B12D0A3 for ; Wed, 11 May 2016 13:35:30 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id f89so69743383ioi.0 for ; Wed, 11 May 2016 13:35:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:date:message-id:subject:from:to:cc; bh=BRpc3SFYR3HwzI6IoPgO2pip/7ICORaUqFu7ReA3fnc=; b=SiDrur5t3JreaYgL3KhbhODFzoMu4VPFFiCgh61gBvAIBmgfl77OggA8OkM44J0R/B cUkx4TrCof4a98tmuvZFAo4Le3qC1emwwX16J24t5vq7AcOaCWPD+3YNLHUDg2MB1gfv yRAuENNccMiOBFXEavmCOlMWCa77v7UjICa2M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to:cc; bh=BRpc3SFYR3HwzI6IoPgO2pip/7ICORaUqFu7ReA3fnc=; b=hFy844LkQFgpCHt6AqbHR3sgR5w7xVkUMXYc+HWEOn6exAAJnt3FxGa+EVD2WoP6AV rSVhRmW4HVaCn70374G3YbmWz7ewpRyBkmibWfHj8Y0AiV1+Cni4zx/mRZYFVDzdh28y kGbQaKk8c8bQ7VA9XxczvWV023BptoGmYckeu0yAohJR2fXhReCbK9r70rvAGrZxtOLv FxC8U05IM0kknzpvJD0Sxboqv8yryFYpsj77nt8OPrRTrBws2FokWcgKtxB//5YPN2+4 kT3awXwxqYNREkqQCkqQI1lgtxpaxSdldlgUZJhpVcXNL/aAwZqAMV3DcJnbyDAq2I8s HBjQ== X-Gm-Message-State: AOPr4FWW4DSElcm+xL/orEWPWLqO/K0KgCCAuus3JHVDaNIKQ8eeOsqGP+H63GkYgYHNXR83ZKcR3t4KkIHF1g== MIME-Version: 1.0 X-Received: by 10.107.129.75 with SMTP id c72mr5121263iod.102.1462998929728; Wed, 11 May 2016 13:35:29 -0700 (PDT) Sender: kurta@drkurt.com Received: by 10.107.20.202 with HTTP; Wed, 11 May 2016 13:35:29 -0700 (PDT) Date: Wed, 11 May 2016 13:35:29 -0700 X-Google-Sender-Auth: lypXLq3u4x9nG6gGr2NlXqLGpXI Message-ID: From: "Kurt Andersen (b)" To: Alessandro Vesely Content-Type: multipart/alternative; boundary=001a113f99b0838ca4053296fbf9 Archived-At: Cc: "dmarc@ietf.org" , "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 11 May 2016 20:35:33 -0000 --001a113f99b0838ca4053296fbf9 Content-Type: text/plain; charset=UTF-8 On Wed, May 11, 2016 at 11:40 AM, Alessandro Vesely wrote: > On Wed 11/May/2016 19:09:45 +0200 Kurt Andersen (b) wrote: > > > > What would an AS[0] assertion provide that would not be already asserted > by > > the originator's DKIM-Signature? > > Nothing, except that the originator's DKIM-Signature is broken after MLM > processing. In that respect, ARC-Seal is similar to weak signatures. > > > If AS[1] is untrustworthy (using the term advisedly), but AS[0] still > > verifies, then presumably the original DKIM-Signature would also still > > verify and ARC-based information is not needed to have a pass for the > DMARC > > evaluation. > > If the body was altered the original DKIM-Signature is broken. If AS(0) is > good --which is possible since it didn't sign the body-- and rfc5322.from > matches the AS(0) signer, can we then bypass DMARC validation? To address > Brandon's concern, high value targets should never produce an AS(0) in the > first place. > AS[0] will not be "good" in the way you propose because nearly all of the transformations that will break DKIM will also break the AMS (ARC-Message-Signature) and, per https://tools.ietf.org/html/draft-andersen-arc-04#section-5.1.1.5 bullet 3, AMS must pass for the overall ARC set to be considered valid. I'd like to respectfully suggest that "bypassing DMARC validation" is pretty far out of scope for what we've intended with ARC. --Kurt --001a113f99b0838ca4053296fbf9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, May 11, 2016 at 11:40 AM, Alessandro Vesely <vesely@tana.it> wrote:
On Wed 11/May/2016 19:09:45 += 0200 Kurt Andersen (b) wrote:
>
> What would an AS[0] assertion provide that would not be already assert= ed by
> the originator's DKIM-Signature?

Nothing, except that the originator's DKIM-Signature is broken a= fter MLM
processing.=C2=A0 In that respect, ARC-Seal is similar to weak signatures.<= br>
> If AS[1] is untrustworthy (using the term advisedly), but AS[0] still<= br> > verifies, then presumably the original DKIM-Signature would also still=
> verify and ARC-based information is not needed to have a pass for the = DMARC
> evaluation.

If the body was altered the original DKIM-Signature is broken.=C2=A0= If AS(0) is
good --which is possible since it didn't sign the body-- and rfc5322.fr= om
matches the AS(0) signer, can we then bypass DMARC validation?=C2=A0 To add= ress
Brandon's concern, high value targets should never produce an AS(0) in = the
first place.

AS[0] will not be "go= od" in the way you propose because nearly all of the transformations t= hat will break DKIM will also break the AMS (ARC-Message-Signature) and, pe= r https://tools.ietf.org/html/draft-andersen-arc-04#section-5.1.1.5 = bullet 3, AMS must pass for the overall ARC set to be considered valid.

I'd like to respectfully suggest that "bypas= sing DMARC validation" is pretty far out of scope for what we've i= ntended with ARC.

--Kurt=C2=A0

--001a113f99b0838ca4053296fbf9-- From nobody Wed May 11 13:59:51 2016 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 8ACE612D7FE for ; Wed, 11 May 2016 13:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-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=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MtTrzTFliZPh for ; Wed, 11 May 2016 13:59:47 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29CC712D1DE for ; Wed, 11 May 2016 13:59:47 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q01X9KKE28013593@mauve.mrochek.com> for dmarc@ietf.org; Wed, 11 May 2016 13:54:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1463000082; bh=UocSN43sQFvpXKS9SI02A3SLG10I9uBQtkiCWVtUKIE=; h=From:Date:Subject:To; b=iS3LsEF9kmYyf2EZklsWV6psp90LmM54rzyU65YK6Kfl9S4a0bGtfohi2bah9WLkB 7F2wvpssq52QitQAhz9JoWusqAHz43faPePkbLxydNzNqO+55vpWXramLqGbiF/9eK iBtNlotSB5Y7iJW6ZN8CwtkLJqq9jvqxQ1kRO4AM= MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_Kni1M8ErRerAL6mYSZkvAw)" Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q01WURPJU800005M@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for dmarc@ietf.org; Wed, 11 May 2016 13:54:40 -0700 (PDT) From: ned+dmarc@mrochek.com Message-id: <01Q01X9IOH1I00005M@mauve.mrochek.com> Date: Wed, 11 May 2016 13:45:01 -0700 (PDT) To: dmarc@ietf.org Archived-At: Subject: [dmarc-ietf] Document shepard's review of draft-ietf-dmarc-interoperability-14 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 11 May 2016 20:59:49 -0000 --Boundary_(ID_Kni1M8ErRerAL6mYSZkvAw) Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT In my capacity as document shepard, I've now done fairly careful review of the document. The results of that review are attached below. Almost all - but not all - of the issues I found were editorial, not technical, in nature, which is as it should be for a document that this stage. However, we are also about to issue an IETF-wide last call, which will hopefully result in wider review of the document by a more general audience, so now is also the time to correct as many editorial nits as we can so the document is as clear as it can be. For this reason I think it would be a good idea to address these nits sooner rather than later. But if that's a problem I certainly can live with going to last call with the current version. Ned --Boundary_(ID_Kni1M8ErRerAL6mYSZkvAw) Content-type: text/plain; CHARSET=us-ascii Content-transfer-encoding: 7BIT Content-disposition: attachment First, some global changes need to be made to be consistent with RFC 5598: "RFC5321.mailfrom" -> "RFC5321.MailFrom" "RFC5321.HELO/EHLO" -> "RFC5321.HELO/.EHLO" "RFC5321.Helo" -> "RFC5321.HELO/.EHLO" "RFC5322.from" -> "RFC5322.From" I note that RFC5322.Foo usage other than RFC5322.from appears to be correct. I will add that I take no position on the style chosen in RFC 5598, in particular the RFC5321.HELO/.EHLO form. But if we're going to use RFC 5598 conventions we need to be consistent with them. The document variously, and more or less interchangeably, uses the terms "bounce" message and delivery status notification to refer to messages with a null RFC5322.MailFrom. Neither term is ideal; "bounce" message is too informal and potentially covers messages with non-NULL RFC5322.MailFrom, and both terms are insufficiently general. The term RFC 5321 uses is "notification message", but only in a narrow context. I therefore suggest defining this term in the conventions section as follows: The term "notification message" (RFC 5321 section 4.5.5) is used to refer a message with a null RFC5321.MailFrom. And then use this term throughout the document whereever it currently says "bounce" message or delivery status notification. The Introduction ends with: Also, some practices which are in use at the time of this document may or may not be "best practices" as future standards evolve. This statement doesn't seem to connect with anything. Is this talking about practices described in this document? It so, it should be changed to something like: Note that some practices described in this document and presently in use may or may not be "best practices", especially as future standards evolve. Or perhaps drop the statement completely. (It's axiomatic that best practices are going to change over time.) In 1.1 Document Conventions: Notation regarding structured fields is taken from [RFC5598]. Organizational Domain and Authenticated Identifiers are specified in DMARC [RFC7489]. The first is a sentence fragment and both are incomplete. How about: The notation used to document references structured fields is defined in [RFC5598] section 1.3. The terms "Organizational Domain" and "Authenticated Identifier" are specified in DMARC [RFC7489] section 3. There probably should be a paragraph break before the last sentence in section 2. The first paragraph in section 2.1 says: The identifiers which are used by DKIM and SPF are technical components of the transport process for SMTP. This is true of SPF, which uses RFC5321.mailfrom and RFC5321.HELO/HELO. But DKIM doesn't really take identifiers from the message and certainly not from the SMTP transport layer. I'm not entirely sure how to fix this since I'm not sure what this note is trying to say. The obviou thing to do is simply remove the reference to DKIM entirely. The last sentence of section 2.1 says: The mitigations described in this document generally require the relaxed mode of Identifier Alignment. Maybe I'm missing something, but I don't think this is true - in fact from what I can tell few if any of the mitigations absolutely require relaxed mode. I suggest changing this to read: Some of the mitigations described in this document only work with the relaxed mode of Identifier Alignment. In section 2.1.1 we need to clarify whether "multiple DKIM signatures" refers to multiple signatures for the same domain, multiple signatures for different domains, or both. (Since I don't know the state of interoperability here I can't answer this question.) Section 2.2, second paragraph: "forwarding behavior involves" -> "forwarding operations involve" In section 2.3, third paragraph the document states: The latter allows for trivial modifications (largely regarding whitespace and folding) that maintain the integrity of the content of the email. The wording here is awkward, but more to the point, this ignores space adjustment attacks on the message body, per RFC 6376 section 8.1. I suggest changing this to something like: The latter is designed to accomodate trivial modifications to whitespace and folding which, at least in header case, generally have no semantic significance. Section 3.1, third paragraph: "Mediator is a hybrid" -> "Mediator as a hybrid" Section 3.1.1, second paragraph: "These issues manifest themselves" -> "This situation manifests" "Examples of the latter issue" -> "Example of the latter situation" (The point here is these are, as the text says, the beginnings of issues that actually occur when DKIM/DMARC is subsequently applied. As such, calling them issues is premature.) Section 3.1.1, first bullet of second list uses the term "Pseudo-open relays", which I've never heard before and doesn't seem quite right. How about "Partially open"? In section 3.1.2.1 I think we're likely to get pushback on the "and syntactically" phrase in the second paragraph, but I don't know how to word it any better. In section 3.1, in the sentence "There are also SIEVE extensions that modify the body." let's please add a reference to RFC 5703 since we're already referencing it elsewhere. In section 3.2.5, fourth bullet item: "the potential threat form malware" -> "the potential threat from malware" Section 4.1.3.3 first bullet item: "carefully crafted as to not collide" -> "carefully crafted so as to not collide" Section 4.1.3.3 second bullet item: "(as of August 2015)" -> "(as of the publication of this document)" Section 4.1.3.3 fifth bullet item: Section 3.1 in RFC 7372 defines some DKIM codes and section 3.2 some SPF codes, but AFAICT RFC 7489 doesn't define any DMARC-specific codes. (It uses the fairly generic 5.7.1 code instead.) What am I missing? Regardless of what it is, this needs to be clarified so people can figure out what to implement. Section 4.2, first sentence: The following mitigations are based on Internet Drafts (I-Ds) which have not yet received broad consensus. Broad consensus is not the issue, completeness in both the technical and process sense is the issue. I suggest changing this to something like: The following mitigations are based on Internet Drafts (I-Ds) which are still in process. In section 6, change: In Section 4.1.1.1, discusses the importance of appropriate DKIM key management vis a vis third party email senders. to: Section 4.1.1.1 discusses the importance of appropriate DKIM key management vis a vis third party email senders. And change: In Section 4.1.3.3, warns that rewriting the RFC5322.from header field and changing the domain name should not be done with any domain. to: Section 4.1.3.3 warns that rewriting the RFC5322.from header field and changing the domain name should not be done with any domain. Appendix A needs to start out with an explanation of what these messages are examples of. In section A.1, the sample message is syntactically valid, however, the "(envelope-from jqd@d1.example)" comment at the end of the Received: field is both superfluous and (IMO) ill-advised and should be removed. In section A.2, the sample message contains many syntax errors: (a) The id clause value "Lkm25302jJR;5" in the first Received: field contains a semicolon. This value is supposed to have word syntax; semicolons are not allowed. (b) Although not syntactically incorrect, the trailing period on mail.dmarc.org. is unexpected and should be removed. (c) There are two Return-path: fields in the outer header. (d) The second Received: field is missing the mandatory from clause. (e) The second Received: field also has an invalid id clause value; this time it's the period. (f) The "(w-x-y-z.dsl.static.isp.com [w.x.y.z])" clause needs to use an appropriate example domain, e.g. example.net. The x,x,y,z probably should be changed to appropriate values per the final comment below. (f) The mandatory From: field is missing from the outer header. (g) This delivery status notification uses a nonstandard format; it should be reworked to use standard DSN format. If the message isn't reformatted into DSN format a Return-path: field should be added to the inner message. Finally, there's some sort of I-D nit being reported having to do with example IP addresses. I don't really understand this, but I suspect/hope it can be eliminated by changing all the IPs to be in the 192.0.2.0/24 range everywhere, per RFC 5737 section 3. (I personally think all the "must use proper example domains/IPs stuff is a waste of time, but many other people do not.) That's it! --Boundary_(ID_Kni1M8ErRerAL6mYSZkvAw)-- From nobody Wed May 11 15:28:35 2016 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 D648D12D18B for ; Wed, 11 May 2016 15:28:32 -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 s8boVAPxp7dm for ; Wed, 11 May 2016 15:28:31 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::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 000DA12B049 for ; Wed, 11 May 2016 15:28:30 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id o66so63906307ywc.3 for ; Wed, 11 May 2016 15:28:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=GMRgtK3ndcMoRS5d24LQWXiAhKw2TaCfKxaNoGsm9EU=; b=xgleKENv5P8pLJKS3UjbUv73zAo2GxvkCmECl8bpAZf3MHH9g4UZk7q0foN1auMJ0c KoNLtthw2AFFo1lQa35ZR5vVSo7htZa/S+xUo8tYTHPKZFX5opEG073seyT5XgeBa45G uXkiJ7GksSf3ic5tprmwAaMh9jNb9p8zLyixdaAppGzT4MxZIrtliNNyW2h1HuNAtRHl xTW04jq1j08skszxXBxEfePV2+DilLlFFCtc/LEpyHpeGII4GHhwzscSe/xqSgwnSBWq ThN1H3MapMCKgRMBY1pDlzx7/wokxfdcyDDsu5L0amHMAiEEBcz6Voe3JSZOkNrFohrv aTzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=GMRgtK3ndcMoRS5d24LQWXiAhKw2TaCfKxaNoGsm9EU=; b=BH/od5YTEj4M1I74UnZ20321J57gOTFnpJtnoPpfxLenXLFgaLYvH2C91LrKI0lA4Z VXp3vLEecSkx7oi8PqKGWf/J6ju1VUc7E/mD27MhwxcIUxD4pLJHTq+Vr6ptbwrIzaCY OSjcfWcklQyJEXz/73Kuw/43zCggnAP2PKFqVpH3XK6ssw7nWqcLgqmq4PhPq8GDeBzQ NL8z7N9OH9puGhb8POqo9PU0k9Rq0iPtUFQWNhZp53hFrLAEh9fV1FERfBcYw4BBFaBi m4A9r+8GzPXcTFnrsbBpv1IBX3S03GB1EllpcU3xjwIFako4YWWtYqFM57eX3PZOwLGR 6MUw== X-Gm-Message-State: AOPr4FU1BXJINI5HCswSu3Zx5fHoczkau3RsPL7CSkhFdvOvCXKKFegHOSo3uk2wUwBNDE3ppa8g+rDGgONLlg== MIME-Version: 1.0 X-Received: by 10.129.80.11 with SMTP id e11mr3203553ywb.197.1463005710265; Wed, 11 May 2016 15:28:30 -0700 (PDT) Received: by 10.37.103.215 with HTTP; Wed, 11 May 2016 15:28:30 -0700 (PDT) In-Reply-To: <573363BB.9030701@tana.it> References: <20160511002303.14397.qmail@ary.lan> <57327D81.6050306@gmail.com> <57331D94.2010004@tana.it> <573363BB.9030701@tana.it> Date: Wed, 11 May 2016 15:28:30 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: multipart/alternative; boundary=001a1147d2b2aa34a60532988fc6 Archived-At: Cc: "dmarc@ietf.org" , "Kurt Andersen \(b\)" , ARC Discussion Subject: Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 11 May 2016 22:28:33 -0000 --001a1147d2b2aa34a60532988fc6 Content-Type: text/plain; charset=UTF-8 On Wed, May 11, 2016 at 9:54 AM, Alessandro Vesely wrote: > > [... assume ARC-Seal: i=0 still verifies ...] > > >>> ARC-0 is substantially equivalent to a weak signature. The ARC-Seal > >>> field proves that the originator was involved. ARC-Message-Signature > >>> is expected to be broken by forwarders. ARC-Authentication-Results may > >>> contain just an auth stanza, with a possibly redacted authenticated > >>> identity. > >> > >> Doesn't the i=1 ARC set also prove the originator was involved? > > No, it doesn't. > Could you say why not? It seems to me the i=1 ARC set is validating the message authentication provided by the originator. That seems to qualify to me as "involved" on the part of the originator. > > Yes, AS[1] testifies to the Authenticated-Results of receiving the > message > > from the originator. > > That only proves the first receiver was involved. A final receiver may > trust > its results or not. > What is the first receiver reporting if not the authentication claims made by the originator? Confused, -MSK --001a1147d2b2aa34a60532988fc6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, May 11, 2016 at 9:54 AM, Alessandro Vesely <vesely@t= ana.it> wrote:

[... assume ARC-Seal: i=3D0 still verifies ...]

>>> ARC-0 is substantially equivalent to a weak signature.=C2=A0 T= he ARC-Seal
>>> field proves that the originator was involved.=C2=A0 ARC-Messa= ge-Signature
>>> is expected to be broken by forwarders.=C2=A0 ARC-Authenticati= on-Results may
>>> contain just an auth stanza, with a possibly redacted authenti= cated
>>> identity.
>>
>> Doesn't the i=3D1 ARC set also prove the originator was involv= ed?

No, it doesn't.

Could you sa= y why not?=C2=A0 It seems to me the i=3D1 ARC set is validating the message= authentication provided by the originator.=C2=A0 That seems to qualify to = me as "involved" on the part of the originator.
=C2=A0
> Yes, AS[1] testifies to the Authenticated-Results of = receiving the message
> from the originator.

That only proves the first receiver was involved.=C2=A0 A final rece= iver may trust
its results or not.

What is the first r= eceiver reporting if not the authentication claims made by the originator?<= br>
Confused,
-MSK
--001a1147d2b2aa34a60532988fc6-- From nobody Wed May 11 15:37:23 2016 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 AFAA012D73E for ; Wed, 11 May 2016 15:37: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 Mo7-RGfGTila for ; Wed, 11 May 2016 15:37:19 -0700 (PDT) Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.4]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02F7F12D706 for ; Wed, 11 May 2016 15:37:18 -0700 (PDT) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES532.agna.amgreetings.com ([::1]) with mapi id 14.03.0266.001; Wed, 11 May 2016 18:37:17 -0400 From: "MH Michael Hammer (5304)" To: "Murray S. Kucherawy" , Alessandro Vesely Thread-Topic: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone) Thread-Index: AQHRq6XIKi9honnvoEyH7i9tKTJyqZ+0lKYA//+99vA= Date: Wed, 11 May 2016 22:37:16 +0000 Message-ID: References: <20160511002303.14397.qmail@ary.lan> <57327D81.6050306@gmail.com> <57331D94.2010004@tana.it> <573363BB.9030701@tana.it> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.254.232] x-kse-attachmentfiltering-interceptor-info: protection disabled x-kse-serverinfo: USCLES532.agna.amgreetings.com, 9 x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean, bases: 5/11/2016 9:26:00 PM x-kse-dlp-scaninfo: Skipped Content-Type: multipart/alternative; boundary="_000_CE39F90A45FF0C49A1EA229FC9899B052664516AUSCLES544agnaam_" MIME-Version: 1.0 Archived-At: Cc: "Kurt Andersen \(b\)" , "dmarc@ietf.org" , ARC Discussion Subject: Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 11 May 2016 22:37:22 -0000 --_000_CE39F90A45FF0C49A1EA229FC9899B052664516AUSCLES544agnaam_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCkZyb206IGRtYXJjIFttYWlsdG86ZG1hcmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIE11cnJheSBTLiBLdWNoZXJhd3kNClNlbnQ6IFdlZG5lc2RheSwgTWF5IDExLCAyMDE2IDY6 MjkgUE0NClRvOiBBbGVzc2FuZHJvIFZlc2VseQ0KQ2M6IGRtYXJjQGlldGYub3JnOyBLdXJ0IEFu ZGVyc2VuIChiKTsgQVJDIERpc2N1c3Npb24NClN1YmplY3Q6IFJlOiBbZG1hcmMtaWV0Zl0gUHJv cG9zYWwgdG8gYWRvcHQgQVJDIGRvY3VtZW50cyBpbnRvIHRoZSBXRyAodG93YXJkIHBoYXNlIDIg bWlsZXN0b25lKQ0KDQpPbiBXZWQsIE1heSAxMSwgMjAxNiBhdCA5OjU0IEFNLCBBbGVzc2FuZHJv IFZlc2VseSA8dmVzZWx5QHRhbmEuaXQ8bWFpbHRvOnZlc2VseUB0YW5hLml0Pj4gd3JvdGU6DQoN ClsuLi4gYXNzdW1lIEFSQy1TZWFsOiBpPTAgc3RpbGwgdmVyaWZpZXMgLi4uXQ0KDQo+Pj4gQVJD LTAgaXMgc3Vic3RhbnRpYWxseSBlcXVpdmFsZW50IHRvIGEgd2VhayBzaWduYXR1cmUuICBUaGUg QVJDLVNlYWwNCj4+PiBmaWVsZCBwcm92ZXMgdGhhdCB0aGUgb3JpZ2luYXRvciB3YXMgaW52b2x2 ZWQuICBBUkMtTWVzc2FnZS1TaWduYXR1cmUNCj4+PiBpcyBleHBlY3RlZCB0byBiZSBicm9rZW4g YnkgZm9yd2FyZGVycy4gIEFSQy1BdXRoZW50aWNhdGlvbi1SZXN1bHRzIG1heQ0KPj4+IGNvbnRh aW4ganVzdCBhbiBhdXRoIHN0YW56YSwgd2l0aCBhIHBvc3NpYmx5IHJlZGFjdGVkIGF1dGhlbnRp Y2F0ZWQNCj4+PiBpZGVudGl0eS4NCj4+DQo+PiBEb2Vzbid0IHRoZSBpPTEgQVJDIHNldCBhbHNv IHByb3ZlIHRoZSBvcmlnaW5hdG9yIHdhcyBpbnZvbHZlZD8NCg0KTm8sIGl0IGRvZXNuJ3QuDQoN CkNvdWxkIHlvdSBzYXkgd2h5IG5vdD8gIEl0IHNlZW1zIHRvIG1lIHRoZSBpPTEgQVJDIHNldCBp cyB2YWxpZGF0aW5nIHRoZSBtZXNzYWdlIGF1dGhlbnRpY2F0aW9uIHByb3ZpZGVkIGJ5IHRoZSBv cmlnaW5hdG9yLiAgVGhhdCBzZWVtcyB0byBxdWFsaWZ5IHRvIG1lIGFzICJpbnZvbHZlZCIgb24g dGhlIHBhcnQgb2YgdGhlIG9yaWdpbmF0b3IuDQoNCk1IOiBJcyBpdCBub3QgcG9zc2libGUgZm9y IGk9MSBBUkMgc2V0IHRvIGZvcmdlIHRoZSDigJx2YWxpZGF0aW9u4oCdIG9mIHRoZSBtZXNzYWdl IGF1dGhlbnRpY2F0aW9uIHB1cnBvcnRlZGx5IHByb3ZpZGVkIGJ5IHRoZSBwdXJwb3J0ZWQgb3Jp Z2luYXRvcj8NCg0KDQo+IFllcywgQVNbMV0gdGVzdGlmaWVzIHRvIHRoZSBBdXRoZW50aWNhdGVk LVJlc3VsdHMgb2YgcmVjZWl2aW5nIHRoZSBtZXNzYWdlDQo+IGZyb20gdGhlIG9yaWdpbmF0b3Iu DQoNClRoYXQgb25seSBwcm92ZXMgdGhlIGZpcnN0IHJlY2VpdmVyIHdhcyBpbnZvbHZlZC4gIEEg ZmluYWwgcmVjZWl2ZXIgbWF5IHRydXN0DQppdHMgcmVzdWx0cyBvciBub3QuDQoNCldoYXQgaXMg dGhlIGZpcnN0IHJlY2VpdmVyIHJlcG9ydGluZyBpZiBub3QgdGhlIGF1dGhlbnRpY2F0aW9uIGNs YWltcyBtYWRlIGJ5IHRoZSBvcmlnaW5hdG9yPw0KDQpNSDogVGhlIGZpcnN0IHJlY2VpdmVyIGlz IGFzc2VydGluZyBhdXRoZW50aWNhdGlvbiBjbGFpbXMgYnkgdGhlIHB1cnBvcnRlZCBvcmlnaW5h dG9yLiBUaGF0IGlzIG5vdCB0aGUgc2FtZSB0aGluZyBhcyB2YWxpZGF0aW5nICh2ZXJpZmlhYmxl KSBhdXRoZW50aWNhdGlvbiBjbGFpbXMgYnkgdGhlIG9yaWdpbmF0b3IuDQpDb25mdXNlZCwNCi1N U0sNCg== --_000_CE39F90A45FF0C49A1EA229FC9899B052664516AUSCLES544agnaam_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzow aW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IGRtYXJjIFttYWlsdG86ZG1hcmMt Ym91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+TXVycmF5IFMuIEt1Y2hlcmF3 eTxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIE1heSAxMSwgMjAxNiA2OjI5IFBNPGJyPg0K PGI+VG86PC9iPiBBbGVzc2FuZHJvIFZlc2VseTxicj4NCjxiPkNjOjwvYj4gZG1hcmNAaWV0Zi5v cmc7IEt1cnQgQW5kZXJzZW4gKGIpOyBBUkMgRGlzY3Vzc2lvbjxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW2RtYXJjLWlldGZdIFByb3Bvc2FsIHRvIGFkb3B0IEFSQyBkb2N1bWVudHMgaW50byB0 aGUgV0cgKHRvd2FyZCBwaGFzZSAyIG1pbGVzdG9uZSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBNYXkgMTEsIDIwMTYgYXQgOTo1 NCBBTSwgQWxlc3NhbmRybyBWZXNlbHkgJmx0OzxhIGhyZWY9Im1haWx0bzp2ZXNlbHlAdGFuYS5p dCIgdGFyZ2V0PSJfYmxhbmsiPnZlc2VseUB0YW5hLml0PC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 YnI+DQpbLi4uIGFzc3VtZSBBUkMtU2VhbDogaT0wIHN0aWxsIHZlcmlmaWVzIC4uLl08YnI+DQo8 YnI+DQomZ3Q7Jmd0OyZndDsgQVJDLTAgaXMgc3Vic3RhbnRpYWxseSBlcXVpdmFsZW50IHRvIGEg d2VhayBzaWduYXR1cmUuJm5ic3A7IFRoZSBBUkMtU2VhbDxicj4NCiZndDsmZ3Q7Jmd0OyBmaWVs ZCBwcm92ZXMgdGhhdCB0aGUgb3JpZ2luYXRvciB3YXMgaW52b2x2ZWQuJm5ic3A7IEFSQy1NZXNz YWdlLVNpZ25hdHVyZTxicj4NCiZndDsmZ3Q7Jmd0OyBpcyBleHBlY3RlZCB0byBiZSBicm9rZW4g YnkgZm9yd2FyZGVycy4mbmJzcDsgQVJDLUF1dGhlbnRpY2F0aW9uLVJlc3VsdHMgbWF5PGJyPg0K Jmd0OyZndDsmZ3Q7IGNvbnRhaW4ganVzdCBhbiBhdXRoIHN0YW56YSwgd2l0aCBhIHBvc3NpYmx5 IHJlZGFjdGVkIGF1dGhlbnRpY2F0ZWQ8YnI+DQomZ3Q7Jmd0OyZndDsgaWRlbnRpdHkuPGJyPg0K Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBEb2Vzbid0IHRoZSBpPTEgQVJDIHNldCBhbHNvIHByb3Zl IHRoZSBvcmlnaW5hdG9yIHdhcyBpbnZvbHZlZD88YnI+DQo8YnI+DQpObywgaXQgZG9lc24ndC48 bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkNvdWxkIHlvdSBzYXkgd2h5IG5vdD8mbmJzcDsgSXQgc2VlbXMgdG8gbWUgdGhlIGk9MSBB UkMgc2V0IGlzIHZhbGlkYXRpbmcgdGhlIG1lc3NhZ2UgYXV0aGVudGljYXRpb24gcHJvdmlkZWQg YnkgdGhlIG9yaWdpbmF0b3IuJm5ic3A7IFRoYXQgc2VlbXMgdG8gcXVhbGlmeSB0byBtZSBhcyAm cXVvdDtpbnZvbHZlZCZxdW90OyBvbiB0aGUgcGFydCBvZiB0aGUgb3JpZ2luYXRvci48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NSDogSXMgaXQgbm90IHBvc3NpYmxlIGZv ciBpPTEgQVJDIHNldCB0byBmb3JnZSB0aGUg4oCcdmFsaWRhdGlvbuKAnSBvZiB0aGUgbWVzc2Fn ZSBhdXRoZW50aWNhdGlvbiBwdXJwb3J0ZWRseSBwcm92aWRlZCBieSB0aGUgcHVycG9ydGVkIG9y aWdpbmF0b3I/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJy Pg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mZ3Q7IFllcywgQVNbMV0gdGVzdGlmaWVzIHRvIHRoZSBBdXRoZW50aWNhdGVk LVJlc3VsdHMgb2YgcmVjZWl2aW5nIHRoZSBtZXNzYWdlPGJyPg0KJmd0OyBmcm9tIHRoZSBvcmln aW5hdG9yLjxicj4NCjxicj4NClRoYXQgb25seSBwcm92ZXMgdGhlIGZpcnN0IHJlY2VpdmVyIHdh cyBpbnZvbHZlZC4mbmJzcDsgQSBmaW5hbCByZWNlaXZlciBtYXkgdHJ1c3Q8YnI+DQppdHMgcmVz dWx0cyBvciBub3QuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPldoYXQgaXMgdGhl IGZpcnN0IHJlY2VpdmVyIHJlcG9ydGluZyBpZiBub3QgdGhlIGF1dGhlbnRpY2F0aW9uIGNsYWlt cyBtYWRlIGJ5IHRoZSBvcmlnaW5hdG9yPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TUg6IFRoZSBmaXJzdCByZWNlaXZlciBpcyBh c3NlcnRpbmcgYXV0aGVudGljYXRpb24gY2xhaW1zIGJ5IHRoZSBwdXJwb3J0ZWQgb3JpZ2luYXRv ci4gVGhhdCBpcyBub3QgdGhlIHNhbWUgdGhpbmcgYXMgdmFsaWRhdGluZw0KICh2ZXJpZmlhYmxl KSBhdXRoZW50aWNhdGlvbiBjbGFpbXMgYnkgdGhlIG9yaWdpbmF0b3IuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q29uZnVzZWQsPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tTVNLPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CE39F90A45FF0C49A1EA229FC9899B052664516AUSCLES544agnaam_-- From nobody Wed May 11 15:50:43 2016 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 1D31D12D19E for ; Wed, 11 May 2016 15:50: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 (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 Hz8NUGH5ZOe9 for ; Wed, 11 May 2016 15:50:41 -0700 (PDT) Received: from mail-io0-x242.google.com (mail-io0-x242.google.com [IPv6:2607:f8b0:4001:c06::242]) (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 95E0712B049 for ; Wed, 11 May 2016 15:50:41 -0700 (PDT) Received: by mail-io0-x242.google.com with SMTP id x35so8139273ioi.0 for ; Wed, 11 May 2016 15:50: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:date:message-id:subject :from:to:cc; bh=fjp/RdmvWo+FmfgaP3rUA1hkfu6e2I6K3bnvs0cSJVs=; b=gUpuXDO8ZuYEjZ44Flqd2qcgvOSHniIGqYJT89D8f/CDNt3nRq6xAD8pH5GpX7cswC 5K96W/uNMK3ke8+RC8QXuUf/1lr6hXOconU1PDcWcDsTHHKzLPKQk38OwdTrAzZzM3z3 d/c89YThFTgzJfB95Z1CsovKSEcQPY8LXuSBk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=fjp/RdmvWo+FmfgaP3rUA1hkfu6e2I6K3bnvs0cSJVs=; b=AC4VISmncKF0yr+OySCssugXVJoLJX8FQns+O/aQeGGqIGHsNjk+ONk/g7rX5IfL/u XqiLXMhk09t5hGTNbnak3AjxYgzxnA+AJU9ti+sfUpNylRam4zZ7gZTlKj/SEBm1KVFg w7YUH4YjiJkoqD7Qfk5N7UNj0hJo4+uAFXMEcsEReJnEifK2t35enVMXBjYlF5NlfZ34 SZlv/ep2aWpQVz2P2jc+BMsorZqgjrpkJXVhoE/XD1rp11PK72nY6XXvIEWgRjhgYrUu POS0VjQMRLSXMWKBID4agtAlZXGQYjVM0Jq/W25BM/y4N5tnEXAGEoeHU/kXtkSGJuzC 4IFA== X-Gm-Message-State: AOPr4FUUmzmOtPpbkRnkcHpLgutwnGly6V3N/1HHrMF9TyuXfTeHNIz7c1eJq46SclUduA0mlP0VxvfTnrhceQ== MIME-Version: 1.0 X-Received: by 10.36.79.150 with SMTP id c144mr4539568itb.28.1463007041000; Wed, 11 May 2016 15:50:41 -0700 (PDT) Sender: kurta@drkurt.com Received: by 10.107.20.202 with HTTP; Wed, 11 May 2016 15:50:40 -0700 (PDT) In-Reply-To: References: <20160511002303.14397.qmail@ary.lan> <57327D81.6050306@gmail.com> <57331D94.2010004@tana.it> <573363BB.9030701@tana.it> Date: Wed, 11 May 2016 15:50:40 -0700 X-Google-Sender-Auth: EHdMqykOU-ajCCgdWSQW-zgnicQ Message-ID: From: "Kurt Andersen (b)" To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=001a11447e52fba759053298de0c Archived-At: Cc: "Murray S. Kucherawy" , "MH Michael Hammer \(5304\)" , Alessandro Vesely Subject: Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 11 May 2016 22:50:43 -0000 --001a11447e52fba759053298de0c Content-Type: text/plain; charset=UTF-8 Might I suggest that this somewhat lengthy digression from the identified subject of the thread should move to another thread (unique subject line)? --Kurt --001a11447e52fba759053298de0c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Might I suggest that this somew= hat lengthy digression from the identified subject of the thread should mov= e to another thread (unique subject line)?
=
--Kurt
<= br>

--001a11447e52fba759053298de0c-- From nobody Wed May 11 19:15:10 2016 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 DB7DE12D0D8 for ; Wed, 11 May 2016 19:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_12LTRDOM=0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rolandturner.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 lTGvsIvuXw3n for ; Wed, 11 May 2016 19:15:06 -0700 (PDT) Received: from sg.rolandturner.com (sg.rolandturner.com [175.41.138.242]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8120F12B02B for ; Wed, 11 May 2016 19:15:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=rolandturner.com; s=20120325; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=EBaLHFU/ozjrQ7PewHnnbzuJFujBiCFlsoLe39l4K9g=; b=GJdeZebslo0XeoU+sgM1E4+ENwXkdcQWv2uhbiP+6QIDpIn9ZRT2PXbnqoBN61QXO2Niyw+1gpMIrEJ4tRNq4wdbeOYQ6zh8CvJRTWb0AHAmNK3UXFGIqyakDy+maGx13SB5HlshJSNhGN2c5aov0OwNFtHOVrAWoVKdPMGSSDA=; Received: from [116.12.149.133] (port=58755 helo=[10.100.1.125]) by sg.rolandturner.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1b0g9R-0006Ek-0h; Thu, 12 May 2016 02:14:57 +0000 To: "Kurt Andersen (b)" , "Murray S. Kucherawy" References: <20160511002303.14397.qmail@ary.lan> <57327D81.6050306@gmail.com> <57331D94.2010004@tana.it> From: Roland Turner Message-ID: <5733E720.3030706@rolandturner.com> Date: Thu, 12 May 2016 10:14:56 +0800 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------070905040300000405040009" Archived-At: Cc: "dmarc@ietf.org" , Alessandro Vesely , ARC Discussion Subject: [dmarc-ietf] Independent origination and AS[0] (Re: [arc-discuss] Proposal to adopt ARC documents into the WG (toward phase 2 milestone)) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 12 May 2016 02:15:09 -0000 This is a multi-part message in MIME format. --------------070905040300000405040009 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 05/11/2016 11:29 PM, Kurt Andersen (b) via arc-discuss wrote: > The concept of an AS[0] set of headers was debated and deemed, as > suggested by Murray, Oh! I've missed this. Did it happen on arc-discuss, or elsewhere? (I've not seen it on the list, and a quick scan of Murray's posts in the archive turned up nothing.) > to just be a repetition of the DKIM signature assertion. As such, it > doesn't really add any utility. I disagree. This is comparable to claiming that Arc-Seals generally are just repetitions of assertions that could be made with DKIM. In a limited sense this is true, but having a well-specified set of rules for chaining these assertions appears to be valuable, which is much of the rationale for introducing ARC in the first place. The same reasoning applies to an assertion by an independent originator. > There have been suggestions on the arc-discuss list that, perhaps, > AS[0] could be used as an assertion "on behalf of" some other domain > that the message submitter was known to the sending ADMD Right, this is the independent origination case (e.g. Gmail "send as my work address", ESPs, ...), that is currently glaringly unaddressed. > (as mentioned below under "authenticated identity"). The biggest > problem with that, is whether anyone should trust such purported > authentication claims. Sure, but that's _*exactly*_ the same problem as trusting ARC forwarders' claims in the first place. The question that a receiver is asking, of every step in the chain (and after verifying the mechanical aspects of signature verification) is whether they trust the party whose key was used to make the signature to make the assertion that's being made. Failure to support independent origination explicitly (I've suggested cv=I to the same end previously) invites ad hoc arrangements, or simply outright false AS[1] assertions. (In the context of establishing consensus around a spec, there is a particularly idiotic response to the latter action, which is to declare wrong-doing and assume that all such messages can be discarded, which ignores a significant fraction of the real-world problem that ARC is being developed to address.) > > Doesn't the i=1 ARC set also prove the originator was involved? > > > Yes, AS[1] testifies to the Authenticated-Results of receiving the > message from the originator. That's actually a "no". AS[1] permits a receiver (or other assessor) to determine with some confidence that the putative signer made such an assertion about the putative originator, it provides no information about the involvement of the putative originator except to the extent that the assessor additionally trusts the assertions of the putative signer. Decisions to trust are necessarily outside the specification. This argument applies equivalently to AS[0] independent origination scenarios and to AS[>0] forwarding scenarios. - Roland --------------070905040300000405040009 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 05/11/2016 11:29 PM, Kurt Andersen (b) via arc-discuss wrote:

The concept of an AS[0] set of headers was debated and deemed, as suggested by Murray,

Oh! I've missed this. Did it happen on arc-discuss, or elsewhere? (I've not seen it on the list, and a quick scan of Murray's posts in the archive turned up nothing.)

to just be a repetition of the DKIM signature assertion. As such, it doesn't really add any utility.

I disagree. This is comparable to claiming that Arc-Seals generally are just repetitions of assertions that could be made with DKIM. In a limited sense this is true, but having a well-specified set of rules for chaining these assertions appears to be valuable, which is much of the rationale for introducing ARC in the first place. The same reasoning applies to an assertion by an independent originator.

There have been suggestions on the arc-discuss list that, perhaps, AS[0] could be used as an assertion "on behalf of" some other domain that the message submitter was known to the sending ADMD

Right, this is the independent origination case (e.g. Gmail "send as my work address", ESPs, ...), that is currently glaringly unaddressed.

(as mentioned below under "authenticated identity"). The biggest problem with that, is whether anyone should trust such purported authentication claims.

Sure, but that's exactly the same problem as trusting ARC forwarders' claims in the first place. The question that a receiver is asking, of every step in the chain (and after verifying the mechanical aspects of signature verification) is whether they trust the party whose key was used to make the signature to make the assertion that's being made.

Failure to support independent origination explicitly (I've suggested cv=I to the same end previously) invites ad hoc arrangements, or simply outright false AS[1] assertions. (In the context of establishing consensus around a spec, there is a particularly idiotic response to the latter action, which is to declare wrong-doing and assume that all such messages can be discarded, which ignores a significant fraction of the real-world problem that ARC is being developed to address.)


Doesn't the i=1 ARC set also prove the originator was involved?

Yes, AS[1] testifies to the Authenticated-Results of receiving the message from the originator.

That's actually a "no". AS[1] permits a receiver (or other assessor) to determine with some confidence that the putative signer made such an assertion about the putative originator, it provides no information about the involvement of the putative originator except to the extent that the assessor additionally trusts the assertions of the putative signer. Decisions to trust are necessarily outside the specification. This argument applies equivalently to AS[0] independent origination scenarios and to AS[>0] forwarding scenarios.

- Roland

--------------070905040300000405040009-- From nobody Wed May 11 19:19:53 2016 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 0508A12D0D8 for ; Wed, 11 May 2016 19:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.996 X-Spam-Level: X-Spam-Status: No, score=-2.996 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, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rolandturner.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 XrfplHFYgRNn for ; Wed, 11 May 2016 19:19:50 -0700 (PDT) Received: from sg.rolandturner.com (sg.rolandturner.com [175.41.138.242]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD0F412D0B6 for ; Wed, 11 May 2016 19:19:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=rolandturner.com; s=20120325; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=xkRgT0KuNEuEW7bTpkOTVc+n7x9KKku9HJjsvRhHkno=; b=YVmQAWWTMMAsd9djS8rsYJoHXHy0oXkB/c3YlHrM9XfeVBXne0jy55RkEGiovGbPthKM0B6RyvcKCRxmm3T4Y6Dh7un+yeI2BxfCizKIZZ30fBzD9Q9UFxnOLm0KCTjhTCHJQW+1JIg3dJnADhsMpfL1cJec4n0p5qpYOvmrI6A=; Received: from [116.12.149.133] (port=58761 helo=[10.100.1.125]) by sg.rolandturner.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1b0gE6-0006FX-NG; Thu, 12 May 2016 02:19:46 +0000 To: "Murray S. Kucherawy" , Alessandro Vesely References: <20160511002303.14397.qmail@ary.lan> <57327D81.6050306@gmail.com> <57331D94.2010004@tana.it> <573363BB.9030701@tana.it> From: Roland Turner Message-ID: <5733E842.8020208@rolandturner.com> Date: Thu, 12 May 2016 10:19:46 +0800 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------040404080706030900000506" Archived-At: Cc: "Kurt Andersen \(b\)" , "dmarc@ietf.org" , ARC Discussion Subject: Re: [dmarc-ietf] [arc-discuss] Proposal to adopt ARC documents into the WG (toward phase 2 milestone) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 12 May 2016 02:19:52 -0000 This is a multi-part message in MIME format. --------------040404080706030900000506 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 05/12/2016 06:28 AM, Murray S. Kucherawy via arc-discuss wrote: > On Wed, May 11, 2016 at 9:54 AM, Alessandro Vesely > wrote: > > > >> Doesn't the i=1 ARC set also prove the originator was involved? > > No, it doesn't. > > > Could you say why not? It seems to me the i=1 ARC set is validating > the message authentication provided by the originator. That seems to > qualify to me as "involved" on the part of the originator. I'd suggest not. AS[1] permits a receiver (or other assessor) to determine with some confidence that the putative signer made such an assertion about the putative originator, it provides no information about the involvement of the putative originator except to the extent that the assessor additionally trusts the assertions of the putative signer. Decisions to trust are necessarily outside the specification. This argument applies equivalently to AS[0] independent origination scenarios and to AS[>0] forwarding scenarios. > > Yes, AS[1] testifies to the Authenticated-Results of receiving the message > > from the originator. > > That only proves the first receiver was involved. A final receiver > may trust > its results or not. > > > What is the first receiver reporting if not the authentication claims > made by the originator? They could equally be reporting fraudulent claims in order to defeat email security systems at (a) downstream receiver(s). - Roland --------------040404080706030900000506 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 05/12/2016 06:28 AM, Murray S. Kucherawy via arc-discuss wrote:

On Wed, May 11, 2016 at 9:54 AM, Alessandro Vesely <vesely@tana.it> wrote:

>> Doesn't the i=1 ARC set also prove the originator was involved?

No, it doesn't.

Could you say why not?  It seems to me the i=1 ARC set is validating the message authentication provided by the originator.  That seems to qualify to me as "involved" on the part of the originator.

I'd suggest not. AS[1] permits a receiver (or other assessor) to determine with some confidence that the putative signer made such an assertion about the putative originator, it provides no information about the involvement of the putative originator except to the extent that the assessor additionally trusts the assertions of the putative signer. Decisions to trust are necessarily outside the specification. This argument applies equivalently to AS[0] independent origination scenarios and to AS[>0] forwarding scenarios.

> Yes, AS[1] testifies to the Authenticated-Results of receiving the message
> from the originator.

That only proves the first receiver was involved.  A final receiver may trust
its results or not.

What is the first receiver reporting if not the authentication claims made by the originator?

They could equally be reporting fraudulent claims in order to defeat email security systems at (a) downstream receiver(s).

- Roland

--------------040404080706030900000506-- From nobody Wed May 11 22:47:40 2016 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 CD58D12D13A for ; Wed, 11 May 2016 22:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.895 X-Spam-Level: X-Spam-Status: No, score=-2.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RP_MATCHES_RCVD=-0.996] 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 14bhmqzS_jRF for ; Wed, 11 May 2016 22:47:36 -0700 (PDT) Received: from turnbull.sk.tsukuba.ac.jp (turnbull.sk.tsukuba.ac.jp [130.158.96.25]) (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 1D06B12D0C5 for ; Wed, 11 May 2016 22:47:35 -0700 (PDT) Received: from steve by turnbull.sk.tsukuba.ac.jp with local (Exim 4.87) (envelope-from ) id 1b0jTU-0001nA-Ct; Thu, 12 May 2016 14:47:52 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22324.6408.365758.858945@turnbull.sk.tsukuba.ac.jp> Date: Thu, 12 May 2016 14:47:52 +0900 From: "Stephen J. Turnbull" To: Roland Turner In-Reply-To: <5733E720.3030706@rolandturner.com> References: <20160511002303.14397.qmail@ary.lan> <57327D81.6050306@gmail.com> <57331D94.2010004@tana.it> <5733E720.3030706@rolandturner.com> X-Mailer: VM 8.2.0b under 21.5 (beta34) "kale" e1ed68423813 XEmacs Lucid (x86_64-apple-darwin15.4.0) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: steve@turnbull.sk.tsukuba.ac.jp X-SA-Exim-Scanned: No (on turnbull.sk.tsukuba.ac.jp); SAEximRunCond expanded to false Archived-At: Cc: "dmarc@ietf.org" , "Kurt Andersen \(b\)" , "Murray S. Kucherawy" , Alessandro Vesely Subject: [dmarc-ietf] Independent origination and AS[0] X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 12 May 2016 05:47:39 -0000 I believe this thread has moved to "dmarc", so "arc-discuss" has been removed. Roland Turner writes: > > (as mentioned below under "authenticated identity"). The biggest > > problem with that, is whether anyone should trust such purported > > authentication claims. > > Sure, but that's _*exactly*_ the same problem as trusting ARC > forwarders' claims in the first place. In a particular formal sense, perhaps. But an ARC assertion is an assertion that certain data have been *validated*. An originator assertion is an assertion that certain data is *authentic*. The assertions are different in *kind*, and therefore the trust decision is a different problem (requires different data and balances different risks). ARC doesn't help with authenticity, as you yourself have been at pains to explain. Trying to stretch it to do so is a bad idea (at least from the point of view of mailing list owners). > Failure to support independent origination explicitly (I've > suggested cv=I to the same end previously) invites ad hoc > arrangements, That may be true, but IMO it's out of scope for ARC. It should be done in DKIM or DMARC. ARC currently is very easy to interpret: a third party asserts that it validated some data provided by an earlier party in the chain (possibly but not always the originator). Let's not muddy it with assertions that belong to an originator protocol. Steve From nobody Thu May 12 00:28:52 2016 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 C5A3212D875 for ; Thu, 12 May 2016 00:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.298 X-Spam-Level: X-Spam-Status: No, score=-5.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-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=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUtmuu8Yzxaa for ; Thu, 12 May 2016 00:28:48 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D601712D561 for ; Thu, 12 May 2016 00:28:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1463038122; bh=OiREMxfEC2sJ5DGtRDY8CWVrqQ/jLrqdSnkj8+DFf44=; l=1432; h=To:References:Cc:From:Date:In-Reply-To; b=PqHgc3CGsNeKgGujNsTUXDfvZjlhWu04w/cEZ2B4uU/yspSprNbUo5LE7eLKn6fm2 dYrpUQaDRq70W/9O32+9jdWC1Kq05pXHfBDXS+lD7ptEmBzXqEs1r1E/RKkHt968UM BLtCNoB7ZCiLXV/gBq4z87ezmDP+iY0OAe2/Q8f0= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.88] (pcale.tana [172.25.197.88]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Thu, 12 May 2016 09:28:42 +0200 id 00000000005DC042.00000000573430AA.0000132B To: "Kurt Andersen (b)" References: From: Alessandro Vesely Message-ID: <573430A9.8080207@tana.it> Date: Thu, 12 May 2016 09:28:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: "dmarc@ietf.org" , "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 12 May 2016 07:28:50 -0000 On Wed 11/May/2016 22:35:29 +0200 Kurt Andersen (b) wrote: > On Wed, May 11, 2016 at 11:40 AM, Alessandro Vesely wrote: > >> If the body was altered the original DKIM-Signature is broken. If AS(0) is >> good --which is possible since it didn't sign the body-- and rfc5322.from >> matches the AS(0) signer, can we then bypass DMARC validation? To address >> Brandon's concern, high value targets should never produce an AS(0) in the >> first place. > > AS[0] will not be "good" in the way you propose because nearly all of the > transformations that will break DKIM will also break the AMS > (ARC-Message-Signature) and, per > https://tools.ietf.org/html/draft-andersen-arc-04#section-5.1.1.5 bullet 3, > AMS must pass for the overall ARC set to be considered valid. That requirement is not necessarily about AMS(0). It can be AMS(i), i > 0. (Indeed, the current spec contemplates i > 0 only.) > I'd like to respectfully suggest that "bypassing DMARC validation" is > pretty far out of scope for what we've intended with ARC. Yet, I share the feeling which originated this thread, namely that ARC can do more than validate email address portability (via forwarding) among a private group of huge mailbox providers. If a single solution can be used for both solving DMARC's indirect mail flows problem and participating in safe forwarding, that can make life easier for mail system maintainers. Ale From nobody Thu May 12 14:25:03 2016 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 602B112D0A3 for ; Thu, 12 May 2016 14:25:01 -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 XtFlF0zdm0Gh for ; Thu, 12 May 2016 14:24:59 -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 A73AA12B05A for ; Thu, 12 May 2016 14:24:59 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id o66so96560481ywc.3 for ; Thu, 12 May 2016 14:24:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=FOJotU9J5TqAmmXpC3y3RTB974QoW3vTTQk233e9EU4=; b=h+uxUjOAFo9tuIGnRgFDh7BijjYcJqZ2tdsJ88RzJ5hOYGguVmHlHWSUYqAxwyZs8t 7bbzaz4MiWEs5ksBivDVeKqawWaHJl3Ow0k6TNe8dikgZhqcB9S+BZ5XncJ+RbLRPETK umx8ZaFjNocWH4wYW8PNCinZ7+SPD/2AWBkYkw6+MblU5qC2SjUyVHRRKQB40/WxWseW kAmNhGnTAQFBxVqJqW8lG/GqY1JS9EfP3RleVre3StisyShzOMzr4A2eueusuCqnGcC3 dz0fPwLrdKf92c79cYDReX4OY9HRKN8oZW3Jt84C834yyY5Lc4zOTyfBL58G/sPHbRIJ H7Jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=FOJotU9J5TqAmmXpC3y3RTB974QoW3vTTQk233e9EU4=; b=U8AuQ/ZUG3KkijqcGkPFnPLYuwHu0JHL+C9RHONPkV5f7C/Ldm2pIy1o50+BeUNX+/ LdIaSsHOim636GUvvbOK0wbUsD3k5kwBc+ZJiyvXfdz6ETqbR8sOF3ioeFZAIhR/CYaC PkkjKwiqNxPcmf8cBBY5XMcvu3B3DVDuTGvqCwThSn63mMVcSpjTouGOopBXPL8sO0jG +tlTKcIWX54r66FJW85NGEm4LGwUARXGErO7MVQYebMOHVXKGts9ZIu6tgc8pA/Rn9i5 KzMjVjWUl3pVi50pgb4Sb58G0o1EOkbZ1zLYlHXfoSWTimtkJ7RAr2tt98/4mADbnrMk 5Qdg== X-Gm-Message-State: AOPr4FWmU7ABOgE1c5Vuz1Ii0Dmxb2IL0JdjzFK9s+XfguKuna+gyBpfKYxeY65VhZX6OBnFlwggAXZTqVsUww== MIME-Version: 1.0 X-Received: by 10.37.65.22 with SMTP id o22mr5020309yba.32.1463088298852; Thu, 12 May 2016 14:24:58 -0700 (PDT) Received: by 10.37.103.215 with HTTP; Thu, 12 May 2016 14:24:58 -0700 (PDT) In-Reply-To: <5733E842.8020208@rolandturner.com> References: <20160511002303.14397.qmail@ary.lan> <57327D81.6050306@gmail.com> <57331D94.2010004@tana.it> <573363BB.9030701@tana.it> <5733E842.8020208@rolandturner.com> Date: Thu, 12 May 2016 14:24:58 -0700 Message-ID: From: "Murray S. Kucherawy" To: Roland Turner Content-Type: multipart/alternative; boundary=001a11c02116540e870532abca3a Archived-At: Cc: "Kurt Andersen \(b\)" , "dmarc@ietf.org" , ARC Discussion , Alessandro Vesely Subject: Re: [dmarc-ietf] [arc-discuss] Proposal to adopt ARC documents into the WG (toward phase 2 milestone) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 12 May 2016 21:25:01 -0000 --001a11c02116540e870532abca3a Content-Type: text/plain; charset=UTF-8 On Wed, May 11, 2016 at 7:19 PM, Roland Turner wrote: > > I'd suggest not. AS[1] permits a receiver (or other assessor) to determine > with some confidence that the putative signer made such an assertion about > the putative originator, it provides no information about the involvement > of the putative originator except to the extent that the assessor > additionally trusts the assertions of the putative signer. Decisions to > trust are necessarily outside the specification. This argument applies > equivalently to AS[0] independent origination scenarios and to AS[>0] > forwarding scenarios. > What would an i=0 ARC Set tell you that the i=1 set does not? As I understand it, an i=0 set would be the author asserting "I validated my own mail, and it was good." How would one consume such an assertion in a meaningful way? > > Yes, AS[1] testifies to the Authenticated-Results of receiving the >> message >> > from the originator. >> >> That only proves the first receiver was involved. A final receiver may >> trust >> its results or not. >> > > What is the first receiver reporting if not the authentication claims made > by the originator? > > > They could equally be reporting fraudulent claims in order to defeat email > security systems at (a) downstream receiver(s). > ...meaning nodes 0 (originator) and 1 are in collusion? Sure, that's possible, but how would requiring an i=0 thwart such an arrangement? -MSK --001a11c02116540e870532abca3a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, May 11, 2016 at 7:19 PM, Roland Turner <r= oland@rolandturner.com> wrote:
=
=20 =20 =20
I'd suggest not. AS[1] permits a receiver (or other assessor) to determine with some confidence that the putative signer made such an assertion about the putative originator, it provides no information about the involvement of the putative originator except to the extent that the assessor additionally trusts the assertions of the putative signer. Decisions to trust are necessarily outside the specification. This argument applies equivalently to AS[0] independent origination scenarios and to AS[>0] forwarding scenarios.

What would an i=3D0 AR= C Set tell you that the i=3D1 set does not?

As I understa= nd it, an i=3D0 set would be the author asserting "I validated my own = mail, and it was good."=C2=A0 How would one consume such an assertion = in a meaningful way?


> Yes, AS[1] testifies to the Authenticated-Results of receiving the message
> from the originator.

That only proves the first receiver was involved.=C2= =A0 A final receiver may trust
its results or not.

What is the first receiver reporting if not the authentication claims made by the originator?

 They could equally be reporting fraudulent claims in order to defeat email security systems at (a) downstream receiver(s).

...meaning nodes 0 (originator) and 1 are in collusion?=C2= =A0 Sure, that's possible, but how would requiring an i=3D0 thwart such= an arrangement?

-MSK

=
--001a11c02116540e870532abca3a-- From nobody Thu May 12 14:57:03 2016 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 E213912B02F for ; Thu, 12 May 2016 14:57:00 -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 l1oKisKMtohP for ; Thu, 12 May 2016 14:56:59 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::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 E062212D171 for ; Thu, 12 May 2016 14:56:58 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id f89so111290813ioi.0 for ; Thu, 12 May 2016 14:56:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:date:message-id:subject:from:to; bh=VQhVXRsu9gQgAa6M4ld4V0RJyDcL4oLjnAyBgJ45xAk=; b=VhrUppSvvm/G82SdTVvOOGjN6nfaVsxIbwh2Pk1EUNVfTiYP1Jb1LP4oi3N2ojet+a +BSdjZVWgDt9evpi3cHiQzQnsSlzPf0Deu0lMYSejhVz7X8DwCkzV+u6FvosT1AWSmJT 6qI0oLXSo6IjPnMGnhJ2D3Hcu4a4+hSIE9ZpY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to; bh=VQhVXRsu9gQgAa6M4ld4V0RJyDcL4oLjnAyBgJ45xAk=; b=HPPAbHim7g7RDDFl3i0KdMdl/Pz/0+sUI1U7Q8jDPoc8WZqInE67ygeYiwqfGfoFd8 +Ggt/gfwa6LbpRxRY7REkUGhxyAjFytWWv0oAHlqbJ5iA1ddniZRqbczEIoI6qo5Mf8I lMWiT03QDlL9dVLTGWcY8VTlXf8QWtDQtz+t8lBfN3O4F5pR+WnpkAsrlx2iCgPJ7xxC HzckOPIVZ0T0QuCgoxLragX9JzQ1TNiSxnep8XheMRPckdQjwnZBr4U3ZJr66WOqSCjP EEaM0yd5OI4a0HxJk0wn8hVxfLYIMdm2ig5elwIthSgehGk4YgIMtv8JGuMhSwJB1DaB AO2w== X-Gm-Message-State: AOPr4FWwv4r4i18l+LZdwKD1TAF4NIJB8ghIEYPDRi1UR5SMFbhSa2M5xa3/lu9FG2jII679uHrm/UaC0/3SGg== MIME-Version: 1.0 X-Received: by 10.107.10.37 with SMTP id u37mr9346289ioi.92.1463090218313; Thu, 12 May 2016 14:56:58 -0700 (PDT) Sender: kurta@drkurt.com Received: by 10.107.20.202 with HTTP; Thu, 12 May 2016 14:56:58 -0700 (PDT) Date: Thu, 12 May 2016 14:56:58 -0700 X-Google-Sender-Auth: owQ3C8doFx0VDUv38uDMtxyelC0 Message-ID: From: "Kurt Andersen (b)" To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=001a113de4dcbce7850532ac3c35 Archived-At: Subject: [dmarc-ietf] Other potential work items for the ARC spec X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 12 May 2016 21:57:01 -0000 --001a113de4dcbce7850532ac3c35 Content-Type: text/plain; charset=UTF-8 Allessandro Veseley had suggested (on the arc-discuss) list that the semantics and construction of the ARC sets could be defined in a generalized DKIM-like recipe. When I had discussed this with Dave Crocker, he pointed out that such an idea would align with the (never quite finalized) DOSETA ( https://datatracker.ietf.org/doc/draft-crocker-doseta-base/) idea and that having both ARC and DKIM as potential instantiations of the abstract concept could be enough to bring DOSETA to realization. --Kurt --001a113de4dcbce7850532ac3c35 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Allessandro Veseley had suggested (on the arc-discuss) lis= t that the semantics and construction of the ARC sets could be defined in a= generalized DKIM-like recipe.

When I had discussed this= with Dave Crocker, he pointed out that such an idea would align with the (= never quite finalized) DOSETA (https://datatracker.ietf.org/doc/draft-crocker-= doseta-base/) idea and that having both ARC and DKIM as potential insta= ntiations of the abstract concept could be enough to bring DOSETA to realiz= ation.

--Kurt
--001a113de4dcbce7850532ac3c35-- From nobody Fri May 13 18:19:51 2016 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 06BCF12B011; Fri, 13 May 2016 18:19:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160514011947.10521.24138.idtracker@ietfa.amsl.com> Date: Fri, 13 May 2016 18:19:47 -0700 Archived-At: Cc: dmarc@ietf.org Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-interoperability-15.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 14 May 2016 01:19:48 -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 of the IETF. Title : Interoperability Issues Between DMARC and Indirect Email Flows Authors : Franck Martin Eliot Lear Tim Draegen Elizabeth Zwicky Kurt Andersen Filename : draft-ietf-dmarc-interoperability-15.txt Pages : 25 Date : 2016-05-13 Abstract: DMARC introduces a mechanism for expressing domain-level policies and preferences for email message validation, disposition, and reporting. The DMARC mechanism can encounter interoperability issues when messages do not flow directly from the author's administrative domain to the final recipients. Collectively these email flows are referred to as indirect email flows. This document describes interoperability issues between DMARC and indirect email flows. Possible methods for addressing interoperability issues are presented. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperability/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dmarc-interoperability-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-interoperability-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 13 18:34:04 2016 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 C92E012D1B5 for ; Fri, 13 May 2016 18:34:02 -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 GKy9m72-doVF for ; Fri, 13 May 2016 18:34:01 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::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 E99CD12D19E for ; Fri, 13 May 2016 18:34:00 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id 190so153303490iow.1 for ; Fri, 13 May 2016 18:34:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=Fr5QbCXTUNaF9VWl4311C7rV8FhOLlahGuTDujAOLyc=; b=AYSz7Y3GDx2HOwG3fBE3frySB4a/8SBOGVxyPil70cEPXgYmkw+c1Ap0JVVATKTSeW QhdALL3me1KbccX1fHwncs5ZSscI5uzna+rxYgJbfOvAmbnI7lZ8bbChdUlVm5kH/VfT cvFihZTTjofpzGKq8fOfRdgcXaHsCBlO/UVHA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Fr5QbCXTUNaF9VWl4311C7rV8FhOLlahGuTDujAOLyc=; b=XaZsY+axUi1tLtgcviXhqS091arwEGFLZsUSi5B2SrXW3RdBZ40ZWFL52XZRWUV1L3 XwDyAlG8pBeEBnABtlwIDaM1H5bkHbxHevdg3lMgTBDV2QTDxv3eLTukS85pyQQOcuH1 jGMLmMbmURa8d1dF/lh/ekvqH0GdCuYht0zSdgLrtGi76GiKTgkF7yRnODFyaYZxtB6N fK1sUeBmjoGvrK8YHdJ5Y6dy1w0pQMYyjhAflinKzo6sn8opjK1/SbgvvHd1d6Vd+LBz bB4hREg47bwstyLAEehHcssZrwXL2v7uVTD70L6g+1D4RAJ8DzMoB45TJ4hMhtv8PiaZ aKvg== X-Gm-Message-State: AOPr4FULBNd5JjFJatT2GhA470FceDoqw4h+gs8wPSnLIG5HK4kn2FrkHS5TchjmGHFxtLZM6BE6wO0dMOGYwA== MIME-Version: 1.0 X-Received: by 10.107.129.75 with SMTP id c72mr13864882iod.102.1463189640308; Fri, 13 May 2016 18:34:00 -0700 (PDT) Received: by 10.107.20.202 with HTTP; Fri, 13 May 2016 18:34:00 -0700 (PDT) In-Reply-To: <01Q01X9IOH1I00005M@mauve.mrochek.com> References: <01Q01X9IOH1I00005M@mauve.mrochek.com> Date: Fri, 13 May 2016 18:34:00 -0700 Message-ID: From: Kurt Andersen To: ned+dmarc@mrochek.com Content-Type: multipart/alternative; boundary=001a113f99b0c008240532c362a0 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Document shepard's review of draft-ietf-dmarc-interoperability-14 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 14 May 2016 01:34:03 -0000 --001a113f99b0c008240532c362a0 Content-Type: text/plain; charset=UTF-8 On Wed, May 11, 2016 at 1:45 PM, wrote: > > For this reason I think it would be a good idea to address these nits > sooner > rather than later. > I have just now posted https://tools.ietf.org/html/draft-ietf-dmarc-interoperability-15 which incorporates the fixes suggested by Ned. The only one that I did not incorporate was the suggestion to reformat the example message in A.2 into a standard DSN (mainly in the interests of time, but also because it may make sense to just drop the appendix altogether). Thank you for the fine-tooth comb treatment! --Kurt Andersen --001a113f99b0c008240532c362a0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, May 11, 2016 at 1:45 PM, <ned+dmarc@mrochek.com> wr= ote:

For this reason I think it would be a good idea to address these nits soone= r
rather than later.

I have just now post= ed =C2=A0https://tools.ietf.org/html/draft-ietf-dmarc-interoperability-15= which incorporates the fixes suggested by Ned. The only one that I did= not incorporate was the suggestion to reformat the example message in A.2 = into a standard DSN (mainly in the interests of time, but also because it m= ay make sense to just drop the appendix altogether).

Thank you for the fine-tooth comb treatment!

--= Kurt Andersen

--001a113f99b0c008240532c362a0-- From nobody Fri May 13 18:52:44 2016 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 09F6212B01E for ; Fri, 13 May 2016 18:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-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=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HxvcbTeIhNTB for ; Fri, 13 May 2016 18:52:41 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53EF912B011 for ; Fri, 13 May 2016 18:52:41 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q0503EF9U8013EPJ@mauve.mrochek.com> for dmarc@ietf.org; Fri, 13 May 2016 18:47:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1463190458; bh=/Tvs9gv7dCUJtBV6XfQrxze2SiEqzlVn/EmfB5pLEwY=; h=From:Cc:Date:Subject:In-reply-to:References:To; b=BPfDqMZ/X55xv0Cy/e8fPReuXMzhKrA60giuesTIZ6aH94K76v83YEnxRD7c3Ghgd H2U9DV/xccGB6zBhhp3rBFlD/sAG8m+Bk2IC34Qay5OzTYpjbQ0saEo4PB3g9MPAUY 1O70jw40tg5NHGudV5ELpDz5TXYrNt2n74knxw7k= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q01WURPJU800005M@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for dmarc@ietf.org; Fri, 13 May 2016 18:47:35 -0700 (PDT) From: ned+dmarc@mrochek.com Message-id: <01Q0503CE4EE00005M@mauve.mrochek.com> Date: Fri, 13 May 2016 18:44:09 -0700 (PDT) In-reply-to: "Your message dated Fri, 13 May 2016 18:34:00 -0700" References: <01Q01X9IOH1I00005M@mauve.mrochek.com> To: Kurt Andersen Archived-At: Cc: "dmarc@ietf.org" , ned+dmarc@mrochek.com Subject: Re: [dmarc-ietf] Document shepard's review of draft-ietf-dmarc-interoperability-14 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 14 May 2016 01:52:43 -0000 > On Wed, May 11, 2016 at 1:45 PM, wrote: > > > > For this reason I think it would be a good idea to address these nits > > sooner > > rather than later. > > > I have just now posted > https://tools.ietf.org/html/draft-ietf-dmarc-interoperability-15 which > incorporates the fixes suggested by Ned. The only one that I did not > incorporate was the suggestion to reformat the example message in A.2 into > a standard DSN (mainly in the interests of time, but also because it may > make sense to just drop the appendix altogether). It's by no means essential to do that. > Thank you for the fine-tooth comb treatment! No problem! Ned From nobody Sun May 15 07:41:37 2016 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 B3F2D12B074 for ; Sun, 15 May 2016 07:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.416 X-Spam-Level: X-Spam-Status: No, score=-3.416 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, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rolandturner.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 6hJqaWVCXw8j for ; Sun, 15 May 2016 07:41:34 -0700 (PDT) Received: from sg.rolandturner.com (sg.rolandturner.com [175.41.138.242]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7205128B44 for ; Sun, 15 May 2016 07:41:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=rolandturner.com; s=20120325; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=Ocl/fSyzbdTmMW9c1PyTmFpUPSxYU+exdf+gi6abOsg=; b=aai47OEJxXQDeZ8ZyZtakWPgOBTAlcgXUbwJrXa762hiqcx6imb7j6w7QBE40iU8gwwoAUV4Nspqeh0InY1JLuVTv7TZUeRfs3DOVjIUGmlDaO7nzOrY5gjjTffxNNKM3GFaXbovkI31l6Wlk7qWw/jMLOKuXYMWJ6a0bE7ezAo=; Received: from [202.156.169.29] (port=44547 helo=[10.179.69.102]) by sg.rolandturner.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1b1xEW-0002VA-Gj; Sun, 15 May 2016 14:41:28 +0000 To: "Murray S. Kucherawy" References: <20160511002303.14397.qmail@ary.lan> <57327D81.6050306@gmail.com> <57331D94.2010004@tana.it> <573363BB.9030701@tana.it> <5733E842.8020208@rolandturner.com> From: Roland Turner Message-ID: <57388A97.1090107@rolandturner.com> Date: Sun, 15 May 2016 22:41:27 +0800 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------090908030200030200080303" Archived-At: Cc: "Kurt Andersen \(b\)" , "dmarc@ietf.org" , ARC Discussion , Alessandro Vesely Subject: [dmarc-ietf] Third-party Origination (Re: [arc-discuss] Proposal to adopt ARC documents into the WG (toward phase 2 milestone)) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2016 14:41:36 -0000 This is a multi-part message in MIME format. --------------090908030200030200080303 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 05/13/2016 05:24 AM, Murray S. Kucherawy wrote: > On Wed, May 11, 2016 at 7:19 PM, Roland Turner > > wrote: > > > I'd suggest not. AS[1] permits a receiver (or other assessor) to > determine with some confidence that the putative signer made such > an assertion about the putative originator, it provides no > information about the involvement of the putative originator > except to the extent that the assessor additionally trusts the > assertions of the putative signer. Decisions to trust are > necessarily outside the specification. This argument applies > equivalently to AS[0] independent origination scenarios and to > AS[>0] forwarding scenarios. > > > What would an i=0 ARC Set tell you that the i=1 set does not? > > As I understand it, an i=0 set would be the author asserting "I > validated my own mail, and it was good." How would one consume such > an assertion in a meaningful way? (Note that during writing the following, my stance has changed. I'd now recommend the registration of a new 7601.Method instead of specifying a special interpretation for AS[0].) In the specific case which I see as relevant - that of third-party origination - an i=0 set would be a 5598.Originator asserting that it had a good faith belief that it was acting on behalf of an Author who has legitimate use of the domain-name/email-address, despite the fact that no available Method can be used to substantiate that claim. Typical cases for this good faith to belief to arise would include at least: * ESPs acting on behalf of [typically] smaller customers who haven't gotten their SPF include: and/or DKIM CNAMEs created correctly, and * webmail services sending with an email address in another domain that a user has claimed and demonstrated control of (or at least the ability to receive messages at). For a receiver, the ability to tell the difference between: * "we're forwarding this message that we think is probably OK, although we received it via SMTP and it passed no authentication mechanisms", and * "we originated this message on behalf of a customer or user with a good faith belief that their use of the domain-name/email-address is legitimate" would be useful in cases where (and while) the receiver trusted the Originator's practices in this respect, particularly where a statistical model was otherwise flagging the message as borderline. It might reasonably be objected that a DKIM signature by the Originator alone would achieve the same result, however 7601 2.7.1 makes clear that DKIM passes need only be reported in Authentication-Results: headers (and therefore only appear in ARC-Authentication-Results headers) where they are acceptable to the reporting ADMD, and specifically offers as an example the case where "an ADMD policy might require that the signature(s) on the message be added using the DNS domain present in the From header field of the message, thus making third-party signatures unacceptable even if they verify", meaning that a third-party Originator cannot rely upon an ARC-signing forwarder to convey this information. As a practical matter, an ARC-signing forwarder could also throw away the existing chain and start a new one if it wished, however this is not an expected mode of operation, while DKIM validators being choosy about what they validate and/or report certainly is. An interesting alternative would be to amend 7601 to require the reporting of all DKIM results and to disregard the fact that some DKIM implementations simply won't, although this does not seem ideal. It occurs to me while writing that an additional Method could be registered for third-party Originators to explicitly assert (a) that they're originating on behalf of the putative Author, and (b) that they've authenticated the Author by some prior means. This would appear to be the essence of the capability that I'm advocating: a standardised means of making this claim in a form that receivers can recognise explicitly as being different from a typical forwarding case and therefore to potentially draw different assumptions. This approach would not require AS[0], it would simply use AS[1] and cause the assertion to appear in AAR[1]. Pending the registration of a new Method, this could simply be a comment on the "none" result: From: User ARC-Authentication-Results: i=1; webmail.example; none (sent by webmail.example on behalf of user@company.example) or From: Company ARC-Authentication-Results: i=1; esp.example; none (sent by esp.example on behalf of customer.example) (some creative abuse of vbr and auth results would work, but wouldn't quite convey the intended information). The approach that I had suggested earlier (cv=I) now appears to me to overload the cv field and, as above, I now view a specific 7601.Method as a better option than a special interpretation for AS[0]. - Roland > > >> > Yes, AS[1] testifies to the Authenticated-Results of >> receiving the message >> > from the originator. >> >> That only proves the first receiver was involved. A final >> receiver may trust >> its results or not. >> >> >> What is the first receiver reporting if not the authentication >> claims made by the originator? > > They could equally be reporting fraudulent claims in order to > defeat email security systems at (a) downstream receiver(s). > > > ...meaning nodes 0 (originator) and 1 are in collusion? Sure, that's > possible, but how would requiring an i=0 thwart such an arrangement? > > -MSK > --------------090908030200030200080303 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 05/13/2016 05:24 AM, Murray S. Kucherawy wrote:

On Wed, May 11, 2016 at 7:19 PM, Roland Turner <roland@rolandturner.com> wrote:

I'd suggest not. AS[1] permits a receiver (or other assessor) to determine with some confidence that the putative signer made such an assertion about the putative originator, it provides no information about the involvement of the putative originator except to the extent that the assessor additionally trusts the assertions of the putative signer. Decisions to trust are necessarily outside the specification. This argument applies equivalently to AS[0] independent origination scenarios and to AS[>0] forwarding scenarios.

What would an i=0 ARC Set tell you that the i=1 set does not?

As I understand it, an i=0 set would be the author asserting "I validated my own mail, and it was good."  How would one consume such an assertion in a meaningful way?

(Note that during writing the following, my stance has changed. I'd now recommend the registration of a new 7601.Method instead of specifying a special interpretation for AS[0].)

In the specific case which I see as relevant - that of third-party origination - an i=0 set would be a 5598.Originator asserting that it had a good faith belief that it was acting on behalf of an Author who has legitimate use of the domain-name/email-address, despite the fact that no available Method can be used to substantiate that claim. Typical cases for this good faith to belief to arise would include at least:
  • ESPs acting on behalf of [typically] smaller customers who haven't gotten their SPF include: and/or DKIM CNAMEs created correctly, and
  • webmail services sending with an email address in another domain that a user has claimed and demonstrated control of (or at least the ability to receive messages at).

For a receiver, the ability to tell the difference between:
  • "we're forwarding this message that we think is probably OK, although we received it via SMTP and it passed no authentication mechanisms", and
  • "we originated this message on behalf of a customer or user with a good faith belief that their use of the domain-name/email-address is legitimate"

would be useful in cases where (and while) the receiver trusted the Originator's practices in this respect, particularly where a statistical model was otherwise flagging the message as borderline.

It might reasonably be objected that a DKIM signature by the Originator alone would achieve the same result, however 7601 2.7.1 makes clear that DKIM passes need only be reported in Authentication-Results: headers (and therefore only appear in ARC-Authentication-Results headers) where they are acceptable to the reporting ADMD, and specifically offers as an example the case where

"an ADMD policy might require that the signature(s) on the message be added using the DNS domain present in the From header field of the message, thus making third-party signatures unacceptable even if they verify",

meaning that a third-party Originator cannot rely upon an ARC-signing forwarder to convey this information. As a practical matter, an ARC-signing forwarder could also throw away the existing chain and start a new one if it wished, however this is not an expected mode of operation, while DKIM validators being choosy about what they validate and/or report certainly is.

An interesting alternative would be to amend 7601 to require the reporting of all DKIM results and to disregard the fact that some DKIM implementations simply won't, although this does not seem ideal.

It occurs to me while writing that an additional Method could be registered for third-party Originators to explicitly assert (a) that they're originating on behalf of the putative Author, and (b) that they've authenticated the Author by some prior means. This would appear to be the essence of the capability that I'm advocating: a standardised means of making this claim in a form that receivers can recognise explicitly as being different from a typical forwarding case and therefore to potentially draw different assumptions. This approach would not require AS[0], it would simply use AS[1] and cause the assertion to appear in AAR[1]. Pending the registration of a new Method, this could simply be a comment on the "none" result:

    From: User <user@company.example>
    ARC-Authentication-Results: i=1; webmail.example; none (sent by webmail.example on behalf of user@company.example)

or

    From: Company <info@company.example>
    ARC-Authentication-Results: i=1; esp.example; none (sent by esp.example on behalf of customer.example)

(some creative abuse of vbr and auth results would work, but wouldn't quite convey the intended information).

The approach that I had suggested earlier (cv=I) now appears to me to overload the cv field and, as above, I now view a specific 7601.Method as a better option than a special interpretation for AS[0].

- Roland






> Yes, AS[1] testifies to the Authenticated-Results of receiving the message
> from the originator.

That only proves the first receiver was involved.  A final receiver may trust
its results or not.

What is the first receiver reporting if not the authentication claims made by the originator?

 They could equally be reporting fraudulent claims in order to defeat email security systems at (a) downstream receiver(s).

...meaning nodes 0 (originator) and 1 are in collusion?  Sure, that's possible, but how would requiring an i=0 thwart such an arrangement?

-MSK


--------------090908030200030200080303-- From nobody Sun May 15 07:48:42 2016 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 607A512D0CA for ; Sun, 15 May 2016 07:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.427 X-Spam-Level: X-Spam-Status: No, score=-3.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rolandturner.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 5M8tE2svt10U for ; Sun, 15 May 2016 07:48:40 -0700 (PDT) Received: from sg.rolandturner.com (sg.rolandturner.com [175.41.138.242]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 097C8128B44 for ; Sun, 15 May 2016 07:48:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=rolandturner.com; s=20120325; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=KQzeGfd4iyxpd5kNzDx4JEGt3KgoFlUPWhMAR2HHqkc=; b=X5zogVSwXQJH7Gip0Q+d+opV9RbysMEDqO/hH4ne3fkEmsfgcJXSK/2OWytIqIspmeO8zAih5cTnubHRyJ33Y/EerA+Ba2fzScV2qOS7Nd2lgrDleID+hpn+sx0RPGJMlETMKzhIEoag/J3216X9AVyfjs7rS6xyOBW/K3P4588=; Received: from [202.156.169.29] (port=44562 helo=[10.179.69.102]) by sg.rolandturner.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1b1xLP-0002WJ-5h; Sun, 15 May 2016 14:48:35 +0000 To: "Stephen J. Turnbull" References: <20160511002303.14397.qmail@ary.lan> <57327D81.6050306@gmail.com> <57331D94.2010004@tana.it> <5733E720.3030706@rolandturner.com> <22324.6408.365758.858945@turnbull.sk.tsukuba.ac.jp> From: Roland Turner Message-ID: <57388C42.9000108@rolandturner.com> Date: Sun, 15 May 2016 22:48:34 +0800 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <22324.6408.365758.858945@turnbull.sk.tsukuba.ac.jp> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "dmarc@ietf.org" , "Kurt Andersen \(b\)" , "Murray S. Kucherawy" , Alessandro Vesely Subject: Re: [dmarc-ietf] Independent origination and AS[0] X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2016 14:48:41 -0000 On 05/12/2016 01:47 PM, Stephen J. Turnbull wrote: > I believe this thread has moved to "dmarc", so "arc-discuss" has been > removed. Thanks. It appears that I was not on dmarc (now corrected), so had missed quite a bit of the discussion. > Roland Turner writes: > > > > (as mentioned below under "authenticated identity"). The biggest > > > problem with that, is whether anyone should trust such purported > > > authentication claims. > > > > Sure, but that's _*exactly*_ the same problem as trusting ARC > > forwarders' claims in the first place. > > In a particular formal sense, perhaps. But an ARC assertion is an > assertion that certain data have been *validated*. An originator > assertion is an assertion that certain data is *authentic*. The > assertions are different in *kind*, and therefore the trust decision > is a different problem (requires different data and balances different > risks). ARC doesn't help with authenticity, as you yourself have been > at pains to explain. Trying to stretch it to do so is a bad idea (at > least from the point of view of mailing list owners). Thanks for persisting on this. Per my earlier email to Murray, I now agree with you. The sensible thing to do would appear to be to register a new 7601.Method to describe situations where a 5598.Originator wishes to explicitly assert that they're acting on behalf of an Author from a different ADMD whom they've previously authenticated by some other means. > > Failure to support independent origination explicitly (I've > > suggested cv=I to the same end previously) invites ad hoc > > arrangements, > > That may be true, but IMO it's out of scope for ARC. It should be > done in DKIM or DMARC. ARC currently is very easy to interpret: a > third party asserts that it validated some data provided by an earlier > party in the chain (possibly but not always the originator). Let's > not muddy it with assertions that belong to an originator protocol. I'd suggest that the areas of concern (webmail providing the ability for someone to send with the From: address of their work account that they've previously demonstrated control of, [typically] small customers of ESPs who haven't got their DKIM etc. sorted out) aren't well addressed by DKIM or DMARC, but that there's also a better option than AS[0]. - Roland From nobody Sun May 15 07:55:11 2016 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 A763912B047 for ; Sun, 15 May 2016 07:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.426 X-Spam-Level: X-Spam-Status: No, score=-3.426 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, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rolandturner.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 occ24HTN7Zkt for ; Sun, 15 May 2016 07:55:08 -0700 (PDT) Received: from sg.rolandturner.com (sg.rolandturner.com [175.41.138.242]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FC4E128B44 for ; Sun, 15 May 2016 07:55:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=rolandturner.com; s=20120325; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=lVLijjjTBk71Fioaujb+bj2TiX+xgveBpO3+h3CbZY8=; b=xqK9AUagkYfp2AxDHFfoGnCCtt/RfvGNSAXaY7Q+JnEBCOmcb0zwia/P9umYGWeGOjYvIKIvGaxcNY2PzMfECDqOq45nD03cATpdxvKzLJODInGXpTcQlpERYL3+EAbTGBgV71IMXmnllW1ulTuTIjhYoJcpE2fvH3Al7y2Bsxo=; Received: from [202.156.169.29] (port=44577 helo=[10.179.69.102]) by sg.rolandturner.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1b1xRh-0002XG-6S; Sun, 15 May 2016 14:55:05 +0000 To: "Murray S. Kucherawy" References: <20160511002303.14397.qmail@ary.lan> <57327D81.6050306@gmail.com> <57331D94.2010004@tana.it> <573363BB.9030701@tana.it> <5733E842.8020208@rolandturner.com> From: Roland Turner Message-ID: <57388DC8.4060901@rolandturner.com> Date: Sun, 15 May 2016 22:55:04 +0800 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------010902080608080307080005" Archived-At: Cc: "Kurt Andersen \(b\)" , "dmarc@ietf.org" , ARC Discussion , Alessandro Vesely Subject: Re: [dmarc-ietf] [arc-discuss] Proposal to adopt ARC documents into the WG (toward phase 2 milestone) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2016 14:55:09 -0000 This is a multi-part message in MIME format. --------------010902080608080307080005 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit (Sorry Murray, I missed the tail of your message.) On 05/13/2016 05:24 AM, Murray S. Kucherawy wrote: > > Yes, AS[1] testifies to the Authenticated-Results of receiving the > message > > from the originator. > > That only proves the first receiver was involved. A final > receiver may trust > its results or not. > > > What is the first receiver reporting if not the authentication > claims made by the originator? They could equally be reporting fraudulent claims in order to defeat email security systems at (a) downstream receiver(s). ...meaning nodes 0 (originator) and 1 are in collusion? Sure, that's possible, but how would requiring an i=0 thwart such an arrangement? No, "they" meaning the i=1 party. Having a third-party originator state their own assertions in a form that ARC will include in its chain allows the receiver to make decisions based upon the trust of the i=0 party, even where they don't trust the i=1 party. Also, no requirement, just an option for Originators. Per my earlier message though, I'd now suggest that this is a job for a new 7601.Method. - Roland --------------010902080608080307080005 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
(Sorry Murray, I missed the tail of your message.)

On 05/13/2016 05:24 AM, Murray S. Kucherawy wrote:


> Yes, AS[1] testifies to the Authenticated-Results of receiving the message
> from the originator.

That only proves the first receiver was involved.  A final receiver may trust
its results or not.

What is the first receiver reporting if not the authentication claims made by the originator?

 They could equally be reporting fraudulent claims in order to defeat email security systems at (a) downstream receiver(s).

...meaning nodes 0 (originator) and 1 are in collusion?  Sure, that's possible, but how would requiring an i=0 thwart such an arrangement?

No, "they" meaning the i=1 party. Having a third-party originator state their own assertions in a form that ARC will include in its chain allows the receiver to make decisions based upon the trust of the i=0 party, even where they don't trust the i=1 party.

Also, no requirement, just an option for Originators. Per my earlier message though, I'd now suggest that this is a job for a new 7601.Method.

- Roland

--------------010902080608080307080005-- From nobody Mon May 16 22:45:05 2016 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 5EEC512D56F for ; Mon, 16 May 2016 22:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.001 X-Spam-Level: X-Spam-Status: No, score=-102.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, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=Cdro8PpF; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=W1b/O4Ns 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 ZwTLO-phqv4q for ; Mon, 16 May 2016 22:45:00 -0700 (PDT) Received: from ntbbs.santronics.com (mail.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 79B2A12D52A for ; Mon, 16 May 2016 22:45:00 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1985; t=1463463898; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=RgqXuly9aGoHRJptV8pfmYpBG2k=; b=Cdro8PpFQwb/TjkgBI9cZ93OUnmBSwei+UUIXUfF3Bu+9RE9ZLFThi9hoRSfo2 j0CAANixJbWcZn3gYl4giUCO+/0SaD3+4DblqD/maaUbuJTiDvm/O/BunHylEZYK utbsVvcQjIMtr1kla9fm2qFeYmwwT5j+tc3eI1SHOL2rI= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.5) for dmarc@ietf.org; Tue, 17 May 2016 01:44:58 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.5) with ESMTP id 3132445569.1.3944; Tue, 17 May 2016 01:44:56 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1985; t=1463463638; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=9YGHLYd jG3z7/Lyq+D1v73FN467aa3lI9WqlQmCOb0M=; b=W1b/O4NsZSfSyyAZ5NduI6Q q48V7oh6UNHXCbv52/ftKG0lxuLL//3022/I/Chzd0PpUgaJCIb7Cd93XzZvuBVj 0s8p5gT6v8HjeI4Onkt06Y5s67ULGshe8YlKolNbqdp667xw59YEVMeoI9PkZtTA BxCE4ywd+ncx2wInbi1k= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.5) for dmarc@ietf.org; Tue, 17 May 2016 01:40:38 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.5) with ESMTP id 3160566282.9.36760; Tue, 17 May 2016 01:40:37 -0400 Message-ID: <573AAFD8.1060901@isdg.net> Date: Tue, 17 May 2016 01:44:56 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: Barry Leiba References: <20160511002303.14397.qmail@ary.lan> <57327D81.6050306@gmail.com> <57331D94.2010004@tana.it> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 17 May 2016 05:45:04 -0000 On 5/11/2016 12:00 PM, Barry Leiba wrote: > I'm pulling the arc-discuss list back off the distribution for this > message (and it's probably a good idea to alert people when you add a > new mailing list to an ongoing discussion). > > Kurt's original message asked whether the DMARC working group... > > 1. ...wants to work on the ARC spec, using > https://datatracker.ietf.org/doc/draft-andersen-arc/ as a starting > point, and > > 2. ...also wants to work on ARC usage recommendations, using > https://datatracker.ietf.org/doc/draft-jones-arc-usage/ as a starting > point. > > It certainly seems that the working group is interested in discussing > ARC, as I can judge from the discussion in the short time since Kurt's > proposal. So let's go back and get a proper answer: > > Does anyone object to having the DMARC working group take on this work? > Does anyone object to using the two documents above as starting points > for that work? > Does anyone have an alternative proposal? > > Please respond to this list, , by 20 May. > > Barry, for the DMARC chairs Barry, I believe the IETF should offer an simplified Policy Lookup alternative for 3rd party authorization. It should be a "product option" for implementators of any size. I think the ARC framework attempts to achieve the same end result at a very more complex, higher cost design approach. I don't opposed any further development, however, technical alternatives should be offered. I could reintroduce a modified DSAP (DKIM Signature Authorization Protocol) proposal that would piggy back off the DMARC protocol. I could consolidate ADSP/ATPS and wrap it over DMARC. I think the IETF should offer simplified alternatives using the original proof of concept "Policy DNS lookup" models. DMARC now replaced ADSP - a policy lookup solution. It just needs to be further developed with 3rd party extensions. That could include ARC as well. Thanks -- HLS From nobody Tue May 17 08:08:19 2016 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 F084412B05F for ; Tue, 17 May 2016 08:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.728 X-Spam-Level: X-Spam-Status: No, score=-5.728 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-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=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OqoarD4IA4xt for ; Tue, 17 May 2016 08:08:16 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA28D12D16F for ; Tue, 17 May 2016 08:08:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1463497693; bh=08mSARnrrC2ZiHG7hSQWG9yJbICDYTEpssQ0s82HD/I=; l=1154; h=To:References:Cc:From:Date:In-Reply-To; b=BhD1ms3iTfBcml04iOOVoNT1/uHCGchEDmq0ktckDef6mNXCZEcd5lwnzPhtK1vUG QrXFjtzc1WoW5+al1mJwb/bCR4vF6nA1j3hg7fkh4Gxze47rxd0S3zak19YgX8RJT3 ywSOP1e78YlnashTw5TUpQt+w3JIZ+FG1ho0whA4= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.88] (pcale.tana [172.25.197.88]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Tue, 17 May 2016 17:08:13 +0200 id 00000000005DC050.00000000573B33DD.00006F73 To: Barry Leiba , "Kurt Andersen (b)" References: <20160511002303.14397.qmail@ary.lan> <57327D81.6050306@gmail.com> <57331D94.2010004@tana.it> From: Alessandro Vesely Message-ID: <573B33DD.5040802@tana.it> Date: Tue, 17 May 2016 17:08:13 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: DMARC Subject: Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 17 May 2016 15:08:18 -0000 On Wed 11/May/2016 18:00:25 +0200 Barry Leiba wrote: > It certainly seems that the working group is interested in discussing > ARC, as I can judge from the discussion in the short time since Kurt's > proposal. So let's go back and get a proper answer: > > Does anyone object to having the DMARC working group take on this work? > Does anyone object to using the two documents above as starting points > for that work? ARC, as currently documented and conceived, aims at "a more nuanced interpretation to guide any local policies related to messages that arrive with broken domain authentication (DMARC)." It does not propose any DMARC improvement, let alone phase 2 milestone. Unless ARC commits to a purpose congenial with DMARC's charter, I'd find it objectionable for this WG to take on its work. > Does anyone have an alternative proposal? The "least broken" proposal for phase 2 seems to be dkim-conditional. It emerged as an originator protocol, so it can develop without muddying ARC. > Please respond to this list, , by 20 May. On it, but I doubt ARC consensus will be apparent by that date. Ale From nobody Tue May 17 12:53:10 2016 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 933C612DD8F for ; Tue, 17 May 2016 12:53:09 -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 5kzu6ZQYw52F for ; Tue, 17 May 2016 12:53:07 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::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 0ACDC12D969 for ; Tue, 17 May 2016 12:53:07 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id x194so26828620ywd.0 for ; Tue, 17 May 2016 12:53:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=4kTReoObNvB9BMbMuS659YW8dDfCFQl313zvPlicNVs=; b=BtS0rkcd1jpSTNPCKwLqFANZff0rZW0eMkhqjZ3RQkVWwhyE1acompDyX98h1hBDPv y+Wl31BN/muid2KOO2aeCjFpVZJ9U1+SD67MaM4+Y9Zq4oZxpofFWwfJFBi2P/6XfYK2 a5jmY9NKVdScVap5CSB/b9d06eFwml47BiqxzTHGdZBAdDn/OKgIQcA/UpobkQgPDkXN A9VkP6/9IDDb/jtTkvn+1KJw4x2pQnCJuDxDHJ3i2uL9a/z5ehtFcKd8Ul2gtXja5IYG QPhWRQ6jY40IkcQOYQlGjTVUaj9BYCINB1KqXKYoA1Zt9U/w8jI4tCe3o2MnlSbafftu hXOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=4kTReoObNvB9BMbMuS659YW8dDfCFQl313zvPlicNVs=; b=BdstPKZYyfopd3trLyVIroBdtlEG96iHgQAOMgjiuP5cpjo0Ps4dIYzAd91DmJnJEw 8yrtvcP32wKXvs/otXpFqj3pAvUPuay36snVXsXAsyUVni9iF8Gf9a+Wt0wMkxWRaswu 5xsoGFZdWb6w6sjSQFRZXga0/hxH5A7lhMr123e+FAf839msf9flk0JSUohu5Sf6YlOZ utcuNsbTEXxSV8c9Re/9QOKs3bXuatknwF1K391K1G+9ufeVndIW1c9K2kOPZlu6LdSh FSeK5o7BBjHQJLpxNjAz8HFtP5QJ2A5UYfbIV/8BrsFefTuGuX6E6uTZ5DKU9I6xwWpY 1b2Q== X-Gm-Message-State: AOPr4FWbD12yYn6F9m4n6bn22MILNBT1fGW1iIe1ycUMw4c5Er1cmyc/sSdg/YxP1OL0I11/ZT8kJ4PXu8Ga+A== MIME-Version: 1.0 X-Received: by 10.13.240.65 with SMTP id z62mr1792844ywe.314.1463514786273; Tue, 17 May 2016 12:53:06 -0700 (PDT) Received: by 10.37.103.215 with HTTP; Tue, 17 May 2016 12:53:06 -0700 (PDT) In-Reply-To: <573B33DD.5040802@tana.it> References: <20160511002303.14397.qmail@ary.lan> <57327D81.6050306@gmail.com> <57331D94.2010004@tana.it> <573B33DD.5040802@tana.it> Date: Tue, 17 May 2016 12:53:06 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: multipart/alternative; boundary=94eb2c034e60f5a0dd05330f16a5 Archived-At: Cc: "Kurt Andersen \(b\)" , DMARC , Barry Leiba Subject: Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 17 May 2016 19:53:09 -0000 --94eb2c034e60f5a0dd05330f16a5 Content-Type: text/plain; charset=UTF-8 On Tue, May 17, 2016 at 8:08 AM, Alessandro Vesely wrote: > > Does anyone object to having the DMARC working group take on this work? > I agree with Alessandro, but for procedural reasons: I'm not sure it fits within our present charter. The charter enumerates three tracks, the first of which appears to allow discussion of new protocols; in particular, one might argue that ARC is a "form of DKIM signature that is better able to survive transit through intermediaries". However, in the second track, it says "The working group will not develop additional mail authentication technologies, but may document authentication requirements that are desirable", and there are chunks of ARC that are clearly new. (Having now implemented ARC, I can attest that there was enough new code needed that I would call it "new".) Absent a desire to form a distinct working group to develop ARC, I think we need to discuss rechartering before we can entertain this motion. > Does anyone object to using the two documents above as starting points > > for that work? > Modulo the first question, no. > ARC, as currently documented and conceived, aims at "a more nuanced > interpretation to guide any local policies related to messages that arrive > with > broken domain authentication (DMARC)." It does not propose any DMARC > improvement, let alone phase 2 milestone. > It proposes to provide a new authentication method that can more accurately reflect the "true" (for some value thereof) authenticity of a message, allowing DMARC to behave more accurately. How is that not an improvement? DMARC was meant to be extensible to better authentication methods as they appear, and this is an instance of such. > Unless ARC commits to a purpose congenial with DMARC's charter, I'd find it > objectionable for this WG to take on its work. > > > Does anyone have an alternative proposal? > > The "least broken" proposal for phase 2 seems to be dkim-conditional. It > emerged as an originator protocol, so it can develop without muddying ARC. > I have an unreleased implementation of that. It also more easily qualifies under our charter, IMHO. I think we should at least allow discussion of that one. -MSK --94eb2c034e60f5a0dd05330f16a5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, May 17, 2016 at 8:08 AM, Alessandro Vesely <vesely@t= ana.it> wrote:
> Does anyone object to having the DMARC working group take on this w= ork?

I agree with Alessandro, bu= t for procedural reasons: I'm not sure it fits within our present chart= er.

The charter enumerates three tracks, the first of which appears = to allow discussion of new protocols; in particular, one might argue that A= RC is a "form of DKIM signature that is better able to survive transit= through intermediaries".=C2=A0 However, in the second track, it says = "The working group will not develop additional mail authentication tec= hnologies, but may document authentication requirements that are desirable&= quot;, and there are chunks of ARC that are clearly new.=C2=A0 (Having now = implemented ARC, I can attest that there was enough new code needed that I = would call it "new".)

Absent a desire to form a= distinct working group to develop ARC, I think we need to discuss recharte= ring before we can entertain this motion.

> Does anyone object to using the two documents above as starting points=
> for that work?

Modulo the f= irst question, no.
=C2=A0
ARC, as currently documented and conceived, aims at "a more nua= nced
interpretation to guide any local policies related to messages that arrive = with
broken domain authentication (DMARC)."=C2=A0 It does not propose any D= MARC
improvement, let alone phase 2 milestone.

It proposes to provide a new authentication method that can more accurat= ely reflect the "true" (for some value thereof) authenticity of a= message, allowing DMARC to behave more accurately.=C2=A0 How is that not a= n improvement?=C2=A0 DMARC was meant to be extensible to better authenticat= ion methods as they appear, and this is an instance of such.
= =C2=A0
Unless ARC commits to a purpose congenial with DMARC's charter, I'd= find it
objectionable for this WG to take on its work.

> Does anyone have an alternative proposal?

The "least broken" proposal for phase 2 seems to be dkim-c= onditional.=C2=A0 It
emerged as an originator protocol, so it can develop without muddying ARC.<= br>

I have an unreleased implementation of = that.=C2=A0 It also more easily qualifies under our charter, IMHO.=C2=A0 I = think we should at least allow discussion of that one.

-M= SK
--94eb2c034e60f5a0dd05330f16a5-- From nobody Tue May 17 13:14:24 2016 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 68A4C12DDC2 for ; Tue, 17 May 2016 13:14:22 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 h8QkaTrGRcMG for ; Tue, 17 May 2016 13:14:20 -0700 (PDT) Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.4]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCE3E12DDB8 for ; Tue, 17 May 2016 13:14:19 -0700 (PDT) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES532.agna.amgreetings.com ([::1]) with mapi id 14.03.0266.001; Tue, 17 May 2016 16:14:18 -0400 From: "MH Michael Hammer (5304)" To: "Murray S. Kucherawy" , Alessandro Vesely Thread-Topic: [!!Mass Mail]Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone) Thread-Index: AQHRsE30kL73YwYsiU6ZwUdgwcNIkp+9zecA//+/ugA= Date: Tue, 17 May 2016 20:14:17 +0000 Message-ID: References: <20160511002303.14397.qmail@ary.lan> <57327D81.6050306@gmail.com> <57331D94.2010004@tana.it> <573B33DD.5040802@tana.it> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.144.15.202] x-kse-attachmentfiltering-interceptor-info: protection disabled x-kse-serverinfo: USCLES532.agna.amgreetings.com, 9 x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean, bases: 5/17/2016 4:31:00 PM x-kse-dlp-scaninfo: Skipped Content-Type: multipart/alternative; boundary="_000_CE39F90A45FF0C49A1EA229FC9899B052664D2BEUSCLES544agnaam_" MIME-Version: 1.0 Archived-At: Cc: DMARC , "Kurt Andersen \(b\)" , Barry Leiba Subject: Re: [dmarc-ietf] [!!Mass Mail]Re: Proposal to adopt ARC documents into the WG (toward phase 2 milestone) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 17 May 2016 20:14:22 -0000 --_000_CE39F90A45FF0C49A1EA229FC9899B052664D2BEUSCLES544agnaam_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q29tbWVudHMgaW4tbGluZQ0KDQpGcm9tOiBkbWFyYyBbbWFpbHRvOmRtYXJjLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBNdXJyYXkgUy4gS3VjaGVyYXd5DQpTZW50OiBUdWVzZGF5LCBN YXkgMTcsIDIwMTYgMzo1MyBQTQ0KVG86IEFsZXNzYW5kcm8gVmVzZWx5DQpDYzogS3VydCBBbmRl cnNlbiAoYik7IERNQVJDOyBCYXJyeSBMZWliYQ0KU3ViamVjdDogWyEhTWFzcyBNYWlsXVJlOiBb ZG1hcmMtaWV0Zl0gUHJvcG9zYWwgdG8gYWRvcHQgQVJDIGRvY3VtZW50cyBpbnRvIHRoZSBXRyAo dG93YXJkIHBoYXNlIDIgbWlsZXN0b25lKQ0KDQpPbiBUdWUsIE1heSAxNywgMjAxNiBhdCA4OjA4 IEFNLCBBbGVzc2FuZHJvIFZlc2VseSA8dmVzZWx5QHRhbmEuaXQ8bWFpbHRvOnZlc2VseUB0YW5h Lml0Pj4gd3JvdGU6DQo+IERvZXMgYW55b25lIG9iamVjdCB0byBoYXZpbmcgdGhlIERNQVJDIHdv cmtpbmcgZ3JvdXAgdGFrZSBvbiB0aGlzIHdvcms/DQoNCkkgYWdyZWUgd2l0aCBBbGVzc2FuZHJv LCBidXQgZm9yIHByb2NlZHVyYWwgcmVhc29uczogSSdtIG5vdCBzdXJlIGl0IGZpdHMgd2l0aGlu IG91ciBwcmVzZW50IGNoYXJ0ZXIuDQoNClRoZSBjaGFydGVyIGVudW1lcmF0ZXMgdGhyZWUgdHJh Y2tzLCB0aGUgZmlyc3Qgb2Ygd2hpY2ggYXBwZWFycyB0byBhbGxvdyBkaXNjdXNzaW9uIG9mIG5l dyBwcm90b2NvbHM7IGluIHBhcnRpY3VsYXIsIG9uZSBtaWdodCBhcmd1ZSB0aGF0IEFSQyBpcyBh ICJmb3JtIG9mIERLSU0gc2lnbmF0dXJlIHRoYXQgaXMgYmV0dGVyIGFibGUgdG8gc3Vydml2ZSB0 cmFuc2l0IHRocm91Z2ggaW50ZXJtZWRpYXJpZXMiLiAgSG93ZXZlciwgaW4gdGhlIHNlY29uZCB0 cmFjaywgaXQgc2F5cyAiVGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBub3QgZGV2ZWxvcCBhZGRpdGlv bmFsIG1haWwgYXV0aGVudGljYXRpb24gdGVjaG5vbG9naWVzLCBidXQgbWF5IGRvY3VtZW50IGF1 dGhlbnRpY2F0aW9uIHJlcXVpcmVtZW50cyB0aGF0IGFyZSBkZXNpcmFibGUiLCBhbmQgdGhlcmUg YXJlIGNodW5rcyBvZiBBUkMgdGhhdCBhcmUgY2xlYXJseSBuZXcuICAoSGF2aW5nIG5vdyBpbXBs ZW1lbnRlZCBBUkMsIEkgY2FuIGF0dGVzdCB0aGF0IHRoZXJlIHdhcyBlbm91Z2ggbmV3IGNvZGUg bmVlZGVkIHRoYXQgSSB3b3VsZCBjYWxsIGl0ICJuZXciLikNCk1IOiBUbyB0aGUgZXh0ZW50IHRo YXQgQVJDIGluZm9ybXMgbG9jYWwgcG9saWN5IHVuZGVyIERNQVJDLCBJIHN1cHBvcnQgdGhlIGdy b3VwIHRha2luZyBpdCBvbi4gTXkgcGVyc29uYWwgc3RhbmNlIGlzIHRoYXQgcD1yZWplY3QgbWVh bnMganVzdCB0aGF0IGJ1dCBJIHJlY29nbml6ZSB0aGF0IHRoZXJlIGFyZSBmb2xrcyB3aG8gY2Fu 4oCZdCBnZXQgY29udHJvbCBvZiB0aGVpciBtYWlsIHN0cmVhbXMgb3IgdGhlcmUgYXJlIGNvcm5l ciBjYXNlcyBzdWNoIGFzIG1haWxpbmcgbGlzdHMgd2hpY2ggZm9yIGhpc3RvcmljYWwgcmVhc29u cyBkbyBub3Qgd2lzaCB0byBjaGFuZ2UgaG93IHRoZXkgZnVuY3Rpb24uDQpBYnNlbnQgYSBkZXNp cmUgdG8gZm9ybSBhIGRpc3RpbmN0IHdvcmtpbmcgZ3JvdXAgdG8gZGV2ZWxvcCBBUkMsIEkgdGhp bmsgd2UgbmVlZCB0byBkaXNjdXNzIHJlY2hhcnRlcmluZyBiZWZvcmUgd2UgY2FuIGVudGVydGFp biB0aGlzIG1vdGlvbi4NCg0KTUg6IElmIHdlIG5lZWQgdG8gcmUtY2hhcnRlciB0aGVuIEkgdGhp bmsgd2Ugc2hvdWxkIHJlLWNoYXJ0ZXIuIFRoZXJlIGFyZSBhbHJlYWR5IGltcGxlbWVudGF0aW9u cyBvZiBBUkMgYW5kIHRoZXJlIGFwcGVhcnMgdG8gYmUgc3VmZmljaWVudCBzdXBwb3J0IHRvIGp1 c3RpZnkgdGhlIGVmZm9ydC4NCg0KPiBEb2VzIGFueW9uZSBvYmplY3QgdG8gdXNpbmcgdGhlIHR3 byBkb2N1bWVudHMgYWJvdmUgYXMgc3RhcnRpbmcgcG9pbnRzDQo+IGZvciB0aGF0IHdvcms/DQoN Ck1vZHVsbyB0aGUgZmlyc3QgcXVlc3Rpb24sIG5vLg0KDQpNSDogKzENCg0KDQpBUkMsIGFzIGN1 cnJlbnRseSBkb2N1bWVudGVkIGFuZCBjb25jZWl2ZWQsIGFpbXMgYXQgImEgbW9yZSBudWFuY2Vk DQppbnRlcnByZXRhdGlvbiB0byBndWlkZSBhbnkgbG9jYWwgcG9saWNpZXMgcmVsYXRlZCB0byBt ZXNzYWdlcyB0aGF0IGFycml2ZSB3aXRoDQpicm9rZW4gZG9tYWluIGF1dGhlbnRpY2F0aW9uIChE TUFSQykuIiAgSXQgZG9lcyBub3QgcHJvcG9zZSBhbnkgRE1BUkMNCmltcHJvdmVtZW50LCBsZXQg YWxvbmUgcGhhc2UgMiBtaWxlc3RvbmUuDQoNCkl0IHByb3Bvc2VzIHRvIHByb3ZpZGUgYSBuZXcg YXV0aGVudGljYXRpb24gbWV0aG9kIHRoYXQgY2FuIG1vcmUgYWNjdXJhdGVseSByZWZsZWN0IHRo ZSAidHJ1ZSIgKGZvciBzb21lIHZhbHVlIHRoZXJlb2YpIGF1dGhlbnRpY2l0eSBvZiBhIG1lc3Nh Z2UsIGFsbG93aW5nIERNQVJDIHRvIGJlaGF2ZSBtb3JlIGFjY3VyYXRlbHkuICBIb3cgaXMgdGhh dCBub3QgYW4gaW1wcm92ZW1lbnQ/ICBETUFSQyB3YXMgbWVhbnQgdG8gYmUgZXh0ZW5zaWJsZSB0 byBiZXR0ZXIgYXV0aGVudGljYXRpb24gbWV0aG9kcyBhcyB0aGV5IGFwcGVhciwgYW5kIHRoaXMg aXMgYW4gaW5zdGFuY2Ugb2Ygc3VjaC4NCg0KTUg6IFRoaXMgaXMgbm90IGFuIGV4dGVuc2lvbiBv ZiBETUFSQyBpdHNlbGYuIEl0IGxldmVyYWdlcyBhIERLSU0gbGlrZSBzaWduaW5nIGFwcHJvYWNo IHRvIHByb3ZpZGUgYWRkaXRpb25hbCBkYXRhIHBvaW50cyB0byB2YWxpZGF0b3JzIHdpc2hpbmcg dG8gaW1wbGVtZW50IGxvY2FsIHBvbGljeSBpbiBhIG1vcmUgaW5mb3JtZWQgbWFubmVyLiBUaGlz IGlzIGEgbnVhbmNlZCBidXQgaW1wb3J0YW50IGRpZmZlcmVuY2UgdW5sZXNzIHNvbWVvbmUgaXMg c3VnZ2VzdGluZyBtdW5naW5nIEFSQyBpbnRvIERNQVJDIGl0c2VsZi4NCg0KVW5sZXNzIEFSQyBj b21taXRzIHRvIGEgcHVycG9zZSBjb25nZW5pYWwgd2l0aCBETUFSQydzIGNoYXJ0ZXIsIEknZCBm aW5kIGl0DQpvYmplY3Rpb25hYmxlIGZvciB0aGlzIFdHIHRvIHRha2Ugb24gaXRzIHdvcmsuDQoN Cj4gRG9lcyBhbnlvbmUgaGF2ZSBhbiBhbHRlcm5hdGl2ZSBwcm9wb3NhbD8NCg0KVGhlICJsZWFz dCBicm9rZW4iIHByb3Bvc2FsIGZvciBwaGFzZSAyIHNlZW1zIHRvIGJlIGRraW0tY29uZGl0aW9u YWwuICBJdA0KZW1lcmdlZCBhcyBhbiBvcmlnaW5hdG9yIHByb3RvY29sLCBzbyBpdCBjYW4gZGV2 ZWxvcCB3aXRob3V0IG11ZGR5aW5nIEFSQy4NCg0KSSBoYXZlIGFuIHVucmVsZWFzZWQgaW1wbGVt ZW50YXRpb24gb2YgdGhhdC4gIEl0IGFsc28gbW9yZSBlYXNpbHkgcXVhbGlmaWVzIHVuZGVyIG91 ciBjaGFydGVyLCBJTUhPLiAgSSB0aGluayB3ZSBzaG91bGQgYXQgbGVhc3QgYWxsb3cgZGlzY3Vz c2lvbiBvZiB0aGF0IG9uZS4NCk1IOiBJIHRob3VnaHQgcnVubmluZyBjb2RlIHdhcyBvbmUgb2Yg dGhlIGNyaXRlcmlhLiBEa2ltLWNvbmRpdGlvbmFsIG5ldmVyIGdvdCBzaWduaWZpY2FudCBzdXBw b3J0LiBJ4oCZbSBub3QgYWdhaW5zdCBpdCBwZXIgc2UgYnV0IHVubGVzcyB0aGVyZSBpcyBhIGNv bXBlbGxpbmcgcmVhc29uIEkgcHJlZmVyIHRvIGF2b2lkIHJlLXZpc2l0aW5nIG9sZCBncm91bmQu DQpNaWtlDQo= --_000_CE39F90A45FF0C49A1EA229FC9899B052664D2BEUSCLES544agnaam_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q29tbWVudHMgaW4tbGlu ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBkbWFyYyBbbWFp bHRvOmRtYXJjLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPk11cnJheSBT LiBLdWNoZXJhd3k8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgTWF5IDE3LCAyMDE2IDM6NTMg UE08YnI+DQo8Yj5Ubzo8L2I+IEFsZXNzYW5kcm8gVmVzZWx5PGJyPg0KPGI+Q2M6PC9iPiBLdXJ0 IEFuZGVyc2VuIChiKTsgRE1BUkM7IEJhcnJ5IExlaWJhPGJyPg0KPGI+U3ViamVjdDo8L2I+IFsh IU1hc3MgTWFpbF1SZTogW2RtYXJjLWlldGZdIFByb3Bvc2FsIHRvIGFkb3B0IEFSQyBkb2N1bWVu dHMgaW50byB0aGUgV0cgKHRvd2FyZCBwaGFzZSAyIG1pbGVzdG9uZSk8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBNYXkgMTcsIDIw MTYgYXQgODowOCBBTSwgQWxlc3NhbmRybyBWZXNlbHkgJmx0OzxhIGhyZWY9Im1haWx0bzp2ZXNl bHlAdGFuYS5pdCIgdGFyZ2V0PSJfYmxhbmsiPnZlc2VseUB0YW5hLml0PC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mZ3Q7IERvZXMgYW55b25lIG9iamVjdCB0byBoYXZpbmcgdGhlIERNQVJDIHdvcmtp bmcgZ3JvdXAgdGFrZSBvbiB0aGlzIHdvcms/PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPkkgYWdyZWUgd2l0aCBBbGVzc2FuZHJvLCBidXQgZm9yIHByb2NlZHVyYWwgcmVhc29uczog SSdtIG5vdCBzdXJlIGl0IGZpdHMgd2l0aGluIG91ciBwcmVzZW50IGNoYXJ0ZXIuPGJyPg0KPGJy Pg0KVGhlIGNoYXJ0ZXIgZW51bWVyYXRlcyB0aHJlZSB0cmFja3MsIHRoZSBmaXJzdCBvZiB3aGlj aCBhcHBlYXJzIHRvIGFsbG93IGRpc2N1c3Npb24gb2YgbmV3IHByb3RvY29sczsgaW4gcGFydGlj dWxhciwgb25lIG1pZ2h0IGFyZ3VlIHRoYXQgQVJDIGlzIGEgJnF1b3Q7Zm9ybSBvZiBES0lNIHNp Z25hdHVyZSB0aGF0IGlzIGJldHRlciBhYmxlIHRvIHN1cnZpdmUgdHJhbnNpdCB0aHJvdWdoIGlu dGVybWVkaWFyaWVzJnF1b3Q7LiZuYnNwOyBIb3dldmVyLCBpbiB0aGUgc2Vjb25kDQogdHJhY2ss IGl0IHNheXMgJnF1b3Q7VGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBub3QgZGV2ZWxvcCBhZGRpdGlv bmFsIG1haWwgYXV0aGVudGljYXRpb24gdGVjaG5vbG9naWVzLCBidXQgbWF5IGRvY3VtZW50IGF1 dGhlbnRpY2F0aW9uIHJlcXVpcmVtZW50cyB0aGF0IGFyZSBkZXNpcmFibGUmcXVvdDssIGFuZCB0 aGVyZSBhcmUgY2h1bmtzIG9mIEFSQyB0aGF0IGFyZSBjbGVhcmx5IG5ldy4mbmJzcDsgKEhhdmlu ZyBub3cgaW1wbGVtZW50ZWQgQVJDLCBJIGNhbiBhdHRlc3QgdGhhdA0KIHRoZXJlIHdhcyBlbm91 Z2ggbmV3IGNvZGUgbmVlZGVkIHRoYXQgSSB3b3VsZCBjYWxsIGl0ICZxdW90O25ldyZxdW90Oy4p PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NSDog VG8gdGhlIGV4dGVudCB0aGF0IEFSQyBpbmZvcm1zIGxvY2FsIHBvbGljeSB1bmRlciBETUFSQywg SSBzdXBwb3J0IHRoZSBncm91cCB0YWtpbmcgaXQgb24uIE15IHBlcnNvbmFsIHN0YW5jZSBpcyB0 aGF0IHA9cmVqZWN0DQogbWVhbnMganVzdCB0aGF0IGJ1dCBJIHJlY29nbml6ZSB0aGF0IHRoZXJl IGFyZSBmb2xrcyB3aG8gY2Fu4oCZdCBnZXQgY29udHJvbCBvZiB0aGVpciBtYWlsIHN0cmVhbXMg b3IgdGhlcmUgYXJlIGNvcm5lciBjYXNlcyBzdWNoIGFzIG1haWxpbmcgbGlzdHMgd2hpY2ggZm9y IGhpc3RvcmljYWwgcmVhc29ucyBkbyBub3Qgd2lzaCB0byBjaGFuZ2UgaG93IHRoZXkgZnVuY3Rp b24uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5BYnNlbnQgYSBkZXNpcmUgdG8gZm9ybSBhIGRpc3RpbmN0IHdvcmtpbmcgZ3JvdXAg dG8gZGV2ZWxvcCBBUkMsIEkgdGhpbmsgd2UgbmVlZCB0byBkaXNjdXNzIHJlY2hhcnRlcmluZyBi ZWZvcmUgd2UgY2FuIGVudGVydGFpbiB0aGlzIG1vdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TUg6IElmIHdlIG5lZWQgdG8g cmUtY2hhcnRlciB0aGVuIEkgdGhpbmsgd2Ugc2hvdWxkIHJlLWNoYXJ0ZXIuIFRoZXJlIGFyZSBh bHJlYWR5IGltcGxlbWVudGF0aW9ucyBvZiBBUkMgYW5kIHRoZXJlIGFwcGVhcnMgdG8gYmUgc3Vm ZmljaWVudCBzdXBwb3J0IHRvIGp1c3RpZnkNCiB0aGUgZWZmb3J0LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IERvZXMgYW55b25lIG9iamVjdCB0byB1 c2luZyB0aGUgdHdvIGRvY3VtZW50cyBhYm92ZSBhcyBzdGFydGluZyBwb2ludHM8YnI+DQomZ3Q7 IGZvciB0aGF0IHdvcms/PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5Nb2R1bG8gdGhlIGZpcnN0IHF1ZXN0aW9uLCBuby48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NSDogJiM0MzsxPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KJm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BUkMsIGFzIGN1cnJl bnRseSBkb2N1bWVudGVkIGFuZCBjb25jZWl2ZWQsIGFpbXMgYXQgJnF1b3Q7YSBtb3JlIG51YW5j ZWQ8YnI+DQppbnRlcnByZXRhdGlvbiB0byBndWlkZSBhbnkgbG9jYWwgcG9saWNpZXMgcmVsYXRl ZCB0byBtZXNzYWdlcyB0aGF0IGFycml2ZSB3aXRoPGJyPg0KYnJva2VuIGRvbWFpbiBhdXRoZW50 aWNhdGlvbiAoRE1BUkMpLiZxdW90OyZuYnNwOyBJdCBkb2VzIG5vdCBwcm9wb3NlIGFueSBETUFS Qzxicj4NCmltcHJvdmVtZW50LCBsZXQgYWxvbmUgcGhhc2UgMiBtaWxlc3RvbmUuPG86cD48L286 cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBw cm9wb3NlcyB0byBwcm92aWRlIGEgbmV3IGF1dGhlbnRpY2F0aW9uIG1ldGhvZCB0aGF0IGNhbiBt b3JlIGFjY3VyYXRlbHkgcmVmbGVjdCB0aGUgJnF1b3Q7dHJ1ZSZxdW90OyAoZm9yIHNvbWUgdmFs dWUgdGhlcmVvZikgYXV0aGVudGljaXR5IG9mIGEgbWVzc2FnZSwgYWxsb3dpbmcgRE1BUkMgdG8g YmVoYXZlIG1vcmUgYWNjdXJhdGVseS4mbmJzcDsgSG93IGlzIHRoYXQgbm90IGFuIGltcHJvdmVt ZW50PyZuYnNwOyBETUFSQyB3YXMgbWVhbnQNCiB0byBiZSBleHRlbnNpYmxlIHRvIGJldHRlciBh dXRoZW50aWNhdGlvbiBtZXRob2RzIGFzIHRoZXkgYXBwZWFyLCBhbmQgdGhpcyBpcyBhbiBpbnN0 YW5jZSBvZiBzdWNoLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TUg6IFRoaXMgaXMgbm90IGFu IGV4dGVuc2lvbiBvZiBETUFSQyBpdHNlbGYuIEl0IGxldmVyYWdlcyBhIERLSU0gbGlrZSBzaWdu aW5nIGFwcHJvYWNoIHRvIHByb3ZpZGUgYWRkaXRpb25hbCBkYXRhIHBvaW50cyB0byB2YWxpZGF0 b3JzIHdpc2hpbmcgdG8gaW1wbGVtZW50DQogbG9jYWwgcG9saWN5IGluIGEgbW9yZSBpbmZvcm1l ZCBtYW5uZXIuIFRoaXMgaXMgYSBudWFuY2VkIGJ1dCBpbXBvcnRhbnQgZGlmZmVyZW5jZSB1bmxl c3Mgc29tZW9uZSBpcyBzdWdnZXN0aW5nIG11bmdpbmcgQVJDIGludG8gRE1BUkMgaXRzZWxmLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Vbmxlc3MgQVJDIGNv bW1pdHMgdG8gYSBwdXJwb3NlIGNvbmdlbmlhbCB3aXRoIERNQVJDJ3MgY2hhcnRlciwgSSdkIGZp bmQgaXQ8YnI+DQpvYmplY3Rpb25hYmxlIGZvciB0aGlzIFdHIHRvIHRha2Ugb24gaXRzIHdvcmsu PGJyPg0KPGJyPg0KJmd0OyBEb2VzIGFueW9uZSBoYXZlIGFuIGFsdGVybmF0aXZlIHByb3Bvc2Fs Pzxicj4NCjxicj4NClRoZSAmcXVvdDtsZWFzdCBicm9rZW4mcXVvdDsgcHJvcG9zYWwgZm9yIHBo YXNlIDIgc2VlbXMgdG8gYmUgZGtpbS1jb25kaXRpb25hbC4mbmJzcDsgSXQ8YnI+DQplbWVyZ2Vk IGFzIGFuIG9yaWdpbmF0b3IgcHJvdG9jb2wsIHNvIGl0IGNhbiBkZXZlbG9wIHdpdGhvdXQgbXVk ZHlpbmcgQVJDLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5JIGhhdmUgYW4gdW5y ZWxlYXNlZCBpbXBsZW1lbnRhdGlvbiBvZiB0aGF0LiZuYnNwOyBJdCBhbHNvIG1vcmUgZWFzaWx5 IHF1YWxpZmllcyB1bmRlciBvdXIgY2hhcnRlciwgSU1ITy4mbmJzcDsgSSB0aGluayB3ZSBzaG91 bGQgYXQgbGVhc3QgYWxsb3cgZGlzY3Vzc2lvbiBvZiB0aGF0IG9uZS48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1IOiBJIHRob3VnaHQgcnVubmlu ZyBjb2RlIHdhcyBvbmUgb2YgdGhlIGNyaXRlcmlhLiBEa2ltLWNvbmRpdGlvbmFsIG5ldmVyIGdv dCBzaWduaWZpY2FudCBzdXBwb3J0LiBJ4oCZbSBub3QgYWdhaW5zdCBpdCBwZXIgc2UgYnV0DQog dW5sZXNzIHRoZXJlIGlzIGEgY29tcGVsbGluZyByZWFzb24gSSBwcmVmZXIgdG8gYXZvaWQgcmUt dmlzaXRpbmcgb2xkIGdyb3VuZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_CE39F90A45FF0C49A1EA229FC9899B052664D2BEUSCLES544agnaam_-- From nobody Tue May 17 13:43:39 2016 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 05DB512DDDD for ; Tue, 17 May 2016 13:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.428 X-Spam-Level: X-Spam-Status: No, score=-3.428 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=crash.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 rtiGOAw-RDiZ for ; Tue, 17 May 2016 13:43:30 -0700 (PDT) Received: from segv.crash.com (segv.crash.com [IPv6:2001:470:1:1e9::4415]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04F3612DDDC for ; Tue, 17 May 2016 13:43:29 -0700 (PDT) Received: from abort.crash.com (70-36-157-26.dsl.static.fusionbroadband.com [70.36.157.26]) (authenticated bits=0) by segv.crash.com (8.14.5/8.14.5/cci-colo-1.6) with ESMTP id u4HKhHRP042434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 17 May 2016 13:43:22 -0700 (PDT) (envelope-from smj@crash.com) X-DKIM: OpenDKIM Filter v2.4.3 segv.crash.com u4HKhHRP042434 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=201506-2k; t=1463517802; bh=asyBoBLpFwmhZsOJGQ8caRDQDuHmHGXQz4+qHY0QaLI=; h=Subject:To:References:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=On5ZzASUbjcbh/apRzvw740VClyc4HWNGa14AOYs2tYwvuHRuhwsAtQKz0PlMNF9x jcm8iarCL3Ni+X1nobZJCkPMGtWlkX8yWvGeau6WbA9EUgrcWR3A6BTnd4YK3UHNfd Jo4sJRuacMo9nGdPMgcTXpuW8ZqXID/2QXOIVXRWJEJFmmqfRu8ZUoicxSrObU0DJn pft+mktRZxCKcNwTvqgBingPe0M8EsiZ9eaykyHUQVicmyuOQcAEXmNIvo+6qWGF7D cUzV94TenZ/EWebhHUrqn34sd6wllg7Jminq/Yv8NFkBnJWME1izX6R5IDRRPxJ/dm Cfo4rJGA5rvNA== X-Authentication-Warning: segv.crash.com: Host 70-36-157-26.dsl.static.fusionbroadband.com [70.36.157.26] claimed to be abort.crash.com To: dmarc@ietf.org References: <20160511002303.14397.qmail@ary.lan> <57327D81.6050306@gmail.com> <57331D94.2010004@tana.it> <573B33DD.5040802@tana.it> From: Steven M Jones Organization: Crash Computing Message-ID: <7bc8a322-0d33-bc2e-edc9-ae18693e25f7@crash.com> Date: Tue, 17 May 2016 13:43:20 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (segv.crash.com [72.52.75.15]); Tue, 17 May 2016 13:43:22 -0700 (PDT) Archived-At: Subject: Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 17 May 2016 20:43:38 -0000 On 05/17/2016 12:53, Murray S. Kucherawy wrote: > > The charter enumerates three tracks, the first of which appears to allow > discussion of new protocols; in particular, one might argue that ARC is > a "form of DKIM signature that is better able to survive transit through > intermediaries". However, in the second track, it says "The working > group will not develop additional mail authentication technologies, but > may document authentication requirements that are desirable", and there > are chunks of ARC that are clearly new. (Having now implemented ARC, I > can attest that there was enough new code needed that I would call it > "new".) Seems to me you've identified a contradiction in the charter, rather than an objection to developing ARC... > I have an unreleased implementation of that. It also more easily > qualifies under our charter, IMHO. I think we should at least allow > discussion of that one. Why wouldn't we discuss that, or other proposals? --S. From nobody Tue May 17 13:47:26 2016 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 E67E612DDC2 for ; Tue, 17 May 2016 13:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.428 X-Spam-Level: X-Spam-Status: No, score=-3.428 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=crash.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 1QTpuRi6p0jg for ; Tue, 17 May 2016 13:47:23 -0700 (PDT) Received: from segv.crash.com (segv.crash.com [IPv6:2001:470:1:1e9::4415]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA15912D11C for ; Tue, 17 May 2016 13:47:22 -0700 (PDT) Received: from abort.crash.com (70-36-157-26.dsl.static.fusionbroadband.com [70.36.157.26]) (authenticated bits=0) by segv.crash.com (8.14.5/8.14.5/cci-colo-1.6) with ESMTP id u4HKlDi2042520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 17 May 2016 13:47:19 -0700 (PDT) (envelope-from smj@crash.com) X-DKIM: OpenDKIM Filter v2.4.3 segv.crash.com u4HKlDi2042520 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=201506-2k; t=1463518039; bh=a2zqgrcygQ2f/AjuRBU5HD8X1A6Rjt3PI31O3yDUmQE=; h=Subject:To:References:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=bRC08ESSiTyKT9dtSft9bbUl/6y3hjPvruQHAG6H0TqeU+U/zBYr4mEWaxHNAnY1x fHwlEVS26BoZjlXUdR7/ntN1sri2O7WlYD/6P1ytRBFiM3MsNAzfm18nHwq0TVPaN2 SYAQP30hfo4Dk6oPs/+J6ll+muod+cacK18Ej5VPLRFsmMSzDIyHhFC5ziB093TCwb 0O69c6f4SXgIA4sVIi+75xdXhivHIhpdJ8W8UdZVNgzBSPT1DcKy1oX6z5RRsJvwU/ UUjDCeqlA8QGzhDindjacc1fhe5cYY5I6oKA3O3P+N2lnGtn4xUPnVwVyKvxY52H3W UnLDTMUtiZrhA== X-Authentication-Warning: segv.crash.com: Host 70-36-157-26.dsl.static.fusionbroadband.com [70.36.157.26] claimed to be abort.crash.com To: dmarc@ietf.org References: <20160511002303.14397.qmail@ary.lan> <57327D81.6050306@gmail.com> <57331D94.2010004@tana.it> <573B33DD.5040802@tana.it> From: Steven M Jones Organization: Crash Computing Message-ID: <311003ba-36bd-3e4e-a151-93b4594034eb@crash.com> Date: Tue, 17 May 2016 13:47:17 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (segv.crash.com [72.52.75.15]); Tue, 17 May 2016 13:47:19 -0700 (PDT) Archived-At: Subject: Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 17 May 2016 20:47:25 -0000 On 05/17/2016 13:14, MH Michael Hammer (5304) wrote: > > MK: Absent a desire to form a distinct working group to develop ARC, I think > we need to discuss rechartering before we can entertain this motion. > > MH: If we need to re-charter then I think we should re-charter. There > are already implementations of ARC and there appears to be sufficient > support to justify the effort. I've had discussions with a few folks, and nobody seemed to think this was outside the existing charter. I hope they'll speak up if they still see things the same way... > MH: This is not an extension of DMARC itself. It leverages a DKIM like > signing approach to provide additional data points to validators wishing > to implement local policy in a more informed manner. This is a nuanced > but important difference unless someone is suggesting munging ARC into > DMARC itself. If ARC is approached as a standalone protocol, incorporating support for it into DMARC still involves changes to the DMARC specification at some point. For example, the ARC spec suggests concrete changes to the DMARC aggregate report's local_policy section. If that change in and of itself isn't worthy of work, do we need a clearer extension mechanism? > MK: I have an unreleased implementation of that. It also more easily > qualifies under our charter, IMHO. I think we should at least allow > discussion of that one. > > MH: I thought running code was one of the criteria. Dkim-conditional > never got significant support. I’m not against it per se but unless > there is a compelling reason I prefer to avoid re-visiting old ground. I have no objection to conditional signatures per se, and it seems appropriate to have a discussion of the merits. And I will refrain from starting that discussion now... ;) --S. From nobody Tue May 17 17:46:42 2016 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 CA65D12D563 for ; Tue, 17 May 2016 17:46:40 -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, FREEMAIL_FROM=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 Gm9lEtZZGUnb for ; Tue, 17 May 2016 17:46:39 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::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 576FC12D5C5 for ; Tue, 17 May 2016 17:46:39 -0700 (PDT) Received: by mail-pa0-x22b.google.com with SMTP id gj5so11599378pac.2 for ; Tue, 17 May 2016 17:46:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=r+Uj6y2iHcSthcfhqgmDmGxpLwa8CioE9WbHtHoWZoI=; b=zZGowKHI9RiD1+nuMStMwChyzNJm0UjsTYMzEfhEaZhQ7cGHYnXWinF3/6UsXj9Qu4 hDfrmt9+o9tanrLoac5J11gGssU8b+TOOc9FHiyp2NgZ5dEFmfHw/imk/cgBc8B56CqV nWu41wk4RNG+cw1fUOi1H5rrqcK/qj+9R3gh8daCuSnFqVLn8vXxNqefYp7tyfz47bZ7 78aVPJ7a2OhxG2FgSxShOXkcnJ/da06deH4zVaIX0LdPEgftQBkdGKYCXHSsLwTXU5hq BOsBgKmquqaXiSQ6kU84WSrZL9ONRga/jmFw2I4m6Wal1FyoO3JwVrYhQD53dUmQ7QYw utmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=r+Uj6y2iHcSthcfhqgmDmGxpLwa8CioE9WbHtHoWZoI=; b=B1jPRK9/LW2n1rLLKvM58hkEBWWU83k27Z78UCVKxnzQZfIBPHBU29PgJ75iGhd0ae u0zyY72LyIyP2TivQsFBS9GcKCDZNu54p3gpPv2RimnWPeGZnwsJL57rPrF3/ZDmGC/k M9yT89apgyZ2oBJL3ZPAKBjPo3nKDOKOa/AGcqbh9atLljMg/TI8IZHGOxty/TmP9RRU mPNZzQXgK3uoONIP/ubyQE7G5IjluPQK+FHYEwTiIczKs5jDXsH99QFlbmTvIqVpa0W0 S5MjmMBmRqt5XEjT8Ws6sSEIZMNOyZvrM7WmQigPW+xMpmgslXAF6LSTEv57HL5isCIE p+TQ== X-Gm-Message-State: AOPr4FUZMFabu4LdKrO7GoZjtKA//IJCTsBKkcOiSK2ebBJ9VMQNlxH9cVUF7g8JIQj9rA== X-Received: by 10.66.186.238 with SMTP id fn14mr6359297pac.6.1463532398928; Tue, 17 May 2016 17:46:38 -0700 (PDT) Received: from [192.168.11.47] (104-60-96-29.lightspeed.sntcca.sbcglobal.net. [104.60.96.29]) by smtp.gmail.com with ESMTPSA id h88sm7441795pfd.10.2016.05.17.17.46.35 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 May 2016 17:46:37 -0700 (PDT) To: "Murray S. Kucherawy" References: <20160511002303.14397.qmail@ary.lan> <57327D81.6050306@gmail.com> <57331D94.2010004@tana.it> <573B33DD.5040802@tana.it> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Tue, 17 May 2016 17:46:04 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: DMARC , Barry Leiba Subject: Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 18 May 2016 00:46:41 -0000 On 5/17/2016 12:53 PM, Murray S. Kucherawy wrote: > he charter enumerates three tracks, the first of which appears to allow > discussion of new protocols; in particular, one might argue that ARC is > a "form of DKIM signature that is better able to survive transit through > intermediaries". However, in the second track, it says "The working > group will not develop additional mail authentication technologies, but > may document authentication requirements that are desirable", and there > are chunks of ARC that are clearly new. (Having now implemented ARC, I > can attest that there was enough new code needed that I would call it > "new".) > > Absent a desire to form a distinct working group to develop ARC, I think > we need to discuss rechartering before we can entertain this motion. I don't. Relevant charter text: >> The working group will explore possible updates and extensions to the >> specifications in order to address limitations and/or add >> capabilities. > ... >> Specifications produced by the working group > ... >> 1. Addressing the issues with indirect mail flows >> >> The working group will specify mechanisms for reducing or eliminating >> the DMARC's effects on indirect mail flows, including deployed >> behaviors of many different intermediaries, such as mailing list >> managers, automated mailbox forwarding services, and MTAs that >> perform enhanced message handling that results in message >> modification. Among the choices for addressing these issues are: >> >> - A form of DKIM signature that is better able to survive transit >> through intermediaries. >> >> - Collaborative or passive transitive mechanisms that enable an >> intermediary to participate in the trust sequence, propagating >> authentication directly or reporting its results. > > as against: > >> 2. Reviewing and improving the base DMARC specification >> >> The working group will not develop additional mail authentication >> technologies, but may document authentication requirements that are >> desirable. Any interesting topic produces real challenges in charter-writing and even more challenges in charter-reading. However I read Item 1 as exactly matching the issue at hand and I read that text as being unambiguously perfect for the specific proposal at hand. (Hint: this was not an accident.) The current topic has nothing to do with Item 2, which is where the constraint is placed. So the constraint is not relevant for the current topic. Yes, one certainly could wish for better writing. Sorry about that. But really... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue May 17 17:57:32 2016 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 6AA4B12D55D for ; Tue, 17 May 2016 17:57:31 -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 i33ga5YKFzhP for ; Tue, 17 May 2016 17:57:30 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::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 E275412D5C5 for ; Tue, 17 May 2016 17:57:16 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id x194so33403829ywd.0 for ; Tue, 17 May 2016 17:57:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=gJChAM4elDld1Y7bT6kxtfRnj+yWOo8pHGKrm118ydc=; b=HcAtV3ZDKtzW3zGqtRwqUx/Su8AzGQyHU8Y6kQ16nDIO0L8BtnWA6En+/FfQs3ScLY aMpQHqVuKelkxlNt3AtNN/LKi2JNr3P/4SyrO/E3/5SZnXTcEXEY5fTuBLkixShTt8XR oQNurr0NqxBWqH/HAY3PoVJWgpNu9FLJIYocKAG38/PWboi3Ca1MCJiQKEBkk1I4qmlO 8R69JmEsJ49eAE9e9LzXofUMs5dQNNuUIObpXLbwOZF3qP884Ufp1fl48+YOKx7kR41z qdGBwHJypTMlcaMX0Qtk840Xy3driFHLgokdbghFJiBiiyoVVE6x2Q/rvWC0hE4fVweK NW/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=gJChAM4elDld1Y7bT6kxtfRnj+yWOo8pHGKrm118ydc=; b=hJA4YYmogY5UFyS9Uwa5K2UkYHSyo+x4YH64Kgj25YrHihazK8mfw2zaHpyJLuKbVi TG+TK+PXogAusM1FBXl6Q4ByDxWZl/9z102DfUxStRTYm7VHcwAmacpS8N2pXG1WwDfa QGi4IcCf7e0p4if3s271O/LvTys8MIWVuKnlkOJpmb+9R2JPQINZzW2mmG6OcBg5QeER dqG+LiTfttl9QrS4+21MSdTkGZCJHVNm/raF7qa+HrRqUZxk20DyeAhtsUUW9K15sgD7 CboONKr+Jk4HtljoxLUzq8YsUKiSttnA/XgvkSw+y26aR9tXcp2M9L5BYCrS5Qe3pv2y ivsg== X-Gm-Message-State: AOPr4FUDMLjZ49UcbI+Fm5BR2ggT9ZQcM/CkOxsgtUz1iMrcqhOpp6iJTSNqag9zo7MG725zcIzKVVaYxCVAKg== MIME-Version: 1.0 X-Received: by 10.129.110.196 with SMTP id j187mr2677690ywc.209.1463533036278; Tue, 17 May 2016 17:57:16 -0700 (PDT) Received: by 10.37.103.215 with HTTP; Tue, 17 May 2016 17:57:16 -0700 (PDT) In-Reply-To: <7bc8a322-0d33-bc2e-edc9-ae18693e25f7@crash.com> References: <20160511002303.14397.qmail@ary.lan> <57327D81.6050306@gmail.com> <57331D94.2010004@tana.it> <573B33DD.5040802@tana.it> <7bc8a322-0d33-bc2e-edc9-ae18693e25f7@crash.com> Date: Tue, 17 May 2016 17:57:16 -0700 Message-ID: From: "Murray S. Kucherawy" To: Steven M Jones Content-Type: multipart/alternative; boundary=001a11490af4be994605331356c8 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 18 May 2016 00:57:31 -0000 --001a11490af4be994605331356c8 Content-Type: text/plain; charset=UTF-8 On Tue, May 17, 2016 at 1:43 PM, Steven M Jones wrote: > > Seems to me you've identified a contradiction in the charter, rather > than an objection to developing ARC... > > ...and I thought that's how I'd characterized it. But if the charter says we can't take on this work, or is ambiguous on that point, I think our process dictates we have to sort that out. I don't think I made any comment resembling "We shouldn't talk about ARC here." -MSK --001a11490af4be994605331356c8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, May 17, 2016 at 1:43 PM, Steven M Jones <smj@crash.c= om> wrote:

Seems to me you've identified a contradiction in the charter, ra= ther
than an objection to developing ARC...


...and I thoug= ht that's how I'd characterized it.=C2=A0 But if the charter says w= e can't take on this work, or is ambiguous on that point, I think our p= rocess dictates we have to sort that out.

I don't thi= nk I made any comment resembling "We shouldn't talk about ARC here= ."

-MSK
=C2=A0
--001a11490af4be994605331356c8-- From nobody Tue May 17 18:08:37 2016 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 0DD1C12D72F for ; Tue, 17 May 2016 18:08:37 -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 O8ddMnVHtsQo for ; Tue, 17 May 2016 18:08:35 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34C0512D54F for ; Tue, 17 May 2016 18:08:34 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id x189so33526273ywe.3 for ; Tue, 17 May 2016 18:08:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=KVz7M+t2dx1kzCel2A30dqFa3G5h+nfPwLgpNyFcvh0=; b=1DdEenF/qLOyGkgirxOrotnoyH9cskePFq049aF8T0NhoeawRyzF/N5UPiJCWNrZ16 nkTElzxJWVL1MzX6k+UggsJn2g8Yl8L+qbMCSRqAdIoSGsFZhzS8OM3NkSNbxJ/VXDvN lcWPI+RIGePwKOhFSRn3PWkpCwCMcoEJviKqkcGsSvcpj9X0V60OxZBU63xu/1e0j1d1 jSsuFO5niKibHORQtRsKO6sW93MgcylmqLbuti3CU8NWG9nB3BGCCZCJyl5/JKawFlCO PDfUTIqUBfVyJahfg9myBtooDSDPu38g/S3CWBPg52Y+/fcywnzA5+EVdMHTS4KkxWxj i7/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=KVz7M+t2dx1kzCel2A30dqFa3G5h+nfPwLgpNyFcvh0=; b=XdJ1NKY6kVelAxpWJpjUyktNMtWndl/J2C5zbJoJp+RV5VplZS1VFPRqlPOqgFdyou KINcdrIIk094Jz9W5xzRFcoZk3fmvz2JQjLAT1BRTFAvQBMqu1q1tOy9yoeOCN7Ialjw h4jmlgs5y0us+EXlXUY0L52NNUaqFay28U2/llTVl3Hi6tgpi1ynW4aArG0gdlrDXyLM hPM/qVWGDkOQUwulg9RKEA6YOo5sKrze9gtQ7efQGW5s8TwDS3VD4qYqzg87ddKxx9yT TWxL0JrlwmqutGVVKh/XKze8RBLM0CaJONJfDyT4aghdUdyv4SotR4Zy5GDoE+x71qxq vvcg== X-Gm-Message-State: AOPr4FUsmez10Y1VTTb8kt3vxRA2oasBTqmvQ+7zoIgSK1iDjmuikh7sCGlVpoysX/M4/Sle/D6EIpEcSMBTbg== MIME-Version: 1.0 X-Received: by 10.37.77.194 with SMTP id a185mr2305381ybb.3.1463533713505; Tue, 17 May 2016 18:08:33 -0700 (PDT) Received: by 10.37.103.215 with HTTP; Tue, 17 May 2016 18:08:33 -0700 (PDT) In-Reply-To: References: <20160511002303.14397.qmail@ary.lan> <57327D81.6050306@gmail.com> <57331D94.2010004@tana.it> <573B33DD.5040802@tana.it> Date: Tue, 17 May 2016 18:08:33 -0700 Message-ID: From: "Murray S. Kucherawy" To: Dave Crocker Content-Type: multipart/alternative; boundary=001a113f52721c46dd0533137f90 Archived-At: Cc: DMARC , Barry Leiba Subject: Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 18 May 2016 01:08:37 -0000 --001a113f52721c46dd0533137f90 Content-Type: text/plain; charset=UTF-8 On Tue, May 17, 2016 at 5:46 PM, Dave Crocker wrote: > Relevant charter text: > > The working group will explore possible updates and extensions to the >>> specifications in order to address limitations and/or add >>> capabilities. >>> >> ... >> >>> Specifications produced by the working group >>> >> ... >> >>> 1. Addressing the issues with indirect mail flows >>> >>> The working group will specify mechanisms for reducing or eliminating >>> the DMARC's effects on indirect mail flows, including deployed >>> behaviors of many different intermediaries, such as mailing list >>> managers, automated mailbox forwarding services, and MTAs that >>> perform enhanced message handling that results in message >>> modification. Among the choices for addressing these issues are: >>> >>> - A form of DKIM signature that is better able to survive transit >>> through intermediaries. >>> >>> - Collaborative or passive transitive mechanisms that enable an >>> intermediary to participate in the trust sequence, propagating >>> authentication directly or reporting its results. >>> >> >> as against: >> >> 2. Reviewing and improving the base DMARC specification >>> >>> The working group will not develop additional mail authentication >>> technologies, but may document authentication requirements that are >>> desirable. >>> >> > > Any interesting topic produces real challenges in charter-writing and even > more challenges in charter-reading. > Indeed, I've yet to encounter a perfect charter. > However I read Item 1 as exactly matching the issue at hand and I read > that text as being unambiguously perfect for the specific proposal at > hand. (Hint: this was not an accident.) > > The current topic has nothing to do with Item 2, which is where the > constraint is placed. So the constraint is not relevant for the current > topic. > That feels like a convenient interpretation to me, for two reasons: 1) It feels like a bit of a stretch to call ARC "a form of DKIM signature", so I have to assume ARC falls under the second bullet. 2) The section of the charter you cite enumerates three "tracks', which it later calls "phases". If we're done with the first phase by sending our sole document to the IESG (which has happened, and the chairs have explicitly declared phase one done), then we appear to have entered a phase for which the charter proscribes things like ARC. > Yes, one certainly could wish for better writing. Sorry about that. But > really... I'm not opposed to developing ARC within this WG or even within the IETF. I just want to make sure we're following our own rules here, and that someone who later decides he hates ARC has no basis to appeal. If this needs fixing, let's fix it. If nobody really cares, let's move on. -MSK --001a113f52721c46dd0533137f90 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, May 17, 2016 at 5:46 PM, Dave Crocker <dcrocker@= gmail.com> wrote:


Relevant charter text:

The working group will explore possible updates and extensions to the
specifications in order to address limitations and/or add
capabilities.
...
Specifications produced by the working group
...
=C2=A01. Addressing the issues with indirect mail flows

The working group will specify mechanisms for reducing or eliminating
the DMARC's effects on indirect mail flows, including deployed
behaviors of many different intermediaries, such as mailing list
managers, automated mailbox forwarding services, and MTAs that
perform enhanced message handling that results in message
modification. Among the choices for addressing these issues are:

- A form of DKIM signature that is better able to survive transit
through intermediaries.

- Collaborative or passive transitive mechanisms that enable an
intermediary to participate in the trust sequence, propagating
authentication directly or reporting its results.

as against:

=C2=A02. Reviewing and improving the base DMARC specification

The working group will not develop additional mail authentication
technologies, but may document authentication requirements that are
desirable.


Any interesting topic produces real challenges in charter-writing and even = more challenges in charter-reading.

Ind= eed, I've yet to encounter a perfect charter.
=C2=A0
However I read Item 1 as exactly matching the issue at hand and I read that= text as being unambiguously perfect for the specific proposal at hand.=C2= =A0 (Hint:=C2=A0 this was not an accident.)

The current topic has nothing to do with Item 2, which is where the constra= int is placed. So the constraint is not relevant for the current topic.
=

That feels like a convenient interpretatio= n to me, for two reasons:

1) It feels like a bit of a stretch to cal= l ARC "a form of DKIM signature", so I have to assume ARC falls u= nder the second bullet.

2) The section of the charter you cite enume= rates three "tracks', which it later calls "phases".=C2= =A0 If we're done with the first phase by sending our sole document to = the IESG (which has happened, and the chairs have explicitly declared phase= one done), then we appear to have entered a phase for which the charter pr= oscribes things like ARC.
=C2=A0
Yes, one certainly could wish for better writing.=C2=A0 Sorry about that. B= ut really...

I'm not opposed to develop= ing ARC within this WG or even within the IETF.=C2=A0 I just want to make s= ure we're following our own rules here, and that someone who later deci= des he hates ARC has no basis to appeal.=C2=A0 If this needs fixing, let= 9;s fix it.=C2=A0 If nobody really cares, let's move on.

<= div>-MSK
--001a113f52721c46dd0533137f90-- From nobody Tue May 17 18:16:27 2016 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 A24A012D5E4 for ; Tue, 17 May 2016 18:16: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, FREEMAIL_FROM=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 Cqe1rFHBG_8H for ; Tue, 17 May 2016 18:16:24 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D026112B01C for ; Tue, 17 May 2016 18:16:24 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id c189so12713857pfb.3 for ; Tue, 17 May 2016 18:16:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=hGMnNDfe9/tQokflGb8kSOPzrq3ekcgwazwB/dQPiQM=; b=NkIfCwYTr2zvy5I8ZkdWZr64b/K9pjJ4BuFY+ktcnF/0I9wdA1HIKwU9l4ytZnZ/JS dehNGymSJALF+bsgpFAEx/mQGcfgnWDVgyPUFX3m8qc7j342Kt/0DHWaj07kwCftLcxE 5atFCm9MvtBLjGC/ETijnvMxuq07pUbQCZNwsqYG4D7phEcPjtFG4YUC961IZttOu0XX TeFyWACKfJ//JXhEi4/QOIy3zcbStnRkzC8F1bRdTuWj4XJBgnXH4ybhdGHVpNfQrD/m q92hj4SAq//ue+nIZY2Gc4nMIM1Ky3xncZnUSNv9EHKJ6CXdyHDpku3KBHoQHDBbgFy7 GIGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=hGMnNDfe9/tQokflGb8kSOPzrq3ekcgwazwB/dQPiQM=; b=Sbos5eggKCZqwjVmQotMWzyo6IdZFZpzyculJEK5A1W3O0ZYXLX6ttaYNFXZxuxFTy oXjejR+D+CGxjoWshfTY7yb7e1QuoTAhArPeoHERppZc3pQAvAL7WZhZsUPRgNi/vJXI vc81fc0NEqcv4ZQAQfT8vSGdmFftMaIeVDOEoGgRJowvhf2ONfZFM+NIPvv0HjIYqsAN 8yisw0MVoiuWFN4fK45ThYDkcKdckplMZgU/QYmlIPIyNBf+nnKQWuy0sH5nxPSDz9GF FGbtKcpLGzK1WtiHoVXvBcjk+k1lGSb68nRlDUoCLAt6lhSjI+qqNZGcbbzZpPED36wR Axmg== X-Gm-Message-State: AOPr4FVZJZFebgWqah04N2jzxDL34RRHKC0WKlHKUhYu89aNYbud0Q8Sx7j4ati5CkzwaA== X-Received: by 10.98.4.195 with SMTP id 186mr6647279pfe.154.1463534184332; Tue, 17 May 2016 18:16:24 -0700 (PDT) Received: from [192.168.11.47] (104-60-96-29.lightspeed.sntcca.sbcglobal.net. [104.60.96.29]) by smtp.gmail.com with ESMTPSA id zn12sm7535072pab.14.2016.05.17.18.16.21 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 May 2016 18:16:23 -0700 (PDT) To: "Murray S. Kucherawy" References: <20160511002303.14397.qmail@ary.lan> <57327D81.6050306@gmail.com> <57331D94.2010004@tana.it> <573B33DD.5040802@tana.it> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <7ff3f3d4-4dc2-6629-64ae-5263f79d5b34@gmail.com> Date: Tue, 17 May 2016 18:15:50 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: DMARC , Barry Leiba Subject: Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 18 May 2016 01:16:26 -0000 On 5/17/2016 6:08 PM, Murray S. Kucherawy wrote: > On Tue, May 17, 2016 at 5:46 PM, Dave Crocker > wrote: > > > Relevant charter text: > > The working group will explore possible updates and > extensions to the > specifications in order to address limitations and/or add > capabilities. > > ... > > Specifications produced by the working group > > ... > > 1. Addressing the issues with indirect mail flows > > The working group will specify mechanisms for reducing or > eliminating > the DMARC's effects on indirect mail flows, including deployed > behaviors of many different intermediaries, such as mailing list > managers, automated mailbox forwarding services, and MTAs that > perform enhanced message handling that results in message > modification. Among the choices for addressing these issues are: > > - A form of DKIM signature that is better able to survive > transit > through intermediaries. > > - Collaborative or passive transitive mechanisms that enable an > intermediary to participate in the trust sequence, propagating > authentication directly or reporting its results. > > > as against: > > 2. Reviewing and improving the base DMARC specification > > The working group will not develop additional mail > authentication > technologies, but may document authentication requirements > that are > desirable. > > > > Any interesting topic produces real challenges in charter-writing > and even more challenges in charter-reading. > > > Indeed, I've yet to encounter a perfect charter. > > > However I read Item 1 as exactly matching the issue at hand and I > read that text as being unambiguously perfect for the specific > proposal at hand. (Hint: this was not an accident.) > > The current topic has nothing to do with Item 2, which is where the > constraint is placed. So the constraint is not relevant for the > current topic. > > > That feels like a convenient interpretation to me, for two reasons: > > 1) It feels like a bit of a stretch to call ARC "a form of DKIM > signature", so I have to assume ARC falls under the second bullet. You seem to have missed the second sub-bullet under Item 1: > Collaborative or passive transitive mechanisms that enable an > intermediary to participate in the trust sequence, propagating > authentication directly or reporting its results. That exactly describes ARC. (Did I mention that that wasn't an accident?) > I'm not opposed to developing ARC within this WG or even within the > IETF. I just want to make sure we're following our own rules here, and > that someone who later decides he hates ARC has no basis to appeal. If > this needs fixing, let's fix it. If nobody really cares, let's move on. I get that the issue being raised here is purely procedural and that there is no intended (or even actual) resistance to doing the work. My point is that the points I'm explaining afford a careful reading of the charter and that it shows that the charter /already/ fully covers the proposed work. And not as a stretch. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue May 17 21:53:00 2016 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 3836F12B028 for ; Tue, 17 May 2016 21:52:58 -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 XKQtJcKeQaqX for ; Tue, 17 May 2016 21:52:56 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002: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 915EB12B027 for ; Tue, 17 May 2016 21:52:56 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id g133so37219066ywb.2 for ; Tue, 17 May 2016 21:52:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=yx9WpOR3h79FcO7dJSnEIngezS2idrqEa+06INm3x+w=; b=WxPwHd9ZDDZd+YMF9LiYoxYL0zXEiEEv3Kb7zvyse8kTsQw6OmShO1u17c2RVUv1s9 U3PKKyQgGtlYYcu9EstE88lzR8VVZUVhG7BGvZaJXV8NoKenZc0CaXrffvcNHuYdiu0p kbn7BcgVeKpyc4ydXnMyXRVMDWdLVAPrzhTh5pbL7GUa/AfrQNJM7YlJO/LNfjiu5VQQ XurM/fLR2is6F8noSt/JpFP1awVf3OtupAlZaP8Mmk/YDZpstBgMAa1PwXHenXEZOMtq XYHygUYlAZRjiJyS0Ybih/4OYleio79DOuMMngN/GQ+fJucJJbqXSpR+m6qYHP1jD2/T QdRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=yx9WpOR3h79FcO7dJSnEIngezS2idrqEa+06INm3x+w=; b=ImQYhyROfFsRQNeIigXBFyEqD21IpzVRdevTLj4JuQQgw42LAmoVtRbPUcsvvxEFNS SER9fp0aA3dQteS8RueLRwjyprtWveiRndyK8rkstgaZElCBNtgulAD/1ch1CcBfAigu 0HjphTGAJFQ3EB9DWhIl0zswhaCpD/ynKcBqOVnENZOR5RyNtj267TRDqqKIlJkZ3Eoz DWkQRXr+n0MF9vVBxbRvhrUnXZHrIs3Ab+Rspkt7e/r0tavMhV2krpDlH3yktCJMKxt2 Z4y8NPB0HOc8BjaMazCRY9ZGuyqSbTaq3XKqxXyRw4aN6Eq9BwjLSMMyksErtmBLatBU rd3w== X-Gm-Message-State: AOPr4FXR9fYhR+JmQ9DEv0QDZTgpDprAp9ZRmNXBkccTrhw9wSvcEpwu1/60a5sVbmsSRPCMgD9CYgb+DInKSA== MIME-Version: 1.0 X-Received: by 10.37.106.85 with SMTP id f82mr2772670ybc.108.1463547175794; Tue, 17 May 2016 21:52:55 -0700 (PDT) Received: by 10.37.103.215 with HTTP; Tue, 17 May 2016 21:52:55 -0700 (PDT) In-Reply-To: <7ff3f3d4-4dc2-6629-64ae-5263f79d5b34@gmail.com> References: <20160511002303.14397.qmail@ary.lan> <57327D81.6050306@gmail.com> <57331D94.2010004@tana.it> <573B33DD.5040802@tana.it> <7ff3f3d4-4dc2-6629-64ae-5263f79d5b34@gmail.com> Date: Tue, 17 May 2016 21:52:55 -0700 Message-ID: From: "Murray S. Kucherawy" To: Dave Crocker Content-Type: multipart/alternative; boundary=001a113fc884869d8f053316a175 Archived-At: Cc: DMARC , Barry Leiba Subject: Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 18 May 2016 04:52:58 -0000 --001a113fc884869d8f053316a175 Content-Type: text/plain; charset=UTF-8 On Tue, May 17, 2016 at 6:15 PM, Dave Crocker wrote: > > 1) It feels like a bit of a stretch to call ARC "a form of DKIM >> signature", so I have to assume ARC falls under the second bullet. >> > > You seem to have missed the second sub-bullet under Item 1: > I assure you I didn't. I even said, clearly I thought: "...so I have to assume ARC falls under the second bullet." > Collaborative or passive transitive mechanisms that enable an >> intermediary to participate in the trust sequence, propagating >> authentication directly or reporting its results. >> > > That exactly describes ARC. (Did I mention that that wasn't an accident?) > And I agree, but then I also mentioned that we're now operating under the second phase of the charter, or so the chairs seemed to indicate explicitly with their "phase 1 is done" message. This citation is in the first; the proscription against "additional mail authentication technologies" (which also, by the way, exactly describes ARC) that I'm worried about is in the second. -MSK --001a113fc884869d8f053316a175 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, May 17, 2016 at 6:15 PM, Dave Crocker <dcrocker@= gmail.com> wrote:

1) It feels like a bit of a stretch to call ARC "a form of DKIM
signature", so I have to assume ARC falls under the second bullet.

You seem to have missed the second sub-bullet under Item 1:

I assure you I didn'= t.=C2=A0 I even said, clearly I thought:=C2=A0 "...so I have to assume= ARC falls under the second bullet."


Collaborative or passive transitive mechanisms that enable an
intermediary to participate in the trust sequence, propagating
authentication directly or reporting its results.

 That exactly describes ARC.=C2=A0 (Did I mention that that wasn't an ac= cident?)

And I agree, but then I also mentioned = that we're now operating under the second phase of the charter, or so t= he chairs seemed to indicate explicitly with their "phase 1 is done&qu= ot; message.=C2=A0 This citation is in the first; the proscription against = "additional mail authentication technologies" (which also, by the= way, exactly describes ARC) that I'm worried about is in the second.

-MSK
--001a113fc884869d8f053316a175-- From nobody Tue May 17 22:23:14 2016 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 A6AE512B01B for ; Tue, 17 May 2016 22:23:12 -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 BWo-Hfc1OBQ0 for ; Tue, 17 May 2016 22:23:11 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::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 569D412B008 for ; Tue, 17 May 2016 22:23:11 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id x194so37655024ywd.0 for ; Tue, 17 May 2016 22:23:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=6hti/3NQaczNvUrN3dvXifk+gNkVPlew96Kgv26q3Uo=; b=kIfIElAMlAjN1akZ/4ClqEvwcKLJWWW2iM+WNgdBbxH2azh/p8hEp2CH15TiG18p1N 7q7UxBojlp0VxOlKUtGZRuk9fV1Jw+ZSsJ+1uCjx1N5b5CqGpe7DFueh1Pjav9kJNled wrb8onMXP+FT6EjbLPvnqKY0NjB3+JAvok/ZcZCUIIHaSLA+zSpNKbOFvBCihYtEGUQc GKWOaO2bNLZ1YPBhrJKU4ead+uXiTYMjlNKAN+VyIru5r3dCYAqQcEVPWq4S+xmnjyIl 7EiqZMkpetKEIbJjwnzctH2jp9tQBbt+TbWUJhkual5TbdaNuXH8qCJwFgH677/AkW6H QPPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=6hti/3NQaczNvUrN3dvXifk+gNkVPlew96Kgv26q3Uo=; b=Kdo6KOGKOuQisvDSrUtICYcKLgGbZAcI2N+HYENpa1xjbU/ATQPZLxpvy6O9df2X4Y s8ybbFkVTlq50LKnMUHnnLjSnlXMuslhMdpwV9toZYxl7Zyy6Ks7t1Koc/g6c1jpRTJD nHVWPh3w0FJQ6e3r2p0QmhMabitVe3BaIo4ibzA1c7XeB5aPiIXr3gDeCJN0MY9yv/h0 y1CP4yWBPdEFDp+eKrESBRDOGXmMc35AlUvFLunhn9ruaq7u3OXI1K2FWXy7JSga4VUm vOgZon1qNvH6/Wu+40R7HdvYamEbkYYIg4IKQ/jBE8BLNveRfv2IT5e9ew9+o+9ei5Kg PSZQ== X-Gm-Message-State: AOPr4FWElAQvMsNOG4EY5xhJ0PStB1T9tYsiFKSssiQ0HU+mW1P7bRbaGenO9GBvIQI1ie3J34fbYkVUNTEh8Q== MIME-Version: 1.0 X-Received: by 10.129.27.9 with SMTP id b9mr2891050ywb.173.1463548990607; Tue, 17 May 2016 22:23:10 -0700 (PDT) Received: by 10.37.103.215 with HTTP; Tue, 17 May 2016 22:23:10 -0700 (PDT) In-Reply-To: References: <20160511002303.14397.qmail@ary.lan> <57327D81.6050306@gmail.com> <57331D94.2010004@tana.it> <573B33DD.5040802@tana.it> <7ff3f3d4-4dc2-6629-64ae-5263f79d5b34@gmail.com> Date: Tue, 17 May 2016 22:23:10 -0700 Message-ID: From: "Murray S. Kucherawy" To: Dave Crocker Content-Type: multipart/alternative; boundary=001a1142a41ab2592d0533170d6f Archived-At: Cc: DMARC , Barry Leiba Subject: Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 18 May 2016 05:23:12 -0000 --001a1142a41ab2592d0533170d6f Content-Type: text/plain; charset=UTF-8 On Tue, May 17, 2016 at 9:52 PM, Murray S. Kucherawy wrote: > And I agree, but then I also mentioned that we're now operating under the > second phase of the charter, or so the chairs seemed to indicate explicitly > with their "phase 1 is done" message. This citation is in the first; the > proscription against "additional mail authentication technologies" (which > also, by the way, exactly describes ARC) that I'm worried about is in the > second. > Reducing this to my basic issue, setting aside the matter of phases: There's one clause in the charter that says ARC is fine, and one that proscribes it. You appear to be claiming that the first one wins over the second, plain and simple. I don't understand why it's plain and simple. Why do they not have equal effect? Is there some "default allow" nuance when interpreting ambiguous charters? -MSK --001a1142a41ab2592d0533170d6f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, May 17, 2016 at 9:52 PM, Murray S. Kucherawy <s= uperuser@gmail.com> wrote:
<= div>And I agree, but then I also mentioned that we're now operating und= er the second phase of the charter, or so the chairs seemed to indicate exp= licitly with their "phase 1 is done" message.=C2=A0 This citation= is in the first; the proscription against "additional mail authentica= tion technologies" (which also, by the way, exactly describes ARC) tha= t I'm worried about is in the second.
Reducing this to my basic issue, setting aside the matter of p= hases:

There's one clause in the charter that says AR= C is fine, and one that proscribes it.=C2=A0 You appear to be claiming that= the first one wins over the second, plain and simple.=C2=A0 I don't un= derstand why it's plain and simple.=C2=A0 Why do they not have equal ef= fect?=C2=A0 Is there some "default allow" nuance when interpretin= g ambiguous charters?

-MSK
--001a1142a41ab2592d0533170d6f-- From nobody Tue May 17 22:58:53 2016 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 ED9A512B03E for ; Tue, 17 May 2016 22:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.426 X-Spam-Level: X-Spam-Status: No, score=-3.426 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, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rolandturner.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 LsWybOlk5msU for ; Tue, 17 May 2016 22:58:51 -0700 (PDT) Received: from sg.rolandturner.com (sg.rolandturner.com [175.41.138.242]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75BC112B04F for ; Tue, 17 May 2016 22:58:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=rolandturner.com; s=20120325; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:To:From:Cc:References:Subject; bh=ad/P7xu6+GmFI1FQzVpqQ7M7uXBBwnbd/qSETyXZjVc=; b=SdynsL7BwRoB/SrtAVUKmW3f8vxYPRpv1bP3mRjxZ2Cd8QRYI2GZVB5BNRn+D7PkvxlgvWDyqcfdP3wBdvdcw3mJimCbmW2yqC+kqb/DLh/+/LsRm3fv40vV5Y01Pzs4O3MF803i89lyV8tXiRvUoEosKVCPaUSxc+r9S0umbnQ=; Received: from [116.12.149.133] (port=56328 helo=[10.100.1.116]) by sg.rolandturner.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1b2uVL-0004PZ-Eu; Wed, 18 May 2016 05:58:47 +0000 References: <20160511002303.14397.qmail@ary.lan> <57327D81.6050306@gmail.com> <57331D94.2010004@tana.it> <573B33DD.5040802@tana.it> <7ff3f3d4-4dc2-6629-64ae-5263f79d5b34@gmail.com> From: Roland Turner To: DMARC Message-ID: <573C0496.4060603@rolandturner.com> Date: Wed, 18 May 2016 13:58:46 +0800 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------070300030303040301090508" Archived-At: Cc: Barry Leiba Subject: Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 18 May 2016 05:58:53 -0000 This is a multi-part message in MIME format. --------------070300030303040301090508 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 05/18/2016 01:23 PM, Murray S. Kucherawy wrote: > On Tue, May 17, 2016 at 9:52 PM, Murray S. Kucherawy > > wrote: > > And I agree, but then I also mentioned that we're now operating > under the second phase of the charter, or so the chairs seemed to > indicate explicitly with their "phase 1 is done" message. This > citation is in the first; the proscription against "additional > mail authentication technologies" (which also, by the way, exactly > describes ARC) that I'm worried about is in the second. > > > Reducing this to my basic issue, setting aside the matter of phases: > > There's one clause in the charter that says ARC is fine, and one that > proscribes it. You appear to be claiming that the first one wins over > the second, plain and simple. I don't understand why it's plain and > simple. Why do they not have equal effect? Is there some "default > allow" nuance when interpreting ambiguous charters? Weighing into a conversation that I only half understand, the charter appears to talk about 3 separate Tracks, the apparent implication being that any work item for this WG needs to be in scope for at least one of those Tracks, not that a work item needs to fit into all of them; I would suggest that applying the latter interpretation would (a) contradict the plain language of the charter, and (b) disqualify almost all work items that the WG might consider. As ARC fits squarely into scope for Track 1, the fact that it has characteristics which preclude its being in scope for Track 2 does not by itself put it out of scope for this WG. There is no contradiction here. Separately, the WG's work has been divided into three phases which, although not explained, align approximately with one track each and appear to have been set up to focus the WG's efforts sequentially on one item at a time with a view to actually getting deliverables delivered. This gives rise to the observation that ARC is in scope for Phase I but not in scope for Phase II. So far so good, except that Phase I is currently considered to be complete, meaning that ARC is not in scope for the current or remaining Phases, despite it being in scope for the WG. The good news is that reopening a Phase does not require re-chartering, just consensus of the WG, which is presumably the reason for Barry's question. The dilemma would appear to be that reopening Phases willy-nilly would risk slowing the WG's progress still further, while slavishly sticking to the plan would exclude work on a very worthwhile mechanism which (a) came into being after the charter was written, (b) is a near perfect match for one of the Phase I proposed items, and (c) provides worthwhile capabilities for that proposed item that no other mechanism addressed in Phase I provides. My view is that ARC is a sufficiently compelling addition that reopening Phase I is warranted. - Roland --------------070300030303040301090508 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 05/18/2016 01:23 PM, Murray S. Kucherawy wrote:

On Tue, May 17, 2016 at 9:52 PM, Murray S. Kucherawy <superuser@gmail.com> wrote:
And I agree, but then I also mentioned that we're now operating under the second phase of the charter, or so the chairs seemed to indicate explicitly with their "phase 1 is done" message.  This citation is in the first; the proscription against "additional mail authentication technologies" (which also, by the way, exactly describes ARC) that I'm worried about is in the second.

Reducing this to my basic issue, setting aside the matter of phases:

There's one clause in the charter that says ARC is fine, and one that proscribes it.  You appear to be claiming that the first one wins over the second, plain and simple.  I don't understand why it's plain and simple.  Why do they not have equal effect?  Is there some "default allow" nuance when interpreting ambiguous charters?

Weighing into a conversation that I only half understand, the charter appears to talk about 3 separate Tracks, the apparent implication being that any work item for this WG needs to be in scope for at least one of those Tracks, not that a work item needs to fit into all of them; I would suggest that applying the latter interpretation would (a) contradict the plain language of the charter, and (b) disqualify almost all work items that the WG might consider. As ARC fits squarely into scope for Track 1, the fact that it has characteristics which preclude its being in scope for Track 2 does not by itself put it out of scope for this WG. There is no contradiction here.

Separately, the WG's work has been divided into three phases which, although not explained, align approximately with one track each and appear to have been set up to focus the WG's efforts sequentially on one item at a time with a view to actually getting deliverables delivered. This gives rise to the observation that ARC is in scope for Phase I but not in scope for Phase II. So far so good, except that Phase I is currently considered to be complete, meaning that ARC is not in scope for the current or remaining Phases, despite it being in scope for the WG. The good news is that reopening a Phase does not require re-chartering, just consensus of the WG, which is presumably the reason for Barry's question. The dilemma would appear to be that reopening Phases willy-nilly would risk slowing the WG's progress still further, while slavishly sticking to the plan would exclude work on a very worthwhile mechanism which (a) came into being after the charter was written, (b) is a near perfect match for one of the Phase I proposed items, and (c) provides worthwhile capabilities for that proposed item that no other mechanism addressed in Phase I provides.

My view is that ARC is a sufficiently compelling addition that reopening Phase I is warranted.

- Roland
--------------070300030303040301090508-- From nobody Tue May 17 23:00:31 2016 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 3CB0812B047 for ; Tue, 17 May 2016 23:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.427 X-Spam-Level: X-Spam-Status: No, score=-3.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rolandturner.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 fVEaUFlnDK4P for ; Tue, 17 May 2016 23:00:29 -0700 (PDT) Received: from sg.rolandturner.com (sg.rolandturner.com [175.41.138.242]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2972F12B029 for ; Tue, 17 May 2016 23:00:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=rolandturner.com; s=20120325; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=lgYqhbAt2u6fy7SCZyRXMsjwPvCG+54xgqezspKy/CE=; b=HUjx5cioy2o64H6SVPgrxr45sRlE8IBGDamugvfehGKyI/3T42vM9HZw06nmBmue1jMfj6jhDRaaEXXdo8lzL3DLyzB3MJ0fUhRT7bUEplg1ku5XmRjx/WawrJ+pnPFKjtXK+OW2q28mh4Goe688m5/FXKL42Sj/glHlXNp5ajA=; Received: from [116.12.149.133] (port=56337 helo=[10.100.1.116]) by sg.rolandturner.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1b2uWx-0004Q5-G9; Wed, 18 May 2016 06:00:27 +0000 To: Barry Leiba , DMARC References: <20160511002303.14397.qmail@ary.lan> <57327D81.6050306@gmail.com> <57331D94.2010004@tana.it> <573B33DD.5040802@tana.it> From: Roland Turner Message-ID: <573C04FB.7070302@rolandturner.com> Date: Wed, 18 May 2016 14:00:27 +0800 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <573B33DD.5040802@tana.it> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 18 May 2016 06:00:30 -0000 On Wed 11/May/2016 18:00:25 +0200 Barry Leiba wrote: > It certainly seems that the working group is interested in discussing > ARC, as I can judge from the discussion in the short time since Kurt's > proposal. So let's go back and get a proper answer: > > Does anyone object to having the DMARC working group take on this work? > Does anyone object to using the two documents above as starting points > for that work? I do not object to either of things; in fact I support both. - Roland From nobody Wed May 18 06:41:50 2016 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 F0C0812D145 for ; Wed, 18 May 2016 06:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 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, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no 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 0dgwYAS8Ivb4 for ; Wed, 18 May 2016 06:41:47 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::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 E54EA12B050 for ; Wed, 18 May 2016 06:41:46 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id 77so18783083pfv.2 for ; Wed, 18 May 2016 06:41:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=cLIevqV3/HW9oZLEzDwGEhgNijO1K4Dt43IBnHxNC1E=; b=YV35+fLAAD05eNNS/PUTOjQGOvt8fF6Z6/sc2GVjxu8pZFBztkQgPeegzUUPT23mXb jkY1yo1LJ9erzDaPt0LT0Uj5Tp3Uv4Yz9XUlwYjSiJXUZs51Ie1iz6i+w6++xTk029rB DlmKGbz57gG9kBsxc3avhmPJ02uECFhvVR8Sn5F18KgRRLHbR+JZYz/5Ra2BuaKOlcXi S5RrrQFS6imyNK+3B3c6Y6pRHjh5/Bhdf2C18oHgkj2APw/LN7RSOi39znwD6lBRTEDl TcM3PWhEUXhnY5dH08bX9PoN1+oksJqN1cleS0mliSjozgvK+DFU/dtIgovX6uqPU4Me P3jA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=cLIevqV3/HW9oZLEzDwGEhgNijO1K4Dt43IBnHxNC1E=; b=cRcyjsNu1Zmm6QA8DMtGD3ALHr799BsaqHS1BIIhz2drRPxD1LNiIFlqryChaKhCGy lpJw/QnzZCOYgTKdsp/iwRarfjpkZQWWu6/6QY3tR3bQuTFdVpAyf75OHcQ8FjkgB4P0 KPRVfXPQunrR6NfmoXxIKeTyQhVhoAAFwsm4FuVknSyUTOK500vIzm16tyHCFhgAiNSF MZIVVV/eczqCmPzjqdfafATeoJHvGz22VQHkyPV3F/aphRTU/Ar3XcdVpQkiY9VU7xKa yQztpZKrRpXRMVuEkEwjMZ2sjzWIsBP+rxsQ9AkeOOxoKoJk6LzzxlnADYFJrRvSKnrg Ll7g== X-Gm-Message-State: AOPr4FWd0zd9MSttbZkXKnDNxpBC3SmqUf2+bUCWlJVY8hp+H1M2zbTxh8kkmmxUtbtEzA== X-Received: by 10.98.9.154 with SMTP id 26mr11154755pfj.121.1463578906499; Wed, 18 May 2016 06:41:46 -0700 (PDT) Received: from [172.31.24.111] ([216.9.110.12]) by smtp.gmail.com with ESMTPSA id yl5sm12594351pac.38.2016.05.18.06.41.44 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 18 May 2016 06:41:44 -0700 (PDT) To: "Murray S. Kucherawy" References: <20160511002303.14397.qmail@ary.lan> <57327D81.6050306@gmail.com> <57331D94.2010004@tana.it> <573B33DD.5040802@tana.it> <7ff3f3d4-4dc2-6629-64ae-5263f79d5b34@gmail.com> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Wed, 18 May 2016 06:41:16 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: DMARC , Barry Leiba Subject: Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 18 May 2016 13:41:48 -0000 On 5/17/2016 10:23 PM, Murray S. Kucherawy wrote: > On Tue, May 17, 2016 at 9:52 PM, Murray S. Kucherawy > > wrote: > > And I agree, but then I also mentioned that we're now operating > under the second phase of the charter, or so the chairs seemed to > indicate explicitly with their "phase 1 is done" message. This > citation is in the first; the proscription against "additional mail > authentication technologies" (which also, by the way, exactly > describes ARC) that I'm worried about is in the second. > > > Reducing this to my basic issue, setting aside the matter of phases: > > There's one clause in the charter that says ARC is fine, and one that > proscribes it. You appear to be claiming that the first one wins over > the second, plain and simple. I don't understand why it's plain and > simple. Why do they not have equal effect? Is there some "default > allow" nuance when interpreting ambiguous charters? Murray, There are a few different points here: 1. The proposed activity falls perfectly under "track" 1: > 1. Addressing the issues with indirect mail flows If anyone disagrees with that, that should probably be discussed as a distinct point, because I think it's obvious. 2. The constraint to "not develop additional mail authentication technologies" has a scope limited to the second "track", which is: > Reviewing and improving the base DMARC specification Since the proposed activity does not directly touch any aspect of the base DMARC specification, I again think that the INapplicability of the text for track 2 is also obvious. 3. Now we get to the difference between a track and a phase. And to state the issue is to state its resolution: these are different constructs, with different terminology. As if they are meant to be considered separately... The first item in Phase II is: > Phase II: > > Specification of DMARC improvements to support indirect mail flows And here's where I wish we'd phrased things a bit differently, although I don't think the current wording is a show-stopper. The proposed work falls under this first item in phase II. The catch is that the draft doesn't /say/ it's improving DMARC. (In fact, I've been quite vigorous in pressing to have the proposed spec carefully not say much about DMARC.) But really that's a document-writing point, not a working group functional point. That is, ARC's development has been specifically motivated to respond to exactly this item in Phase II. If we did sloppy specification-writing, we'd have written this as a part of a DMARC enhancement. Not the 'base', of course, but an enhancement. The fact that it's been written as an independent component is so that its use is not /limited/ to DMARC. But again, that's merely a writing artifact. So, my reading of the charter says that the proposed spec falls under the first item of Phase two and the second sub-bullet of Track 1. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed May 18 07:15:35 2016 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 23E2912D1D9 for ; Wed, 18 May 2016 07:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.428 X-Spam-Level: X-Spam-Status: No, score=-3.428 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-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=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ey2QHQZbv9y7 for ; Wed, 18 May 2016 07:15:33 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B989512D103 for ; Wed, 18 May 2016 07:15:32 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q0BB6TEIU80172R4@mauve.mrochek.com> for dmarc@ietf.org; Wed, 18 May 2016 07:10:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1463580630; bh=6sJtrGIykIxODV278Prpx8y+gz6vtVmmWpaMr+mIuKk=; h=From:Cc:Date:Subject:In-reply-to:References:To; b=Mog+5DXTg+z5R4BGUK4TIWZu4Le9YA9HMqNK44SV8Qlp7gmT271Z33F7tnigv0Nhn UFALknyhUbG+ciMe8w6oEYxB2uzj+7Vpj7NSoWez20DcpZ0hBT/5CYZiItNevPxGTj t8xMOM1/0e+BgDF6+NDkQdDWKE927KHjM2HSMcqw= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q07QGYT29C00005M@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for dmarc@ietf.org; Wed, 18 May 2016 07:10:27 -0700 (PDT) From: ned+dmarc@mrochek.com Message-id: <01Q0BB6RZ52800005M@mauve.mrochek.com> Date: Wed, 18 May 2016 07:06:36 -0700 (PDT) In-reply-to: "Your message dated Wed, 18 May 2016 06:41:16 -0700" References: <20160511002303.14397.qmail@ary.lan> <57327D81.6050306@gmail.com> <57331D94.2010004@tana.it> <573B33DD.5040802@tana.it> <7ff3f3d4-4dc2-6629-64ae-5263f79d5b34@gmail.com> To: Dave Crocker Archived-At: Cc: DMARC , "Murray S. Kucherawy" , Barry Leiba Subject: Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 18 May 2016 14:15:34 -0000 > There are a few different points here: > 1. The proposed activity falls perfectly under "track" 1: > > 1. Addressing the issues with indirect mail flows > If anyone disagrees with that, that should probably be discussed as a > distinct point, because I think it's obvious. I concur. > 2. The constraint to "not develop additional mail authentication > technologies" has a scope limited to the second "track", which is: > > Reviewing and improving the base DMARC specification > Since the proposed activity does not directly touch any aspect of the > base DMARC specification, I again think that the INapplicability of the > text for track 2 is also obvious. Agreed again. > 3. Now we get to the difference between a track and a phase. And to > state the issue is to state its resolution: these are different > constructs, with different terminology. As if they are meant to be > considered separately... It never occured to me to think of the two as connected or cooresponding or anything similar. > The first item in Phase II is: > > Phase II: > > > > Specification of DMARC improvements to support indirect mail flows > And here's where I wish we'd phrased things a bit differently, although > I don't think the current wording is a show-stopper. It probably would have help to clearly link this item to track 1. > The proposed work falls under this first item in phase II. > The catch is that the draft doesn't /say/ it's improving DMARC. (In > fact, I've been quite vigorous in pressing to have the proposed spec > carefully not say much about DMARC.) But really that's a > document-writing point, not a working group functional point. Agreed. > That is, ARC's development has been specifically motivated to respond to > exactly this item in Phase II. > If we did sloppy specification-writing, we'd have written this as a part > of a DMARC enhancement. Not the 'base', of course, but an enhancement. > The fact that it's been written as an independent component is so that > its use is not /limited/ to DMARC. But again, that's merely a writing > artifact. > So, my reading of the charter says that the proposed spec falls under > the first item of Phase two and the second sub-bullet of Track 1. As does my own reading. Ned From nobody Fri May 20 06:42:07 2016 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 6D04412D971; Fri, 20 May 2016 06:42:05 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160520134205.328.49041.idtracker@ietfa.amsl.com> Date: Fri, 20 May 2016 06:42:05 -0700 Archived-At: Cc: alexey.melnikov@isode.com, dmarc@ietf.org, draft-ietf-dmarc-interoperability@ietf.org, Ned Freed , dmarc-chairs@ietf.org Subject: [dmarc-ietf] Last Call: (Interoperability Issues Between DMARC and Indirect Email Flows) to Informational RFC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org 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, 20 May 2016 13:42:05 -0000 The IESG has received a request from the Domain-based Message Authentication, Reporting & Conformance WG (dmarc) to consider the following document: - 'Interoperability Issues Between DMARC and Indirect Email Flows' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-06-03. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract DMARC introduces a mechanism for expressing domain-level policies and preferences for email message validation, disposition, and reporting. The DMARC mechanism can encounter interoperability issues when messages do not flow directly from the author's administrative domain to the final recipients. Collectively these email flows are referred to as indirect email flows. This document describes interoperability issues between DMARC and indirect email flows. Possible methods for addressing interoperability issues are presented. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperability/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperability/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Sat May 21 16:24:02 2016 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 A67CB12D53B; Sat, 21 May 2016 16:23:56 -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, FREEMAIL_FROM=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 dRfoLTk-x1tW; Sat, 21 May 2016 16:23:55 -0700 (PDT) Received: from mail-pa0-x244.google.com (mail-pa0-x244.google.com [IPv6:2607:f8b0:400e:c03::244]) (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 55EAF12D539; Sat, 21 May 2016 16:23:55 -0700 (PDT) Received: by mail-pa0-x244.google.com with SMTP id rw9so14316211pab.2; Sat, 21 May 2016 16:23:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=P+cP5ed3lm/8oU7epjfpQ1NPvsXRoaBSMBkCeDYgDIc=; b=Kp4ybeyOCOxgiH6Qpx56R1aWVqSJyDEChuLlXjAeKapuIXHThzW+MX8TcxEQjX0IS6 pCYq9Qcuf3UaZrdLHTRrMMLGYS/hp94qlrvc2DPuqCL+LTnRwbzCtoiGP7A0jZgDhPpa b8pEJj5sXDLmGZLgVQVOYnaUJkRNRWgyTHzkan7zwKyDA35QOcKa0nRAW6/uAuNHdUGT pOMoVQ0Im7Y6g0EVNSvsITTX2D7kZ0WUZkxSra66q/9+BShcQGYuxKL2OzgYmFNmRvrk nzwtb1oLIMWyr9Wivq2tJkrRJa3PLSri8vR/t9OiDqculJiVM6UQuEWDnU8vgI+gkaP1 izhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=P+cP5ed3lm/8oU7epjfpQ1NPvsXRoaBSMBkCeDYgDIc=; b=T2ARJKrjYosdlK/e79jg47hHDn2bj0JlCm39LhItq7bmPRTo+0cRAa5X7NBRNTiWEB kAqyocrPOW90COevSu69ekcDGdpuDA0+GTe6emZKQmU2v/5DgIcRuSAECky/woAkkesh fqSaDh3eVoKaI4kH3vHn4YAtiAcFDTAO8vmzheUIuIcBTcXYrotYEoAIQPke2zT9xlgM roWIs4A6oZnJY7fHAIPFYulYt2IEmq4s5Oc9GSUtHwWXxff4kroK5gbogaQbJ+V9m0Tb WRJbw7Hurwb6cm1CqP+2/0ig6LHlNgANEBvcmY1GbCc7Sx5WjgHoewIXc5BmdrHlFFVd hQhg== X-Gm-Message-State: AOPr4FXB+njoKnKDGmM/JeFkD++ODE6ZY9qBQTqHy/R14pHPkOD5hsRshH9TDSYzG932JQ== X-Received: by 10.66.127.10 with SMTP id nc10mr15780100pab.98.1463872132236; Sat, 21 May 2016 16:08:52 -0700 (PDT) Received: from ?IPv6:2406:e007:4c59:1:64c5:f48:b5f6:2567? ([2406:e007:4c59:1:64c5:f48:b5f6:2567]) by smtp.gmail.com with ESMTPSA id r73sm36310586pfi.4.2016.05.21.16.08.49 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 21 May 2016 16:08:51 -0700 (PDT) To: ietf@ietf.org References: <20160520134205.328.49041.idtracker@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <49148678-7c9b-c200-1862-b7ffaba68928@gmail.com> Date: Sun, 22 May 2016 11:08:47 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160520134205.328.49041.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: alexey.melnikov@isode.com, dmarc@ietf.org, draft-ietf-dmarc-interoperability@ietf.org, Ned Freed , dmarc-chairs@ietf.org Subject: Re: [dmarc-ietf] Last Call: (Interoperability Issues Between DMARC and Indirect Email Flows) to Informational RFC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 21 May 2016 23:23:57 -0000 This is useful. > 4.1.3.3. Mailing Lists > > [RFC6377] provides some guidance on using DKIM with Mailing lists. > The following mitigation techniques can be used to ease > interoperability issues with DMARC and Mailing lists: It should probably be indicated whether these techniques would be applied to all messages, or only to messages sent from domains with a DMARC policy other than "p=none". (I prefer the latter.) ... > o Configuring the MLM to "wrap" the message in a MIME message/rfc822 > part and to send as the Mailing List email address. Many email > clients (as of the publication of this document), especially > mobile clients, have difficulty reading such messages and this is > not expected to change soon. This seems like a quite elegant solution. I'm very surprised by the second sentence - are these clients that have difficulty with many Content-Types or is it a specific issue for message/rfc822? Thanks Brian From nobody Sun May 22 03:54:09 2016 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 8606A12D550; Sun, 22 May 2016 03:54:07 -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, FREEMAIL_FROM=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 (1024-bit key) header.d=fastmail.fm header.b=Pn/m4sZb; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=OZAZNFjs 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 lYCoztm0FR9E; Sun, 22 May 2016 03:54:05 -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 C6CD212D537; Sun, 22 May 2016 03:54:05 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 585F520385; Sun, 22 May 2016 06:54:03 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Sun, 22 May 2016 06:54:03 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=TKBkmV6Pm2OY1zFH4KmbPPJDpiQ=; b=Pn/m4s Zbzd5gMz3YVCx6zDmh+7XOesbAD9hzoO1pW2SbsmwFtPgtQnhQWWYOBVuF3EUFLp H8ifiSzsuqzQ+AZRosG7mgfmcr89yNCquirZS1kpmBSAMgYfsEIfSGvU2LoMMNfl A9Pfdu4gNAqEZZtVpqXCK/tFeXv7bya0Kby2E= DKIM-Signature: v=1; a=rsa-sha1; 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-sasl-enc:x-sasl-enc; s=smtpout; bh=TKBkmV6Pm2OY1zF H4KmbPPJDpiQ=; b=OZAZNFjszYNV6Ip/qbGA817Ubpxlw3oxmKBJ4rYOs6vy8G+ VzBv9h25/qMolUo0PR+IsXgL9pio1IMpFXX4iZhvSbkXAUxmxD6glzXjB1e9pY2Y FtW+6NJSmYxxDBu5Ejk8RGyLDkGJnV874bhU0quxN3O2ON43i8qaukMuQaHA= X-Sasl-enc: qCrjKigNfqMvivVjz8YydWmifFJOwFIiYDkwhpJSp/9+ 1463914442 Received: from [10.9.97.168] (unknown [85.255.234.174]) by mail.messagingengine.com (Postfix) with ESMTPA id E7790F29E5; Sun, 22 May 2016 06:54:02 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPhone Mail (13E238) In-Reply-To: <49148678-7c9b-c200-1862-b7ffaba68928@gmail.com> Date: Sun, 22 May 2016 12:00:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3211644D-09A8-4969-B830-A62F9EBC593B@fastmail.fm> References: <20160520134205.328.49041.idtracker@ietfa.amsl.com> <49148678-7c9b-c200-1862-b7ffaba68928@gmail.com> To: Brian E Carpenter Archived-At: Cc: draft-ietf-dmarc-interoperability@ietf.org, Ned Freed , ietf@ietf.org, dmarc@ietf.org, alexey.melnikov@isode.com, dmarc-chairs@ietf.org Subject: Re: [dmarc-ietf] Last Call: (Interoperability Issues Between DMARC and Indirect Email Flows) to Informational RFC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2016 10:54:08 -0000 On 22 May 2016, at 00:08, Brian E Carpenter wr= ote: >> o Configuring the MLM to "wrap" the message in a MIME message/rfc822 >> part and to send as the Mailing List email address. Many email >> clients (as of the publication of this document), especially >> mobile clients, have difficulty reading such messages and this is >> not expected to change soon. >=20 > This seems like a quite elegant solution. I'm very surprised by the second= > sentence - are these clients that have difficulty with many Content-Types > or is it a specific issue for message/rfc822? Only message/rfc822. E.g. it took iOS a couple of years to start supporting i= t properly. And it is one of the better mobile email clients. From nobody Mon May 23 10:07:48 2016 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 BC9EE12D93A; Mon, 23 May 2016 10:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=peachymango.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 ry63kt7jKcOk; Mon, 23 May 2016 10:07:45 -0700 (PDT) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id BAB9812D9D0; Mon, 23 May 2016 10:07:44 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 66EB7563D58; Mon, 23 May 2016 12:07:39 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 53A43A0482; Mon, 23 May 2016 12:07:39 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3X0IB5lKHf2T; Mon, 23 May 2016 12:07:39 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 09986A0489; Mon, 23 May 2016 12:07:37 -0500 (CDT) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-1.01.com 09986A0489 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1464023257; bh=8TAHlJd9f/UZ00M3IAtClf1PS+AR09zPU5T7ImpLrzA=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=b4SCEnKmaTSeJnCMgbqxFtii0OJpCAY1J1rkKn207iDXaO+pPono/meY488aRd7Ab nxponM0OMY/n4Lwj33LvGpJbHrBI5dLQIelu0TJfSgH/vE5IzRr3NSUgE/yCeHJB2Y KqxephcfIb7M0dVx1/2zZXncXJ0BqE7GUGxdfClk= Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id D5DC9A0482; Mon, 23 May 2016 12:07:36 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id jqVkRMznr48L; Mon, 23 May 2016 12:07:36 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-1.01.com (Postfix) with ESMTP id 8B473A047D; Mon, 23 May 2016 12:07:36 -0500 (CDT) Date: Mon, 23 May 2016 12:07:36 -0500 (CDT) From: Franck Martin To: Alexey Melnikov Message-ID: <1916486689.52040.1464023256291.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <20160520134205.328.49041.idtracker@ietfa.amsl.com> <49148678-7c9b-c200-1862-b7ffaba68928@gmail.com> <3211644D-09A8-4969-B830-A62F9EBC593B@fastmail.fm> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF46 (Mac)/8.0.5_GA_5839) Thread-Topic: Last Call: (Interoperability Issues Between DMARC and Indirect Email Flows) to Informational RFC Thread-Index: zSK/kzQbRfnxVoNyjCTaM+jE22Jfww== Archived-At: Cc: draft-ietf-dmarc-interoperability@ietf.org, Ned Freed , ietf@ietf.org, dmarc@ietf.org, alexey melnikov , Brian E Carpenter , dmarc-chairs@ietf.org Subject: Re: [dmarc-ietf] Last Call: (Interoperability Issues Between DMARC and Indirect Email Flows) to Informational RFC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 23 May 2016 17:07:47 -0000 ----- Original Message ----- > From: "Alexey Melnikov" > To: "Brian E Carpenter" > Cc: draft-ietf-dmarc-interoperability@ietf.org, "Ned Freed" , ietf@ietf.org, dmarc@ietf.org, > "alexey melnikov" , dmarc-chairs@ietf.org > Sent: Sunday, May 22, 2016 4:00:19 AM > Subject: Re: [dmarc-ietf] Last Call: (Interoperability Issues Between > DMARC and Indirect Email Flows) to Informational RFC > > On 22 May 2016, at 00:08, Brian E Carpenter > wrote: > > >> o Configuring the MLM to "wrap" the message in a MIME message/rfc822 > >> part and to send as the Mailing List email address. Many email > >> clients (as of the publication of this document), especially > >> mobile clients, have difficulty reading such messages and this is > >> not expected to change soon. > > > > This seems like a quite elegant solution. I'm very surprised by the second > > sentence - are these clients that have difficulty with many Content-Types > > or is it a specific issue for message/rfc822? > > Only message/rfc822. E.g. it took iOS a couple of years to start supporting > it properly. And it is one of the better mobile email clients. And "forward as attachment" that creates this message/rfc822 has disappeared from many clients... From nobody Thu May 26 14:11:28 2016 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 4A0BC12DB5A for ; Thu, 26 May 2016 14:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.428 X-Spam-Level: X-Spam-Status: No, score=-3.428 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=crash.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 NSA83ElVZzOZ for ; Thu, 26 May 2016 14:11:25 -0700 (PDT) Received: from segv.crash.com (segv.crash.com [IPv6:2001:470:1:1e9::4415]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6A0812DA3D for ; Thu, 26 May 2016 14:09:08 -0700 (PDT) Received: from abort.crash.com (70-36-157-26.dsl.static.fusionbroadband.com [70.36.157.26]) (authenticated bits=0) by segv.crash.com (8.14.5/8.14.5/cci-colo-1.6) with ESMTP id u4QL8xgK084141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 26 May 2016 14:09:05 -0700 (PDT) (envelope-from smj@crash.com) X-DKIM: OpenDKIM Filter v2.4.3 segv.crash.com u4QL8xgK084141 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=201506-2k; t=1464296945; bh=e+eAmuOJN45Q9ZbDsGaSa9UltBXlGKNN2MM8Bl9Xp8k=; h=To:From:Subject:Message-ID:Date:MIME-Version:Content-Type: Content-Transfer-Encoding; b=NsYf+wfk5v2oqIujnCwhvZ7/aLLMivcpSS8ZbbY4RClhSAYssswRLzetp+JeQK707 7fhlBkkk5MgljtUpLaNDLjqNT9YmtXk6JrvTs98cLJ3SO16E3fPkcmp2MWvc+b5B5Y hvXX2SvuGwmFraVzFdLgtYWPeYF1HjYeIQxaYiuMAYz5iKcdYIIsrAttUTfsrW0mOY R7mad8Oz++eWUaB0l2ei1vkAnO3x/gRPFUHwJn4j5956iZAjheD+d7/qvTXbqUVFei qGFReKe7MUDFnZr/QSJKdQxoM8v7YOsXT71H5xr6Ad1pCzdCzcldf86n/ZV++STNb8 nVAWi/UuKSy/Q== X-Authentication-Warning: segv.crash.com: Host 70-36-157-26.dsl.static.fusionbroadband.com [70.36.157.26] claimed to be abort.crash.com To: dmarc@ietf.org From: Steven M Jones Organization: Crash Computing Message-ID: Date: Thu, 26 May 2016 14:09:02 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (segv.crash.com [72.52.75.15]); Thu, 26 May 2016 14:09:05 -0700 (PDT) Archived-At: Subject: [dmarc-ietf] Overview slides for the ARC protocol available X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 26 May 2016 21:11:27 -0000 If you need an overview of the ARC protocol, or some slides would be helpful in explaining it to others, there's a slide deck available from DMARC.org. It's available under the Creative Commons Attribution-ShareAlike license, so you can largely repurpose it, or parts of it, however you see fit. Direct download: https://dmarc.org/presentations/ARC-Overview-2016Q2-v03.pdf SlideShare: http://www.slideshare.net/SteveJones250/overview-of-the-arc-protocol-for-email Share and Enjoy, --Steve. -- Steven M Jones CRASH Computing e: smj@crash.com m: +1-254-220-4488 Skype: smjcrash, +1-415-799-8895