From nobody Thu Jun 1 02:34:16 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA9DA126DED for ; Thu, 1 Jun 2017 02:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.718 X-Spam-Level: X-Spam-Status: No, score=-2.718 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=3ByBeMnz; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=UP7QOctK 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 TOVdv835NqE4 for ; Thu, 1 Jun 2017 02:34:13 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71E2E126BF0 for ; Thu, 1 Jun 2017 02:34:13 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id DC84020AFC; Thu, 1 Jun 2017 05:34:12 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Thu, 01 Jun 2017 05:34:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; 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-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=BoozQjZ4aYYy474OB8 D2Fa3Qkg1aIuOc7NwC6USSixw=; b=3ByBeMnzQJohE9M+BpST/7YmkbfIZ6wepQ H3Q8yK6C0F3ONsTeC/wb3hTEY4VeqN0V6fkLxLR6ecPGk2MgcoMDPTfhTA4he7CF sREKcpoCGnJhi51JYh82KcxF0LZzZ5BKW5mB253h0QrZe8V/nKrhp+2AE+l5lH8m OK8KTjKF2ZKO4SyOIfGyhmBOCgYOI1oBpSswWHN78/65bgH9YRxsCkAM1pahQiHU apQB0ydFKj807Za1+1taC9r3AghfhQC6CHhRdptcNkM6AQIBV1Na9YZ5PB0u2LZV KJNc93o5cqqIoV8DD4bEtWWYFIUWdRj1ahqKP1pSeMTE4ojlAETA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=BoozQjZ4aYYy474OB8D2Fa3Qkg1aIuOc7NwC6USSixw=; b=UP7QOctK Q02lKj2R7UV2lO4ouuUQOik8Dc9yjSSLwCgzdeakexSOLe7rSw//dEKoF6QNwMgX p6IQ9/t8Nmd9j2PdQaVJFZYkcTs1kk1OLvedOfJxNpyNJxr7f2fXFvL32PEzyfEF 0bVSCbEzVQEhdkJb490lz0zfP8b3CA35oL6+A/DIrBE/0Tg94KiIF+dXhq5Jo6yR gBHrQBgAiFsZG4dFlKPaJyjmJBHIuDPRyiUV5THUFxWqOWybYZtnAnpVDN9jXliL Qk954QZfmedH3yzivS4CpWQyxOPhvLiryKQXtJm0czc/AUXkGdxZA/oCfNpNkmHd WBlhU4iagMR83A== X-ME-Sender: X-Sasl-enc: oq1tKFq9IXycK0Q+VAPdz3/evOeGRbUHmxd+K1lqIxwh 1496309652 Received: from [10.228.217.143] (unknown [185.69.144.211]) by mail.messagingengine.com (Postfix) with ESMTPA id 7B7E2241D3; Thu, 1 Jun 2017 05:34:12 -0400 (EDT) Content-Type: multipart/alternative; boundary=Apple-Mail-0C04A5E5-AE2D-4E58-B22E-59B099406C28 Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPhone Mail (13G35) In-Reply-To: Date: Thu, 1 Jun 2017 10:52:00 +0100 Cc: "dmarc@ietf.org" , "Kurt Andersen (b)" Content-Transfer-Encoding: 7bit Message-Id: References: To: "Murray S. Kucherawy" , Barry Leiba Archived-At: Subject: Re: [dmarc-ietf] Proposal: Writing a DMARC usage guide is not a good task for this WG X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2017 09:34:15 -0000 --Apple-Mail-0C04A5E5-AE2D-4E58-B22E-59B099406C28 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On 1 Jun 2017, at 05:23, Murray S. Kucherawy wrote: >=20 >> On Wed, May 31, 2017 at 5:47 AM, Barry Leiba wr= ote: >> I agree with this. If there's stable documentation on DMARC usage >> that we can cite, there's little value in adding our own, which is >> likely to end up diverging from the others. >>=20 >> Does anyone think we *should* proceed with writing this? >=20 > Hard to say. Maybe, with development of a DMARC on the standards track. B= ut I'd like to see some momentum first in general, and secondly a good reaso= n why this has to come from the IETF. Otherwise, some informative text in a= ppendices in either ARC or DMARCbis should suffice, rather than a separate d= ocument. >=20 Is there an expired or not yet posted draft on DMARC usage? I think looking a= t any written text will help inform the decision. --Apple-Mail-0C04A5E5-AE2D-4E58-B22E-59B099406C28 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

On 1 Jun 2017, at 05:23, Murray S. Kucherawy <superuser@gmail.com> wrote:

On Wed, May 31, 2017 at 5:47 AM, Barry Leiba <barryleiba@computer.org> wrote:
I agree with this.  If there's stable documentation on DMARC usage
that we can cite, there's little value in adding our own, which is
likely to end up diverging from the others.

Does anyone think we *should* proceed with writing this?

Hard to say.  Maybe, with development of a DMARC on the standards track.  But I'd like to see some momentum first in general, and secondly a good reason why this has to come from the IETF.  Otherwise, some informative text in appendices in either ARC or DMARCbis should suffice, rather than a separate document.


Is there an expired or not yet posted draft on DMARC usage? I think looking at any written text will help inform the decision.


--Apple-Mail-0C04A5E5-AE2D-4E58-B22E-59B099406C28-- From nobody Thu Jun 1 04:05:14 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7C01293E0 for ; Thu, 1 Jun 2017 04:05: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KHzvCk9_tQuf for ; Thu, 1 Jun 2017 04:05:11 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c: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 190FF12704B for ; Thu, 1 Jun 2017 04:05:11 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id y190so22754851vkc.1 for ; Thu, 01 Jun 2017 04:05:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=kxiiHo6bDH/X6wc7ksoYTWYFOqHfzxLNnSAEBC2V6xU=; b=UU0td8lv6qtXfGP2vIrhzUGTSvm9rhLTaNB+5Zcu8SOBoko93fDSzngy2RI2mtF7bA LYWqCyI8DhyCSMDxSheoovuYZBUFPY593STAG4PVPoDPD1FMfFVx1+biaOIHZSCxdU2p yIrL2/2/lHirdCqCCm/gSw6HgI62HSiciA9W0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=kxiiHo6bDH/X6wc7ksoYTWYFOqHfzxLNnSAEBC2V6xU=; b=XPGBinmKe5TMK9iyZAUhBEAolaX5fjxOtc6qxycetRZiayWniy/grInx7ZQEJGaWRc 2zefdBfmHPnRYWR0UwCB46GhIcZfZGkhjtYk6ibwPKqJAwuLRsNUl0smdKk6mOf/+ClO WtYlMVCgGh+aJWwUkkqdZfF9drvtWUilskKzKTpGfGUu5tHbAZ3UD3bshOIUDIA96WFr m6bxaXj5nAno205uhLc339uCn6p9k05xwbhWZmHTfF2ccf/9+bbAHbqO6yP6nb2Ay/fq huPCG0QxWc28wvBUnYaP489qFAzl1uiYm/6c0DvXgE6HU/t5vwYIJ+sb+ZNeiFk/nRJ7 L97A== X-Gm-Message-State: AODbwcDCum8o9BkS9S8hgwQTSmxoMN/MJaVP/Ng54wLBTUzZ1FaGCjQO ifh99F02gC6VVP5Zr4mugyMbbjJaw0hh X-Received: by 10.31.47.65 with SMTP id v62mr326844vkv.2.1496315109926; Thu, 01 Jun 2017 04:05:09 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.176.83.111 with HTTP; Thu, 1 Jun 2017 04:05:09 -0700 (PDT) In-Reply-To: References: From: "Kurt Andersen (b)" Date: Thu, 1 Jun 2017 19:05:09 +0800 X-Google-Sender-Auth: sA0ppWA8_YgMrkQJkNansR0PSTk Message-ID: To: "Murray S. Kucherawy" Cc: Seth Blank , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a1144067099881f0550e402d3" Archived-At: Subject: Re: [dmarc-ietf] Clarifying question: AAR coverage by AMS X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2017 11:05:13 -0000 --001a1144067099881f0550e402d3 Content-Type: text/plain; charset="UTF-8" On Thu, Jun 1, 2017 at 12:10 PM, Murray S. Kucherawy wrote: > On Wed, May 31, 2017 at 6:23 PM, Kurt Andersen (b) > wrote: > >> There's another question that had been raised by Seth about whether d= >> needs to match within an ARC set. The answer is yes, [...] >> > > Why? > > -MSK > If an ARC-set is created by a single ADMD, I think it's reasonable for that ADMD to identify itself in a singular manner, though I suppose we could have recourse to our favorite "org domain" alignment instead of strict matching if you think that's better. I think that strict d= matching is simpler and less likely to be misused/broken. --Kurt --001a1144067099881f0550e402d3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Jun 1, 2017 at 12:10 PM, Murray S. Kucherawy <superuser@gmail.com> wrote:
On W= ed, May 31, 2017 at 6:23 PM, Kurt Andersen (b) <kboth@drkurt.com> wrote:
There's another question that= had been raised by Seth about whether d=3D needs to match within an ARC se= t. The answer is yes, [...]

Why?

-MSK

If an ARC-set is cr= eated by a single ADMD, I think it's reasonable for that ADMD to identi= fy itself in a singular manner, though I suppose we could have recourse to = our favorite "org domain" alignment instead of strict matching if= you think that's better. I think that strict d=3D matching is simpler = and less likely to be misused/broken.

<= /div>
--Kurt
--001a1144067099881f0550e402d3-- From nobody Thu Jun 1 04:10:48 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2400212950B for ; Thu, 1 Jun 2017 04:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xcoKED3Xrbmk for ; Thu, 1 Jun 2017 04:10:45 -0700 (PDT) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7B6C1294F5 for ; Thu, 1 Jun 2017 04:10:45 -0700 (PDT) Received: by mail-ua0-x22a.google.com with SMTP id j17so25317185uag.3 for ; Thu, 01 Jun 2017 04:10:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=qBl3qVNI35lord10ERS32CZfKwFvGV9NNBPeCpseQWE=; b=bjCJJ6q8DhCKJ2YiUt8z5+zmUOKZVjKUTy0Ip7Rf1kZ/FY8/i/RnIjZmXgaMoxUTyC Q362jZUww+mv/ygpLaGnWK0qJBX2ZPZuGWg3Fq/T2z1FvnQ1vBXRlF+oEB4UGO3328+Z /2aRV+7hcAiB6p92LXNWU84R50/RR8FapAJeE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=qBl3qVNI35lord10ERS32CZfKwFvGV9NNBPeCpseQWE=; b=Pu2n+LpHZQjOM4HMcJq3Ulf6mkx91OZAck4KoG9vpSAwRc2/XB2WXwwGE5Y75z50vs ZfMhKe1zjYC6JVMLZEQ3EcAWpeT/IpzkNO2MQHVQn6XBqHZIXttqQ2KBu+Z5aC/wKGiz tNFdSRGI6pKVd2rCL2pMryPqBvLEY4p1th2Lzz/pea6n7Batuxa5zT82tFedIAMQRW+j DfcnufBTa66UR2QN9NadDmmOendPAUBDDkoy2s8eUyCt2BhyMcm2tY+jfBOzLiMdQaCY GNxxfRDGOXaw2UJCorakQ5smxNRniD1Oynq9mwciA7/rR84qgDmOBWk/E1WxazDsr4X/ t84Q== X-Gm-Message-State: AODbwcBxgskUB/dzjd5t4JCDbUv1cBUvN9Luf+3gcju0EMkiuwY3atj6 2o+iHkcfo008GEPAVz6dc+ZoSvraWs76 X-Received: by 10.176.2.178 with SMTP id 47mr474168uah.36.1496315444809; Thu, 01 Jun 2017 04:10:44 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.176.83.111 with HTTP; Thu, 1 Jun 2017 04:10:44 -0700 (PDT) In-Reply-To: References: <34808716.2nE2qoVfF5@kitterma-e6430> From: "Kurt Andersen (b)" Date: Thu, 1 Jun 2017 19:10:44 +0800 X-Google-Sender-Auth: IzPPbXUwGPMiVyoQ5Vq8qaLy2rQ Message-ID: To: "Murray S. Kucherawy" Cc: Scott Kitterman , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a113cd3ca8f65760550e41629" Archived-At: Subject: Re: [dmarc-ietf] Authentication-Results stamp for ARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2017 11:10:47 -0000 --001a113cd3ca8f65760550e41629 Content-Type: text/plain; charset="UTF-8" On Thu, Jun 1, 2017 at 12:20 PM, Murray S. Kucherawy wrote: > Another way to look at it: A-R is meant to be a channel to record what > authentication was done and what thing in the visible message got > authenticated So, for SPF which does not authenticate *anything* in the original message, how is A-R relevant at all (by that intention)? --Kurt --001a113cd3ca8f65760550e41629 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --001a113cd3ca8f65760550e41629-- From nobody Thu Jun 1 09:30:43 2017 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AC14E1205F0; Thu, 1 Jun 2017 09:30:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: aamelnikov@fastmail.fm, dmarc@ietf.org, barryleiba@gmail.com, dmarc-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.52.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149633464061.22162.7485371906147841853.idtracker@ietfa.amsl.com> Date: Thu, 01 Jun 2017 09:30:40 -0700 Archived-At: Subject: [dmarc-ietf] dmarc - Update to a Meeting Session Request for IETF 99 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2017 16:30:41 -0000 An update to a meeting session request has just been submitted by Barry Leiba, a Chair of the dmarc working group. --------------------------------------------------------- Working Group Name: Domain-based Message Authentication, Reporting & Conformance Area Name: Applications and Real-Time Area Session Requester: Barry Leiba Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 30 Conflicts to Avoid: First Priority: jmap dcrup uta dispatch People who must be present: Ned Freed Barry Leiba Alexey Melnikov Tim Draegen Kurt Andersen Resources Requested: Special Requests: --------------------------------------------------------- From nobody Thu Jun 1 10:14:57 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4CDE12EAEB for ; Thu, 1 Jun 2017 10:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.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 a5y4qLZq76Sy for ; Thu, 1 Jun 2017 10:14:53 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF441129A9A for ; Thu, 1 Jun 2017 10:14:52 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id d14so41639072qkb.1 for ; Thu, 01 Jun 2017 10:14:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oc+qQGbgFcknSjwafrFnwGXdBRU24yzhl/rVUgWz4kw=; b=Bfh7VnBT3GgrB9PPMJucNT3Sb2mC42eE9rKZlXlF6AhQzJjtVFUKCL6Z17yIo5Vszh Wro41Viapv821kCRxjpC0HGMiza7WlLqAM+X0KFnrnCO18KIfdwl15saEQGsRaXwPndt Z61G1vdp//TkLIEEAGXrKdZsL/Oo8TmZ7RivlDRtsYfGfhcyMpqiWtnUJZoT8Az4bme2 xMv3seqWAHyXqnXUvjFLRTKYhYxypD3Cro9Q/4d81vtxbCa6xo0+WhVQa+tYYhCyJRbQ CSJ5FK6wpX4a0HsACKmWMc/nI9X6IVDHcUOfgJ30x6+NwvwyphZEPZWRqMuJjLKqKiS+ ebdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oc+qQGbgFcknSjwafrFnwGXdBRU24yzhl/rVUgWz4kw=; b=lIA4bhMXmFGWTHleJyCIYWep6JYI9stMj5ixnqNj8t01xM+cwRkM3098wvDLgnKbOl bEel8B/DJkWPvCsnY75yRL1vsA6Bq56eLt5vnzbqMGMMLteM+aIt9eAiCf9S8+vLsb6v CO0xt45AIFyBVPQ3NCL3nOMT/1hSbL0ubFTfz+FNrdjF4QlhNmwxl01Oo5WQeR/e3Law BCG+g2ONaafhWx6U/iKv29tsBRepQ/V2esCbmp63fMAfxo/HuTbN4RyDLiG25RQiDFGm 40NkmQcSdny6So21rlOhGRGuqfZF+DTxPZ9N8eIqIYMhI5QsU8JHxwZU88srRMdzuZvE QonQ== X-Gm-Message-State: AKS2vOzf4HJ/1IsfIoHT35uHE8T9VKiUKaLI2qSJZ13cd3e3RPg9vhH2 ei1UEE+my4EEYyk+NJtXD4nDnH3P0kfA X-Received: by 10.55.33.207 with SMTP id f76mr3226858qki.69.1496337291907; Thu, 01 Jun 2017 10:14:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.42.242 with HTTP; Thu, 1 Jun 2017 10:14:31 -0700 (PDT) In-Reply-To: References: From: Seth Blank Date: Thu, 1 Jun 2017 10:14:31 -0700 Message-ID: To: Alexey Melnikov Cc: "Murray S. Kucherawy" , Barry Leiba , "Kurt Andersen (b)" , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a1144dcd6bfa3bc0550e92c1f" Archived-At: Subject: Re: [dmarc-ietf] Proposal: Writing a DMARC usage guide is not a good task for this WG X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2017 17:14:56 -0000 --001a1144dcd6bfa3bc0550e92c1f Content-Type: text/plain; charset="UTF-8" I believe this is the expired draft being referred to: https://tools.ietf.org/html/draft-crocker-dmarc-bcp-03 On Thu, Jun 1, 2017 at 2:52 AM, Alexey Melnikov wrote: > > On 1 Jun 2017, at 05:23, Murray S. Kucherawy wrote: > > On Wed, May 31, 2017 at 5:47 AM, Barry Leiba > wrote: > >> I agree with this. If there's stable documentation on DMARC usage >> that we can cite, there's little value in adding our own, which is >> likely to end up diverging from the others. >> >> Does anyone think we *should* proceed with writing this? >> > > Hard to say. Maybe, with development of a DMARC on the standards track. > But I'd like to see some momentum first in general, and secondly a good > reason why this has to come from the IETF. Otherwise, some informative > text in appendices in either ARC or DMARCbis should suffice, rather than a > separate document. > > > Is there an expired or not yet posted draft on DMARC usage? I think > looking at any written text will help inform the decision. > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > -- [image: logo for sig file.png] Bringing Trust to Email Seth Blank | Head of Product for Open Source and Protocols seth@valimail.com +1-415-894-2724 <415-894-2724> --001a1144dcd6bfa3bc0550e92c1f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thu= , Jun 1, 2017 at 2:52 AM, Alexey Melnikov <aamelnikov@fastmail.fm= > wrote:

On 1 Jun 2017, at 05:23, Murray S. Kucherawy <superuser@gmail.com> wrote:

O= n Wed, May 31, 2017 at 5:47 AM, Barry Leiba <barryleiba@computer.o= rg> wrote:
I agree with this.=C2=A0 If there'= ;s stable documentation on DMARC usage
that we can cite, there's little value in adding our own, which is
likely to end up diverging from the others.

Does anyone think we *should* proceed with writing this?

Hard to say.=C2=A0 Maybe, with development of a DMARC on = the standards track.=C2=A0 But I'd like to see some momentum first in g= eneral, and secondly a good reason why this has to come from the IETF.=C2= =A0 Otherwise, some informative text in appendices in either ARC or DMARCbi= s should suffice, rather than a separate document.


Is there an expired or not = yet posted draft on DMARC usage? I think looking at any written text will h= elp inform the decision.



___________= ____________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc




--

Bringing Trust to E= mail

Seth Blank | Head of Product for Open Source and Protocols=

= seth@valimail.com
+1-415-894-2724
--001a1144dcd6bfa3bc0550e92c1f-- From nobody Thu Jun 1 10:34:39 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02D4612F28E for ; Thu, 1 Jun 2017 10:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 2Bg3FJliuvmf for ; Thu, 1 Jun 2017 10:34:36 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::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 6CC6812F27C for ; Thu, 1 Jun 2017 10:34:36 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id t26so41888152qtg.0 for ; Thu, 01 Jun 2017 10:34:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=j29qB22bxJ7q93WIf5RKvql8H0KkQxmNgIK2z+aMo08=; b=if8OVwf2XGHRSfH/fKrkPHqZD1EoKgZ8vY7oSuwD4kWy/4g25xHSHghHI9B+bKDx9k fbctSaQJh1iPFXjr23E1Am73kjsvKl6+88CcQmk0lAtQTLK9QEm2wwd6qwovQ5ohVU9w 6tGXoutJIZBQF3FpQn4Q8ZDflk8A4EJt97AlzgAA5IKf2B96uiGdQVbByik0O5bzWEZN k0ByfVv0vPTwNuGIxqhezjkAEdEfp0wD+cfrvKenIJnfZZu64s95Va0fTs2Gz7nzMlkP MRu76LgHBcHYYItHPngPJWrB/A8zYYlLvCXZM9UkSXLb3ytvfuNaTfH5Iv33QLKzGTn5 LTyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=j29qB22bxJ7q93WIf5RKvql8H0KkQxmNgIK2z+aMo08=; b=Apk7t+Qz0fI6zhYCPlfgCY0ed8Gx/e8zrvwewy75IKMKwL7A9Xi/vxrTjFZnXU2S2E wWy9c/o7zygQULXtZNSfJTl/nXjZK8HlBg9dEN2oCha6riPoi8Z9thrZn+0+sij6FlA4 dNmVHjXgMXWCnI7c413UMy8hJVqLCZI4XKGdPhuQPv+LyzHN51Zhpxc5AKmzWmP+s+Gx mX8r8ZYGuroQmuAuVCMJLiSUSx486/z/l9Fv4191IIonxUATaSoe55C1d5FNX8n1sQDB TX5ynVjuItZNhkBsRws49PhxkJaUr4u2hMyVibZ/Z/nTUw51xECdPqANqjetMlqu0ej2 dVoQ== X-Gm-Message-State: AODbwcA8Ccf063o0/ktSlT/EeAYoorgVHXB8jopZ0eb7PdjOC8PUU9Kr TDjDAoAYDmifYyejIz7Ofw4ZhmUl0A== X-Received: by 10.237.42.6 with SMTP id c6mr3306341qtd.74.1496338475625; Thu, 01 Jun 2017 10:34:35 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 10.200.36.20 with HTTP; Thu, 1 Jun 2017 10:34:35 -0700 (PDT) In-Reply-To: References: From: Barry Leiba Date: Thu, 1 Jun 2017 13:34:35 -0400 X-Google-Sender-Auth: e2qjSdntKrTznAqM2nylKM0RGRE Message-ID: To: Seth Blank Cc: "dmarc@ietf.org" , "Kurt Andersen (b)" Content-Type: multipart/alternative; boundary="001a1144553e4db1c60550e973f1" Archived-At: Subject: Re: [dmarc-ietf] For fodder for F2F at IETF99 (was: Authentication-Results stamp for ARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2017 17:34:38 -0000 --001a1144553e4db1c60550e973f1 Content-Type: text/plain; charset="UTF-8" I've gone ahead and bumped the time request up to 60 minutes, to be sure we do have time for what we want to discuss. We can always give back some of the time later, as we build an agenda, if that makes sense. Barry On Wed, May 31, 2017 at 7:42 PM, Seth Blank wrote: > AR might be 10-15 minutes. > > What to do to transport the source_ip, which is valuable to report > consumers but doesn't appear to belong in the AR/AAR, could be a > contentious and therefore longer discussion. > > On Wed, May 31, 2017 at 5:42 AM, Barry Leiba > wrote: > >> How long do we think we need for this discussion? >> >> b >> >> On Wed, May 31, 2017 at 2:50 PM, Kurt Andersen (b) >> wrote: >> > (Reposting with adjusted subject) >> > >> > On Wed, May 31, 2017 at 9:46 AM, Kurt Andersen (b) >> wrote: >> >> >> >> Barry et al, >> >> >> >> On Wed, May 31, 2017 at 1:14 AM, Seth Blank wrote: >> >>> >> >>> The current spec defines an arc authres method >> >>> (https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-0 >> 3#section-8.1). >> >>> >> >>> We believe there should also be registered ptypes and properties, that >> >>> should be stamped (but are not required, as they won't always be >> available). >> >>> >> >>> As long as AR stamping happens at the end of chain validation, when an >> >>> ARC set gets created this stamp will be included in the AAR, and AAR >> >>> construction can be clean with no additional language or requirements >> >>> necessary in the spec. >> >> >> >> >> >> This area seems like something that would be productively explored in a >> >> F2F since it is pretty undefined right now and there are some divergent >> >> opinions kicking around... (see the thread with Brandon and Scott so >> far) >> >> >> >> --Kurt >> > >> > >> > >> > _______________________________________________ >> > dmarc mailing list >> > dmarc@ietf.org >> > https://www.ietf.org/mailman/listinfo/dmarc >> > >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> > > > > -- > > [image: logo for sig file.png] > > Bringing Trust to Email > > Seth Blank | Head of Product for Open Source and Protocols > seth@valimail.com > +1-415-894-2724 <415-894-2724> > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --001a1144553e4db1c60550e973f1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've gone ahead and bumped the time request up to 60 m= inutes, to be sure we do have time for what we want to discuss.=C2=A0 We ca= n always give back some of the time later, as we build an agenda, if that m= akes sense.

Barry


On Wed, May 31, 2017 at 7:4= 2 PM, Seth Blank <seth@valimail.com> wrote:
AR might be 10-15 minutes.

What to do to transport the source_ip, which is valuable to report co= nsumers but doesn't appear to belong in the AR/AAR, could be a contenti= ous and therefore longer discussion.
=

On Wed, May 31, 2017 = at 5:42 AM, Barry Leiba <barryleiba@computer.org> wrot= e:
How long do we think we need for this = discussion?

b

On Wed, May 31, 2017 at 2:50 PM, Kurt Andersen (b) <kboth@drkurt.com> wrote:
> (Reposting with adjusted subject)
>
> On Wed, May 31, 2017 at 9:46 AM, Kurt Andersen (b) <kboth@drkurt.com> wrote:
>>
>> Barry et al,
>>
>> On Wed, May 31, 2017 at 1:14 AM, Seth Blank <seth@valimail.com> wrote:
>>>
>>> The current spec defines an arc authres method
>>> (https://tools.= ietf.org/html/draft-ietf-dmarc-arc-protocol-03#section-8.1).<= br> >>>
>>> We believe there should also be registered ptypes and properti= es, that
>>> should be stamped (but are not required, as they won't alw= ays be available).
>>>
>>> As long as AR stamping happens at the end of chain validation,= when an
>>> ARC set gets created this stamp will be included in the AAR, a= nd AAR
>>> construction can be clean with no additional language or requi= rements
>>> necessary in the spec.
>>
>>
>> This area seems like something that would be productively explored= in a
>> F2F since it is pretty undefined right now and there are some dive= rgent
>> opinions kicking around... (see the thread with Brandon and Scott = so far)
>>
>> --Kurt
>
>
>
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org=
> https://www.ietf.org/mailman/listinfo/dmarc=
>

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



--

3D"logo

Bringing Trust to Email

Seth Blank | Head of P= roduct for Open Source= and Protocols

seth@valimail.com
+1-415-894-2724

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


--001a1144553e4db1c60550e973f1-- From nobody Thu Jun 1 11:18:36 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79EC912EC39 for ; Thu, 1 Jun 2017 11:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.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 HX5_zcQGx-P3 for ; Thu, 1 Jun 2017 11:18:32 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::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 6F7F9129AFC for ; Thu, 1 Jun 2017 11:18:32 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id t26so42853278qtg.0 for ; Thu, 01 Jun 2017 11:18:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WOVOANwpr8LFG9K/BuIqOw8lvlnl7v8iyWGMBmgOm5M=; b=OEoFf55Z53JSGozVgKN13Dey7B8wJsXzR+6tLFCZXgazFJBq/r92XSX2HBLLPDeLI0 Op/04/SKfhuOqPad7Zk9w08+xuh9f5YjBW+ntssXyYvH4RCM0qxtS7N1+xCiTQbnHaqb RjtCjj8uW/nP5h8NIpMnzrVc7x7e3A2ykbT91ojZl7gcFLClmEjNoH9EX+lXgZlea+z+ /PLLnDGDWNXkr4H25IulYviFb7joWWjIXO5WwTvgQ88JRIxfxmmtC/pltBw/UzzptCT8 hktwBlgdoTPoPKF5cTEaJ0F1PrCz1ktREw9p1RBZEay3CaOcNig363D1EyxtlKABFDTW YL9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WOVOANwpr8LFG9K/BuIqOw8lvlnl7v8iyWGMBmgOm5M=; b=LEFo5lhu36UncTXCrAsZuHkyPAcvprYezh+aSgBcLsc2H0LQI1Gez8rSQcfkLhWJ8v 59we6TZWcDZjVeHsj+DHkDdAzBD5JPAZxQeN70sxlQ+vH9vTjpNpYAxRa0Fsi8lNI6vi GrWZn+SsWNnify2ukDsG+OKIHNjnzJbrd1P9laMOiT3ze1tIjnL2Y4xDG+pmg8jrJScm ntMyNi2Oi7J32M1cmW1agHLWeB2EtR4xqg0cXaGFORcNr1IMuRaEVWgQpRG1TKHZyJeF vkuzXV9EydgmPaxCMaB24fpDqMoL/ZzuKOMpWaPBMDWoezCaR4/07Le123+sCoTiWKZZ XR8g== X-Gm-Message-State: AODbwcDeB3tLWucZ3DM+h2u8tkwwg71KBtXzhMY6YOiDN/XumnEOJnNY sHk7V6uBfjmVMNv//P7vqukV15GT2vgV X-Received: by 10.200.49.1 with SMTP id g1mr3833792qtb.118.1496341111611; Thu, 01 Jun 2017 11:18:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.42.242 with HTTP; Thu, 1 Jun 2017 11:18:11 -0700 (PDT) In-Reply-To: References: From: Seth Blank Date: Thu, 1 Jun 2017 11:18:11 -0700 Message-ID: To: "Kurt Andersen (b)" Cc: "Murray S. Kucherawy" , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a113a87586bbb8f0550ea10d9" Archived-At: Subject: Re: [dmarc-ietf] Clarifying question: AAR coverage by AMS X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2017 18:18:34 -0000 --001a113a87586bbb8f0550ea10d9 Content-Type: text/plain; charset="UTF-8" I'm slightly confused. I have a strong sense that the d= tag should be the same between the AS and AMS within an ADMD. I can absolutely see why the s= might legitimately vary. However, I can't seem the harm in the d= tag differing. If the signatures validate, why should this matter? Might this be simpler with language like "it is RECOMMENDED that the d= value match between the AS and AMS, as any receiver might look at a mismatch as suspicious." i.e. Don't outright deny because maybe there's a legitimate reason to do this that hasn't been discovered, and leave it up to receivers how to deal with this? Seth On Thu, Jun 1, 2017 at 4:05 AM, Kurt Andersen (b) wrote: > On Thu, Jun 1, 2017 at 12:10 PM, Murray S. Kucherawy > wrote: > >> On Wed, May 31, 2017 at 6:23 PM, Kurt Andersen (b) >> wrote: >> >>> There's another question that had been raised by Seth about whether d= >>> needs to match within an ARC set. The answer is yes, [...] >>> >> >> Why? >> >> -MSK >> > > If an ARC-set is created by a single ADMD, I think it's reasonable for > that ADMD to identify itself in a singular manner, though I suppose we > could have recourse to our favorite "org domain" alignment instead of > strict matching if you think that's better. I think that strict d= matching > is simpler and less likely to be misused/broken. > > --Kurt > -- [image: logo for sig file.png] Bringing Trust to Email Seth Blank | Head of Product for Open Source and Protocols seth@valimail.com +1-415-894-2724 <415-894-2724> --001a113a87586bbb8f0550ea10d9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm slightly confused.

I have a str= ong sense that the d=3D tag should be the same between the AS and AMS withi= n an ADMD. I can absolutely see why the s=3D might legitimately vary. Howev= er, I can't seem the harm in the d=3D tag differing. If the signatures = validate, why should this matter?

Might this be si= mpler with language like "it is RECOMMENDED that the d=3D value match = between the AS and AMS, as any receiver might look at a mismatch as suspici= ous."

i.e. Don't outright deny because ma= ybe there's a legitimate reason to do this that hasn't been discove= red, and leave it up to receivers how to deal with this?

Seth

On Thu, Jun 1, 2017 at 4:05 AM, Kurt Andersen (b) &= lt;kboth@drkurt.com> wrote:
O= n Thu, Jun 1, 2017 at 12:10 PM, Murray S. Kucherawy <<= a href=3D"mailto:superuser@gmail.com" target=3D"_blank">superuser@gmail.com= > wrote:
O= n Wed, May 31, 2017 at 6:23 PM, Kurt Andersen (b) <kboth@drkurt.com>= wrote:
There's another question t= hat had been raised by Seth about whether d=3D needs to match within an ARC= set. The answer is yes, [...]

Why?

=
-MSK

If an A= RC-set is created by a single ADMD, I think it's reasonable for that AD= MD to identify itself in a singular manner, though I suppose we could have = recourse to our favorite "org domain" alignment instead of strict= matching if you think that's better. I think that strict d=3D matching= is simpler and less likely to be misused/broken.

--Kurt


--

3D"logo

Bringing Trust to Email

Seth Blank | Head of Product for Open Source and Protocols

<= a href=3D"mailto:seth@valimail.com" target=3D"_blank">seth@valimail.com= <= br>+1-415-894-2724
--001a113a87586bbb8f0550ea10d9-- From nobody Thu Jun 1 11:40:35 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6485312778E for ; Thu, 1 Jun 2017 11:40:33 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=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 Yna-Hk2T__Fz for ; Thu, 1 Jun 2017 11:40:31 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003: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 3D3E712FEE1 for ; Thu, 1 Jun 2017 11:40:31 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id h4so65051754oib.3 for ; Thu, 01 Jun 2017 11:40:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=b0nsyq5+xcxN57XH98cWO53a8JCYqrSIE2upaSZi3Yg=; b=OO5btXLFrdEq1vVhn7dwtB7c2EKDRNeXs75EqDIScCBtrW2pF69q41NWxj/Wr9ZwdR x5gJ1TQ8aXj8bQJ2MRxi6oEz2nB9GZWSjAVySD/28UAtRn12U9RkfFv8mc21IrbAqdBw fcQ02dsjhAZW8WkRQtNL+buh5kvAJIX/VC2t+5GlXNyf10wAT/bd+eyyP5ei7R8anNv9 +Fvv/wBRMgGwCNxobqh8L9P/7m+ui0VVQSb7wlt4xfMjZKzQLtsjhkQMIGmS2kFvqwbr G0A65Ee3lq5qnizabr6CVrn+11oh0Qw8YeesJdG8/HDdJlVvA5n6S/Cge/eK8wvHuByu V61w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=b0nsyq5+xcxN57XH98cWO53a8JCYqrSIE2upaSZi3Yg=; b=p9jHyUfrxpFb20j5FwN7L16OCi1933GkzMpQSnuSsMmnW1F1rRe05EK4BcGYeF41LD HE39Ax2c8s3B8b/tsj3MoI8Ewn4ur1lzuKMZd6fIDbOGuioOiFRETrmu3+c1236mGHsZ 7Hht4UZX1631OMSwDEzYQNtkFtDw8yf0UAIRYqq33W/vY3Cerr0gugHfSqKqEWVhKDtK 7TtHrj51R37sMoIAqWcxGXGM4PcKXTDc2tP7mrwveYRkbE8c6ezL57gxpcNTIbc03kjT lp4phlwa3QW6vBDYwWI2D1TjB5+NaZb9dChzP/LTTK8YO5P/diAWy9C3fHeU3IxouRCU o3Qw== X-Gm-Message-State: AODbwcAplmCgdIp7Uzs16KAhbHZ1A0e3cFqdwmq7FHF8RLeSHRQyxlDN Q7mnvakDKOaeb9BQ9n0J7LsdRgule+R5 X-Received: by 10.157.20.251 with SMTP id r56mr2021551otr.55.1496342430411; Thu, 01 Jun 2017 11:40:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.8.34 with HTTP; Thu, 1 Jun 2017 11:40:29 -0700 (PDT) In-Reply-To: References: From: Brandon Long Date: Thu, 1 Jun 2017 11:40:29 -0700 Message-ID: To: "Murray S. Kucherawy" Cc: "Kurt Andersen (b)" , "dmarc@ietf.org" , Seth Blank Content-Type: multipart/alternative; boundary="001a113524cc0768a00550ea5fa7" Archived-At: Subject: Re: [dmarc-ietf] Clarifying question: AAR coverage by AMS X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2017 18:40:33 -0000 --001a113524cc0768a00550ea5fa7 Content-Type: text/plain; charset="UTF-8" On Wed, May 31, 2017 at 3:22 PM, Murray S. Kucherawy wrote: > On Wed, May 31, 2017 at 3:08 PM, Brandon Long wrote: > >> On Wed, May 31, 2017 at 1:42 PM, Murray S. Kucherawy > > wrote: >> >>> On Wed, May 31, 2017 at 1:35 PM, Murray S. Kucherawy < >>> superuser@gmail.com> wrote: >>> >>>> What benefit is there to covering AAR with both the AMS and the AS? It >>>> seems to me the AMS is much cleaner (in the sense of ARC being a layer atop >>>> DKIM) if it is purely a renamed DKIM signature with an instance number. >>>> >>>> Put another way, the apparent intent here is to require that things be >>>> generated in a specific order (AAR, then AMS, then AS) but it seems to me >>>> there's no obvious benefit to imposing that constraint given that AS is >>>> supposed to cover everything anyway. >>>> >>> >> Ignoring your DKIM bit, I can also see how this could be extended to >> think about the oddness that having two signatures and whether the keys >> need to match between AS/AMS. >> >> One could imagine that the AMS was just a hash, and it would be a single >> signature in the AS which covers it. That's obviously more different than >> DKIM, but reduces the size of the headers and makes a single point of >> ownership. >> > > Indeed, AS could sign (a) a locally-generated DKIM signature, with an > instance tag (since DKIM validators ignore tags they don't know), plus (b) > the current and all previous AAR/AS fields. > That's kind of the opposite direction of what I was thinking. I'm saying, an AMS doesn't need a b= field, it could instead have an hh field (header hash) or replace bh with a single hash field. ARC-Seal: i=1; a=rsa-sha256; t=1496269322; cv=none; d=google.com; s=arc-20160816; b=dttRxs73FHsET5Zu1FVFwkpnS2bLmNcCXJKMBS5JPwBdfNIqBK7RH2P9K9SzXaBtg4 rpXyIA+nigy2vHiKAP0hU8Cbh2lUtHXQbglvSiom91w+8UpDvvlGI8N4OP7Ju0iAvmfS XAxPGuXKCiyd48jZ+9QOqP1q39gd1mheUrkmFoVYzd9n5bkfwkazhkT05gk1bs16fnE4 1fvOasGjlBvhDEzSv790k7i40NpwXuYRqhYgD3/ndxfT0l/uVJ0qp44krz0yRgyJebjo oNOeJT1dFL3l70BPnDtku5Wof77eD1Ql8rb5uGKnRgpYaaxh2Nt5PNQ0iLtFBWFTQo9c GL2A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:dkim-signature:arc-authentication-results; hash=3Yg5aVXobpP5fEP6VLnpuEPddr3SuybR7iVPPBvW59s= ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com; spf=pass (google.com: domain of superuser@gmail.com designates 2607:f8b0:400c:c05::22c as permitted sender) smtp.mailfrom= superuser@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com This removes the confusion over separate s/d for AMS/AS, reduces the size of the headers added by ARC, reduces the cost of signing/verifying (one less encryption step, though that may not be the expensive part). Ie, our current idea was the onion wrapping, AS wraps AMS which wraps AAR. If we think more of them as a unit, then the signature in the AS is sufficient for the whole unit. Hm, though then, maybe it's not a Message-Signature but just a Message-Hash. Brandon --001a113524cc0768a00550ea5fa7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, May 31, 2017 at 3:22 PM, Murray S. Kucherawy = <superuser@gmai= l.com> wrote:
On Wed, May 31, 2017 at 3:08 = PM, Brandon Long <blong@google.com> wrote:
On Wed, = May 31, 2017 at 1:42 PM, Murray S. Kucherawy <superuser@gmail.com&g= t; wrote:
<= div class=3D"gmail_quote">
On Wed, May 31, 2017 a= t 1:35 PM, Murray S. Kucherawy <superuser@gmail.com> wrote= :
Ignoring your DKIM bit, I can also see how this could be extende= d to think about the oddness that having two signatures and whether the key= s need to match between AS/AMS.

One could imagine = that the AMS was just a hash, and it would be a single signature in the AS = which covers it.=C2=A0 That's obviously more different than DKIM, but r= educes the size of the headers and makes a single point of ownership.
=

Indeed, AS could = sign (a) a locally-generated DKIM signature, with an instance tag (since DK= IM validators ignore tags they don't know), plus (b) the current and al= l previous AAR/AS fields.=C2=A0

That's kind of the opposite direction of what I was th= inking.

I'm saying, an AMS doesn't need a = b=3D field, it could instead have an hh field (header hash) or replace bh w= ith a single hash field.

ARC-Seal: i=3D1; a= =3Drsa-sha256; t=3D1496269322; cv=3Dnone;
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 d=3Dgoogle.com; s=3Darc-20160816;<= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 b=3DdttRxs73FHsET5Zu1FVFwkpnS2bLmNcCX= JKMBS5JPwBdfNIqBK7RH2P9K9SzXaBtg4
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0rpXyIA+nigy2vHiKAP0hU8Cbh2lUtHXQbglvSiom91w+8UpDvvlGI8N4OP7Ju0iAvmfS
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0XAxPGuXKCiyd48jZ+9QOqP1q39gd1mheUr= kmFoVYzd9n5bkfwkazhkT05gk1bs16fnE4
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A01fvOasGjlBvhDEzSv790k7i40NpwXuYRqhYgD3/ndxfT0l/uVJ0qp44krz0yRgyJebjo<= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0oNOeJT1dFL3l70BPnDtku5Wof77eD1Q= l8rb5uGKnRgpYaaxh2Nt5PNQ0iLtFBWFTQo9c
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0GL2A=3D=3D
ARC-Message-Signature: i=3D1; a=3Drsa-sha256; c= =3Drelaxed/relaxed;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 h=3Dcc:to:subject= :message-id:date:from:references:in-reply-to
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0:mime-version:dkim-signature:arc-authentication-results;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 hash=3D3Yg5aVXobpP5fEP6VLnpuEPddr3SuybR7i= VPPBvW59s=3D =C2=A0 =C2=A0 =C2=A0 =C2=A0
ARC-Authentication-Resul= ts: i=3D1; mx.google.com;
= =C2=A0 =C2=A0 =C2=A0 =C2=A0dkim=3Dpass header.i=3D@gmail.com;
=C2=A0 =C2=A0 =C2=A0 =C2=A0spf=3Dpass (google.com: domain of superuser@gmail.com designates 2607:f8b0:400c:c05::22c as= permitted sender) smtp.mailfrom=3Ds= uperuser@gmail.com;
=C2=A0 =C2=A0 =C2=A0 =C2=A0dmarc=3Dpass (= p=3DNONE sp=3DNONE dis=3DNONE) header.from=3Dg= mail.com

This removes the confusion over= separate s/d for AMS/AS, reduces the size of the headers added by ARC, red= uces the cost of signing/verifying (one less encryption step, though that m= ay not be the expensive part).

Ie, our current ide= a was the onion wrapping, AS wraps AMS which wraps AAR.=C2=A0 If we think m= ore of them as a unit, then the signature in the AS is sufficient for the w= hole unit.

Hm, though then, maybe it's not a M= essage-Signature but just a Message-Hash.

Brandon<= /div>
--001a113524cc0768a00550ea5fa7-- From nobody Thu Jun 1 11:47:16 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 754D412778E for ; Thu, 1 Jun 2017 11:47:15 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kU1rfT9l1mpy for ; Thu, 1 Jun 2017 11:47:14 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::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 5C6DC126CD6 for ; Thu, 1 Jun 2017 11:47:14 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id w10so65296204oif.0 for ; Thu, 01 Jun 2017 11:47:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WfHdrqCgd2/POpX80S+KP/wHXjVg4q24UyytFmOZiYA=; b=i9v2vxXPScM2N2owaLofMsMV15z8IPCI1M6hAmib4fRZwZlgkuanPk0rxqSn/g74r6 kS76w52NJisUFZ0RuV1ReBo12efsD12HC8kOvwXtnoBMaKkkYE2727IVddYHuwYSFa/Y 5oK3MOQGqRDzOpRZNjjjcxynLh7AG6+Jvc2NZKr2AtOJ5L3CTXf6gj18t8RHw5aF1PxM 1ENQZAgrsKoAplHNiVyfEATUItoq9naUL4k/Y1YUw2ZPkX3KnGTV0T9V1UCsvjCLAnkg 8BoKc9VjrMspyxfQgJL/bjl6eDK/65oq7LdPGVx3AqISSETkJXYZbHDv6PYrogrSM3/6 XNvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WfHdrqCgd2/POpX80S+KP/wHXjVg4q24UyytFmOZiYA=; b=bW6UO0NFD2VYqLTgf7yXAZTjPJv7RZXe7cuVOCbPUnekWLiYVrJnxtdN6+tTI4f+aY MrRU2aP10U158qcLiqjV44k9uvsNKRz+54t35YSOXnl5vLPFxDk0UGVfpc03YPM9qGqs EHP8/au6XwgKZEfsEuN1ZOBbECuy4foyecJyP+Ce074ZBvEmw2YTg1qx4AovD65fzfEd RkpQgk6Tzidh3gdYT+ys0kiqOSUHx1PItMu+3U9YxdYI3O77z8ORawGeQHu+KiLi1wpV U7AVcC7JT+NoVSDLAhBZs5x+k+gSaiw62SwwU57AuRpmLz+psoPWR+qKzext8iJRSEd5 JmTg== X-Gm-Message-State: AODbwcAbM+gpbBIUzZLSxCKptEqDNVbdLNeBJ98M7LOUx0BLSXmV5d4u VJZm1Qb07eaYKFjTEKXTbS/4e2CsFJK7SSI= X-Received: by 10.202.52.214 with SMTP id b205mr2171319oia.133.1496342833519; Thu, 01 Jun 2017 11:47:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.8.34 with HTTP; Thu, 1 Jun 2017 11:47:12 -0700 (PDT) In-Reply-To: References: <34808716.2nE2qoVfF5@kitterma-e6430> From: Brandon Long Date: Thu, 1 Jun 2017 11:47:12 -0700 Message-ID: To: "Kurt Andersen (b)" Cc: "Murray S. Kucherawy" , "dmarc@ietf.org" , Scott Kitterman Content-Type: multipart/alternative; boundary="001a113cbd3a0e8abe0550ea77a0" Archived-At: Subject: Re: [dmarc-ietf] Authentication-Results stamp for ARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2017 18:47:15 -0000 --001a113cbd3a0e8abe0550ea77a0 Content-Type: text/plain; charset="UTF-8" On Thu, Jun 1, 2017 at 4:10 AM, Kurt Andersen (b) wrote: > On Thu, Jun 1, 2017 at 12:20 PM, Murray S. Kucherawy > wrote: > >> Another way to look at it: A-R is meant to be a channel to record what >> authentication was done and what thing in the visible message got >> authenticated > > > So, for SPF which does not authenticate *anything* in the original > message, how is A-R relevant at all (by that intention)? > Yeah, I'm trying to see the real difference between the IP and the smtp.helo ... and of course, there's also policy.iprev. Brandon --001a113cbd3a0e8abe0550ea77a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jun 1, 2017 at 4:10 AM, Kurt Andersen (b) <= ;kboth@drkurt.com= > wrote:
On Thu, J= un 1, 2017 at 12:20 PM, Murray S. Kucherawy <superuser@gmail.com&g= t; wrote:
Another way to look at i= t: A-R is meant to be a channel to record what authentication was done and = what thing in the visible message got authenticated

<= /span>So, for SPF which does not authenticate *anything* in the original me= ssage, how is A-R relevant at all (by that intention)?

Yeah, I'm trying to see the real difference bet= ween the IP and the smtp.helo ... and of course, there's also policy.ip= rev.

Brandon
--001a113cbd3a0e8abe0550ea77a0-- From nobody Thu Jun 1 14:14:28 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD8F6126B7E for ; Thu, 1 Jun 2017 14:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5rqAOLe5Qx_2 for ; Thu, 1 Jun 2017 14:14:26 -0700 (PDT) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1553A1200C5 for ; Thu, 1 Jun 2017 14:14:26 -0700 (PDT) Received: by mail-ua0-x233.google.com with SMTP id y4so34916639uay.2 for ; Thu, 01 Jun 2017 14:14:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=i2h2QBL7JGCuNypCGzm3FYawaeNKwad26D4LmLzzHGE=; b=eb9wahn4oVEJoyc2zdLZgO1u41jWBZhHwdGOv3Ihe8zNpk1gmaA8aTfOvtv00t/qCX KoA3EZ3oWVJYm2GeVu6BVi5yyPUGvUlPn3UX3n0E/i7Ps2fF7cPbfy5Je6WUKwoCAd0T 5+JLj2ps5Smuq52byclch8CvJnEnIWgI+1TPw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=i2h2QBL7JGCuNypCGzm3FYawaeNKwad26D4LmLzzHGE=; b=g71Ziyb/seKKLLHtPpq//gcnRxuRv4iEYugySlRyri88s0+xdKvvtRpk7lWZxyxCaW eKBI83JXnQ7lIlx0b/7XXgHPgTp9wuFpXAunrGde4p1wwtH50cgqMCZu3M3ImrC1dp2W nepA3gtx1prYKdcMMId6prIougfw9iKh2SHm/MaX6OlCgQhbXuMdXLyFy3kQE5hqi7l7 F4OsP6SZfOfa9yPe6vpLqruGNWj8Kzq8flx53HEJmjenZEE6iVGrtpW3D5pjOGZQReUA hpg7tYCbD/HKkDDBfdVAB50VEb5Pvf80y+feY0sdJTp8OPTZnFnodgC4IQ8X5WJ/8Ddq 6o7Q== X-Gm-Message-State: AODbwcAX02d+8ScyYf6CUKF0/WuJx4Tdms9eaBjNaMX+6a3ssKHPkCLK yBIJcDzzdB/JMXJ1lS+EK9e8OBXBwsZS X-Received: by 10.176.65.99 with SMTP id j90mr2024794uad.1.1496351665060; Thu, 01 Jun 2017 14:14:25 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.176.83.111 with HTTP; Thu, 1 Jun 2017 14:14:24 -0700 (PDT) Received: by 10.176.83.111 with HTTP; Thu, 1 Jun 2017 14:14:24 -0700 (PDT) In-Reply-To: References: From: "Kurt Andersen (b)" Date: Fri, 2 Jun 2017 05:14:24 +0800 X-Google-Sender-Auth: CEtYelH4pHhA1t_Ub1NS9iool9c Message-ID: To: Seth Blank Cc: "Murray S. Kucherawy" , dmarc@ietf.org Content-Type: multipart/alternative; boundary="94eb2c12309a7496970550ec8512" Archived-At: Subject: Re: [dmarc-ietf] Clarifying question: AAR coverage by AMS X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2017 21:14:28 -0000 --94eb2c12309a7496970550ec8512 Content-Type: text/plain; charset="UTF-8" On Jun 1, 2017 11:48 PM, "Seth Blank" wrote: I'm slightly confused. I have a strong sense that the d= tag should be the same between the AS and AMS within an ADMD. I can absolutely see why the s= might legitimately vary. However, I can't seem the harm in the d= tag differing. If the signatures validate, why should this matter? That was our thought when writing the spec which is why the spec does not speak to the issue (should be something in the usage doc IMO). I think Gene raised the concern...Gene? --Kurt --94eb2c12309a7496970550ec8512 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Jun 1, 2017 11:48 PM, "Seth Blank" <seth@valimail.com> wrote:
I'm slightly confused.<= div>
I have a strong sense that the d=3D tag should be the sa= me between the AS and AMS within an ADMD. I can absolutely see why the s=3D= might legitimately vary. However, I can't seem the harm in the d=3D ta= g differing. If the signatures validate, why should this matter?

Tha= t was our thought when writing the spec which is why the spec does not spea= k to the issue (should be something in the usage doc IMO). I think Gene rai= sed the concern...Gene?

= --Kurt
--94eb2c12309a7496970550ec8512-- From nobody Thu Jun 1 14:43:24 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FFEC1242F7 for ; Thu, 1 Jun 2017 14:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.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 C6wl_RWoohrk for ; Thu, 1 Jun 2017 14:43:20 -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 83B8A1241FC for ; Thu, 1 Jun 2017 14:43:20 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id 63so13504421ywr.0 for ; Thu, 01 Jun 2017 14:43:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DfrJOGJWQX+3oTbUQiFcHbTiyAQbLR61i8+xZ2j2thM=; b=O5Wl3SxfIX76YGnjGT7y9jPbU1kfMWjGjRr1U14zt12nq4gnpamEhyrVlYDii3TY3V xATM1YaqXeQ+2JORFw8zsWDuFESljALKhqXm1/M+omXDmripiaChWY+5G/ODxmxlKOLn DSbi1SL+GX4GvdQo4tgabq0KZBGOmPBoJUzBUlFvRLQf7ySuI1ejn5jKcT5kJc/+kUNc doVV2dMX2L89qi13HU/SLOgK3C8DrQINvP87KGouI3ERKj/JT/r/F6kya/l74MqD+QRo vX7NsvihpGbJZQqyayOajO4OGzdbtsEXwGs0eiGiYd7cPNbGoMACrRwrEfBrymmFoJyu 8FBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DfrJOGJWQX+3oTbUQiFcHbTiyAQbLR61i8+xZ2j2thM=; b=dc78iAGceLkuMHHXxxCG5Y8A4g3ziLssb12lQQ95dUReRRA3WU88fMfZT9xsxfs+wL 9v3ZwjfHJx3RncsLm9YGwNS41ZH9qKtegxlKyDHNVe03aY/mKVlHEHtC+kSbnWkgSLPy s1swQ/y0dgbtBc3ul5br0mQ7sPG5OxfNWx8BwOIHvXP+iTo00XMCgJvyY9EW7ZXMMojx +00klEp00XMGna+riKR31e9InkvDoY9KtH25WoLyjE7uVxAB+jknQzb9T8CKmJv68sFi ktzDQbevrYTzQaiUnlts6mn4ZYNXifqHutWhU2rD+HrSKauQrViE6YePBe87W6Ex7dWi ZP+Q== X-Gm-Message-State: AODbwcAKSN+IFkHqhL0JYdj79oa8c6D/M1QP1ZlEf7vIL9X2ft0e9Q9i cnoASMRePocsF6y8pWHQXNhM0ogpLZMo X-Received: by 10.129.92.133 with SMTP id q127mr3178156ywb.235.1496353399677; Thu, 01 Jun 2017 14:43:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.208.143 with HTTP; Thu, 1 Jun 2017 14:43:19 -0700 (PDT) In-Reply-To: References: From: Gene Shuman Date: Thu, 1 Jun 2017 14:43:19 -0700 Message-ID: To: "Kurt Andersen (b)" Cc: Seth Blank , dmarc@ietf.org, "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary="001a114d8f8cd8c59d0550ececf2" Archived-At: Subject: Re: [dmarc-ietf] Clarifying question: AAR coverage by AMS X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2017 21:43:23 -0000 --001a114d8f8cd8c59d0550ececf2 Content-Type: text/plain; charset="UTF-8" I don't have particularly strong opinions here. I can see no reason for the d= to differ, but also no harm in allowing it do so. So I think the question of what to do here is slightly more philosophical. I think I generally fall on the side of reducing user flexibility when nothing is actively gained as opposed to granting user flexibility when there is no harm. But again, no real strong opinion on the matter. On Thu, Jun 1, 2017 at 2:14 PM, Kurt Andersen (b) wrote: > On Jun 1, 2017 11:48 PM, "Seth Blank" wrote: > > I'm slightly confused. > > I have a strong sense that the d= tag should be the same between the AS > and AMS within an ADMD. I can absolutely see why the s= might legitimately > vary. However, I can't seem the harm in the d= tag differing. If the > signatures validate, why should this matter? > > > That was our thought when writing the spec which is why the spec does not > speak to the issue (should be something in the usage doc IMO). I think Gene > raised the concern...Gene? > > --Kurt > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --001a114d8f8cd8c59d0550ececf2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't have particularly strong opinions here.=C2=A0 = I can see no reason for the d=3D to differ, but also no harm in allowing it= do so.=C2=A0 So I think the question of what to do here is slightly more p= hilosophical. I think I generally fall on the side of reducing user flexibi= lity when nothing is actively gained as opposed to granting user flexibilit= y when there is no harm.=C2=A0 But again, no real strong opinion on the mat= ter. =C2=A0 =C2=A0

On Thu, Jun 1, 2017 at 2:14 PM, Kurt Andersen (b) = <kboth@drkurt.com<= /a>> wrote:
<= div class=3D"gmail_extra" dir=3D"auto">
On Jun 1,= 2017 11:48 PM, "Seth Blank" <seth@valimail.com> wrote:
I'm= slightly confused.

I have a strong sense that the d=3D = tag should be the same between the AS and AMS within an ADMD. I can absolut= ely see why the s=3D might legitimately vary. However, I can't seem the= harm in the d=3D tag differing. If the signatures validate, why should thi= s matter?

<= div dir=3D"auto">That was our thought when writing the spec which is why th= e spec does not speak to the issue (should be something in the usage doc IM= O). I think Gene raised the concern...Gene?

--Kurt

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


--001a114d8f8cd8c59d0550ececf2-- From nobody Thu Jun 1 15:32:23 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C6B212778E for ; Thu, 1 Jun 2017 15:32:22 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFOJ903uJrqL for ; Thu, 1 Jun 2017 15:32:21 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39F68124D6C for ; Thu, 1 Jun 2017 15:32:21 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id l18so71793846oig.2 for ; Thu, 01 Jun 2017 15:32:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kOixNF6YfjYVbqEtJu8H7W8+eitoLP8PXui0UyBsAVs=; b=GQPONie4dIHoOGghginPiqFi+gdyzJeVGwVV2tAXWBaijPB0Y9rVyPZjWRlEdu7xd1 NRHKTE2WRvmiG8hSXUm8ZHxL/Hg6XVPJpA69i+mJmJ/1pdOLMs9FOzpECOpuHz2MvO4p uSwTkNx43/eEcIkcKDGYzsDWBLEFHk8nqk+fFoQ9DjsSRgYUnKLcfuEXtz7tec3OEctv GIVhgV5fwnWydKVFwnAtTRPA3lnd68j1k/i0PsIyyThv+hpWtGfBzXHmhzOS7iuwZNtP L/DVGPWsqZBz8FkeCS9SOalwEvWSSv4MwL7zxOBeW6BqAGobAjXZuZZrRy4B0cFrXSDp 5fzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kOixNF6YfjYVbqEtJu8H7W8+eitoLP8PXui0UyBsAVs=; b=VPn5R8SIzv2VmwVggpZN87XQCwIFP98EQOGilAz+jyuOw0x97pxYdIz4h3x2/tm8jK mUdeDnLMbpL4iuattJWtiqSDv0+7aG6TPF/I7zrKUOp/ZzI5JsTDPgemkKB2Q0mABSO+ 2/8Yd48qJ0c2s1NRzl1LbPCoK+SUlWyJWGWQwkJowPIw2WNI28RUD+M9j/OENG0pgvec U/d7MLnug09DkALBTgnshEDqsVpSXOo/XoAc00nx3suWgNrIi3qKBD6qILL5PyqB4WSi p6IviIOaFfo4Q4F4J9L4CjpzfaBdVGHnGlTiey3qViqUOTyAZbaNMi1U0G/fVmS0O/pK I80Q== X-Gm-Message-State: AODbwcBDv0/XIjKCkWd35CrDDBSrQt7GHlq25WmgzSgKpsRJ3iZ9ZVHu Mp1lFebin4bytgff/PWw9rQjwGY2Se2o X-Received: by 10.157.40.238 with SMTP id s101mr2987798ota.88.1496356340374; Thu, 01 Jun 2017 15:32:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.8.34 with HTTP; Thu, 1 Jun 2017 15:32:19 -0700 (PDT) In-Reply-To: References: From: Brandon Long Date: Thu, 1 Jun 2017 15:32:19 -0700 Message-ID: To: "Kurt Andersen (b)" Cc: Seth Blank , "dmarc@ietf.org" , "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary="001a113edb9420db970550ed9c51" Archived-At: Subject: Re: [dmarc-ietf] Clarifying question: AAR coverage by AMS X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2017 22:32:22 -0000 --001a113edb9420db970550ed9c51 Content-Type: text/plain; charset="UTF-8" On Thu, Jun 1, 2017 at 2:14 PM, Kurt Andersen (b) wrote: > On Jun 1, 2017 11:48 PM, "Seth Blank" wrote: > > I'm slightly confused. > > I have a strong sense that the d= tag should be the same between the AS > and AMS within an ADMD. I can absolutely see why the s= might legitimately > vary. However, I can't seem the harm in the d= tag differing. If the > signatures validate, why should this matter? > > > That was our thought when writing the spec which is why the spec does not > speak to the issue (should be something in the usage doc IMO). I think Gene > raised the concern...Gene? > I think we thought s might be different between arc and dkim, I don't think we really considered it being different between AMS/AS. That said, I don't think different selectors is that important. I do think that having different domains for AMS/AS needlessly complicates thinking about reputation/trust of the chain. Do you trust based on AS or on AMS, on either or only on pairs. Without an example of a legitimate use case for them being different, I think we should err on the side of requiring them to be the same (assuming no one takes me up on my suggestion of removing it from the AMS entirely) Brandon --001a113edb9420db970550ed9c51 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jun 1, 2017 at 2:14 PM, Kurt Andersen (b) <= ;kboth@drkurt.com= > wrote:
On Jun 1, 2017 11:48 PM, "Seth Blank" <seth@valimail.com> wrote:
I'm slightly confused.

I have a strong sens= e that the d=3D tag should be the same between the AS and AMS within an ADM= D. I can absolutely see why the s=3D might legitimately vary. However, I ca= n't seem the harm in the d=3D tag differing. If the signatures validate= , why should this matter?

That was our thought when writing t= he spec which is why the spec does not speak to the issue (should be someth= ing in the usage doc IMO). I think Gene raised the concern...Gene?

I think we thought s might be different= between arc and dkim, I don't think we really considered it being diff= erent between AMS/AS.

That said, I don't think= different selectors is that important.

I do think that havin= g different domains for AMS/AS needlessly complicates thinking about reputa= tion/trust of the chain.=C2=A0 Do you trust based on AS or on AMS, on eithe= r or only on pairs.

Without an example of a legiti= mate use case for them being different, I think we should err on the side o= f requiring them to be the same (assuming no one takes me up on my suggesti= on of removing it from the AMS entirely)

Brandon
--001a113edb9420db970550ed9c51-- From nobody Thu Jun 1 22:26:51 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB01C127078 for ; Thu, 1 Jun 2017 22:26:49 -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 19JiobgiMclD for ; Thu, 1 Jun 2017 22:26:48 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c: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 313B9126D05 for ; Thu, 1 Jun 2017 22:26:48 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id p85so35209515vkd.3 for ; Thu, 01 Jun 2017 22:26:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iknsYlB5BfAjU0FIaRHnYA99EVhH0XL977eIU7hSsJU=; b=KP6Xo4bkSS85ue841NvE0SGqWYUSUNBosZYeLZZljhLtJOfD1EZKY2c2HM2NvI5M7p IqasdKXiIl6nu4njvjRGGNW2zGuD5dwURqJ0wlRe6MuxCd00Enle4ZEnJDr/Pv03nGvi BbE+SYgmzoIc2gZ08WdVFptZbn6gVaHT+Ql7LgsX5R2tbgfCn1i1Kk5CA4n4W+E34Ii4 R+2mUdUvnXDizNSYtkTYcwwWoC4guzbPa+ulryvr/z82JHI8vb4oVhngQAkyVywEfKE3 uFJWlOGB1VUKmjUmNnKatCKDUumjQwfbznSbwnYJRJi5F9uwxCYB099NANEDN77jlXhD 6Fkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iknsYlB5BfAjU0FIaRHnYA99EVhH0XL977eIU7hSsJU=; b=DGah9qTV5e59lCV+R1dGGDfSzqPd81U1n+YX/uUct5jQVzbhJvAOuqhK5R+TuTYXOH wxaH6PfD8iuL2RqpAQnB0LKUecPACYK45HZARhNWSCLt0g8SQZLK3domVDOzq+GFmfiQ 2s3n6EpOmGMnnFUM9RMnrQJUIwlFux4fJIkGk7lDwpgHjVX4rq5kB6OmeV10BLCO9nbW UwkPXj0cTkBnAAg0q7Ddx6lxHyD5kLS3mLk0zOJXYfcx/Hg+TiZPavT+rDUPh8tN0BdG vb25RfnsQj+haAXc3wNE96tfsIfOSGbL70kYtp0KBpBnbJlTJ2v7u22iDG2i5rRaOEDK 1/6A== X-Gm-Message-State: AODbwcDJkvE5f+f96rnAbIsfA6Az9S00BtNrBG6V8IjVnjHfR/WC0Mof Ng3jrcMeprIPDOeuSfi0SsaKsqFHOQ== X-Received: by 10.31.33.3 with SMTP id h3mr2620577vkh.29.1496381207286; Thu, 01 Jun 2017 22:26:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.25.69 with HTTP; Thu, 1 Jun 2017 22:26:46 -0700 (PDT) In-Reply-To: References: <34808716.2nE2qoVfF5@kitterma-e6430> From: "Murray S. Kucherawy" Date: Thu, 1 Jun 2017 22:26:46 -0700 Message-ID: To: "Kurt Andersen (b)" Cc: Scott Kitterman , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a11c0087e4f19bd0550f36669" Archived-At: Subject: Re: [dmarc-ietf] Authentication-Results stamp for ARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 05:26:49 -0000 --001a11c0087e4f19bd0550f36669 Content-Type: text/plain; charset="UTF-8" On Thu, Jun 1, 2017 at 4:10 AM, Kurt Andersen (b) wrote: > On Thu, Jun 1, 2017 at 12:20 PM, Murray S. Kucherawy > wrote: > >> Another way to look at it: A-R is meant to be a channel to record what >> authentication was done and what thing in the visible message got >> authenticated > > > So, for SPF which does not authenticate *anything* in the original > message, how is A-R relevant at all (by that intention)? > Consensus at the time was that the envelope was included in the definition of "message". Basically it's anything that's reasonably considered payload in RFC5321 or RFC5322. The IP address of the client is never part of SMTP or its payload, unless you count non-standard or optional stuff in Received fields. -MSK --001a11c0087e4f19bd0550f36669 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jun 1, 2017 at 4:10 AM, Kurt Andersen (b) <kboth@d= rkurt.com> wrote:
On Thu, Jun 1, 20= 17 at 12:20 PM, Murray S. Kucherawy <superuser@gmail.com> = wrote:
Another way to look at it: A-R is = meant to be a channel to record what authentication was done and what thing= in the visible message got authenticated

So, = for SPF which does not authenticate *anything* in the original message, how= is A-R relevant at all (by that intention)?
<= br>
Consensus at the time was that the envelope was included in t= he definition of "message".=C2=A0 Basically it's anything tha= t's reasonably considered payload in RFC5321 or RFC5322.=C2=A0 The IP a= ddress of the client is never part of SMTP or its payload, unless you count= non-standard or optional stuff in Received fields.

-MSK =
--001a11c0087e4f19bd0550f36669-- From nobody Thu Jun 1 22:28:06 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAE6F127078 for ; Thu, 1 Jun 2017 22:28:04 -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 CAfUgUKP5cZb for ; Thu, 1 Jun 2017 22:28:03 -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 66258126D05 for ; Thu, 1 Jun 2017 22:28:03 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id p62so115108vkp.0 for ; Thu, 01 Jun 2017 22:28:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vzFjaqdu5oCGy5SGkCiPBD0DSsijI60p8Q8OFZtd3Mc=; b=d6fEFfc1FqF3PUe7cT759zh49Vc6COEctSZsfPxNIz1TDjb7nnjih5rERfupZsHptq GFGsxwihRBD0fhJHjDgtrdG6R49Q8oGEKROkZY+hhbSDgJ2m27bh+Cvml/kFYlua1NQT irCxTZpyf5Sal1Nk4GhSmGV9GCIwezGiiSBRThIwjzCv1okSeQ5W5cACy9DX/YZf0LbC GrDNrCZ2V3CaR3PgccBqiZskck3u3D3RxCex6fMu1JJmmYUy/Q7SUY8V7xMEuzaELVbW /yE+Ccn09hTM27ncHoLNyf5irUNLL5u2t5mTANoCDVEF5cH+S55J/+g8/ac9TN8R75nw D50g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vzFjaqdu5oCGy5SGkCiPBD0DSsijI60p8Q8OFZtd3Mc=; b=oqkdDERhVzJ/4ChLybAuWCn5EBh74pEFzHqdEhB9DGTetvosv4GhLGqpMZ7kZyFvRR Src5Ah0H1Gsi5j/ZI9Mj2fvLOrmjtFwpzlmfOZvelbqtmuDYhgcSR4kXM8v2RbMIGP1l /aTtziej3qhn2LtZjC/dbzq7CEOJXgHdervg+TltXcgeOsz0Lko/nVoV7yo5IwV6z5WG Imd1Pr0b+5CsWodddCmMqH+NQ0s21YHPzauLQx8wqZ5SmhqMpB3c7ajgESed29fIwSOG HLQjHnvTgUcpwOjVu/j3bJ/wWN+y3U0I06N2zqLtvTS6EnsqPnF7igSwHDrE6JmRXzov 9HoQ== X-Gm-Message-State: AODbwcAhhGH6VWGpTUM+f+7fEuwPYeBu8OTNReY+AOEWslVIX7RPkxMf ysEBI39y3V/tJtcBg4m3E6bxcpidQ6t6 X-Received: by 10.31.158.195 with SMTP id h186mr2665217vke.30.1496381282598; Thu, 01 Jun 2017 22:28:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.25.69 with HTTP; Thu, 1 Jun 2017 22:28:01 -0700 (PDT) In-Reply-To: References: From: "Murray S. Kucherawy" Date: Thu, 1 Jun 2017 22:28:01 -0700 Message-ID: To: "Kurt Andersen (b)" Cc: Seth Blank , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a11425dfecc44bd0550f36ad6" Archived-At: Subject: Re: [dmarc-ietf] Clarifying question: AAR coverage by AMS X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 05:28:05 -0000 --001a11425dfecc44bd0550f36ad6 Content-Type: text/plain; charset="UTF-8" On Thu, Jun 1, 2017 at 4:05 AM, Kurt Andersen (b) wrote: > On Thu, Jun 1, 2017 at 12:10 PM, Murray S. Kucherawy > wrote: > >> On Wed, May 31, 2017 at 6:23 PM, Kurt Andersen (b) >> wrote: >> >>> There's another question that had been raised by Seth about whether d= >>> needs to match within an ARC set. The answer is yes, [...] >>> >> >> Why? >> >> -MSK >> > > If an ARC-set is created by a single ADMD, I think it's reasonable for > that ADMD to identify itself in a singular manner, though I suppose we > could have recourse to our favorite "org domain" alignment instead of > strict matching if you think that's better. I think that strict d= matching > is simpler and less likely to be misused/broken. > I wasn't making any sort of claim about "better". I'm just wondering if there's a practical reason to say the two domains MUST or even SHOULD be the same. -MSK --001a11425dfecc44bd0550f36ad6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jun 1, 2017 at 4:05 AM, Kurt Andersen (b) <kboth@d= rkurt.com> wrote:
On Thu, Jun= 1, 2017 at 12:10 PM, Murray S. Kucherawy <superuser@gmail.com> wrote:
On Wed, May= 31, 2017 at 6:23 PM, Kurt Andersen (b) <kboth@drkurt.com> wr= ote:
There's another question that had be= en raised by Seth about whether d=3D needs to match within an ARC set. The = answer is yes, [...]

Why?

-MSK

If an A= RC-set is created by a single ADMD, I think it's reasonable for that AD= MD to identify itself in a singular manner, though I suppose we could have = recourse to our favorite "org domain" alignment instead of strict= matching if you think that's better. I think that strict d=3D matching= is simpler and less likely to be misused/broken.
<= div>
I wasn't making any sort of claim about "better= ".=C2=A0 I'm just wondering if there's a practical reason to s= ay the two domains MUST or even SHOULD be the same.

-MSK =
--001a11425dfecc44bd0550f36ad6-- From nobody Thu Jun 1 22:30:43 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7F0127078 for ; Thu, 1 Jun 2017 22:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yD3xSt5xGwdK for ; Thu, 1 Jun 2017 22:30:39 -0700 (PDT) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67552126D05 for ; Thu, 1 Jun 2017 22:30:39 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id x47so39352465uab.0 for ; Thu, 01 Jun 2017 22:30:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2gJmhbdYfK/QVOuP+n90ZOTakHY22LgCKC/UafpZFnE=; b=rvIgME3oyFVO7di/XyoMh7PUUVH8reRQ0mHEiwCOLDZbmv5oqd0s1V+MksdI+UyU9e 3afhDAGK+mdzJWemeScHF5wmHrwHdmAvGZ7R5WDlqiFc+OO9uLYKDNiYK5uoDpELWwXf 5/KW+iB7DPDFTezryuBEjKnQY6gUzmEdF0dYcNsMVDwsYAdRGWK7ObvWpp/u/1TsiPZn d0Z2Mf9HNbZUfGrTma/M/ZWmgMbDDvTpBMwYJO2Smf4sFam91w3YhccQZup5/nzjQDYf 2rCOizVlIXTUVpwGlBk5ZCDThMxJTXdG5WMdTlCs0KdfZOysWfNnt3qQcbwkQ0T2xjNX ImJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2gJmhbdYfK/QVOuP+n90ZOTakHY22LgCKC/UafpZFnE=; b=g21I3H21crP5RrbEVIdgbplmaar0PBobmoevbnLrwkVyvlu3AyUWSeDo50tAJJUxiL 36LXINMewCJ/7MSuGCKHt3MhCQeiZ0BdkGnadJRUGitvQTuPO+NigAao7+0eHInImEn7 lq9EaxmoWkZ4H2yojQKo5mYuBNPqqmv/tIW4uBmAPtbacuKjmAGQFrQHEv6nfBpfb5Kh JIrUUNA0c51GK7mOjPeyUJLW+82allCiRDcqHa7dwhvSeTyeq6jx+H9P3eIO/WVHv+Cq vkY+uZNeeRgDK4D4YPkSPpz9tFSpYSbF+Ep1oomrpkz7t5mbbMqVxV/tKDQZlh1ox4Sh dxzw== X-Gm-Message-State: AODbwcBBZF1oSfa+BC9ddN+pGHFM31RJUSs5aDtpkA3dskCchaeBRa6x vDHxaibWPWgn/EDvxl6kQe/TkzVQtQ== X-Received: by 10.176.69.65 with SMTP id r59mr2879381uar.80.1496381438584; Thu, 01 Jun 2017 22:30:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.25.69 with HTTP; Thu, 1 Jun 2017 22:30:37 -0700 (PDT) In-Reply-To: References: From: "Murray S. Kucherawy" Date: Thu, 1 Jun 2017 22:30:37 -0700 Message-ID: To: Gene Shuman Cc: "Kurt Andersen (b)" , Seth Blank , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0b9898186bd80550f3745d" Archived-At: Subject: Re: [dmarc-ietf] Clarifying question: AAR coverage by AMS X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 05:30:41 -0000 --94eb2c0b9898186bd80550f3745d Content-Type: text/plain; charset="UTF-8" On Thu, Jun 1, 2017 at 2:43 PM, Gene Shuman wrote: > I don't have particularly strong opinions here. I can see no reason for > the d= to differ, but also no harm in allowing it do so. So I think the > question of what to do here is slightly more philosophical. I think I > generally fall on the side of reducing user flexibility when nothing is > actively gained as opposed to granting user flexibility when there is no > harm. But again, no real strong opinion on the matter. > I'm taking the opposite approach: There might be some utility later to them being different, so why proscribe it just because we don't see anything to gain when the protocol is nascent? I'd rather lock things down later, or lock them down as a local policy matter, than do MUST NOT in the protocol document absent a compelling reason. -MSK --94eb2c0b9898186bd80550f3745d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jun 1, 2017 at 2:43 PM, Gene Shuman <gene@valimai= l.com> wrote:
I don't have = particularly strong opinions here.=C2=A0 I can see no reason for the d=3D t= o differ, but also no harm in allowing it do so.=C2=A0 So I think the quest= ion of what to do here is slightly more philosophical. I think I generally = fall on the side of reducing user flexibility when nothing is actively gain= ed as opposed to granting user flexibility when there is no harm.=C2=A0 But= again, no real strong opinion on the matter.
I'm taking the opposite approach: There might be some util= ity later to them being different, so why proscribe it just because we don&= #39;t see anything to gain when the protocol is nascent?=C2=A0 I'd rath= er lock things down later, or lock them down as a local policy matter, than= do MUST NOT in the protocol document absent a compelling reason.

-MSK
--94eb2c0b9898186bd80550f3745d-- From nobody Fri Jun 2 06:55:36 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EEFB127369 for ; Fri, 2 Jun 2017 06:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.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 HnpkYQVhY6A1 for ; Fri, 2 Jun 2017 06:55:32 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::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 4DA96120721 for ; Fri, 2 Jun 2017 06:55:32 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id y201so60033397qka.0 for ; Fri, 02 Jun 2017 06:55:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ruE54YrZ0Cu2by2wHQMxMcqA42OfAFAA1EjHnfUx/mM=; b=ZzbSizwIoXFOlT96f0RnMrr8MYmtAF3SnDtuFhcGi0g9qR7GA6uPoacllGa1g7nVF6 g5iPYF4T3ys3vqFUTYnScj8wzG1L7Zi1c5Kz5aKJ01VCxkShy7rXWmi8yRX9oB1zAfZR 6rIhRYSA73iTsAFTJEUfzTit9RvzV8gBQqEw6p2zmXTZFUMIXv8m3y5ZXpQydxr1fo7U krus+ul+Pe8NPIgp70EAPqTLoLzmU2HdC+WfHNLsJoUXECl9M6xxcUzeXg/iDXXhys1C hob+vTUaIaDjX3UH2NQDa+yhhYx0okerKItBOlmXyeDzuoH9sE6rbic0uqR0X6NcUopm oUMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ruE54YrZ0Cu2by2wHQMxMcqA42OfAFAA1EjHnfUx/mM=; b=XXFRfyktFN7sa0IrADf+wwZ45BCTKPzBSVNvOq+E/hICrz1a2o9N/lbb5spGQCGUcz ZEX76y2E+QETEc87cgEY2l8EwpLQquywQruoFncYWvqZUvrgQGG4C+Vr3GIrmuZrHxco gwwosIqj04LdsepbURS6T7LdQuJ2n5+Geb5JSMdDLz+DL9j6llIkARuZwnufOrklsV1z fYyFnfGkiJW3ZSyp5MIHqIcsL85q8d+ddVB0X5LnKDdLqQ6quPMrv+ebIHsxFsylfUuR YP8sETA4VZJItWjmKp3x2EgE5ztbytOaXHZKu22jiOcYHRx33nFy5WOHked8I1AKkiR2 LDgg== X-Gm-Message-State: AODbwcDE310827215DL4VzjiYZx+qvvTGRXoolhAkWTaR8NBHPL5hfKU 00uLk1wUALlu4uDm9aJRktEb/TDiDkpb X-Received: by 10.55.4.135 with SMTP id 129mr7723603qke.10.1496411731456; Fri, 02 Jun 2017 06:55:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.42.242 with HTTP; Fri, 2 Jun 2017 06:55:11 -0700 (PDT) In-Reply-To: References: From: Seth Blank Date: Fri, 2 Jun 2017 06:55:11 -0700 Message-ID: To: "Murray S. Kucherawy" Cc: Gene Shuman , "Kurt Andersen (b)" , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a114c6e9eb1170d0550fa813a" Archived-At: Subject: Re: [dmarc-ietf] Clarifying question: AAR coverage by AMS X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 13:55:34 -0000 --001a114c6e9eb1170d0550fa813a Content-Type: text/plain; charset="UTF-8" On Thu, Jun 1, 2017 at 10:30 PM, Murray S. Kucherawy wrote: > > I'm taking the opposite approach: There might be some utility later to > them being different, so why proscribe it just because we don't see > anything to gain when the protocol is nascent? I'd rather lock things down > later, or lock them down as a local policy matter, than do MUST NOT in the > protocol document absent a compelling reason. > I'm on the same page. Furthermore (and I say this mostly ignorant of IETF precedent here), I think it's beneficial for the AS and AMS to remain as close to normal DKIM-Signatures as possible, and additional constrains or variance in acceptable tags/values or semantical constraints across them be kept to a bare minimum. I think everything else really belongs as local policy for a receiver, unless there is specific and clear benefit to the protocol to impose the restriction. I don't think requiring d= to match between AS and AMS clears this bar for the protocol, but it absolutely makes sense for a receiver to factor into delivery decisions. And then, as MSK just said, if a good reason for doing this arises later, it's possible. And if a malicious use arises, then receivers are still in their right to shut those chains down and might already be doing so by default. Seth -- [image: logo for sig file.png] Bringing Trust to Email Seth Blank | Head of Product for Open Source and Protocols seth@valimail.com +1-415-894-2724 <415-894-2724> --001a114c6e9eb1170d0550fa813a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Jun 1, 2017 at 10:30 PM, Murray S. Kucherawy <superuser@gmail.com> wrote:
I'm taking the oppos= ite approach: There might be some utility later to them being different, so= why proscribe it just because we don't see anything to gain when the p= rotocol is nascent?=C2=A0 I'd rather lock things down later, or lock th= em down as a local policy matter, than do MUST NOT in the protocol document= absent a compelling reason.=

I'm on the same= page. Furthermore (and I say this mostly ignorant of IETF precedent here),= I think it's beneficial for the AS and AMS to remain as close to norma= l DKIM-Signatures as possible, and additional constrains or variance in acc= eptable tags/values or semantical constraints across them be kept to a bare= minimum. I think everything else really belongs as local policy for a rece= iver, unless there is specific and clear benefit to the protocol to impose = the restriction.

I don't think requiring d=3D to match between AS and AMS cle= ars this bar for the protocol, but it absolutely makes sense for a receiver= to factor into delivery decisions. And then, as MSK just said, if a good r= eason for doing this arises later, it's possible. And if a malicious us= e arises, then receivers are still in their right to shut those chains down= and might already be doing so by default.
=
Seth
<= div>
--
--001a114c6e9eb1170d0550fa813a-- From nobody Fri Jun 2 08:08:23 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A56D12EBF0 for ; Fri, 2 Jun 2017 08:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7NF28HMuEso for ; Fri, 2 Jun 2017 08:08:11 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::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 69E7012EBF3 for ; Fri, 2 Jun 2017 08:08:11 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id d14so61751510qkb.1 for ; Fri, 02 Jun 2017 08:08:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=HpdcDS9mBUaiVnWGNdpxuF7MfxTk+ueip9RWau10xwI=; b=JAZ7NuAijCODH+ZQPGOoxPESMcQ1pEdIvhphKOfvjqC4J1UcEPslO0yCMYamvQFMnH 2ewaawNF31dwd0dVBT9HixTmMeijsWpcGt47lpcby3BPZdP0W6n/3viFvlFvnbGWpLum i4pKV3zFBPcqhcilC6ViYWBfZF7BoMKV4HvnVmpFyWQXKuSffkUOkTxi3jVWxggGsR/C UnDjvtAjRmpcjXAKusE0RiN4KV2OEUA7zPjpMOH5qw2NWtXj1hzUCWGw9pVHE3ffbHhg K7A27QH225tXZItWb4WSzDDvQ+WNn7/6EhzGPqWK2kQH96kP4lonA6GxEqL0lo1tvk7r DaSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=HpdcDS9mBUaiVnWGNdpxuF7MfxTk+ueip9RWau10xwI=; b=e/ViXbbpZ4SHVlJ/rjvlQhEPFoSB9ajmTLdFECt7quIUdo6nuJte+Kz6Jvxk2M4u18 UrY8dvm2Tr6xEepRzmCc0dtUWp47tD496UPNyPCq8uJAw6TceA0Ry/qPF7cwzspTyLEd 3wuKmGyTEvoFRIDvspTEK89jHuBDYWI6+iIgtAu3GbOTDLSy1JkTtYSppRPeAErpvGjJ Ax1iTton3JosZXQSpNWC7BcL/R4iGPOJdQm8Pdk2UzO3KoJqMxnvXpXt3S/gzmkjAcaA 2kdxtzKtDbRiUROWT+gxrMimeiIndkoa0QUf3Alm4itarVAFJ25QNCa/6qjErZjkkpcz jhBg== X-Gm-Message-State: AODbwcATv+gtnjmssC2DZ19AxmBg48bBFLl79pVblHT3SncfE+ZJHVzG 9fnojUNtk2NHtOfdPLSM7SDnu6lfVw== X-Received: by 10.55.163.88 with SMTP id m85mr8514511qke.118.1496416090338; Fri, 02 Jun 2017 08:08:10 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 10.200.36.20 with HTTP; Fri, 2 Jun 2017 08:08:09 -0700 (PDT) From: Barry Leiba Date: Fri, 2 Jun 2017 11:08:09 -0400 X-Google-Sender-Auth: 8azeQX7hbf1MMlhXUfQCD0lCFZg Message-ID: To: "dmarc@ietf.org" , Seth Blank Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [dmarc-ietf] Valimail and DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 15:08:13 -0000 The valimail.com domain appears to have recently (it looks like it started 1 June) set a restrictive DMARC policy, and that's caused a boatload of disabled subscriptions. Basically, whenever Seth (or any other valimail.com user, but recently that's been Seth) sends a message to the list now, anyone whose domain honours that policy has their copy of the message bounced back and not delivered. After a few of those, mailman disables their subscriptions. Seth, please (1) do not post messages to the list from your valimail.com address until this is resolved, and (2) do what you can to get this resolved. Thanks, Barry, chairing From nobody Fri Jun 2 08:09:53 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE873129BF7 for ; Fri, 2 Jun 2017 08:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ZLXA6l5BHXX for ; Fri, 2 Jun 2017 08:09:49 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::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 55C8A1252BA for ; Fri, 2 Jun 2017 08:09:49 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id u188so4873542qkd.2 for ; Fri, 02 Jun 2017 08:09:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=zZxATinH9nITbqTBYY7Itlhzb+ez5glqRf76KV4Fx1w=; b=uENUXL2mlpbCdRpbCxskcCyNA5/xvPLGIM/Rmv03AegSe0+0HgK+XxvWh633QvALC7 p9+VkzQcVw3GoRcHyN1hDoSoNQ/AtGqrgZjqnoqOoUgOSfx6ZXuqkcZMRDMhwcQCiNLG U2NvjU62q4AJoAg0wpBOXB+ljp8K3+tuJtiQ3vacwYbqmL1qzrtPKMdpQVaCysDFjyt5 rpN8ccxEqLgFM15oRWikD4ls/04b1M2aBRQ1Pd/Fg0BYFPvTVeNP9vZLWv5ZV2LUMHta VXh9w66iGeT7v8Jm1bqYZ10UhCLAncsbvtPqBikRA5eoyZcj7RB4jGK3D+es6vVH9D5q kJSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=zZxATinH9nITbqTBYY7Itlhzb+ez5glqRf76KV4Fx1w=; b=GqYzeFRClcg06yknWlarsp0117rxRTEjoip4Lat985CEi8+7QzkJtNh9F04qfL8Dyy sASputOj7gXV/hwVxCmN8h2S/rEKK0g0k/ryylb1BkGy9F4BKkLK4Ugsw5T7CPDkDuc6 1T492BCTiOjTto+PqV8cA+bgVdZ6vTLGqptTm0/0G80pH6sfRe9jB+pO7lIMDbI4CFUS yuQFTpUKHK/DimHgm6/XkerYoGntjJaHqn8F9kgQy2nFKFYvjrRj6V761JpqMbE8wMZz B06+dVm3HPhwkWHm7d5O063ybba4Lzo+bHs+GHuj7MV7Mrelhg7soqG3+F5m8lqXR6k3 j19Q== X-Gm-Message-State: AODbwcCCn51DHpr1hE3kIq1l2jzwzwrcIpkJqLrSixU4OKxycsM6g2ol 4uAS8hz9obiMvB2iFwvJwJhQEevFSA== X-Received: by 10.55.97.212 with SMTP id v203mr9206658qkb.129.1496416187394; Fri, 02 Jun 2017 08:09:47 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 10.200.36.20 with HTTP; Fri, 2 Jun 2017 08:09:47 -0700 (PDT) In-Reply-To: References: From: Barry Leiba Date: Fri, 2 Jun 2017 11:09:47 -0400 X-Google-Sender-Auth: RRFQAL5-dS6U4RNdIOJZUAjPK0Y Message-ID: To: "dmarc@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [dmarc-ietf] Valimail and DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 15:09:53 -0000 Oh, and I've reset the disabled bits for everyone who was disabled due to bounces. But that doesn't scale, and I don't have the time to keep doing that. Barry On Fri, Jun 2, 2017 at 11:08 AM, Barry Leiba wrote: > The valimail.com domain appears to have recently (it looks like it > started 1 June) set a restrictive DMARC policy, and that's caused a > boatload of disabled subscriptions. Basically, whenever Seth (or any > other valimail.com user, but recently that's been Seth) sends a > message to the list now, anyone whose domain honours that policy has > their copy of the message bounced back and not delivered. After a few > of those, mailman disables their subscriptions. > > Seth, please (1) do not post messages to the list from your > valimail.com address until this is resolved, and (2) do what you can > to get this resolved. > > Thanks, > Barry, chairing From seth@sethblank.com Fri Jun 2 15:03:27 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 984B01293F4 for ; Fri, 2 Jun 2017 15:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id InDL7DJkT7_3 for ; Fri, 2 Jun 2017 15:03:25 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c: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 9E9E5126FDC for ; Fri, 2 Jun 2017 15:03:25 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id p62so11524631vkp.0 for ; Fri, 02 Jun 2017 15:03:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=M6JD79D64t+EgB3p6NDTZOZrxHNee3GOfFjkArYH1Lo=; b=Z66dQdddiJK3tvTyO6GEVZyUQBu14vWUfCrQ0phac09sG3JhiVB0LJR/fMv6FBpLqe jWOT8SY2xNLIYlo7F/ZIo04wo6lStn3ozFyJReva1e4jv+oCd5PM6eeH/6B4DKLvH/EQ v0b7gsTGD/B9wVdfvxtQ1OIMCMaXN/q0hg3jBz6Y5s54zC5OhtGWWYNZcJU3khkMPlNE aksiCDFzmbKcLUS3Ppce1WdRhoe7kqXTO9dOSOaEbOZlT4rD6cPQTXPeHvV05RoYQHl9 bKHw00oMgKzJKxwhs6MVVX9CfTr8gyhCOncvxIJ/NLCwfV7ftTUPP20Dy8DJ4xgusk1E u1SA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=M6JD79D64t+EgB3p6NDTZOZrxHNee3GOfFjkArYH1Lo=; b=Owm5zevPa59zg7p9ul9rdt3ChvdNRCjXcHi6I0Adc7o6hJkblxxffz2o4X+GvlQMJ6 xlOyCvyrSK9Qz++B37jG8h2ce0FjPJR7E/q34h1UxssvtzBfsFCqL9VfoPnRkU/YmVxw vaeO3yuXjHyQRkIVClbzGTOOb+pv2uBs1AfLYIBqDilNTexiAH5OEeC73c13LdwTn55B iMnW9pMJpnEtdxnbecuM4162O9xk538KLghqbfqkRQWcZBLAEFFtlbbpufGf+Q/xVbHK L6iHRFyTVI4wc4MK+Zv2+CsEtJndyJM1zXrySHELqXrSuC0nIm2gF+3Sg30hKUG/Eyn5 J41g== X-Gm-Message-State: AODbwcA0L5zboHshonls2zH+RkyjidqbrAm+TDwFXnn9fPqyBt5pqGaM UIhBFSwLXi0WxTRmPUuEUaB4miRCgP87 X-Received: by 10.31.84.4 with SMTP id i4mr4486843vkb.142.1496441004587; Fri, 02 Jun 2017 15:03:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.74.133 with HTTP; Fri, 2 Jun 2017 15:03:04 -0700 (PDT) From: Seth Blank Date: Fri, 2 Jun 2017 15:03:04 -0700 Message-ID: To: Barry Leiba , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a114e549a81a3a7055101521d" Archived-At: Subject: Re: [dmarc-ietf] Valimail and DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 22:05:53 -0000 --001a114e549a81a3a7055101521d Content-Type: text/plain; charset="UTF-8" Replying from my personal account as requested: On Fri, Jun 2, 2017 at 8:08 AM, Barry Leiba wrote: > The valimail.com domain appears to have recently (it looks like it > started 1 June) set a restrictive DMARC policy, and that's caused a > valimail.com has been at reject for over a year, and was at quarantine for over a year before that. Was anything changed recently with the list? > boatload of disabled subscriptions. Basically, whenever Seth (or any > other valimail.com user, but recently that's been Seth) sends a > message to the list now, anyone whose domain honours that policy has > their copy of the message bounced back and not delivered. After a few > of those, mailman disables their subscriptions. > Seth, please (1) do not post messages to the list from your > valimail.com address until this is resolved, and (2) do what you can > to get this resolved. > (1) Done. (2) valimail.com is at reject and will be staying there, but valimail staff will start using the list from personal addresses (please forgive us briefly for any lapses as we switch over). On a deeper level with respect to (2), this is why the work of this WG in general and of ARC in particular is so critical. The data clearly shows a quickening pace of DMARC adoption, and the expectation should be that there will be more members on this list from domains at p=reject as time progresses. This problem is going to get worse for this list, all IETF lists, and all mailing lists in general. While we can patch it in the interim by sending from personal addresses, ARC is the actual solution here, and I'm looking forward to being able to send from valimail.com to this list again in the near future. Seth > > Thanks, > Barry, chairing --001a114e549a81a3a7055101521d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Replying from my personal account as requested:
=

On Fri, Jun 2, 2017 at 8:08 AM, Barry Leiba=C2=A0<b= arryleiba@computer.org>=C2=A0wrote:
The=C2=A0valimail.com=C2=A0domain appears to h= ave recently (it looks like it
started 1 June) set a restrictive DMARC p= olicy, and that's caused a

valimail.com has been at reject for over a yea= r, and was at quarantine for over a year before that. Was anything changed = recently with the list?
=C2=A0
boatload of disabled subscriptions.=C2=A0 Basically, w= henever Seth (or any
other=C2=A0valimail.com=C2=A0user, but recently that= 's been Seth) sends a
message to the list now, anyone whose domain h= onours that policy has
their copy of the message bounced back and not de= livered.=C2=A0 After a few
of those, mailman disables their subscription= s.

Seth, = please (1) do not post messages to the list from your
valimail.com=C2=A0a= ddress until this is resolved, and (2) do what you can
to get this resol= ved.

(1) Done.

(2) valimail.com is at reject and will= be staying there, but valimail staff will start using the list from person= al addresses (please forgive us briefly for any lapses as we switch over).<= /div>

On a deeper level with respect to (2), this is why= the work of this WG in general and of ARC in particular is so critical. Th= e data clearly shows a quickening pace of DMARC adoption, and the expectati= on should be that there will be more members on this list from domains at p= =3Dreject as time progresses. This problem is going to get worse for this l= ist, all IETF lists, and all mailing lists in general. While we can patch i= t in the interim by sending from personal addresses, ARC is the actual solu= tion here, and I'm looking forward to being able to send from valimail.com to this list again in the near fu= ture.

Seth
=C2=A0

Thanks,
Barry, chairing
--001a114e549a81a3a7055101521d-- From nobody Fri Jun 2 17:08:48 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6B3129AB7 for ; Fri, 2 Jun 2017 17:08: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=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 REOjeVPafLbJ for ; Fri, 2 Jun 2017 17:08:44 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3E02129BFF for ; Fri, 2 Jun 2017 17:08:43 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id l18so109725259oig.2 for ; Fri, 02 Jun 2017 17:08:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=X9sb5U+Wl0U+nvuLQXO9KFMPHIt8uztJbaqNCaNvhSU=; b=Jeyh/7AtqmCOS+FZbPXH/eKoc8LcavvGch8wZBW06CRm8xB1uqmwwDIp/rSgxJBezV LcxrgiTzp+Gx/+ZC5qAEM4KUrEK/EwiKO9NafErGVtBS/ZzosgczwM/SQDKFsAfjoyek 0khbGaUhU4A3ejrm4oVOeStMKZF2v1zz2WvXXfLYojJyOTdRUKL4a0cMOmLRmg3faKtx tDi8YJzj74ufy82rkXkTQ4Q4MM+POdzPc7yXlbFAnN5fStiQP9BErDZFUTvfUPsUrb9o UxuGYeegCSQ5R2LLt2n1PXG9nohxzY04/GInNxVO2hHUuZ/7TF4HEhwo5P7XxoUCScIu wVQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=X9sb5U+Wl0U+nvuLQXO9KFMPHIt8uztJbaqNCaNvhSU=; b=IHABDtdJ10eOOLZeiivpm/u2guJfE33jwgOo8UYQldPUU8aFEUN9zFfR3fzgoVqckO aq/8F3vZt3sUYlsW3ops6NX7pkztWvOjM7W4mkr1MNqYCmyjELGA4Ans1Af5K7l/bq3x NzRZTioCOXGcDjtssOiZZ/rdJCK9KMIUJvIOG1g6YDir5eUYWCQTqXeItWBpIqO0iLu0 7sL62IpvebDez/FxaKw0L9c3OjcjvzYb/pPnBwbgAAir0pq7MuQzMp9Eu48xYZYacmKg UV4v4uKBrsQgc/yLxZjB5PVxwch2CjUUC2iJeJmhN7+izO47b9Ng0SLRqD331VjBrkjc blow== X-Gm-Message-State: AODbwcDhi6d50p+/j0VGMYSzmHs+9nD02jJMbq0m/hjcIIjWPoWaj3hQ xQJmxJY3uQKb7Ly2CXHIz/a1xXerGdZ4 X-Received: by 10.202.102.221 with SMTP id m90mr3896822oik.177.1496448523189; Fri, 02 Jun 2017 17:08:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.8.34 with HTTP; Fri, 2 Jun 2017 17:08:42 -0700 (PDT) In-Reply-To: References: From: Brandon Long Date: Fri, 2 Jun 2017 17:08:42 -0700 Message-ID: To: Seth Blank Cc: Barry Leiba , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a1140fb64a6a5c60551031290" Archived-At: Subject: Re: [dmarc-ietf] Valimail and DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 00:08:46 -0000 --001a1140fb64a6a5c60551031290 Content-Type: text/plain; charset="UTF-8" On Fri, Jun 2, 2017 at 3:03 PM, Seth Blank wrote: > Replying from my personal account as requested: > > On Fri, Jun 2, 2017 at 8:08 AM, Barry Leiba > wrote: > >> The valimail.com domain appears to have recently (it looks like it >> started 1 June) set a restrictive DMARC policy, and that's caused a >> > > valimail.com has been at reject for over a year, and was at quarantine > for over a year before that. Was anything changed recently with the list? > Were the rejects from a specific host... like gmail? We've been making some changes in preparation for supporting arc, and the spam team is always making changes to combat specific campaigns, so it would be good to know if we've made life worse for mailing lists. (and google.com has also been reject for a while, so good to know if my posts are also causing issues) Brandon > boatload of disabled subscriptions. Basically, whenever Seth (or any >> other valimail.com user, but recently that's been Seth) sends a >> message to the list now, anyone whose domain honours that policy has >> their copy of the message bounced back and not delivered. After a few >> of those, mailman disables their subscriptions. > > >> Seth, please (1) do not post messages to the list from your >> valimail.com address until this is resolved, and (2) do what you can >> to get this resolved. >> > > (1) Done. > > (2) valimail.com is at reject and will be staying there, but valimail > staff will start using the list from personal addresses (please forgive us > briefly for any lapses as we switch over). > > On a deeper level with respect to (2), this is why the work of this WG in > general and of ARC in particular is so critical. The data clearly shows a > quickening pace of DMARC adoption, and the expectation should be that there > will be more members on this list from domains at p=reject as time > progresses. This problem is going to get worse for this list, all IETF > lists, and all mailing lists in general. While we can patch it in the > interim by sending from personal addresses, ARC is the actual solution > here, and I'm looking forward to being able to send from valimail.com to > this list again in the near future. > > Seth > > >> >> Thanks, >> Barry, chairing > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --001a1140fb64a6a5c60551031290 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Jun 2, 2017 at 3:03 PM, Seth Blank <seth@sethblank.com>= ; wrote:
Rep= lying from my personal account as requested:
On Fri, Jun 2, 2017 at 8:08 AM, Barry Leiba=C2=A0&= lt;barryleiba@= computer.org>=C2=A0wrote:
The=C2=A0valimail.com=C2=A0domain appears to have rec= ently (it looks like it
started 1 June) set a restrictive DMARC policy, = and that's caused a

valimail.com has been at rej= ect for over a year, and was at quarantine for over a year before that. Was= anything changed recently with the list?

=
Were the rejects from a specific host... like gmail?=C2=A0 We= 9;ve been making some changes in preparation for supporting arc, and the sp= am team is always making
changes to combat specific campaigns, so= it would be good to know if we've made life worse for mailing lists.

(and google.com h= as also been reject for a while, so good to know if my posts are also causi= ng issues)

Brandon
=C2=A0=C2=A0
boatload of disabled subscriptions.=C2= =A0 Basically, whenever Seth (or any
other=C2=A0valimail.com=C2=A0user, b= ut recently that's been Seth) sends a
message to the list now, anyon= e whose domain honours that policy has
their copy of the message bounced= back and not delivered.=C2=A0 After a few
of those, mailman disables th= eir subscriptions.

Seth, please (1) do not post messages to the list from your
valimai= l.com=C2=A0address until this is resolved, and (2) do what you can
t= o get this resolved.

(1) Done.

(2) valimail.com is at reject and will be staying there, but valimail st= aff will start using the list from personal addresses (please forgive us br= iefly for any lapses as we switch over).

On a deep= er level with respect to (2), this is why the work of this WG in general an= d of ARC in particular is so critical. The data clearly shows a quickening = pace of DMARC adoption, and the expectation should be that there will be mo= re members on this list from domains at p=3Dreject as time progresses. This= problem is going to get worse for this list, all IETF lists, and all maili= ng lists in general. While we can patch it in the interim by sending from p= ersonal addresses, ARC is the actual solution here, and I'm looking for= ward to being able to send from valimail.com to this list again in the near future.
Seth
=C2=A0

Thanks,
Barry, chairing

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


--001a1140fb64a6a5c60551031290-- From nobody Sat Jun 3 03:33:06 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE14A127B60 for ; Sat, 3 Jun 2017 03:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.908 X-Spam-Level: X-Spam-Status: No, score=0.908 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=wemonitoremail.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 Uw8u9Oz50Kwy for ; Sat, 3 Jun 2017 03:33:03 -0700 (PDT) Received: from mail.wemonitoremail.com (mail.wemonitoremail.com [78.47.26.204]) (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 7F5F0126BF6 for ; Sat, 3 Jun 2017 03:33:03 -0700 (PDT) X-WeMonitorEmail-From: ken@wemonitoremail.com X-WeMonitorEmail-VirusCheck: Clean Received: from auth (localhost [127.0.0.1]) by mail.wemonitoremail.com (8.14.4/8.14.4/inbound) with ESMTP id v53AWJTp000867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 3 Jun 2017 11:32:21 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemonitoremail.com; s=mail; t=1496485941; bh=T3QTtyP/Fo/eFDNMR0Q+w6MdvF6Y3VClRJlT/kaAVPI=; h=Subject:From:To:Date; b=eXXGSIF4uo6lCOOyTxF7OBvL/SF/Hxt4FeutHosHWmvb+IvvgdLrJfbLcO5wzG5JY 1D6LG8YMNnInkrp8/Vd72EoFdP+s5OZKyU0limj1pEX33FRSJWF8Bq0f//c/0Ec4t/ 7f6xER1oEQoz1icBFnuKFFL75smNsDQploOX4iac= Message-ID: <1496485938.3555.19.camel@wemonitoremail.com> From: "Ken O'Driscoll" To: dmarc@ietf.org Date: Sat, 03 Jun 2017 11:32:18 +0100 In-Reply-To: References: Organization: We Monitor Email Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Valimail and DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 10:33:05 -0000 MailMan has supported DMARC domains for ages through a simple address re- writing mechanism. It works quite well. The version running this list (2.1.22) definitely supports it, it just needs to be enabled.   Unless there is a good reason which prevents it, turning it on is probably a better long-term solution. ARC isn't going to be universally deployed overnight and some personal domains (mine included) are no doubt DMARC protect too. Not to mention, the irony of the official DMARC mailing list discouraging postings from DMARC protected domains due to compatibility issues! Just my two cents, apologies if this was previously discussed by the list. Ken. --  Ken O'Driscoll / We Monitor Email  t: +353 1 254 9400 | w: www.wemonitoremail.com On Fri, 2017-06-02 at 11:08 -0400, Barry Leiba wrote: > The valimail.com domain appears to have recently (it looks like it > started 1 June) set a restrictive DMARC policy, and that's caused a > boatload of disabled subscriptions.  Basically, whenever Seth (or any > other valimail.com user, but recently that's been Seth) sends a > message to the list now, anyone whose domain honours that policy has > their copy of the message bounced back and not delivered.  After a few > of those, mailman disables their subscriptions. > > Seth, please (1) do not post messages to the list from your > valimail.com address until this is resolved, and (2) do what you can > to get this resolved. > > Thanks, > Barry, chairing > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Sat Jun 3 04:14:58 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A15EA128CF0 for ; Sat, 3 Jun 2017 04:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PyBpx07JRMdd for ; Sat, 3 Jun 2017 04:14:54 -0700 (PDT) Received: from miucha.iecc.com (w6.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76525127058 for ; Sat, 3 Jun 2017 04:14:54 -0700 (PDT) Received: (qmail 31040 invoked from network); 3 Jun 2017 11:14:53 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 3 Jun 2017 11:14:53 -0000 Date: 3 Jun 2017 11:14:31 -0000 Message-ID: <20170603111431.3820.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org Cc: ken@wemonitoremail.com In-Reply-To: <1496485938.3555.19.camel@wemonitoremail.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Valimail and DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 11:14:56 -0000 In article <1496485938.3555.19.camel@wemonitoremail.com> you write: >MailMan has supported DMARC domains for ages through a simple address re- >writing mechanism. It works quite well. The version running this list >(2.1.22) definitely supports it, it just needs to be enabled.   The IETF has a long-running discussion about how to deal with DMARC and is looking at some options. Putting the list's address on the From: line is not one of the options. It would be utterly unproductive to reargue this topic here, so please don't. R's, John From nobody Sat Jun 3 07:41:07 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97E5E12E91F for ; Sat, 3 Jun 2017 07:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b6qCC29cYZJM for ; Sat, 3 Jun 2017 07:41:04 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::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 1A87A12E058 for ; Sat, 3 Jun 2017 07:41:04 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id u10so57974587uaf.1 for ; Sat, 03 Jun 2017 07:41:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vz4u5NEdrU+n983xZu0A/QxxD0GDqyiQ6Kre+85WYKc=; b=nWAzeGTY0F7Xf2lLmA98eE+wE8NECt9q4/5ZFoLNb5hhAJBdCfeZjrFunCPhsRjgI1 HI8cgjgm+JNqI1Z3ia9IOfdx6k4/QlfRCWBlPA+8HeHoVmG90FVgH9tmQxvmdAcQKQeu DneDGP8NP3Jlt4Vij1k6KRxkF775qZzqqGgeaFo2Jkg3RlsxmfSuYpacIWs82pVXpDiU 5cR1WpmZ6O4jAa+JmCVZl0xly+3G7hjEFf0KJLJslI3wAEhOWULLq6X/JzjLIOHr44hM iMFWIdKtw1mdY8+fdzYGuu372/aAf5O++RK6CTYEaMKzcdVkz8d57+PwXFBKBqU0YEq2 JGiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vz4u5NEdrU+n983xZu0A/QxxD0GDqyiQ6Kre+85WYKc=; b=YOOhAGvizJeL5PB0FdsE+IzeDn5TktJoX+AKqxwyQcobOU3Fz7u4KsUn8d67TovCbq l4xUoRzMm7Royg5e8BHceiw9HDYLtov5cCdcpFwiLKVnNZHi9zSMWIU/igKpOTgBYr9J VMaQG2Sx09rfFD3johEACrvwBxiky6bI9mz3RjrTxUft9GH3oICLnBWiMqQltr/LWTAk tbHTnUJH/zNdBMhQvVIp9pUQ580ANTh+trBhw9LNiC+BYKmWptmAgkd++nKn3C0bt8ol m06XVtptrzQQfkNIVgrm66jepL1QV4jlOzoNvFufz7WBx/XpeuMn8hb2OOu3RI5yjY1Y Wa6Q== X-Gm-Message-State: AODbwcDtYi5HEkYTD+56+dRU9lChc2jDY4pjbNUX/34UMcg1Es/VOLr1 FMHfTkgffJQZb9zJGx0+nVv5p4Gp04B3cM0= X-Received: by 10.176.81.4 with SMTP id e4mr6797359uaa.33.1496500863203; Sat, 03 Jun 2017 07:41:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.25.69 with HTTP; Sat, 3 Jun 2017 07:41:02 -0700 (PDT) In-Reply-To: <1496485938.3555.19.camel@wemonitoremail.com> References: <1496485938.3555.19.camel@wemonitoremail.com> From: "Murray S. Kucherawy" Date: Sat, 3 Jun 2017 07:41:02 -0700 Message-ID: To: "Ken O'Driscoll" Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c1914905b7e9c05510f42c4" Archived-At: Subject: Re: [dmarc-ietf] Valimail and DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 14:41:06 -0000 --94eb2c1914905b7e9c05510f42c4 Content-Type: text/plain; charset="UTF-8" On Sat, Jun 3, 2017 at 3:32 AM, Ken O'Driscoll wrote: > Not to mention, the irony of the official DMARC mailing list discouraging > postings from DMARC protected domains due to compatibility issues! > Not long ago there was some advice circulated that DMARC is really only for protecting domains that don't contain users, or at least no users that participate in lists. Section 10.5 of RFC7489 hints at this. I think it's fair to say that its activation by operators of domains that do have people participating in lists was somewhat destructive. I would also say a good chunk of the IETF looks at the existence of this working group as the necessary result of the damage DMARC caused in the first place. If you look at it that way, there's no irony here at all. -MSK --94eb2c1914905b7e9c05510f42c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Jun 3, 2017 at 3:32 AM, Ken O'Driscoll <= ken@wemonitoremail.com> wrote:
=
Date: Tue, 6 Jun 2017 10:25:52 -0700 X-Google-Sender-Auth: Y6BlXblxOPiI0cs8pPxc3T8o7bI Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a113d167861734805514de92e" Archived-At: Subject: [dmarc-ietf] Next version of the draft was delayed due to TSA X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 17:26:07 -0000 --001a113d167861734805514de92e Content-Type: text/plain; charset="UTF-8" The TSA policies that took my laptop away from me when returning via Dubai derailed my plans to get the next draft of the I-D completed. I'm planning to work on it in transit to M3AAWG so that I can post an update on Friday after reaching Lisbon. --Kurt --001a113d167861734805514de92e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The TSA policies that took my laptop away from me when ret= urning via Dubai derailed my plans to get the next draft of the I-D complet= ed. I'm planning to work on it in transit to M3AAWG so that I can post = an update on Friday after reaching Lisbon.

--Kurt
<= /div> --001a113d167861734805514de92e-- From nobody Tue Jun 6 18:17:04 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39786129487 for ; Tue, 6 Jun 2017 18:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-XHfq_tlIfU for ; Tue, 6 Jun 2017 18:17:01 -0700 (PDT) Received: from mail-ot0-x22a.google.com (mail-ot0-x22a.google.com [IPv6:2607:f8b0:4003:c0f::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 93D80120725 for ; Tue, 6 Jun 2017 18:17:01 -0700 (PDT) Received: by mail-ot0-x22a.google.com with SMTP id i31so24976448ota.3 for ; Tue, 06 Jun 2017 18:17:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=MwupWgIDuJqvTVvQT4ejzsAOoBldoyX+vMJiFDWaUeE=; b=TzM5ygtbGJn7FbDm8cBzuB2fnfR+nPC2Ywg1EMkYGvXQhgDeqCi1Nv1qR1NgrefD2t KLkjYpy4HAVzzjGhfX7cqB8nyQ7swYdNaT0792jtyrmeDkABA6Ai+DRtXvDhiiUT+fvg yKLt0eiJPYMAgIIQINCf6cA0GOvoYILK7itqgPFFadhrCufNALpiEUAW3mbV+6pYmjfZ BdYTReFqTu2vZKSIQt1eb+uLfXE1jCKB+B8clbtm2eXoxP9TUpOOrvMaJbDU/HNYn3jy hTfpo6HzoUkHjuDhc3GbRiuVrenxrJgIXHaAqFfw7747kVLb5+jAHZSCXZQmg8L4N1uZ KvNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=MwupWgIDuJqvTVvQT4ejzsAOoBldoyX+vMJiFDWaUeE=; b=lZorbEPP9qnrwelcYbj9Dgim4VsOeJ+Rvhedj3T4RbuZjW1HxbMtImcODVRtlIOcfR +iE+kM+s/z9JEZ/SHfPpIXJe5nI1UoRJk8kfl///0OR3yVioRwnzyPW0hSzFe0oPoI74 a+v5jgsab94B5rpfZLJvhpgG8H1q7qcMgy8WA2K38ZE+mnzm88RduV6niJL9vTuzlUPO aNQ0atIPYtFkKbOZa8FKHo/xCIY2woR9AiIP7OZjzrU3xN61K+xkBu4zuO2yEdhwrLxv f9MBYQz/cOqO9dFSrLv7yuD9IBXinOc5ghU11jEWxgAMgotA86vEyAShs9gKQulKskUN Xc9g== X-Gm-Message-State: AODbwcCHLZEtGU4gmLMvALP1Mej2YyAKMCZVIEZWfwkO3wIQSt4R8OHo h7tNlITgOcYI/3OcXqQ= X-Received: by 10.157.37.5 with SMTP id k5mr16881061otb.189.1496798220650; Tue, 06 Jun 2017 18:17:00 -0700 (PDT) Received: from ?IPv6:2602:304:cda0:8800:d17e:7fe3:9cb7:7c98? ([2602:304:cda0:8800:d17e:7fe3:9cb7:7c98]) by smtp.gmail.com with ESMTPSA id b72sm93780oii.20.2017.06.06.18.16.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Jun 2017 18:16:59 -0700 (PDT) To: "Kurt Andersen (b)" , "dmarc@ietf.org" References: From: Dave Crocker Message-ID: <6a1c679b-d5e0-2e4d-fe5f-b3a4c9db4e4c@gmail.com> Date: Tue, 6 Jun 2017 18:16:50 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Next version of the draft was delayed due to TSA X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 01:17:03 -0000 On 6/6/2017 10:25 AM, Kurt Andersen (b) wrote: > The TSA policies that took my laptop away from me when returning via > Dubai derailed my plans to get the next draft of the I-D completed. I'm > planning to work on it in transit to M3AAWG so that I can post an update > on Friday after reaching Lisbon. In the early days of computing, one of the marks of a really expert programmer was being able to squeeze the most program into the smallest amount of memory. Today it's about being able to edit documents on the smallest device. It's difficult to think of this as an advance. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Jun 7 11:33:27 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A070126C2F for ; Wed, 7 Jun 2017 11:33:25 -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, 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 AHsF3ERkSLKD for ; Wed, 7 Jun 2017 11:33:23 -0700 (PDT) Received: from miucha.iecc.com (w6.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDD6D129B15 for ; Wed, 7 Jun 2017 11:33:00 -0700 (PDT) Received: (qmail 16607 invoked from network); 7 Jun 2017 18:32:59 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 7 Jun 2017 18:32:59 -0000 Date: 7 Jun 2017 18:32:37 -0000 Message-ID: <20170607183237.1444.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org Cc: dcrocker@gmail.com In-Reply-To: <6a1c679b-d5e0-2e4d-fe5f-b3a4c9db4e4c@gmail.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Next version of the draft was delayed due to TSA X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 18:33:25 -0000 In article <6a1c679b-d5e0-2e4d-fe5f-b3a4c9db4e4c@gmail.com> you write: >Today it's about being able to edit documents on the smallest device. Naah, it's routing around damage, except that now it's flight routing rather than packet routing. I live in the US but I usually fly out of Toronto which is seeming more and more like a good idea. R's, John From nobody Sat Jun 17 04:23:22 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10BFF126CF6 for ; Sat, 17 Jun 2017 04:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 VMF0NNq3FYxM for ; Sat, 17 Jun 2017 04:23:19 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::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 352B9120046 for ; Sat, 17 Jun 2017 04:23:19 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id b205so24492425itg.1 for ; Sat, 17 Jun 2017 04:23:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eudaemon.net; s=dkey; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=EIa4KWRozdy/Zv6BuuHcvip6kTQqrkblKhw4VGs99HI=; b=VsG1gonXnE6aJ55jCG0ZT5l/sJMOE4IeBHpwWkyxTPLzFDp+yr0P3kNIpVF4FYCVsX QqfsAS0lq4BW4VhJ3WITFM4m6vO1VgOM+1TA/YaUZr3prCgj6Psterc5fv5Z+We47xLB O8eXl+25uHh7+8M2R8RGLtXWBPljyKKrSXFjE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=EIa4KWRozdy/Zv6BuuHcvip6kTQqrkblKhw4VGs99HI=; b=MvheL+M4wZOhTxMwRyH3ICLkp+OuTtafyQ8THsMcvyFa/FSSav6ielHuDo5oFQI0pR QiKR61UhM1WyUPWuU+1Oaoyy+9EbDfO5ikYuE5jyrABh8PtouS+pPGF+C6Oxg6wiYi0y /ysDHWtlJKwT37XdthPnS3CaWt9Eb7Lix8yb+swvJjtaHIK1nFFyxA+PbL9RAgR9VsLX THQN9egKHAzhHrPxRD8XR1SrKrh6ZGpCaHS6DnFeWIfaY9/UEbE7yzA7jyUWvWryJhvX MT6o8FzvWJsw6w3cY5H9mYF7blcJKutwiDCAx4hqfCiu0cTIKzjJ72iO3JOOzIum4Cyi jxcw== X-Gm-Message-State: AKS2vOzWRhFyLb/1Jbbjg4jmVlmGOrQ4bzoU4l7GkOymNIG6wT6CemUO vOHgiwvTPR2Onv8o X-Received: by 10.36.4.4 with SMTP id 4mr7382832itb.73.1497698598404; Sat, 17 Jun 2017 04:23:18 -0700 (PDT) Received: from ?IPv6:2607:fb90:a24f:c87e:c48b:ad40:71cd:7d12? ([2607:fb90:a24f:c87e:c48b:ad40:71cd:7d12]) by smtp.gmail.com with ESMTPSA id z68sm905396itb.0.2017.06.17.04.23.17 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 17 Jun 2017 04:23:17 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_EE3D2BE6-ABE1-4CD6-999C-6B046AD54E4A" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Tim Draegen In-Reply-To: Date: Sat, 17 Jun 2017 07:23:15 -0400 Cc: "Murray S. Kucherawy" , Barry Leiba , "Kurt Andersen (b)" , "dmarc@ietf.org" Message-Id: References: To: Alexey Melnikov X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [dmarc-ietf] Proposal: Writing a DMARC usage guide is not a good task for this WG X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 11:23:21 -0000 --Apple-Mail=_EE3D2BE6-ABE1-4CD6-999C-6B046AD54E4A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jun 1, 2017, at 5:52 AM, Alexey Melnikov = wrote: >=20 > Is there an expired or not yet posted draft on DMARC usage? I think = looking at any written text will help inform the decision. I brainstormed a bit while at M3AAWG with a few people about the DMARC = Usage Guide. Then I got the opportunity to convert notes into a draft = while pulling an all nighter in Chicago O'Hare. I'll post a draft and then start a new thread with the details. --Apple-Mail=_EE3D2BE6-ABE1-4CD6-999C-6B046AD54E4A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On = Jun 1, 2017, at 5:52 AM, Alexey Melnikov <aamelnikov@fastmail.fm> wrote:

Is there an expired or not yet posted draft on = DMARC usage? I think looking at any written text will help inform the = decision.

I brainstormed a bit while at M3AAWG with a = few people about the DMARC Usage Guide. Then I got the opportunity to = convert notes into a draft while pulling an all nighter in Chicago = O'Hare.

I'll = post a draft and then start a new thread with the details.

= --Apple-Mail=_EE3D2BE6-ABE1-4CD6-999C-6B046AD54E4A-- From nobody Sat Jun 17 04:54:02 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 310D01292FC for ; Sat, 17 Jun 2017 04:54: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 7zuDYDBpNXAe for ; Sat, 17 Jun 2017 04:53:58 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF0DA126BF0 for ; Sat, 17 Jun 2017 04:53:58 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id y77so43037632ioe.3 for ; Sat, 17 Jun 2017 04:53:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eudaemon.net; s=dkey; h=from:subject:date:references:to:message-id:mime-version; bh=BDYhLzcvgEEuS0rr6A2YGcXBkF1s8IzGPgCl++WgAVM=; b=WMcz9nOxqm2JLDTL4Parx4pfThEEomECXuOZIG6Q18979Hga0Yc3mmwSLJIPxQeJdw w8NZwip4GfklOQ9SKLP4RUyZ4IPR4dwwzPCrW43+ijoFbSTKvT6e+45278BgfX7ZmJs1 5yvUsTyov2zl5Yxysyf3LWJ+jE6nb4HF0L3B4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:date:references:to:message-id :mime-version; bh=BDYhLzcvgEEuS0rr6A2YGcXBkF1s8IzGPgCl++WgAVM=; b=nKZ/l8s8MK/vrj3NSVAcowOvNpSwsYhif3Uuh4sbcDaSbgV0IgDlgNAjYGITqDEkG/ xco6IJn0zR/E+4vr/9tzhm4nBvDDlqQyNv8RxxQzbHJRPJZf2xuU1jPM7jpGGM7XqFHS oTTQgnAWtnZTlhASExJB9P0YmyO74bW7euP0JbtJwDmAjlU/AgMh5IEMQ8A3pucE1it4 hGlt9GrbIaZcHwt5mCtXfrJZqs/gB2e+/fq00NjjmYjbp7eHzSvNaIYZbeAnpcq/aSqJ bWPeJv5LYj96htkH7zdUUnmffNaOUwYzNVP0qPdwc8bIMigJG7HzM4pR+7VTnRhNnPMp ctCA== X-Gm-Message-State: AKS2vOxgqtoqe5O4cjjvESab2OUbhOSScfZLKQEnp6oOGNyPSf8djYFp jGZk8wbXZjRMSLM0GYBzgQ== X-Received: by 10.107.128.84 with SMTP id b81mr13695929iod.26.1497700437750; Sat, 17 Jun 2017 04:53:57 -0700 (PDT) Received: from ?IPv6:2607:fb90:a24f:c87e:c48b:ad40:71cd:7d12? ([2607:fb90:a24f:c87e:c48b:ad40:71cd:7d12]) by smtp.gmail.com with ESMTPSA id m129sm2854425iom.27.2017.06.17.04.53.57 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 17 Jun 2017 04:53:57 -0700 (PDT) From: Tim Draegen Content-Type: multipart/alternative; boundary="Apple-Mail=_A162DC60-C06E-4771-B81E-C413E462E3C7" Date: Sat, 17 Jun 2017 07:53:56 -0400 References: <149769914616.14196.7281583245238152220.idtracker@ietfa.amsl.com> To: dmarc Message-Id: Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [dmarc-ietf] Fwd: New Version Notification for draft-tdraegen-dmarc-usage-guide-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 11:54:01 -0000 --Apple-Mail=_A162DC60-C06E-4771-B81E-C413E462E3C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii TOP POST because this is a notification. It's my understanding that people want to share their DMARC operational = experience. However, it appears that people in operational roles simply = do not have the time to participate directly in the lightly structured = IETF context.=20 To see if there is any way to get experience shared despite the gap, = I'll be using this draft and interviewing people with operational = experience to at least get their insight posted to the list. As you can see, the draft is organized into 3 audiences: domain owners, = senders, and receivers. I'll try to get at least a few from each = audience. I've got some volunteers already, and will push each one to = the list as they happen. This is the best I can do to determine if there is momentum to be had. I = hope that by the next in person meeting, we can at least discuss is = there is a "there there". If there isn't, it won't be for lack of = trying. > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-tdraegen-dmarc-usage-guide-00.txt > Date: June 17, 2017 at 7:32:26 AM EDT > To: "Tim Draegen" >=20 >=20 > A new version of I-D, draft-tdraegen-dmarc-usage-guide-00.txt > has been successfully submitted by Tim Draegen and posted to the > IETF repository. >=20 > Name: draft-tdraegen-dmarc-usage-guide > Revision: 00 > Title: DMARC Interoperability Usage Guide > Document date: 2017-06-17 > Group: Individual Submission > Pages: 8 > URL: = https://www.ietf.org/internet-drafts/draft-tdraegen-dmarc-usage-guide-00.t= xt > Status: = https://datatracker.ietf.org/doc/draft-tdraegen-dmarc-usage-guide/ > Htmlized: = https://tools.ietf.org/html/draft-tdraegen-dmarc-usage-guide-00 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-tdraegen-dmarc-usage-guide-00 >=20 >=20 > Abstract: > Domain-based Message Authentication, Reporting, and Conformance > (DMARC) allows for the expression of domain-level policies and > preferences for message validation, disposition, and reporting > between mail-originating and mail-receiving organizations. This > usage guide presents strategies for successful interoperation of > historically disparate mail systems in the presence of domain-level > policies. >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat >=20 --Apple-Mail=_A162DC60-C06E-4771-B81E-C413E462E3C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii TOP POST because this is a notification.

It's my understanding that people want = to share their DMARC operational experience. However, it appears that = people in operational roles simply do not have the time to participate = directly in the lightly structured IETF context. 

To see if there is any = way to get experience shared despite the gap, I'll be using this draft = and interviewing people with operational experience to at least get = their insight posted to the list.

As you can see, the draft is organized = into 3 audiences: domain owners, senders, and receivers. I'll try to get = at least a few from each audience. I've got some volunteers already, and = will push each one to the list as they happen.

This is the best I can do to determine = if there is momentum to be had. I hope that by the next in person = meeting, we can at least discuss is there is a "there there". If there = isn't, it won't be for lack of trying.




Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-tdraegen-dmarc-usage-guide-00.txt
Date: = June 17, 2017 at 7:32:26 AM = EDT
To: = "Tim Draegen" <tim@eudaemon.net>

A new version of I-D, = draft-tdraegen-dmarc-usage-guide-00.txt
has been = successfully submitted by Tim Draegen and posted to the
IETF= repository.

Name: = draft-tdraegen-dmarc-usage-guide
Revision: 00
Title:= = DMARC Interoperability Usage Guide
Document = date: = 2017-06-17
Group: Individual Submission
Pages:= = 8
URL: =            https://www.ietf.org/internet-drafts/draft-tdraegen-dmarc-usage= -guide-00.txt
Status: =         https://datatracker.ietf.org/doc/draft-tdraegen-dmarc-usage-gui= de/
Htmlized:       https://tools.ietf.org/html/draft-tdraegen-dmarc-usage-guide-00=
Htmlized:       https://datatracker.ietf.org/doc/html/draft-tdraegen-dmarc-usag= e-guide-00


Abstract:
  Domain-based Message Authentication, Reporting, = and Conformance
  (DMARC) allows for the = expression of domain-level policies and
=   preferences for message validation, disposition, and = reporting
  between mail-originating and = mail-receiving organizations.  This
=   usage guide presents strategies for successful = interoperation of
  historically disparate mail = systems in the presence of domain-level
=   policies.




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

The IETF = Secretariat


= --Apple-Mail=_A162DC60-C06E-4771-B81E-C413E462E3C7-- From geneshuman@gmail.com Mon Jun 19 15:52:02 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD53129566 for ; Mon, 19 Jun 2017 15:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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=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 u0JQDU1PXjvo for ; Mon, 19 Jun 2017 15:51:58 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 975B61293FD for ; Mon, 19 Jun 2017 15:51:58 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id y77so73432286ioe.3 for ; Mon, 19 Jun 2017 15:51:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=4kmlpWeczSwIsgApToV65FDGJmyX4+H9EtRW+tveVUE=; b=Oe6l+G2xYxqmnL5m6SMwptDa74xJuNI2MPe/ytd9GmU6w5p1QhcHK7hGkqlXMaAATB gRtYg5ZTDsGFZgOP0Hum1SShcV99U1ezvWQy8rtwwxLi1RTKwqHtfhQIAZMu7jWA7j/x DBjxT+5TaxH+vbseSMNXzgFJlwayHg0zXfLzZIC/bTSOcl188tjG1cAbrbaSLNTiTnao V+wQ8tGFHoMCVMbbEevcDKO6xuxUNBX9lKwbokYrqBSlRe+VUmkuTfWMcv1/cGLbKXrs DOF6bBa0tJEdG6QRacDg27WBeak7WngOyohADQSvSDcmOaY71Wp49HpLQgCraLJIHtdr 2jBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=4kmlpWeczSwIsgApToV65FDGJmyX4+H9EtRW+tveVUE=; b=fclwwCt+Y7qE8bUt2XONFmDZYZSXdiup71Mg/p1bVli0ufNuVW/e0Xxc90189Aqhad M03TP2fD7H3Wo6NV2kjytXAQ2yO5JBPvTqwaYIrJEwxfhAniEE4kBkQfkgfDwOR6m6WU QPEJLXtcyLMxvvzgEi6h7lCnclU+64xHtpfXRUqrtHafSPTiQgyJ1R1O3t9SgSQzub/n OzVOwGGitaKduFLf5i6ZcEfZ3xlPzJxwxyVkWGCV1UPxRNjNTXAGMH/ALZfqlHU+f9UM thXgZ4tHGoYAksGfblcTHmGZL30dB9ZLRfIw1vhkVKiQtWDm+IMoEEULpkhva0KPTreF fmEA== X-Gm-Message-State: AKS2vOwlKqxtkzkHRC3tWXsH21r58HLfVDsy/W65AIBZtG9/L0/DWuPK 5EPdq0/WyqiZNAqO+IZVAOmhtxxqvw== X-Received: by 10.107.17.21 with SMTP id z21mr23156654ioi.34.1497912717707; Mon, 19 Jun 2017 15:51:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.0.209 with HTTP; Mon, 19 Jun 2017 15:51:57 -0700 (PDT) From: Gene Shuman Date: Mon, 19 Jun 2017 15:51:57 -0700 Message-ID: To: dmarc@ietf.org Content-Type: multipart/alternative; boundary="001a113ed096719660055257fb97" Archived-At: Subject: [dmarc-ietf] ARC cv=invalid X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 22:52:39 -0000 --001a113ed096719660055257fb97 Content-Type: text/plain; charset="UTF-8" Starting a new thread, as this is probably *the* major blocker wrt OpenARC. The last thread basicaly was questioining the need for the cv=invalid status entirely. The major question being, with an invalid/mangled chain, how are we supossed to compute a b= value for the ARC-Seal? If we do in fact maintain the cv=invalid state, we can create a local AMS, but we can no longer enforce a mandatory b= in the AS. The other alternative is just to stamp arc=invalid in the the AR & be done with it. It is very much important to figure this out. In the former case we would need to say that AS b= is undefined when cv=invalid, which wouldn't be that big of a deal afaik. In the later case, we could simply abort processing of messages, and put the status in AR. It's unclear to me which is preferable. Another question, which is related, but independent to the former, is what *precisely* constitutes an invalid chain vs a failing one. I had previously been working on the assumption that invalid was a property strictly relate to the i= tag & the chain itself. ie. duplicate i= tags, missing i= tags, missing AMS, AS, AAR headers, etc. But there are a large class of errors that I had previously been considering failures which could possibly be considered invalid results. For instance, the s= tag is strictly required. When verifying an inbound message with a missing s= tag, is cv=fail, or invalid? dkimpy & the test suite(and google's arc implementation?) all consider this a fail, while OpenARC currently considers this to be invalid. What is correct here? I suggest failure, this way we can limit invalid *strictly* to mangled sets/i= tags etc. Basically circumstances in which it is strictly impossible to generate an AS b= value consistiently. =Gene --001a113ed096719660055257fb97 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Starting a new thread, as this is probably *the* major blo= cker wrt OpenARC. The last thread basicaly was questioining the need for th= e cv=3Dinvalid status entirely.=C2=A0 The major question being, with an inv= alid/mangled chain, how are we supossed to compute a b=3D value for the ARC= -Seal?=C2=A0 If we do in fact maintain the cv=3Dinvalid state, we can creat= e a local AMS, but we can no longer enforce a mandatory b=3D in the AS.=C2= =A0 The other alternative is just to stamp arc=3Dinvalid in the the AR &= ; be done with it.=C2=A0 It is very much important to figure this out.=C2= =A0 In the former case we would need to say that AS b=3D is undefined when = cv=3Dinvalid, which wouldn't be that big of a deal afaik.=C2=A0 In the = later case, we could simply abort processing of messages, and put the statu= s in AR.=C2=A0 It's unclear to me which is preferable. =C2=A0 =C2=A0
Another question, which is related, but independent to the= former, is what *precisely* constitutes an invalid chain vs a failing one.= =C2=A0 I had previously been working on the assumption that invalid was a p= roperty strictly relate to the i=3D tag & the chain itself. =C2=A0ie. d= uplicate i=3D tags, missing i=3D tags, missing AMS, AS, AAR headers, etc.= =C2=A0 But there are a large class of errors that I had previously been con= sidering failures which could possibly be considered invalid results.=C2=A0= For instance, the s=3D tag is strictly required.=C2=A0 When verifying an i= nbound message with a missing s=3D tag, is cv=3Dfail, or invalid? =C2=A0dki= mpy & the test suite(and google's arc implementation?) all consider= this a fail, while OpenARC currently considers this to be invalid.=C2=A0 W= hat is correct here?=C2=A0 I suggest failure, this way we can limit invalid= *strictly* to mangled sets/i=3D tags etc.=C2=A0 Basically circumstances in= which it is strictly impossible to generate an AS b=3D value consistiently= . =C2=A0

=3DGene


=
--001a113ed096719660055257fb97-- From nobody Tue Jun 20 11:35:28 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E82D129445 for ; Tue, 20 Jun 2017 11:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pt1hXVVVZZ1B for ; Tue, 20 Jun 2017 11:35:24 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC2211315D8 for ; Tue, 20 Jun 2017 11:35:19 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id g40so90534395uaa.3 for ; Tue, 20 Jun 2017 11:35:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=/wKnNl71j990JCgcc7tFnNw4J5XsY3cvOhi5VmRbDGI=; b=GQQ4YsyUAc4rskAVb2tKVJ6PRq9axb7yKJVrPqamXakgG45yMRaJGMKHdjWXB7wDeU ywAajvX/Q8nxUk23gQyM3Kcju7+Qdzu4dVa96CSDOrcI3fdK1GpjCUfoDvHMenlR7Mo5 bIaSNiW2Qh14L1shB2xU3E+d8BWuG6dMNMqFU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=/wKnNl71j990JCgcc7tFnNw4J5XsY3cvOhi5VmRbDGI=; b=ZFqmtO/0XsY2az7oEVW2bpyqMAuSMSatMf7NsV2AyZdL4csgLOD3wlkDb9qqr+g/ul Q2Ob0hbhLtV6I3IVyz/1t4AyF9/b+5FDiYJyK/lD6OvQYNIO2g7Ytof9n5gK9x+j7Qfy PF84wEdxO0/hPBbFfoIu5sWSvHUrSBSODX/ZK3xU5ihIzgkHOe8oofoPvF2zh1gw18FZ onLuS5h8C+XrzsiD6NzOcb1tXQgBuHseNN30XQJtGFa+P1HqxHZQ3URJDaELIg4BpcxE Cbhmrqe87g/hsAGVsmfub/lUz9bttK8SR932lMBaEBeHi4nxA0GZ3fVtgxpH6hJMVCNw HJkw== X-Gm-Message-State: AKS2vOyRYsWc0aHc4dw3IKifA/QzNui/y7JOzE0JjGb9UJPLCXZbCYa+ s6iqAKYpZXI6JfNRISq/b18HkNcD3QXTYt4OPw== X-Received: by 10.176.2.203 with SMTP id 69mr12740436uah.36.1497983718695; Tue, 20 Jun 2017 11:35:18 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.176.75.153 with HTTP; Tue, 20 Jun 2017 11:35:18 -0700 (PDT) In-Reply-To: References: From: "Kurt Andersen (b)" Date: Tue, 20 Jun 2017 11:35:18 -0700 X-Google-Sender-Auth: cbeXal2zqD_O6071uy5TWKg6Vvw Message-ID: To: Gene Shuman Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a113db8be6f5a3d0552688392" Archived-At: Subject: Re: [dmarc-ietf] ARC cv=invalid X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 18:35:27 -0000 --001a113db8be6f5a3d0552688392 Content-Type: text/plain; charset="UTF-8" On Mon, Jun 19, 2017 at 3:51 PM, Gene Shuman wrote: > Starting a new thread, as this is probably *the* major blocker wrt > OpenARC. . . > Taking your two questions in reversed order: . . .what *precisely* constitutes an invalid chain vs a failing one? I had > previously been working on the assumption that invalid was a property > strictly relate to the i= tag & the chain itself. ie. duplicate i= tags, > missing i= tags, missing AMS, AS, AAR headers, etc. This is what we intended when writing the spec and with some of the initial implementations. "invalid" is a description of a chain which does not have all of the right pieces ("structural integrity" is the term used in 5.1.1.5). "fail" is what happens when something else is broken (can't or doesn't validate - no "s" tag for instance). > with an invalid/mangled chain, how are we suposed to compute a b= value > for the ARC-Seal? > Thinking back to the conversations when the spec was being initially developed, I don't know that we touched on this specific scenario, but I think that the most consistent approach with the rest of the spec would be to have the spec call out a specific "implicit h=" handling for this situation. I'd suggest the following approach for creating an ARC set in an invalid situation: set i = one more than the highest i value found in the (mangled) ARC fragments or 51 (based on the "Maximum 'i' Tag Value). Use only the ARC headers for this set in the implicit 'h' since those will be entirely under the control of the signing system. For the AMS, nothing special should be required. How does that sound? --Kurt --001a113db8be6f5a3d0552688392 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Jun 19, 2017 at 3:51 PM, Gene Shuman=C2=A0<geneshuman@gmail.com= >=C2=A0wrote:
Starting a new thread, as this is probably *the* major b= locker wrt OpenARC. . .
=C2=A0
Taking your two questions in reversed order:

. . .what *precisely* constitutes an invalid chain vs a failing one?=C2= =A0 I had previously been working on the assumption that invalid was a prop= erty strictly relate to the i=3D tag & the chain itself. =C2=A0ie. dupl= icate i=3D tags, missing i=3D tags, missing AMS, AS, AAR headers, etc.=C2= =A0

This is what we intended when writing t= he spec and with some of the initial implementations. "invalid" i= s a description of a chain which does not have all of the right pieces (&qu= ot;structural integrity" is the term used in 5.1.1.5). "fail"= ; is what happens when something else is broken (can't or doesn't v= alidate - no "s" tag for instance).=C2=A0
=C2=A0
<= div class=3D"gmail_quote">
with an invalid/mangled chain, how are we suposed to comp= ute a b=3D value for the ARC-Seal?

T= hinking back to the conversations when the spec was being initially develop= ed, I don't know that we touched on this specific scenario, but I think= that the most consistent approach with the rest of the spec would be to ha= ve the spec call out a specific "implicit h=3D" handling for this= situation. I'd suggest the following approach for creating an ARC set = in an invalid situation: set i =3D one more than the highest i value found = in the (mangled) ARC fragments or 51 (based on the "Maximum 'i'= ; Tag Value). Use only the ARC headers for this set in the implicit 'h&= #39; since those will be entirely under the control of the signing system. = For the AMS, nothing special should be required.

H= ow does that sound?

--Kurt
--001a113db8be6f5a3d0552688392-- From nobody Tue Jun 20 12:32:55 2017 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EAF3F131615; Tue, 20 Jun 2017 12:32:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dmarc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149798717292.25080.2138783422128120657@ietfa.amsl.com> Date: Tue, 20 Jun 2017 12:32:52 -0700 Archived-At: Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-04.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 19:32:53 -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 : Authenticated Received Chain (ARC) Protocol Authors : Kurt Andersen Brandon Long Steven Jones Filename : draft-ietf-dmarc-arc-protocol-04.txt Pages : 45 Date : 2017-06-20 Abstract: Authenticated Received Chain (ARC) permits an organization which is creating or handling email to indicate its involvement with the handling process. It defines a set of cryptographically signed header fields in a manner analagous to that of DKIM. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Changes in the message that might break DKIM can be identified through the ARC set of header fields. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-protocol/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-04 https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-arc-protocol-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-arc-protocol-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 20 12:33:14 2017 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2568A13160E; Tue, 20 Jun 2017 12:33:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dmarc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149798719011.24958.18255924081132788813@ietfa.amsl.com> Date: Tue, 20 Jun 2017 12:33:10 -0700 Archived-At: Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-usage-02.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 19:33:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain-based Message Authentication, Reporting & Conformance of the IETF. Title : Recommended Usage of the Authenticated Received Chain (ARC) Authors : Steven Jones John Rae-Grant J. Trent Adams Kurt Andersen Filename : draft-ietf-dmarc-arc-usage-02.txt Pages : 15 Date : 2017-06-20 Abstract: The Authentication Received Chain (ARC) provides a means to preserve email authentication results and verify the identity of email message handlers, each of which participates by inserting certain header fields before passing the message on. But the specification does not indicate how intermediaries and receivers should interpret or utilize ARC. This document will provide guidance in these areas. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-usage/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmarc-arc-usage-02 https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-arc-usage-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-arc-usage-02 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 Tue Jun 20 13:18:49 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5327E1294C4 for ; Tue, 20 Jun 2017 13:18:36 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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=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 CgQZFmKQlWAK for ; Tue, 20 Jun 2017 13:18:34 -0700 (PDT) Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::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 BE9A613162B for ; Tue, 20 Jun 2017 13:18:25 -0700 (PDT) Received: by mail-ot0-x232.google.com with SMTP id u13so83802936otd.2 for ; Tue, 20 Jun 2017 13:18:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=8B0dHQteeud4T13RclsjERYYNYPilk0FzzxP151HX2I=; b=DmQULfd6PzKboInALZXYwF6ImlChTxwp9mrtG4Gy3yGhS1aqfSCHUjvm8cISh6Ng9t e2tYT+GmQkfMyrwFDMXVEW2NXmGC7KDAEXKkn3EZddjKZy/vZHe/UEosJdbj+og+MCzD uNQ/7Cos4CGuqG+doRbmGeQGNAowrkv+3231SBKymNcOrHNxtuTE3i+B77N5KqTGmLmP gXAYbEmY8IBHlYFnpqpburb6nsV8ODG8e3/tLrnrWKsL+PqcmXpTWCaGKahV7PZeMSrk 5/vvFFZ05YLOxK2rdoArzrlY4o2HIV7VB62Zp6yZ6VWE2goVX0LUtmQ9sC9S0NY0LmBU aOBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=8B0dHQteeud4T13RclsjERYYNYPilk0FzzxP151HX2I=; b=HdBwbwykJo7oP0b0VXkp2Hn6f4Awqw4awR7Us3+fGSWnBlSdK8NTnDHT5y5YR6QJF0 8Y2xWsC+q3rvONOpVftzJwwPXax6I6Yjr6l+S+eklKcTaHzX5Yfz1I3GbS8zDCkuJFDv uzANgXWBLfcgDMLBl8SAooB1sXJJF5+yD90PRXWKnAqazIaaqz/MPAUBZOq3l3RlRTWL yzVPgsBFMBBQBHFOqKqRcXU0y62puEjEgYz4xyGWr8rTYWREkRIJa9/D9AaSHIJBraMz 1Vp4vdBiFdu91gT3qQpnVKxLkVfU316+V5/N8/o0ZSpgyYnX9cBBj42H5okNqNVzPVtI Rm8g== X-Gm-Message-State: AKS2vOy6Xh/6Z423nlLUN5ik8HBKZGPA4K4D2/Qu5JvTitAq6jSzqu8D v9ELx8sSY3BCV0eaI+ldrXalGG0/WsWCH3I= X-Received: by 10.157.80.131 with SMTP id b3mr17365274oth.4.1497989904759; Tue, 20 Jun 2017 13:18:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.68.42 with HTTP; Tue, 20 Jun 2017 13:18:24 -0700 (PDT) In-Reply-To: References: From: Brandon Long Date: Tue, 20 Jun 2017 13:18:24 -0700 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="f4030435aeb42705bd055269f482" Archived-At: Subject: Re: [dmarc-ietf] ARC cv=invalid X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 20:18:36 -0000 --f4030435aeb42705bd055269f482 Content-Type: text/plain; charset="UTF-8" On Mon, Jun 19, 2017 at 3:51 PM, Gene Shuman wrote: > Starting a new thread, as this is probably *the* major blocker wrt > OpenARC. The last thread basicaly was questioining the need for the > cv=invalid status entirely. The major question being, with an > invalid/mangled chain, how are we supossed to compute a b= value for the > ARC-Seal? If we do in fact maintain the cv=invalid state, we can create a > local AMS, but we can no longer enforce a mandatory b= in the AS. The > other alternative is just to stamp arc=invalid in the the AR & be done with > it. It is very much important to figure this out. In the former case we > would need to say that AS b= is undefined when cv=invalid, which wouldn't > be that big of a deal afaik. In the later case, we could simply abort > processing of messages, and put the status in AR. It's unclear to me which > is preferable. > > Another question, which is related, but independent to the former, is what > *precisely* constitutes an invalid chain vs a failing one. I had > previously been working on the assumption that invalid was a property > strictly relate to the i= tag & the chain itself. ie. duplicate i= tags, > missing i= tags, missing AMS, AS, AAR headers, etc. But there are a large > class of errors that I had previously been considering failures which could > possibly be considered invalid results. For instance, the s= tag is > strictly required. When verifying an inbound message with a missing s= > tag, is cv=fail, or invalid? dkimpy & the test suite(and google's arc > implementation?) all consider this a fail, while OpenARC currently > considers this to be invalid. What is correct here? I suggest failure, > this way we can limit invalid *strictly* to mangled sets/i= tags etc. > Basically circumstances in which it is strictly impossible to generate an > AS b= value consistiently. > The google implementation pre-dates cv=invalid, and when I went to implement it, I couldn't find a good reason to do so, nor a great bright-line rule for how to differentiate the two. I don't see the point of trying to continue the chain after a cv=fail, so having a mechanism to do so, and the possibly complicated rules associated with it, seem pointless. The alternative would be to strip the arc-set entirely and start fresh. That seems to have minor benefit, so I didn't implement that, either, but I could imagine doing that if some useful case came up. This is also strictly more useful than trying to persist an invalid chain. I could see a cv=restart as an equivalent to cv=none for this type of case, I guess. Brandon --f4030435aeb42705bd055269f482 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jun 19, 2017 at 3:51 PM, Gene Shuman <geneshuman@gmail.com<= /a>> wrote:
St= arting a new thread, as this is probably *the* major blocker wrt OpenARC. T= he last thread basicaly was questioining the need for the cv=3Dinvalid stat= us entirely.=C2=A0 The major question being, with an invalid/mangled chain,= how are we supossed to compute a b=3D value for the ARC-Seal?=C2=A0 If we = do in fact maintain the cv=3Dinvalid state, we can create a local AMS, but = we can no longer enforce a mandatory b=3D in the AS.=C2=A0 The other altern= ative is just to stamp arc=3Dinvalid in the the AR & be done with it.= =C2=A0 It is very much important to figure this out.=C2=A0 In the former ca= se we would need to say that AS b=3D is undefined when cv=3Dinvalid, which = wouldn't be that big of a deal afaik.=C2=A0 In the later case, we could= simply abort processing of messages, and put the status in AR.=C2=A0 It= 9;s unclear to me which is preferable. =C2=A0 =C2=A0

Ano= ther question, which is related, but independent to the former, is what *pr= ecisely* constitutes an invalid chain vs a failing one.=C2=A0 I had previou= sly been working on the assumption that invalid was a property strictly rel= ate to the i=3D tag & the chain itself. =C2=A0ie. duplicate i=3D tags, = missing i=3D tags, missing AMS, AS, AAR headers, etc.=C2=A0 But there are a= large class of errors that I had previously been considering failures whic= h could possibly be considered invalid results.=C2=A0 For instance, the s= =3D tag is strictly required.=C2=A0 When verifying an inbound message with = a missing s=3D tag, is cv=3Dfail, or invalid? =C2=A0dkimpy & the test s= uite(and google's arc implementation?) all consider this a fail, while = OpenARC currently considers this to be invalid.=C2=A0 What is correct here?= =C2=A0 I suggest failure, this way we can limit invalid *strictly* to mangl= ed sets/i=3D tags etc.=C2=A0 Basically circumstances in which it is strictl= y impossible to generate an AS b=3D value consistiently. =C2=A0
=

The google implementation pre-dates cv=3Di= nvalid, and when I went to implement it, I couldn't find a good reason = to do so, nor a great bright-line rule for how to differentiate the two.

I don't see the point of trying to continue the = chain after a cv=3Dfail, so having a mechanism to do so, and the possibly c= omplicated rules associated with it, seem pointless.

The alternative would be to strip the arc-set entirely and start fresh.= =C2=A0 That seems to have minor benefit, so I didn't implement that, ei= ther, but I could imagine doing that if some useful case came up.=C2=A0 Thi= s is also strictly more useful than trying to persist an invalid chain.=C2= =A0 I could see a cv=3Drestart as an equivalent to cv=3Dnone for this type = of case, I guess.

Brandon
--f4030435aeb42705bd055269f482-- From nobody Tue Jun 20 13:44:53 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8699131643 for ; Tue, 20 Jun 2017 13:44:51 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5vHjLObgmnr for ; Tue, 20 Jun 2017 13:44:49 -0700 (PDT) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::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 7CBB2131647 for ; Tue, 20 Jun 2017 13:44:49 -0700 (PDT) Received: by mail-ua0-x232.google.com with SMTP id g40so93817962uaa.3 for ; Tue, 20 Jun 2017 13:44:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=nevZ2yLHcYvEwRY62YaJkaiMpWv1rvvdD6zJ7DKObi4=; b=yq/XaFylKidEkoE1CF49ZR4CP9JGB8O4dSyyQBBJseOt1dJ2IuNdlamKEmC0k/Nz9o AyEOn3W/h95aqQ3U9UbkBT9bNxbqTcWI0OgoDkhr1DUPawUZe49ga0EXDIuX1j3jfsXB 6AjtTvhjeQn4C2fZFUK4uvHYe98ODR9M+bDEPrTbfPojJpFlthA7vw8CRCxoz5s8OxNK k+7mBDKofLKAxyOrqkKaL6pwJinGGP2L4OfPJIpdQhew3pjhUd4LVhNTi8U2mgFzipWp 3V8oJw4KESuj9DC/HS6tyTeae8MvVSKttii83eWfIKq2gBb5QOXXUvHIqUhLClyJQQpX DMbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=nevZ2yLHcYvEwRY62YaJkaiMpWv1rvvdD6zJ7DKObi4=; b=ETzuLmBRMQkrVV8YhihxCbCIc6pygkrrb/EhniLIOJjrZlOTQQ9HCQFVC0aa2LOvas B95PXrG4J2lpOSG9vZ/O6pviRnbwYsHveqWRIgVCiLz+bVGxwSncvWhcBmuwvUEKMaYD R0XKoSYaR0FB0GGVTRmvI04AjxOJY5t6HHp5/h3Gu2/uI0fly/GAsj18rrjN1H+dzoWR dkfM5sS6w2y9RJzElVPlzHHYHrvvoZ369aLmBsytFX/RwshGwQJYmii7TqplZxhPNWYg /sO1x1I06VaSTQNv/TdKrAE9sE2OYljaeryBkaEEbZFZ7tD08z5lRowQZ43jq26pwjFg FCYg== X-Gm-Message-State: AKS2vOwkrgFOTaW4P/148drlHp0E9k70wUmm2SyOLBmixor2HT9BSkeg 9oerSgA6PTn/FstUo+QyZ4uXsG85i31VjBI= X-Received: by 10.176.16.201 with SMTP id x9mr18731481uab.45.1497991488270; Tue, 20 Jun 2017 13:44:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.152.80 with HTTP; Tue, 20 Jun 2017 13:44:27 -0700 (PDT) In-Reply-To: References: From: Seth Blank Date: Tue, 20 Jun 2017 13:44:27 -0700 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="f4030436160689688f05526a5264" Archived-At: Subject: Re: [dmarc-ietf] ARC cv=invalid X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 20:44:52 -0000 --f4030436160689688f05526a5264 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 20, 2017 at 1:18 PM, Brandon Long wrote: > The google implementation pre-dates cv=invalid, and when I went to > implement it, I couldn't find a good reason to do so, nor a great > bright-line rule for how to differentiate the two. > > I don't see the point of trying to continue the chain after a cv=fail, so > having a mechanism to do so, and the possibly complicated rules associated > with it, seem pointless. > Are you suggesting that we remove cv=invalid and leave everything under cv=fail, because that's all that matters to transmit downstream via the AS? And then, if someone wants to really make it clear what happened, that could be stamped in an A-R header like "arc=fail (invalid ARC set at i=3: too many headers)"? Or do you think at this juncture, in the A-R "arc=invalid" makes sense like "arc=invalid (missing AS for i=2)" to differentiate ARC set failures from all other failures? The alternative would be to strip the arc-set entirely and start fresh. > That seems to have minor benefit, so I didn't implement that, either, but I > could imagine doing that if some useful case came up. This is also > strictly more useful than trying to persist an invalid chain. I could see > a cv=restart as an equivalent to cv=none for this type of case, I guess. > I think "restarting" an ARC chain makes no sense. If the chain breaks, it's broken. Custody's been lost and you don't get to show up with a new message. --f4030436160689688f05526a5264 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Jun 20, 2017 at 1:18 PM, Brandon Long <blong@google.com> = wrote:
The google imple= mentation pre-dates cv=3Dinvalid, and when I went to implement it, I couldn= 't find a good reason to do so, nor a great bright-line rule for how to= differentiate the two.

I don't see= the point of trying to continue the chain after a cv=3Dfail, so having a m= echanism to do so, and the possibly complicated rules associated with it, s= eem pointless.

Are = you suggesting that we remove cv=3Dinvalid and leave everything under cv=3D= fail, because that's all that matters to transmit downstream via the AS= ?

And then, if someone wants to really make it cle= ar what happened, that could be stamped in an A-R header like "arc=3Df= ail (invalid ARC set at i=3D3: too many headers)"? Or do you think at = this juncture, in the A-R "arc=3Dinvalid" makes sense like "= arc=3Dinvalid (missing AS for i=3D2)" to differentiate ARC set failure= s from all other failures?

<= div>The alternative would be to strip the arc-set entirely and start fresh.= =C2=A0 That seems to have minor benefit, so I didn't implement that, ei= ther, but I could imagine doing that if some useful case came up.=C2=A0 Thi= s is also strictly more useful than trying to persist an invalid chain.=C2= =A0 I could see a cv=3Drestart as an equivalent to cv=3Dnone for this type = of case, I guess.

I= think "restarting" an ARC chain makes no sense. If the chain bre= aks, it's broken. Custody's been lost and you don't get to show= up with a new message.

--f4030436160689688f05526a5264-- From nobody Tue Jun 20 14:17:12 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A95E3129486 for ; Tue, 20 Jun 2017 14:17: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 kub_paWeMTEd for ; Tue, 20 Jun 2017 14:17:07 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::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 32EC8127873 for ; Tue, 20 Jun 2017 14:17:07 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id m47so21399701iti.0 for ; Tue, 20 Jun 2017 14:17:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mQpdh9z7BEY31NbdILeCk8TgKL7vUqOMLKwEYWvbdc8=; b=YV2sHRMNMIh5qBOLuBDb2De/uq3ly3DU9Sz7N/oTVzOBaVDz0GNi4/YIpdpXhqIFcS oTKJG12Jxm7Pd0jEuOhHnkmrTDg2WnT/e6JppnevvL7ydl5iyme7G2m4Yp9HjA6nq1g8 +iwP6T+bmMY0jfL5FOqw178PahXjIW3lL6wSCIgfonIofnFR8vVzIS7E9dx2xg+20Yfc FSx8K7F18EIuUzpAi3QwJ8M9kavKa+RHCBK+AEY3T5n5pQg6WVATctfpOSTo0qWxqKxV e+dLdxQ31OO/5rL+bzDjtEtFw0YPU/ISzM+j3SocqnEZpVehPnp4bSPjqD24EoJ/X/Pj W+8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mQpdh9z7BEY31NbdILeCk8TgKL7vUqOMLKwEYWvbdc8=; b=a/C3rTXJi6Vdjd477oe5S8nVo7WKQs3Xhdae+7x3/ZAswLl/Rt0cGiTEXbTNLr+was sMdDdNTaXvKXfU5sxlnOl5bvihyH4FdpT8lL+SmFiY1Ld+tr3CmDw36+APiYRc+3MGDa h2KmBqLkDiLuE3Kg3E54dZ2YL2igE4QtKFizYyVw+hVRpYkXSuPGu+c2RKSBoGuNRR+R 17PhFzH5P1bimaKYxfN/HkLO3wH14cFGfxInoUEfkCu9EP85jH9QP7RAyZwXaNwyeyR1 CKuMEZiBWMmUqfFxA8C2xrtmTsrugvRl57P4Je76s2U12DUuX4B90WZT3yjxVYfs5w2m d9Qg== X-Gm-Message-State: AKS2vOynB1QVX7Ng1s4/XX0kFUx9fWsq9/iUZPuK2n9mBBpM0v1yE62A 0gsIbM/VZG0Hcxkl7WX5+ReyAwS3Dg== X-Received: by 10.36.43.146 with SMTP id h140mr5716599ita.72.1497993426485; Tue, 20 Jun 2017 14:17:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.0.209 with HTTP; Tue, 20 Jun 2017 14:17:05 -0700 (PDT) In-Reply-To: References: From: Gene Shuman Date: Tue, 20 Jun 2017 14:17:05 -0700 Message-ID: To: Seth Blank Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a114749aa0fce4605526ac651" Archived-At: Subject: Re: [dmarc-ietf] ARC cv=invalid X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 21:17:10 -0000 --001a114749aa0fce4605526ac651 Content-Type: text/plain; charset="UTF-8" Yeah, we certainly shouldn't be restarting the chain, and I (& I think most everyone else) concur that when it's invalid, the end. However I also don't think we should be keeping everything as fail, as invalid is pretty sematically different. And there is a clear line. cv=invalid if and only if you can't reliably produce an AS b= value, given the current rules. I think I very much agree with Kurt on wrt this line. Also, I don't think we should be relying on the contents of AR header fields to make determinations about ARC chains. It seems off to me to have to parse all AR headers to look for an arc=invalid or whatever to decide how to handle your ARC messages. But I possibly could be convinced otherwise. This leaves us with the option of sticking cv=invalid in the AS, and still the open question of if and how to generate the AS b= tag. Kurt's suggestion seems totally fine, although slightly awkward. Not sure I have any better ideas though. What is the value of creating this signature, as opposed to just not & relying solely on our AMS? I guess we are signing our new AAR then, which is worth something? =Gene On Tue, Jun 20, 2017 at 1:44 PM, Seth Blank wrote: > On Tue, Jun 20, 2017 at 1:18 PM, Brandon Long wrote: > >> The google implementation pre-dates cv=invalid, and when I went to >> implement it, I couldn't find a good reason to do so, nor a great >> bright-line rule for how to differentiate the two. >> >> I don't see the point of trying to continue the chain after a cv=fail, so >> having a mechanism to do so, and the possibly complicated rules associated >> with it, seem pointless. >> > > Are you suggesting that we remove cv=invalid and leave everything under > cv=fail, because that's all that matters to transmit downstream via the AS? > > And then, if someone wants to really make it clear what happened, that > could be stamped in an A-R header like "arc=fail (invalid ARC set at i=3: > too many headers)"? Or do you think at this juncture, in the A-R > "arc=invalid" makes sense like "arc=invalid (missing AS for i=2)" to > differentiate ARC set failures from all other failures? > > The alternative would be to strip the arc-set entirely and start fresh. >> That seems to have minor benefit, so I didn't implement that, either, but I >> could imagine doing that if some useful case came up. This is also >> strictly more useful than trying to persist an invalid chain. I could see >> a cv=restart as an equivalent to cv=none for this type of case, I guess. >> > > I think "restarting" an ARC chain makes no sense. If the chain breaks, > it's broken. Custody's been lost and you don't get to show up with a new > message. > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --001a114749aa0fce4605526ac651 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yeah, we certainly shouldn't be restarting the chain, = and I (& I think most everyone else) concur that when it's invalid,= the end. However I also don't think we should be keeping everything as= fail, as invalid is pretty sematically different.=C2=A0 And there is a cle= ar line. =C2=A0cv=3Dinvalid if and only if you can't reliably produce a= n AS b=3D value, given the current rules.=C2=A0 I think I very much agree w= ith Kurt on wrt this line. =C2=A0

Also, I don't= think we should be relying on the contents of AR header fields to make det= erminations about ARC chains.=C2=A0 It seems off to me to have to parse all= AR headers to look for an arc=3Dinvalid or whatever to decide how to handl= e your ARC messages.=C2=A0 But I possibly could be convinced otherwise.

This leaves us with the option of sticking cv= =3Dinvalid in the AS, and still the open question of if and how to generate= the AS b=3D tag.=C2=A0 Kurt's suggestion seems totally fine, although = slightly awkward.=C2=A0 Not sure I have any better ideas though.=C2=A0 What= is the value of creating this signature, as opposed to just not & rely= ing solely on our AMS?=C2=A0 I guess we are signing our new AAR then, which= is worth something?

=3DGene

On Tue, Jun 20, 2017 at 1:4= 4 PM, Seth Blank <seth@sethblank.com> wrote:
On Tue, Jun 20, 2017 at 1:18 PM, Brandon = Long <blong@google.com> wrote:
=
The google implementation pre-dates cv=3Dinvalid, and when I wen= t to implement it, I couldn't find a good reason to do so, nor a great = bright-line rule for how to differentiate the two.
I don't see the point of trying to continue the chain after= a cv=3Dfail, so having a mechanism to do so, and the possibly complicated = rules associated with it, seem pointless.

Are you suggesting that we remove cv=3Dinvali= d and leave everything under cv=3Dfail, because that's all that matters= to transmit downstream via the AS?

And then, if s= omeone wants to really make it clear what happened, that could be stamped i= n an A-R header like "arc=3Dfail (invalid ARC set at i=3D3: too many h= eaders)"? Or do you think at this juncture, in the A-R "arc=3Dinv= alid" makes sense like "arc=3Dinvalid (missing AS for i=3D2)"= ; to differentiate ARC set failures from all other failures?

The alternative woul= d be to strip the arc-set entirely and start fresh.=C2=A0 That seems to hav= e minor benefit, so I didn't implement that, either, but I could imagin= e doing that if some useful case came up.=C2=A0 This is also strictly more = useful than trying to persist an invalid chain.=C2=A0 I could see a cv=3Dre= start as an equivalent to cv=3Dnone for this type of case, I guess.

I think "resta= rting" an ARC chain makes no sense. If the chain breaks, it's brok= en. Custody's been lost and you don't get to show up with a new mes= sage.


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


--001a114749aa0fce4605526ac651-- From nobody Tue Jun 20 14:38:14 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBFC512EC58 for ; Tue, 20 Jun 2017 14:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.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 GmXSdl1pvF2K for ; Tue, 20 Jun 2017 14:38:07 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::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 A54FE126C22 for ; Tue, 20 Jun 2017 14:38:07 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id v20so27911608qtg.1 for ; Tue, 20 Jun 2017 14:38:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=Ugr/XlydNDubLc0u6w+OpsinFGRjXb/TMjXS4yNnuUM=; b=UXFLwGWu32344H814rWKqSo+RzoRoejZgi4rpCmI+rCOZiclWnvI67UYoqJMtwBbnG HehICXzBdHqiUAhu6vWtgajmwIpEGBJ8fba2zWOXbuKytkKRbJuTXz2Y6JW49V+bB3Mj oUuFRqrSvH4JRsn2OlRTwLidpRrvUVf9ZAlzmu+tl7j51riasfIW8V9n46s37bfV/QtH dIr907PK43ojS9T2Tb4TgnyCLYhAfrknAV9s6fV4xPyFfIakpByWg6yIvysiySc8Ur1y XPnxLeGzfaeSkpUMiezt1goTmC/Ub2wO8lc/18W7sbQukNQJJ06IyL6RuK4QGBvICfne tuaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=Ugr/XlydNDubLc0u6w+OpsinFGRjXb/TMjXS4yNnuUM=; b=QLFPC6oRZZ6rWO3nRO5h3oBVg8Vkvd3o0QF6+JePBMWOHRYfpT+L4Pzz+V8P4B+Jsu HXGbN1xk/XxolRLNtuaCP2iHAKQfPM0RdiqgXJaPj8B9rGrh0Xa+xI+hGaaiJhDleUtU 5xcEQMKIlFdLTiMCuy61vYauHJ2VHiL5dG4OuDmK/bws7rEQAd6W6040RNVb8ucqlNTh UltbZUNcztIp69j2L4zl591BhRTAAsrvkhiYq4F2bG8ijGoT/Cnc0KFdmjnG4Ek562VT i597TRZW6zdblyz2lrfbMUIME6e5rFH3+JB+H5SG8rr3q+U2XcIY+v1GWrH0vqTbQsi1 rShw== X-Gm-Message-State: AKS2vOzXscKBAzcO1Gb/DP/JYrfcX//NAHBtNn9xGaJh24cbjW1vf5aE 0vja/MbnVaYmcCIxX1bHLK8Xf5OoBFcUQCI= X-Received: by 10.200.34.66 with SMTP id p2mr40925837qtp.2.1497994686385; Tue, 20 Jun 2017 14:38:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.43.27 with HTTP; Tue, 20 Jun 2017 14:37:45 -0700 (PDT) In-Reply-To: References: From: Seth Blank Date: Tue, 20 Jun 2017 14:37:45 -0700 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a113d4df62860bd05526b112a" Archived-At: Subject: Re: [dmarc-ietf] ARC cv=invalid X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 21:38:11 -0000 --001a113d4df62860bd05526b112a Content-Type: text/plain; charset="UTF-8" On Tue, Jun 20, 2017 at 2:17 PM, Gene Shuman wrote: > Yeah, we certainly shouldn't be restarting the chain, and I (& I think > most everyone else) concur that when it's invalid, the end. However I also > don't think we should be keeping everything as fail, as invalid is pretty > sematically different. And there is a clear line. cv=invalid if and only > if you can't reliably produce an AS b= value, given the current rules. I > think I very much agree with Kurt on wrt this line. > I guess my question is, if the AS state is cv=fail vs cv=invalid, does the difference between these two statuses make any meaningful difference for a receiver to make a final delivery decision around a dmarc reject|quarantine? Brandon? Or is it useful later, when processing logs, to determine ARC signers who are signing improperly? If yes, then they should absolutely stay distinct states. Otherwise, maybe it's just trace information? And if so, that was the reason for the AAR, so it seems to me that's where the distinction is best catalogued. To be very clear: I'm thinking out loud here, I do not have a strong opinion one way or the other, and am very curious what the group thinks. > Also, I don't think we should be relying on the contents of AR header > fields to make determinations about ARC chains. It seems off to me to have > to parse all AR headers to look for an arc=invalid or whatever to decide > how to handle your ARC messages. But I possibly could be convinced > otherwise. > Oh, I agree. That's my point. From my vantage point (which could be wrong), if an invalid state does not offer any additional help to a receiver than a fail, then an AAR would never need to be parsed in-flight. However, this is a very good point and I'm sympathetic. If pulling ARC signatories who produce an invalid result end up being crucial, it's most likely way easier to do this from the AS cv= than from the AARs. > > This leaves us with the option of sticking cv=invalid in the AS, and still > the open question of if and how to generate the AS b= tag. Kurt's > suggestion seems totally fine, although slightly awkward. Not sure I have > any better ideas though. What is the value of creating this signature, as > opposed to just not & relying solely on our AMS? I guess we are signing > our new AAR then, which is worth something? > I also don't have any better ideas. > > =Gene > > On Tue, Jun 20, 2017 at 1:44 PM, Seth Blank wrote: > >> On Tue, Jun 20, 2017 at 1:18 PM, Brandon Long wrote: >> >>> The google implementation pre-dates cv=invalid, and when I went to >>> implement it, I couldn't find a good reason to do so, nor a great >>> bright-line rule for how to differentiate the two. >>> >>> I don't see the point of trying to continue the chain after a cv=fail, >>> so having a mechanism to do so, and the possibly complicated rules >>> associated with it, seem pointless. >>> >> >> Are you suggesting that we remove cv=invalid and leave everything under >> cv=fail, because that's all that matters to transmit downstream via the AS? >> >> And then, if someone wants to really make it clear what happened, that >> could be stamped in an A-R header like "arc=fail (invalid ARC set at i=3: >> too many headers)"? Or do you think at this juncture, in the A-R >> "arc=invalid" makes sense like "arc=invalid (missing AS for i=2)" to >> differentiate ARC set failures from all other failures? >> >> The alternative would be to strip the arc-set entirely and start fresh. >>> That seems to have minor benefit, so I didn't implement that, either, but I >>> could imagine doing that if some useful case came up. This is also >>> strictly more useful than trying to persist an invalid chain. I could see >>> a cv=restart as an equivalent to cv=none for this type of case, I guess. >>> >> >> I think "restarting" an ARC chain makes no sense. If the chain breaks, >> it's broken. Custody's been lost and you don't get to show up with a new >> message. >> >> >> _______________________________________________ >> 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 > > -- [image: logo for sig file.png] Bringing Trust to Email Seth Blank | Head of Product for Open Source and Protocols seth@valimail.com +1-415-894-2724 <415-894-2724> --001a113d4df62860bd05526b112a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Jun 20, 2017 at 2:17 PM, Gene Shuman <geneshuman@gmail.com><= /span> wrote:
Yeah, we c= ertainly shouldn't be restarting the chain, and I (& I think most e= veryone else) concur that when it's invalid, the end. However I also do= n't think we should be keeping everything as fail, as invalid is pretty= sematically different.=C2=A0 And there is a clear line. =C2=A0cv=3Dinvalid= if and only if you can't reliably produce an AS b=3D value, given the = current rules.=C2=A0 I think I very much agree with Kurt on wrt this line. = =C2=A0


I guess my ques= tion is, if the AS state is cv=3Dfail vs cv=3Dinvalid, does the difference = between these two statuses make any meaningful difference for a receiver to= make a final delivery decision around a dmarc reject|quarantine? Brandon?<= /div>

Or is it useful later, when processing logs, to de= termine ARC signers who are signing improperly?

If= yes, then they should absolutely stay distinct states.

Otherwise, maybe it's just trace information? And if so, that was= the reason for the AAR, so it seems to me that's where the distinction= is best catalogued.

To be very clear: I'm thi= nking out loud here, I do not have a strong opinion one way or the other, a= nd am very curious what the group thinks.

=C2=A0
Also, I don&#= 39;t think we should be relying on the contents of AR header fields to make= determinations about ARC chains.=C2=A0 It seems off to me to have to parse= all AR headers to look for an arc=3Dinvalid or whatever to decide how to h= andle your ARC messages.=C2=A0 But I possibly could be convinced otherwise.=

Oh, I agree. That= 9;s my point. From my vantage point (which could be wrong), if an invalid s= tate does not offer any additional help to a receiver than a fail, then an = AAR would never need to be parsed in-flight.

Howev= er, this is a very good point and I'm sympathetic. If pulling ARC signa= tories who produce an invalid result end up being crucial, it's most li= kely way easier to do this from the AS cv=3D than from the AARs.
= =C2=A0

This leaves us with the option of sticking cv=3D= invalid in the AS, and still the open question of if and how to generate th= e AS b=3D tag.=C2=A0 Kurt's suggestion seems totally fine, although sli= ghtly awkward.=C2=A0 Not sure I have any better ideas though.=C2=A0 What is= the value of creating this signature, as opposed to just not & relying= solely on our AMS?=C2=A0 I guess we are signing our new AAR then, which is= worth something?

I also don= 9;t have any better ideas.

=C2=A0

=3DGene

On Tue, Jun 20, 2017 at 1:44 PM, Seth Blank <<= a href=3D"mailto:seth@sethblank.com" target=3D"_blank">seth@sethblank.com> wrote:
On Tue, Jun 20, 2017 at 1:18 PM, Brandon Long <blong@googl= e.com> wrote:
The go= ogle implementation pre-dates cv=3Dinvalid, and when I went to implement it= , I couldn't find a good reason to do so, nor a great bright-line rule = for how to differentiate the two.

I don= 't see the point of trying to continue the chain after a cv=3Dfail, so = having a mechanism to do so, and the possibly complicated rules associated = with it, seem pointless.

Are you suggesting that we remove cv=3Dinvalid and leave every= thing under cv=3Dfail, because that's all that matters to transmit down= stream via the AS?

And then, if someone wants to r= eally make it clear what happened, that could be stamped in an A-R header l= ike "arc=3Dfail (invalid ARC set at i=3D3: too many headers)"? Or= do you think at this juncture, in the A-R "arc=3Dinvalid" makes = sense like "arc=3Dinvalid (missing AS for i=3D2)" to differentiat= e ARC set failures from all other failures?

The alternative would be to strip the arc-set en= tirely and start fresh.=C2=A0 That seems to have minor benefit, so I didn&#= 39;t implement that, either, but I could imagine doing that if some useful = case came up.=C2=A0 This is also strictly more useful than trying to persis= t an invalid chain.=C2=A0 I could see a cv=3Drestart as an equivalent to cv= =3Dnone for this type of case, I guess.

I think "restarting" an ARC chain mak= es no sense. If the chain breaks, it's broken. Custody's been lost = and you don't get to show up with a new message.


_______________________________________________
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




--
=

3D"logo

Bringing Trust to Email

Seth Blank | Head of Product for Open Source and Protocols

<= a href=3D"mailto:seth@valimail.com" target=3D"_blank">seth@valimail.com= <= br>+1-415-894-2724
--001a113d4df62860bd05526b112a-- From nobody Tue Jun 20 19:08:05 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25E25129A8E for ; Tue, 20 Jun 2017 19:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQZaavSRT5IU for ; Tue, 20 Jun 2017 19:08:01 -0700 (PDT) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::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 86C9E1296C9 for ; Tue, 20 Jun 2017 19:08:01 -0700 (PDT) Received: by mail-ua0-x22c.google.com with SMTP id j53so85369176uaa.2 for ; Tue, 20 Jun 2017 19:08:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=2kecVmAvKOU/bsbmFF1Yp2HzDv1dljUJ9YTRTl50Pyg=; b=OeCgLVe4zJLat2M40vl04PLtenxnPRhfIBokpff1OOPI8msjpE0k5J8ydo5pcwUXrK 6F7QAAG+ZXtg3LgzqmBqbAD9wGy+PEHlaUZGlILLP7PwYkbFdl09uKaViWM9n4rMhAHN zMdf94oOfmyW9CouUVC8vArUdoryDu9/02NfU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=2kecVmAvKOU/bsbmFF1Yp2HzDv1dljUJ9YTRTl50Pyg=; b=MwPgRMfduPSGRIKC2jzlfe9WJvNU4WTS6doSd2S2u0f3sSKj7Z73qoHdBg57dmxEeb 7Go4pH80T30pTrIOLYGhu8H8qq79apqkcPr7iqCzM1WkSXkE6KSgMUkr+Y0qnrMecPn+ jdjxHR+yjmeKfwYIGUGvqBgZOlBuQTPocr8uvCS/7/3Mjq4e5CJ5Ne+Y/g+d3PMwCvF0 awR8P+YsdRDivxKAUhIuoePoc7aUwhp0gTiltkPT2LAZX9oUSLCS0HCcBDArkUpwMm3o o4pJKKCnt24SzVLiLxv5dOkv0fiYans/uFBRtItGD3JBf9LKcCTogQLmvvyb+2xZqgSN oFdw== X-Gm-Message-State: AKS2vOwb6o2tej8jVP3iygw3FlmVE6f2ti+7JJGHKtbTZUtmekzlfhu7 cGXDWyzY/pBPSOqVEq28cTtvF3TOgdfT X-Received: by 10.159.52.77 with SMTP id s13mr14738388uab.8.1498010880520; Tue, 20 Jun 2017 19:08:00 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.176.75.153 with HTTP; Tue, 20 Jun 2017 19:08:00 -0700 (PDT) In-Reply-To: References: From: "Kurt Andersen (b)" Date: Tue, 20 Jun 2017 19:08:00 -0700 X-Google-Sender-Auth: 2mQjHq_liOxW1d2PGePtm_YroHI Message-ID: To: Gene Shuman Cc: Seth Blank , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="f403043eb7a467d04c05526ed61b" Archived-At: Subject: Re: [dmarc-ietf] ARC cv=invalid X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 02:08:04 -0000 --f403043eb7a467d04c05526ed61b Content-Type: text/plain; charset="UTF-8" Formerly, On Tue, Jun 20, 2017 at 1:44 PM, Seth Blank wrote: > On Tue, Jun 20, 2017 at 1:18 PM, Brandon Long wrote: > >> The google implementation pre-dates cv=invalid, and when I went to >> implement it, I couldn't find a good reason to do so, nor a great >> bright-line rule for how to differentiate the two. >> >> I don't see the point of trying to continue the chain after a cv=fail, so >> having a mechanism to do so, and the possibly complicated rules associated >> with it, seem pointless. >> > > Are you suggesting that we remove cv=invalid and leave everything under > cv=fail, because that's all that matters to transmit downstream via the AS? > > And then, if someone wants to really make it clear what happened, that > could be stamped in an A-R header like "arc=fail (invalid ARC set at i=3: > too many headers)"? Or do you think at this juncture, in the A-R > "arc=invalid" makes sense like "arc=invalid (missing AS for i=2)" to > differentiate ARC set failures from all other failures? > > The alternative would be to strip the arc-set entirely and start fresh. >> That seems to have minor benefit, so I didn't implement that, either, but I >> could imagine doing that if some useful case came up. This is also >> strictly more useful than trying to persist an invalid chain. I could see >> a cv=restart as an equivalent to cv=none for this type of case, I guess. >> > > I think "restarting" an ARC chain makes no sense. If the chain breaks, > it's broken. Custody's been lost and you don't get to show up with a new > message. > > On Tue, Jun 20, 2017 at 2:17 PM, Gene Shuman replied: > > Also, I don't think we should be relying on the contents of AR header > fields to make determinations about ARC chains. It seems off to me to have > to parse all AR headers to look for an arc=invalid or whatever to decide > how to handle your ARC messages. > I agree with Seth that putting this info into the AAR headers is not the right approach. > This leaves us with the option of sticking cv=invalid in the AS, and still > the open question of if and how to generate the AS b= tag. Kurt's > suggestion seems totally fine, although slightly awkward. Not sure I have > any better ideas though. What is the value of creating this signature, as > opposed to just not & relying solely on our AMS? I guess we are signing > our new AAR then, which is worth something? > Yes, you are signing your AAR and AMS (much like the i=1 ARC signer is doing) attesting to the state of the message when you handled it. You can't really say anything about previous handlers except that any traces of their work has been thoroughly trashed. --Kurt --f403043eb7a467d04c05526ed61b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Formerly,= On Tue, Jun 20, 2017 at 1:44 PM, Seth Blank=C2=A0<seth@sethblank.com= >=C2=A0wrote:
= On Tue, Jun 20, 2017 at 1:18 PM, Brandon Long=C2=A0<blong@google.com>= ;=C2=A0wrote:
<= div dir=3D"ltr">
= The google implementation pre-dates cv=3Dinvalid, and when I went to implem= ent it, I couldn't find a good reason to do so, nor a great bright-line= rule for how to differentiate the two.

I don&= #39;t see the point of trying to continue the chain after a cv=3Dfail, so h= aving a mechanism to do so, and the possibly complicated rules associated w= ith it, seem pointless.

=
Are you suggesting that we remove cv=3Dinvalid and leave everything un= der cv=3Dfail, because that's all that matters to transmit downstream v= ia the AS?

And then, if someone wants to really ma= ke it clear what happened, that could be stamped in an A-R header like &quo= t;arc=3Dfail (invalid ARC set at i=3D3: too many headers)"? Or do you = think at this juncture, in the A-R "arc=3Dinvalid" makes sense li= ke "arc=3Dinvalid (missing AS for i=3D2)" to differentiate ARC se= t failures from all other failures?

The alternative would be to strip the arc-set = entirely and start fresh.=C2=A0 That seems to have minor benefit, so I didn= 't implement that, either, but I could imagine doing that if some usefu= l case came up.=C2=A0 This is also strictly more useful than trying to pers= ist an invalid chain.=C2=A0 I could see a cv=3Drestart as an equivalent to = cv=3Dnone for this type of case, I guess.

I think "restarting" an ARC chain makes no sense= . If the chain breaks, it's broken. Custody's been lost and you don= 't get to show up with a new message.

<= /div>
=C2=A0
O= n Tue, Jun 20, 2017 at 2:17 PM, Gene Shuman <geneshuman@gmail.com= > replied:
<= div dir=3D"ltr">

Also, I don't think we should = be relying on the contents of AR header fields to make determinations about= ARC chains.=C2=A0 It seems off to me to have to parse all AR headers to lo= ok for an arc=3Dinvalid or whatever to decide how to handle your ARC messag= es.=C2=A0

I agree with S= eth that putting this info into the AAR headers is not the right approach.= =C2=A0
=C2=A0
This leaves us with the option of sticking cv=3Di= nvalid in the AS, and still the open question of if and how to generate the= AS b=3D tag.=C2=A0 Kurt's suggestion seems totally fine, although slig= htly awkward.=C2=A0 Not sure I have any better ideas though.=C2=A0 What is = the value of creating this signature, as opposed to just not & relying = solely on our AMS?=C2=A0 I guess we are signing our new AAR then, which is = worth something?

Yes, you a= re signing your AAR and AMS (much like the i=3D1 ARC signer is doing) attes= ting to the state of the message when you handled it. You can't really = say anything about previous handlers except that any traces of their work h= as been thoroughly trashed.

--Kurt

<= /div>
--f403043eb7a467d04c05526ed61b-- From nobody Wed Jun 21 13:53:19 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76A98129484 for ; Wed, 21 Jun 2017 13:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8E9y9ag2Nj8 for ; Wed, 21 Jun 2017 13:53:16 -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 D87FF1274D2 for ; Wed, 21 Jun 2017 13:53:15 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id t87so11238654ioe.0 for ; Wed, 21 Jun 2017 13:53:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YxPvYUEV2tXw8HooykadLgGBWgOhgN/B1dQsCnRPcl8=; b=Ig9KVb5cgIldaIOY00vybs0er6y+4OR1JZfIFqfxklyDPoEKc+Ow2RYTTVY8pVqQWT 30kcqI4VTJFdpPIUF3yKISfh+zX+kTJy7BZaBr2FdY9IS3mXY0Zfzo/N5zpyxiGwPyhF tdJ7LAEhQ71xAmIH8GweAsIyK3clvMGPGK8UUBqOFGDB3IJSk4elXoIucM9tyr3oeN6/ U8xuXTO4qM2CK7ZBlw7F5V6LvrT24YQ5skbOvqMJcE2XkZ7G+ra8gW2mOZklAMmaf+if TfM9++KYsRHAJkrlyVITnW8iDMAxS3gdnT+03hf9VmzFTpFZXmKL5Bjj5aHA80YezpTh ghJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YxPvYUEV2tXw8HooykadLgGBWgOhgN/B1dQsCnRPcl8=; b=CVYjljxkflSAO3wybO5KRlhLd/eiUh8Dd00Z/GWd4XoAXNShossMBuAEAwek7nCvxO QN0g3ZM9U47DKV+8tYGCdOoAC4D63dFmKrrSF5qGCCKmsS4YwY+Tl9lttXK6HQaL46vm MtSc1LOdG+VrunHDnMmiaMkIiCktVmf84kpLyrxNGItz/3pk/GdlcZcmbkm/VViqUJgr 6y+hS977CbbhYwqxrEi7yA2uj20hCs+cmKU95zrW34t50cSzDRrEkf1vbMrOnL8CTfTD 3PTFkXv3mzIPln/SV6qsUiAkL9WguqwtauWpYO4nGbgOLh5egmeWHODUh9QWUOnX4uY9 fvow== X-Gm-Message-State: AKS2vOwn/aycr6Z3EFcZrCAqZKkXRSvxT5ScAZ6VUFR6ZfTd/VK1koOF pNRyfNpN3E6CDDl14yAIZVq2JRMwUg== X-Received: by 10.107.17.21 with SMTP id z21mr32287474ioi.34.1498078395271; Wed, 21 Jun 2017 13:53:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.0.209 with HTTP; Wed, 21 Jun 2017 13:53:14 -0700 (PDT) In-Reply-To: References: From: Gene Shuman Date: Wed, 21 Jun 2017 13:53:14 -0700 Message-ID: To: "Kurt Andersen (b)" Cc: Seth Blank , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a113ed096989a4405527e8e39" Archived-At: Subject: Re: [dmarc-ietf] ARC cv=invalid X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 20:53:18 -0000 --001a113ed096989a4405527e8e39 Content-Type: text/plain; charset="UTF-8" OK, so we've spoken with Brandon a bit about this in person, and we're still a bit unclear about the resolution of this issue. It seems we have two choices available to us upon receipt of an invalid chain(which is defined as AS b= unable to be computed). 1. Simply stop adding further ARC headers. Put arc=fail(or invalid) in the AR. Further recipients will detect that the chain is broken as well, for the same reasons. This is clearly the easiest solution. 2. Add one further ARC-Set with an explicit cv=invalid in order to 'close' the chain, using the rule that Kurt has suggested. This seems to have some benefit to me, but it's minimal. It seems to wrap things up nicely, and it means that all ARC chains have a well defined cv value, which makes testing a little easier. However the cost is clearly added complexity, both in the spec and implementations. Is there any other tangible value to adding this final ARC-Set? Does it help identify the failure point in the chain? Is there any other benefit? Kurt, can you speak to this? =Gene On Tue, Jun 20, 2017 at 7:08 PM, Kurt Andersen (b) wrote: > Formerly, On Tue, Jun 20, 2017 at 1:44 PM, Seth Blank > wrote: > >> On Tue, Jun 20, 2017 at 1:18 PM, Brandon Long wrote: >> >>> The google implementation pre-dates cv=invalid, and when I went to >>> implement it, I couldn't find a good reason to do so, nor a great >>> bright-line rule for how to differentiate the two. >>> >>> I don't see the point of trying to continue the chain after a cv=fail, >>> so having a mechanism to do so, and the possibly complicated rules >>> associated with it, seem pointless. >>> >> >> Are you suggesting that we remove cv=invalid and leave everything under >> cv=fail, because that's all that matters to transmit downstream via the AS? >> >> And then, if someone wants to really make it clear what happened, that >> could be stamped in an A-R header like "arc=fail (invalid ARC set at i=3: >> too many headers)"? Or do you think at this juncture, in the A-R >> "arc=invalid" makes sense like "arc=invalid (missing AS for i=2)" to >> differentiate ARC set failures from all other failures? >> >> The alternative would be to strip the arc-set entirely and start fresh. >>> That seems to have minor benefit, so I didn't implement that, either, but I >>> could imagine doing that if some useful case came up. This is also >>> strictly more useful than trying to persist an invalid chain. I could see >>> a cv=restart as an equivalent to cv=none for this type of case, I guess. >>> >> >> I think "restarting" an ARC chain makes no sense. If the chain breaks, >> it's broken. Custody's been lost and you don't get to show up with a new >> message. >> >> > On Tue, Jun 20, 2017 at 2:17 PM, Gene Shuman > replied: > >> >> Also, I don't think we should be relying on the contents of AR header >> fields to make determinations about ARC chains. It seems off to me to have >> to parse all AR headers to look for an arc=invalid or whatever to decide >> how to handle your ARC messages. >> > > I agree with Seth that putting this info into the AAR headers is not the > right approach. > > >> This leaves us with the option of sticking cv=invalid in the AS, and >> still the open question of if and how to generate the AS b= tag. Kurt's >> suggestion seems totally fine, although slightly awkward. Not sure I have >> any better ideas though. What is the value of creating this signature, as >> opposed to just not & relying solely on our AMS? I guess we are signing >> our new AAR then, which is worth something? >> > > Yes, you are signing your AAR and AMS (much like the i=1 ARC signer is > doing) attesting to the state of the message when you handled it. You can't > really say anything about previous handlers except that any traces of their > work has been thoroughly trashed. > > --Kurt > > --001a113ed096989a4405527e8e39 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
OK, so we've spoken with Brandon a bit about this in p= erson, and we're still a bit unclear about the resolution of this issue= .

It seems we have two choices available to us upon rece= ipt of an invalid chain(which is defined as AS b=3D unable to be computed).=

1. Simply stop adding further ARC headers.=C2=A0 = Put arc=3Dfail(or invalid) in the AR.=C2=A0 Further recipients will detect = that the chain is broken as well, for the same reasons.=C2=A0 This is clear= ly the easiest solution.

2. Add one further ARC-Se= t with an explicit cv=3Dinvalid in order to 'close' the chain, usin= g the rule that Kurt has suggested.=C2=A0 This seems to have some benefit t= o me, but it's minimal.=C2=A0 It seems to wrap things up nicely, and it= means that all ARC chains have a well defined cv value, which makes testin= g a little easier.=C2=A0 However the cost is clearly added complexity, both= in the spec and implementations.=C2=A0 Is there any other tangible value t= o adding this final ARC-Set?=C2=A0 Does it help identify the failure point = in the chain?=C2=A0 Is there any other benefit?=C2=A0 Kurt, can you speak t= o this?

=3DGene


On Tue, Jun 20, 2017 at 7= :08 PM, Kurt Andersen (b) <kboth@drkurt.com> wrote:
Formerly, On Tue, Jun 20, 2017 at 1:44 PM, Seth Blank= =C2=A0<seth@sethblank.com>=C2=A0wrote:
=
On Tue, Jun 20, 2017 at 1:18 PM, Brandon Long=C2=A0= <blong@google.com>=C2=A0wrote:
The google implementation pre-dates cv=3Dinvalid, a= nd when I went to implement it, I couldn't find a good reason to do so,= nor a great bright-line rule for how to differentiate the two.

I don't see the point of trying to continue the chain= after a cv=3Dfail, so having a mechanism to do so, and the possibly compli= cated rules associated with it, seem pointless.

Are you suggesting that we remove cv=3Dinvalid= and leave everything under cv=3Dfail, because that's all that matters = to transmit downstream via the AS?

And then, if so= meone wants to really make it clear what happened, that could be stamped in= an A-R header like "arc=3Dfail (invalid ARC set at i=3D3: too many he= aders)"? Or do you think at this juncture, in the A-R "arc=3Dinva= lid" makes sense like "arc=3Dinvalid (missing AS for i=3D2)"= to differentiate ARC set failures from all other failures?

<= /div>
The alternative would be= to strip the arc-set entirely and start fresh.=C2=A0 That seems to have mi= nor benefit, so I didn't implement that, either, but I could imagine do= ing that if some useful case came up.=C2=A0 This is also strictly more usef= ul than trying to persist an invalid chain.=C2=A0 I could see a cv=3Drestar= t as an equivalent to cv=3Dnone for this type of case, I guess.
=

I think "restarting" an AR= C chain makes no sense. If the chain breaks, it's broken. Custody's= been lost and you don't get to show up with a new message.
<= br>
=C2=A0
On Tue, Jun 20, 2017 at 2:17 PM, Gene Shuman <geneshuman@gmail.com> replied:

<= /div>
Also, I don't think we should be relying on the contents of A= R header fields to make determinations about ARC chains.=C2=A0 It seems off= to me to have to parse all AR headers to look for an arc=3Dinvalid or what= ever to decide how to handle your ARC messages.=C2=A0

I agree with Seth that putting this in= fo into the AAR headers is not the right approach.=C2=A0
=C2=A0
This leaves us with the option of sticking cv=3Dinvalid= in the AS, and still the open question of if and how to generate the AS b= =3D tag.=C2=A0 Kurt's suggestion seems totally fine, although slightly = awkward.=C2=A0 Not sure I have any better ideas though.=C2=A0 What is the v= alue of creating this signature, as opposed to just not & relying solel= y on our AMS?=C2=A0 I guess we are signing our new AAR then, which is worth= something?

Yes, you= are signing your AAR and AMS (much like the i=3D1 ARC signer is doing) att= esting to the state of the message when you handled it. You can't reall= y say anything about previous handlers except that any traces of their work= has been thoroughly trashed.

--Kurt

<= /div>

--001a113ed096989a4405527e8e39-- From nobody Wed Jun 21 14:05:16 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB53D1274D2 for ; Wed, 21 Jun 2017 14:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smfwDI5dut4G for ; Wed, 21 Jun 2017 14:05:13 -0700 (PDT) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::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 D8AEF128B4E for ; Wed, 21 Jun 2017 14:05:12 -0700 (PDT) Received: by mail-ua0-x232.google.com with SMTP id j53so112327031uaa.2 for ; Wed, 21 Jun 2017 14:05:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=IoCDmgSXzYp8uKWESxu0dzMLsbONQ7bSIX6o9KfiBZg=; b=S8RNb9PuYxTvE6tBgPWACDdORrl2wpgoADl/C7RThY6z9UaO/Sb5mod/IZiWbKobpF gc5FiP4bdbgcidiwPp9F3In0Y/K7z6JwVUtqNyTtxcBBOoh7KQlpS3VQ9NScIpTYqLwg flwVWpdKvpBXqBty735KR86+Vqg1uMVAR3kBw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=IoCDmgSXzYp8uKWESxu0dzMLsbONQ7bSIX6o9KfiBZg=; b=lOFOqQ5kzTlygaS8+GK1oJYN2l7HNUlic1lX/+UhbvL+s4c6G0PT5VOFPwGVhCiJ/e 1zSa8+yq3vUZXQF79MzvR/YrF9HmDftKs1Sr1h6fAGi4gXbcf0myQSmH8N61au47g6YF EehJv6Z4GsEGumWldEgJIl2c/gWzty4pHbtWOav3hc6ptbquu3wVgj+FX/kEGUWZ1Ulo jSaOFGK/wyAK4jyknwLCyDNqW+Zc7ssvMUcBbDIIFDY5XFX5qdD9ZwZOgJEoL3E5lmVU DoCflz0qI79O0MvxgkaDUmDSC7LOicz0HvwqKs7fkjEsOp1IdA0cko+B3J9BqojZ+uJf 6+2w== X-Gm-Message-State: AKS2vOyUjPIkudE/PjVavWb6nz1LOb7+gH+LmgQEG/4o8O0fEedR6sTf sL5vh1W4x8CUkwUfkbNWrT12ZHP3cDLj X-Received: by 10.176.2.203 with SMTP id 69mr18736070uah.36.1498079111944; Wed, 21 Jun 2017 14:05:11 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.176.75.153 with HTTP; Wed, 21 Jun 2017 14:05:11 -0700 (PDT) In-Reply-To: References: From: "Kurt Andersen (b)" Date: Wed, 21 Jun 2017 14:05:11 -0700 X-Google-Sender-Auth: fwogYa6lT-G3F88z1VjZcyD17Jw Message-ID: To: Gene Shuman Cc: Seth Blank , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a113db8be508ee205527eb963" Archived-At: Subject: Re: [dmarc-ietf] ARC cv=invalid X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 21:05:15 -0000 --001a113db8be508ee205527eb963 Content-Type: text/plain; charset="UTF-8" On Wed, Jun 21, 2017 at 1:53 PM, Gene Shuman wrote: > > It seems we have two choices available to us upon receipt of an invalid > chain(which is defined as AS b= unable to be computed). > > 1. Simply stop adding further ARC headers. Put arc=fail(or invalid) in > the AR. Further recipients will detect that the chain is broken as well, > for the same reasons. This is clearly the easiest solution. > If you put arc=fail in an AR and then the next hop ignores and strips the AR (per spec), what good is it? 2. Add one further ARC-Set with an explicit cv=invalid in order to 'close' > the chain, using the rule that Kurt has suggested. This seems to have some > benefit to me, but it's minimal. It seems to wrap things up nicely, and it > means that all ARC chains have a well defined cv value, which makes testing > a little easier. However the cost is clearly added complexity, both in the > spec and implementations. Is there any other tangible value to adding this > final ARC-Set? Does it help identify the failure point in the chain? Is > there any other benefit? Kurt, can you speak to this? > A terminal ARC-set with cv=invalid is the only way to "close" a chain and avoid reprocessing by each and every subsequent hop as far as I can see. --Kurt --001a113db8be508ee205527eb963 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Jun 21, 2017 at 1:53 PM, Gene Shuman <geneshuman@gmail.com><= /span> wrote:

<= /div>
It seems we have two choices available to us upon receipt of an i= nvalid chain(which is defined as AS b=3D unable to be computed).
=
1. Simply stop adding further ARC headers.=C2=A0 Put arc=3Df= ail(or invalid) in the AR.=C2=A0 Further recipients will detect that the ch= ain is broken as well, for the same reasons.=C2=A0 This is clearly the easi= est solution.

If you put arc=3D= fail in an AR and then the next hop ignores and strips the AR (per spec), w= hat good is it?

2. Add one further ARC-Set with an explicit cv=3Dinvalid in o= rder to 'close' the chain, using the rule that Kurt has suggested.= =C2=A0 This seems to have some benefit to me, but it's minimal.=C2=A0 I= t seems to wrap things up nicely, and it means that all ARC chains have a w= ell defined cv value, which makes testing a little easier.=C2=A0 However th= e cost is clearly added complexity, both in the spec and implementations.= =C2=A0 Is there any other tangible value to adding this final ARC-Set?=C2= =A0 Does it help identify the failure point in the chain?=C2=A0 Is there an= y other benefit?=C2=A0 Kurt, can you speak to this?

A terminal ARC-set with cv= =3Dinvalid is the only way to "close" a chain and avoid reprocess= ing by each and every subsequent hop as far as I can see.

--Kurt
--001a113db8be508ee205527eb963-- From nobody Wed Jun 21 16:18:08 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 240DE126B72 for ; Wed, 21 Jun 2017 16:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wnPJFHbCTdEo for ; Wed, 21 Jun 2017 16:18:02 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::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 7C39E12426E for ; Wed, 21 Jun 2017 16:18:02 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id c189so94411oia.2 for ; Wed, 21 Jun 2017 16:18:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BT58codZcuHT/hpF2HxR3du/4UGdpIXvFLQKg9oeXG8=; b=pnn6hnGH1qLq9BhupGDEEblU0Rk0UhPsSgCZJmpLYq7lyAKi8SgahN8QIyK9LQ1URd A4dTFxPc9OndYA9FA/BctGCezrp8PypLkZ6+510Y9mVzveBnMZv+avdEyIsmVnfOVh0a dFooXq8xXyD67hW37B1tcWoEZoun/AKeNi2eXmaj1oWaCkIwyS6EcwD5ktptW9Cyraj7 aP9mXyA/SwQvBsW4MmnkZrnuL810BO6YsMVcgNgjILddOYUDXpZA6ZRA6wxYODJ5ZecR 2kri7woAmFiGy4yDwfjzisVA5yE74U5BfPf90uFSrG/6556RqGztvyUBkE1ZN0jLFO8C aS4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BT58codZcuHT/hpF2HxR3du/4UGdpIXvFLQKg9oeXG8=; b=d2gsaKeiu/KiqYX9e2Xayjg7/NjGcoXcv0BZHRZReDq9USxVRxwCwrj+//m+5YBHC5 EKSaSeeoa9ZU4ck8ZaLQmArhs0qp/5LfpWgLDohIimVIp/oGeh70b9pH6c/bclVjllzN HNsCaoB1l2jGOx0GnzxlAQaKD+H6xn0wo77S4ckj1I+P8Cxh+kjCcAYhGITiZRcePw2b f5wsPQ01aPxIzp61fJyloL61yYSg3DvU/Zni8mah8j2+0qEaD/e70AcYsfph5g838Wb4 CqYPGtIS4A3e6/X6NtTZtJBmRK+ys01e2nm+2fhQd4vgcPLNrdjorZ0OTBEvFIMl69UM 7ofQ== X-Gm-Message-State: AKS2vOyvD54XoOcqn7oGB0gsbJZeAaoS8wDiGoHwOufhjjbEJAkkNSLs p8Btsk74AMLthSMbDKjhG8nTP5OfaT9/FQg= X-Received: by 10.202.198.13 with SMTP id w13mr18598911oif.51.1498087081625; Wed, 21 Jun 2017 16:18:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.68.42 with HTTP; Wed, 21 Jun 2017 16:18:00 -0700 (PDT) In-Reply-To: References: From: Brandon Long Date: Wed, 21 Jun 2017 16:18:00 -0700 Message-ID: To: "Kurt Andersen (b)" Cc: Gene Shuman , "dmarc@ietf.org" , Seth Blank Content-Type: multipart/alternative; boundary="001a11c17ab858361205528094af" Archived-At: Subject: Re: [dmarc-ietf] ARC cv=invalid X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 23:18:05 -0000 --001a11c17ab858361205528094af Content-Type: text/plain; charset="UTF-8" On Wed, Jun 21, 2017 at 2:05 PM, Kurt Andersen (b) wrote: > On Wed, Jun 21, 2017 at 1:53 PM, Gene Shuman wrote: > >> >> It seems we have two choices available to us upon receipt of an invalid >> chain(which is defined as AS b= unable to be computed). >> >> 1. Simply stop adding further ARC headers. Put arc=fail(or invalid) in >> the AR. Further recipients will detect that the chain is broken as well, >> for the same reasons. This is clearly the easiest solution. >> > > If you put arc=fail in an AR and then the next hop ignores and strips the > AR (per spec), what good is it? > None, but what good is the broken chain? If all you're doing is avoiding reprocessing, that seems pretty minimal. > 2. Add one further ARC-Set with an explicit cv=invalid in order to 'close' >> the chain, using the rule that Kurt has suggested. This seems to have some >> benefit to me, but it's minimal. It seems to wrap things up nicely, and it >> means that all ARC chains have a well defined cv value, which makes testing >> a little easier. However the cost is clearly added complexity, both in the >> spec and implementations. Is there any other tangible value to adding this >> final ARC-Set? Does it help identify the failure point in the chain? Is >> there any other benefit? Kurt, can you speak to this? >> > > A terminal ARC-set with cv=invalid is the only way to "close" a chain and > avoid reprocessing by each and every subsequent hop as far as I can see. > Note that we don't have a temp fail, so cv=fail could just be due to DNS being unavailable, so the next hop may actually be able to validate the chain, assuming the failing hop was a non-modifying hop. Would you expect the next hop to also had a cv=fail arc header that only signs itself? I'm just fundamentally unclear what the utility of passing the fail state forward is. I understand the conceptual difference between cv=invalid and cv=fail, but I feel that's going to be heavily implementation specific unless we have very explicit rules to look for that are in the spec. Ie, our arc impl has on the order of 20 failure codes which are used to populate different error messages in the comment of the authres header, similar to our dkim impl. I can certainly go through the list and decide which ones are invalid vs fail, but someone else could make a different list. Our signer also has a handful of "these things must be right to sign this", but it generally assumes a valid chain, having a comprehensive view of of possibly invalid chains seems challenging. That said, there are plenty of cv=fail which have nothing to do with the chain structure, and could be dns or ams signature failures or whatever. That said, part of me goes back to the dkim mantra, a broken signature tells you nothing. A broken chain tells you nothing. Brandon --001a11c17ab858361205528094af Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jun 21, 2017 at 2:05 PM, Kurt Andersen (b) &l= t;kboth@drkurt.com> wrote:
On Wed, = Jun 21, 2017 at 1:53 PM, Gene Shuman <geneshuman@gmail.com> wrote:

It seems we have two choices available to us upon receipt of an inval= id chain(which is defined as AS b=3D unable to be computed).

=
1. Simply stop adding further ARC headers.=C2=A0 Put arc=3Dfail(= or invalid) in the AR.=C2=A0 Further recipients will detect that the chain = is broken as well, for the same reasons.=C2=A0 This is clearly the easiest = solution.

If you put arc= =3Dfail in an AR and then the next hop ignores and strips the AR (per spec)= , what good is it?

= None, but what good is the broken chain?=C2=A0 If all you're doing is a= voiding reprocessing, that seems pretty minimal.
=C2=A0
2. Add one further ARC-Set with an explicit cv=3Dinvalid = in order to 'close' the chain, using the rule that Kurt has suggest= ed.=C2=A0 This seems to have some benefit to me, but it's minimal.=C2= =A0 It seems to wrap things up nicely, and it means that all ARC chains hav= e a well defined cv value, which makes testing a little easier.=C2=A0 Howev= er the cost is clearly added complexity, both in the spec and implementatio= ns.=C2=A0 Is there any other tangible value to adding this final ARC-Set?= =C2=A0 Does it help identify the failure point in the chain?=C2=A0 Is there= any other benefit?=C2=A0 Kurt, can you speak to this?

A terminal ARC-se= t with cv=3Dinvalid is the only way to "close" a chain and avoid = reprocessing by each and every subsequent hop as far as I can see.

Note that we don't have a temp fail= , so cv=3Dfail could just be due to DNS being unavailable, so the next hop = may actually be able to validate the chain, assuming the failing hop was a = non-modifying hop.

Would you expect the next hop t= o also had a cv=3Dfail arc header that only signs itself?

I'm just fundamentally unclear what the utility of passing the = fail state forward is.

I understand the conceptual difference= between cv=3Dinvalid and cv=3Dfail, but I feel that's going to be heav= ily implementation specific unless we have very explicit rules to look for = that are in the spec.=C2=A0 Ie, our arc impl has on the order of 20 failure= codes which are used to populate different error messages in the comment o= f the authres header, similar to our dkim impl.=C2=A0 I can certainly go th= rough the list and decide which ones are invalid vs fail, but someone else = could make a different list.=C2=A0 Our signer also has a handful of "t= hese things must be right to sign this", but it generally assumes a va= lid chain, having a comprehensive view of of possibly invalid chains seems = challenging.

That said, there are plenty of cv=3Df= ail which have nothing to do with the chain structure, and could be dns or = ams signature failures or whatever.

That said, par= t of me goes back to the dkim mantra, a broken signature tells you nothing.= =C2=A0 A broken chain tells you nothing.

Brandon= =C2=A0
--001a11c17ab858361205528094af-- From nobody Wed Jun 21 18:19:58 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3D4412943B for ; Wed, 21 Jun 2017 18:19:51 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QxDAJlnTjhUU for ; Wed, 21 Jun 2017 18:19:49 -0700 (PDT) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::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 9956E129434 for ; Wed, 21 Jun 2017 18:19:49 -0700 (PDT) Received: by mail-ua0-x22d.google.com with SMTP id z22so2134183uah.1 for ; Wed, 21 Jun 2017 18:19:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=TnWRxKHYrUw0P+E4kGNwJYP9d0TITJAdAU3toqSSFZk=; b=I8UQKvJZ2ortancnQAGeJQEdYwdpODNOjQXqr0NSEkN2HuH5s1ZAijHSMghtUrhXIJ 6f6kTlrz/BoKcZuoMpEfFrAlKTs7tZm0tHmEPymoRKPnG3LMcSSeVR27GdLDquePfrfQ YHzjAUw5XsM2FeADHVEv17T3BQ9miCfDJkI8FPx9Pgwuc+G8MyHFwMdyhdmdLN27p7Du 7WkkGQG7YPF3n31En13syYscI/KoOiEo8784Qt4K4qAYcgF6LZxVV+5ITaddg8UbRpnW YYhyfgjfMexHdAeor3O+aty6GsivpgkiT2NHvNpn2WXMS84sfshhtr1AQZqAzwO633kD M0Pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=TnWRxKHYrUw0P+E4kGNwJYP9d0TITJAdAU3toqSSFZk=; b=UOgBi22/7KXTunVckSpq5jdXGsJAYNIyy7CRmPmjw3tmLWYCm/L/BrlG4rrYJMjbKN 4yocJ22x8a8QUpo20NIXiSC56aDltU+DlDV3Sb53Y38WsRc5Zm5Wn2NpdcOhAX0CPDv7 icWTNFL4emtCZd709Nq7+1SoG5IIaezttk72ZYR2khkq1POHqTjHfQzhl/QX9fpYXNmD L6B+aYVzj8t6OmjATbPTaJON4r7tPocQ0tKTlR5LN8NvOrlsH1WTyAk2Zc6Fa3XW0GC0 DuITfDIvrdW3yWkXPnnkvFrviECAj4EGtKkBH3NAyDD/ugvziRbxsjzwjiDjo2tUzy/X WrtA== X-Gm-Message-State: AKS2vOxdcfYMiInUh66v0agmM2CObQsVqq1tqOX3Y1a0NCGHy3fgkPlo /+12Bo4uM35cLLEgy4Lfof2OmK2ydqmFrHU= X-Received: by 10.159.48.214 with SMTP id k22mr33049uab.31.1498094388230; Wed, 21 Jun 2017 18:19:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.152.80 with HTTP; Wed, 21 Jun 2017 18:19:27 -0700 (PDT) In-Reply-To: References: From: Seth Blank Date: Wed, 21 Jun 2017 18:19:27 -0700 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="f403045dada2da2f6d055282478a" Archived-At: Subject: Re: [dmarc-ietf] ARC cv=invalid X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 01:19:52 -0000 --f403045dada2da2f6d055282478a Content-Type: text/plain; charset="UTF-8" On Wed, Jun 21, 2017 at 4:18 PM, Brandon Long wrote: > > If you put arc=fail in an AR and then the next hop ignores and strips the >> AR (per spec), what good is it? >> > > None, but what good is the broken chain? If all you're doing is avoiding > reprocessing, that seems pretty minimal. > A final evaluation status has merit, but it's not avoiding reprocessing, it's transmitting and signing your name to a definitive position that the chain is dead as you saw it. An ARC chain is a chain of custody, and if custody is lost, that status shouldn't be a hot potato - it should be committed to the chain. And then per the logic in the spec, no one else touches the chain after the chain is declared dead. > A terminal ARC-set with cv=invalid is the only way to "close" a chain and >> avoid reprocessing by each and every subsequent hop as far as I can see. >> > > Note that we don't have a temp fail, so cv=fail could just be due to DNS > being unavailable, so the next hop may actually be able to validate the > chain, assuming the failing hop was a non-modifying hop. > This doesn't scan for several reasons: 1) if you stamp cv=fail, the next hop cannot validate the chain, as per spec it would see cv=fail and stop 2) even if it were within spec, if I stamp fail but modify the message, the chain is now unrecoverable 3) if cv=fail is NOT stamped, and I go about my business, then the next hop will try to recover the chain (and maybe it will recover from a tempfail), but the chain will likely still not validate because the AMS will not validate because I've most likely modified the message in a breaking manner I think Kurt's original point stands. cv=invalid is the only way to terminate a chain with a broken arc set. Seth > --f403045dada2da2f6d055282478a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Jun 21, 2017 at 4:18 PM, Brandon Long <blong@google.com> = wrote:
If you put arc=3Dfail in an AR and then the next hop ignores and str= ips the AR (per spec), what good is it?

None, but what good is the broken chain?=C2=A0 = If all you're doing is avoiding reprocessing, that seems pretty minimal= .

A final evaluatio= n status has merit, but it's not avoiding reprocessing, it's transm= itting and signing your name to a definitive position that the chain is dea= d as you saw it.

An ARC chain is a chain of custod= y, and if custody is lost, that status shouldn't be a hot potato - it s= hould be committed to the chain. And then per the logic in the spec, no one= else touches the chain after the chain is declared dead.
=C2=A0<= /div>
A terminal ARC-set with cv= =3Dinvalid is the only way to "close" a chain and avoid reprocess= ing by each and every subsequent hop as far as I can see.

Note that we don't have a temp fail, = so cv=3Dfail could just be due to DNS being unavailable, so the next hop ma= y actually be able to validate the chain, assuming the failing hop was a no= n-modifying hop.

Th= is doesn't scan for several reasons:
1) if you stamp cv=3Dfai= l, the next hop cannot validate the chain, as per spec it would see cv=3Dfa= il and stop
2) even if it were within spec, if I stamp fail but m= odify the message, the chain is now unrecoverable
3) if cv=3Dfail= is NOT stamped, and I go about my business, then the next hop will try to = recover the chain (and maybe it will recover from a tempfail), but the chai= n will likely still not validate because the AMS will not validate because = I've most likely modified the message in a breaking manner
I think Kurt's original point stands. cv=3Dinvalid is the = only way to terminate a chain with a broken arc set.

Seth

--f403045dada2da2f6d055282478a-- From nobody Fri Jun 23 15:17:54 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67B68129AB0 for ; Fri, 23 Jun 2017 15:17:52 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6H9T-6MFcDvG for ; Fri, 23 Jun 2017 15:17:50 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::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 B163C129AE9 for ; Fri, 23 Jun 2017 15:17:45 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id p187so32536056oif.3 for ; Fri, 23 Jun 2017 15:17:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=eD/c2rUyfWxDxh3+P8JDW1UtFRn/fAbLClWDC7uWVjQ=; b=WNZUka4229Jc+2znqQjTkbHSevj0nWa5xHXwfF3EWV1exThDTU2zTAtA2UrpRPRO41 6ehzy89BhWj+O4GT31+PcKRYLsnnPWTgoO65FrFLw/1jI/pC0QNJZAvzlyw1aFUssDvO gLXrVZNWjH4UeVBnqE8mfMMkSI2Jx69fBhIQ2Y8gbrv4njonARQ4Bi8Jv7McTe9m3YSY 4QhIEqGMRI5PVcEEA0a90iuLAy9bUbVDALIyPQ5rH2o12vJLccAfn033o04UqEKMHFTq raRukK4yS+h7H4lNja1zPeDNXviqli3m52lWBXj2C/TvQQWy++I+k1n1vvYAVLxxxb7l qazg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=eD/c2rUyfWxDxh3+P8JDW1UtFRn/fAbLClWDC7uWVjQ=; b=Wh6kkwomZ4JdwCNEs20KAz4LdUIAPqghiHdBXsmtcPqK2FvqXjjeTA4QQGiYU4TQ8N aNxJCk/1HotF5N6AccrNAUZ4pl3Zpoz0BK92zR7rd2UyfRRmHYixYmb5LDQHqlncu1R8 ncfkNaAqAlQsdFgA/pAgtqg7aCzdszQp0kVCRNtAcc9dfQuNcQmPOc0N1vThpJm0eH/W /sXQuHlvkHnvaNiYm0/7YNtMX9kAGYCXtsOGaR7RKsPHncyRiOJ3HefXRYQIg2nNRczs vo27euQilqZMOsTugMb4kV29QacGmS4ek9OMNjtsHFUYh4wcJBPn9swwyMh/1pd82SYK VyVQ== X-Gm-Message-State: AKS2vOyAJtS+qF2V4QichqCDwaAW+cwKd+Bg0LopqAnKj5arS1p8/1Tf 1bmiecIr1av1/UdHg1ZxA+4vK7C09PL+mNA= X-Received: by 10.202.166.203 with SMTP id t72mr6452090oij.40.1498256264620; Fri, 23 Jun 2017 15:17:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.68.42 with HTTP; Fri, 23 Jun 2017 15:17:44 -0700 (PDT) From: Brandon Long Date: Fri, 23 Jun 2017 15:17:44 -0700 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a1147bd486fec6f0552a7f8db" Archived-At: Subject: [dmarc-ietf] selectors in AAR. X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 22:17:52 -0000 --001a1147bd486fec6f0552a7f8db Content-Type: text/plain; charset="UTF-8" On Wed, May 31, 2017 at 10:07 PM, Murray S. Kucherawy wrote: > > > On Thu, May 4, 2017 at 4:19 PM, Peter Goldstein > wrote: > >> So as a consumer of these reports I'd definitely like to see a structured >> value with as much information as possible. >> > [snip] > >> - DKIM Selectors - Unfortunately we probably can't get the DKIM >> signature selectors (because they aren't generally recorded in the >> Authentication-Results, and so won't be available to downstream hops), but >> if we can get them, that would be very helpful. >> >> > They could be added to A-R, in theory, but they're not really > user-consumable which is why they were originally omitted. > Thinking some more on this while thinking about the format of the DMARC report, I think we should consider it. The AuthRes header was meant to help pass information to the end user (or their mail client) from their own mail system. The AAR header is meant to pass information from each hop to all of the following hops, and meant mostly (at this point) to inform the DMARC handling of the message. And part of the point of DMARC is informing admins/domain owners on how their mail is being evaluated to help them get to stricter levels. It's pretty obvious that for the domains of larger organizations, one can end up with many sources of email. We've taken a pretty strong stance internally at Google that we don't give out DKIM keys, the mail has to relay through us to be signed, but given the blank stares we seem to get from ESPs when we say that, I don't think that's the standard at all. So, different selectors are a really good indicator, possibly more so than IPs, of where mail comes from. But neither IPs nor selectors are included in the AuthRes or AAR headers. Now, the selector is still there if the DKIM signature wasn't removed. Though, it's often removed when messages are deliberately rewritten (mailing lists), because there still exists receivers which reject mail based on broken signatures. IPs are preserved in Received headers, but extracting them and knowing ADMD boundaries and such becomes kind of complicated, compared to the much simpler usage of including them as a propspec for SPF. My point is, AAR is computer consumable authenticated forwarded information. This information may not inform the DMARC result directly, but being able to pass it to the aggregate report seems pretty useful. Brandon --001a1147bd486fec6f0552a7f8db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, May 31, 2017 at 10:07 PM, Murray S. Kucherawy <superuser@gmail.com> wrote:

On Thu, May 4, 2017 at 4:19 PM, Peter Goldstein <peter@valimail.com&= gt; wrote:
So as = a consumer of these reports I'd definitely like to see a structured val= ue with as much information as possible.

[snip]=C2=A0
  • DKIM Selectors - Unfortunately we probably can't get the DKIM= signature selectors (because they aren't generally recorded in the Aut= hentication-Results, and so won't be available to downstream hops), but= if we can get them, that would be very helpful.

They could be added to A-R, in theory, but the= y're not really user-consumable which is why they were originally omitt= ed.

Thinking so= me more on this while thinking about the format of the DMARC report, I thin= k we should consider it.

The AuthRes header was me= ant to help pass information to the end user (or their mail client) from th= eir own mail system.

The AAR header is meant to pa= ss information from each hop to all of the following hops, and meant mostly= (at this point) to inform the DMARC handling of the message.
And part of the point of DMARC is informing admins/domain owner= s on how their mail is being evaluated to help them get to stricter levels.=

It's pretty obvious that for the domains of l= arger organizations, one can end up with many sources of email.=C2=A0 We= 9;ve taken a pretty strong stance internally at Google that we don't gi= ve out DKIM keys, the mail has to relay through us to be signed, but given = the blank stares we seem to get from ESPs when we say that, I don't thi= nk that's the standard at all.

So, different s= electors are a really good indicator, possibly more so than IPs, of where m= ail comes from.=C2=A0 But neither IPs nor selectors are included in the Aut= hRes or AAR headers.

Now, the selector is still th= ere if the DKIM signature wasn't removed.=C2=A0 Though, it's often = removed when messages are deliberately rewritten (mailing lists), because t= here still exists receivers which reject mail based on broken signatures.

IPs are preserved in Received headers, but extracti= ng them and knowing ADMD boundaries and such becomes kind of complicated, c= ompared to the much simpler usage of including them as a propspec for SPF.<= /div>

My point is, AAR is computer consumable authentica= ted forwarded information.=C2=A0 This information may not inform the DMARC = result directly, but being able to pass it to the aggregate report seems pr= etty useful.

Brandon=C2=A0

--001a1147bd486fec6f0552a7f8db-- From nobody Fri Jun 23 17:14:32 2017 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 71C4F12EB43; Fri, 23 Jun 2017 17:07:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: dmarc@ietf.org, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149826283246.7840.12906346366512934622.idtracker@ietfa.amsl.com> Date: Fri, 23 Jun 2017 17:07:12 -0700 Archived-At: Subject: [dmarc-ietf] dmarc - Requested session has been scheduled for IETF 99 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 00:07:15 -0000 Dear Barry Leiba, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. dmarc Session 1 (1:00:00) Thursday, Morning Session I 0930-1200 Room Name: Berlin/Brussels size: 100 --------------------------------------------- Special Note: 09:30-10:30 Request Information: --------------------------------------------------------- Working Group Name: Domain-based Message Authentication, Reporting & Conformance Area Name: Applications and Real-Time Area Session Requester: Barry Leiba Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 30 Conflicts to Avoid: First Priority: jmap dcrup uta dispatch People who must be present: Ned Freed Barry Leiba Alexey Melnikov Tim Draegen Kurt Andersen Resources Requested: Experimental Room Setup (U-Shape and classroom, subject to availability) Special Requests: --------------------------------------------------------- From nobody Mon Jun 26 14:26:17 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7F5129AF4 for ; Mon, 26 Jun 2017 14:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.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 G6dgfLsc-fc8 for ; Mon, 26 Jun 2017 14:26:12 -0700 (PDT) Received: from mail-yb0-x234.google.com (mail-yb0-x234.google.com [IPv6:2607:f8b0:4002:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0763129B02 for ; Mon, 26 Jun 2017 14:26:12 -0700 (PDT) Received: by mail-yb0-x234.google.com with SMTP id b81so4239245yba.2 for ; Mon, 26 Jun 2017 14:26:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HXLc4U98LpnKLqTMzclswDBxdUXv7QqfyofTd1k4GJY=; b=EOjPq1WByRRCCsbW55rrQybjV4yBOi8fzuDbtpRqDk5DEYDJX5NamUi/uegtatAZXn iyA/zrFqBEZnVxoz56jks6TWU+/7h1AACVsC6lyRm58w/JscwAHi/3eyqEnA1MTIbf8e ja8E2BUgT+AoDyox6IN80bmqsCg+B2R1IU3d1t8ZS26AA1N1B6rt/ExJN2nnor+pmN1k POicyM/hf0K/nCHU+iezuC7bm9oCDjNE6RenREnBiGlFkq3HhgW7upQ0rkjItop3sGF2 8xAi1tbTVwGzXr60faSQjc2ejOMEM9IlxeCLZNYOhiNX8f8i7ptBJieXJyOoWzASM5c8 /yfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HXLc4U98LpnKLqTMzclswDBxdUXv7QqfyofTd1k4GJY=; b=G6XItMtQH7xjQbETS99i8artIQphfGFgFnb/8ID1Bp8xYtsQDjaZ8RtyI4lFU8kL9D cK/RbayQri/Cm32XQuCUTE+iBiHkm3jx2M9X1gxZo39DpaRmVLdUX4ddQ99ZAVa3/odl ma19czwhF3uY5ATcI61pXrYLWEgLHkH8yPPOme6z93utFFZiHIZUrNxH3XOBaFX0FQut IdVjLpkblMkbHX94yGnT1cnVuBzfkqqg34I18XfknMdvVoeqyG2wkgGl1Po3viAArg9H +FgeTtDpMMOQrQYLE+u6OIlMJyAS0JbsTorB8qT5JdKhJ5JGR7raFDgm5pY4AI0R+3ps +6pg== X-Gm-Message-State: AKS2vOxA1qrtBIVmTQBkyF0kQi86aLU1sXY+LS6WYrVZGRMlFXK6y/lT XNcAH5yYubpsoiUSsnX5sqGo2afvjXlb X-Received: by 10.37.118.19 with SMTP id r19mr1676963ybc.136.1498512371763; Mon, 26 Jun 2017 14:26:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.61.3 with HTTP; Mon, 26 Jun 2017 14:26:11 -0700 (PDT) In-Reply-To: References: From: Gene Shuman Date: Mon, 26 Jun 2017 14:26:11 -0700 Message-ID: To: Brandon Long Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a114bb40e9c5ebb0552e39902" Archived-At: Subject: Re: [dmarc-ietf] selectors in AAR. X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 21:26:16 -0000 --001a114bb40e9c5ebb0552e39902 Content-Type: text/plain; charset="UTF-8" I definitely support this idea, as having the selectors available is extremely useful to us as part of service authentication. And putting them into the AR headers seems to be the appropriate solution. I guess the next question is how we would actually go about sending this information. Something like header.s? =Gene On Fri, Jun 23, 2017 at 3:17 PM, Brandon Long wrote: > On Wed, May 31, 2017 at 10:07 PM, Murray S. Kucherawy > wrote: > >> >> >> On Thu, May 4, 2017 at 4:19 PM, Peter Goldstein >> wrote: >> >>> So as a consumer of these reports I'd definitely like to see a >>> structured value with as much information as possible. >>> >> > [snip] > >> >>> - DKIM Selectors - Unfortunately we probably can't get the DKIM >>> signature selectors (because they aren't generally recorded in the >>> Authentication-Results, and so won't be available to downstream hops), but >>> if we can get them, that would be very helpful. >>> >>> >> They could be added to A-R, in theory, but they're not really >> user-consumable which is why they were originally omitted. >> > > Thinking some more on this while thinking about the format of the DMARC > report, I think we should consider it. > > The AuthRes header was meant to help pass information to the end user (or > their mail client) from their own mail system. > > The AAR header is meant to pass information from each hop to all of the > following hops, and meant mostly (at this point) to inform the DMARC > handling of the message. > > And part of the point of DMARC is informing admins/domain owners on how > their mail is being evaluated to help them get to stricter levels. > > It's pretty obvious that for the domains of larger organizations, one can > end up with many sources of email. We've taken a pretty strong stance > internally at Google that we don't give out DKIM keys, the mail has to > relay through us to be signed, but given the blank stares we seem to get > from ESPs when we say that, I don't think that's the standard at all. > > So, different selectors are a really good indicator, possibly more so than > IPs, of where mail comes from. But neither IPs nor selectors are included > in the AuthRes or AAR headers. > > Now, the selector is still there if the DKIM signature wasn't removed. > Though, it's often removed when messages are deliberately rewritten > (mailing lists), because there still exists receivers which reject mail > based on broken signatures. > > IPs are preserved in Received headers, but extracting them and knowing > ADMD boundaries and such becomes kind of complicated, compared to the much > simpler usage of including them as a propspec for SPF. > > My point is, AAR is computer consumable authenticated forwarded > information. This information may not inform the DMARC result directly, > but being able to pass it to the aggregate report seems pretty useful. > > Brandon > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --001a114bb40e9c5ebb0552e39902 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I definitely support this idea, as having the selectors av= ailable is extremely useful to us as part of service authentication.=C2=A0 = And putting them into the AR headers seems to be the appropriate solution. = =C2=A0

I guess the next question is how we would actuall= y go about sending this information.=C2=A0 Something like header.s?

=3DGene

On Fri, Jun 23, 2017 at 3:17 PM, Brandon Long <blong@go= ogle.com> wrote:
On Wed, May = 31, 2017 at 10:07 PM, Murray S. Kucherawy <superuser@gmail.com> wrote:


On Thu, May 4, 201= 7 at 4:19 PM, Peter Goldstein <peter@valimail.com> wrote:
So as a consumer of these= reports I'd definitely like to see a structured value with as much inf= ormation as possible.

[snip]=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
  • DKIM Selectors - Unf= ortunately we probably can't get the DKIM signature selectors (because = they aren't generally recorded in the Authentication-Results, and so wo= n't be available to downstream hops), but if we can get them, that woul= d be very helpful.

T= hey could be added to A-R, in theory, but they're not really user-consu= mable which is why they were originally omitted.

Thinking some more on this while thinking= about the format of the DMARC report, I think we should consider it.
=

The AuthRes header was meant to help pass information t= o the end user (or their mail client) from their own mail system.

The AAR header is meant to pass information from each hop t= o all of the following hops, and meant mostly (at this point) to inform the= DMARC handling of the message.

And part of the po= int of DMARC is informing admins/domain owners on how their mail is being e= valuated to help them get to stricter levels.

It&#= 39;s pretty obvious that for the domains of larger organizations, one can e= nd up with many sources of email.=C2=A0 We've taken a pretty strong sta= nce internally at Google that we don't give out DKIM keys, the mail has= to relay through us to be signed, but given the blank stares we seem to ge= t from ESPs when we say that, I don't think that's the standard at = all.

So, different selectors are a really good ind= icator, possibly more so than IPs, of where mail comes from.=C2=A0 But neit= her IPs nor selectors are included in the AuthRes or AAR headers.

Now, the selector is still there if the DKIM signature wasn= 't removed.=C2=A0 Though, it's often removed when messages are deli= berately rewritten (mailing lists), because there still exists receivers wh= ich reject mail based on broken signatures.

IPs ar= e preserved in Received headers, but extracting them and knowing ADMD bound= aries and such becomes kind of complicated, compared to the much simpler us= age of including them as a propspec for SPF.

My po= int is, AAR is computer consumable authenticated forwarded information.=C2= =A0 This information may not inform the DMARC result directly, but being ab= le to pass it to the aggregate report seems pretty useful.

Brandon=C2=A0


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


--001a114bb40e9c5ebb0552e39902-- From nobody Thu Jun 29 08:26:52 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 157E7131472 for ; Thu, 29 Jun 2017 08:26:50 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 EcU7pKp5rYW3 for ; Thu, 29 Jun 2017 08:26:47 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 548A513146B for ; Thu, 29 Jun 2017 08:26:47 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id 63so38483478ywr.0 for ; Thu, 29 Jun 2017 08:26:47 -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=dnO9oegOtRstJf5jiATRnCrHb+1qoOIMGCDrjU4r90s=; b=OVcQ85bJaTKiPHRQYvqzXfsfKkOl8MHpvJr6M01z2KO9lecb6b8pj0W/5pj3joGb4I DXoQjf+R1Gd5+t2UG+Ow2/ME9Zz8+LGbULnrxGUpgOH0Mke5eE2ppFOkQt1klrggetoU OyifNQbzdMSlXuHMzd69nGmg7PyKUpzUQuiLk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=dnO9oegOtRstJf5jiATRnCrHb+1qoOIMGCDrjU4r90s=; b=L7bYfpK5PJq9LMYmCTOIIUKdP2BXxLeSTqbPkfdOdbGI2uY22IHumGRympUyvtQEP2 7eCZkyX+KUsFbtFyH0MfkX3hX3wZhE7cHHKft2bXbgL6yIHoxCJnv8yKMCR9uXcqIWzE 8y5h9KNOvElw4Q4dTnD/UERdYmKsRBxq6CW1O0UbULRsfCvNxHUHML53cjxpbYVo5Zdm DlD5WYtPgVyIdmJDBN70XaVZDABQLVnWCSI5iG99w2/zADBtyyJBb5WujT0ZcyzSrWBM Gvbriqw6EuscMFtYGoQNkx+VY0XbuqToiM7gZyx37H+ZADldMv6xpgr3dm/3tkB4xWyZ 5R4w== X-Gm-Message-State: AKS2vOztqcTMaegLtouL5geGdQa0ZBFis1tDMxkMtPBUdN5Z5JPEz1cb pZhd5JeopM8ijM6UepoDFQ== X-Received: by 10.13.220.69 with SMTP id f66mr12118239ywe.316.1498750006151; Thu, 29 Jun 2017 08:26:46 -0700 (PDT) Received: from [192.168.0.18] (208-104-133-98.brvd.dsl.dyn.comporium.net. [208.104.133.98]) by smtp.gmail.com with ESMTPSA id g5sm2145419ywa.16.2017.06.29.08.26.45 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 29 Jun 2017 08:26:45 -0700 (PDT) From: Tim Draegen Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Thu, 29 Jun 2017 11:26:44 -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] Usage Guide interview (ESP) with Alwin de Bruin @ Measure Mail X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 15:26:50 -0000 [This email is the first of a series described here: = https://www.ietf.org/mail-archive/web/dmarc/current/msg03671.html Thanks = much to Alwin for being the first to volunteer and to help smooth out = the rough spots.] Background: Measure Mail is a Netherlands-based Email Service Provider = operating since 2001. Within Measure Mail Alwin is responsible for = operations. The company strives to remain up to date with changes in the = email ecosystem. Outside of Measure Mail Alwin is heavily involved in = Netherlands standardization communities to establish technology = guidelines for ESPs and government email requirements. Alwin has = advocated for DMARC within Netherlands circles since its public release. Experience: =46rom company perspective, making customers recognizable to the = recipients of email is primary. Two points: =E2=80=A2 Cannot interfere with existing email infrastructure. =E2=80=A2 Cannot settle for =E2=80=9Csent on behalf of=E2=80=9D = in a UI, which lead to the required use of sub-domains. Customers are = provided with DNS settings to allow Measure Mail to send email using a = customer=E2=80=99s sub-domain. Use of sub-domains allows us to make email appear to come from customer, = including addresses, embedded links, and other branding. Ensuring that = all domain identifiers in an email are aligned helps make email obvious = and easy to deliver. Customers accept this explanation as it is easy to = understand. Sending DNS settings to customers can be quite complex. However, the = requirement to implement DNS-changes leads to better customers in terms = of us servicing slightly more technically savvy customers, but also = tends to exclude very small businesses that do not have resources to = deal with DNS configuration. Making DNS changes easier for customers is something we=E2=80=99ve = focused on over the past few years. In this way, we=E2=80=99ve arrived = at requiring DNS changes only once during onboarding. This appears to be = a trend among the market. Customer use of DMARC policies has had little impact on our service. For = the sub-domains that customers provide to us, we originally placed DMARC = records to help monitor email delivery. By design we see little impact = to our service due to customers publishing DMARC policies. When customers publish their own DMARC records, we ask our customers to = provide us with their reporting address so that we can forward = sub-domain specific reports to the customer. In this way the customer = gets a complete picture. Otherwise the customer might not see the = complete picture. Strict vs Relaxed mode: haven=E2=80=99t run into any issues, but mainly = because we work with customers early. Plus, we have DMARC records in = place at sub-domain which we operate in. SPF considerations: we maintain an include that customers use. By doing = this, we can maintain the real SPF record without requiring customer = changes. Also, we use dedicated sub-domains and so configuration avoids = top-level SPF record issues. DKIM considerations: key rotation appears to be relatively new in the = market. Our own infrastructure is ready for key rotation. Customers are = being upgraded to use newer functionality that allows for no-touch key = rotation. But, this is a process where older customers need to perform = DNS changes to get to the =E2=80=9Cno more touch=E2=80=9D world. Key sizes: we=E2=80=99ve always used 1024 bit keys, with our newer = infrastructure using 2048 keys. Once customers are on newer = infrastructure, the upgrade to 2048 bit keys is transparent. DKIM options: we use default DKIM settings when possible. Default = headers that are signed mirror what is published in DKIM spec. Simple = body canonicalization. DKIM timestamp included. Policy implications: we discuss DMARC with customers if the subject = comes up, and when customers are onboarded. People are guided to the = Wikipedia articles on DMARC to learn about the basic stuff. DKIM = sometimes requires additional explanation. Other thoughts on Domain Owner & ESP interaction? We=E2=80=99re thinking = of implementing DMARC reporting for the bounce messages that we receive = to help communicate status to bounce-originating organization. Overall, we don=E2=80=99t have issues with DMARC. This is likely due to = our pre-DMARC understanding that domain alignment is common sense = approach to sending customer email. (end) From nobody Thu Jun 29 22:09:09 2017 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 907A1127863; Thu, 29 Jun 2017 22:09:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dmarc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149879934052.4573.15071593260685629727@ietfa.amsl.com> Date: Thu, 29 Jun 2017 22:09:00 -0700 Archived-At: Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-05.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 05:09:01 -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 : Authenticated Received Chain (ARC) Protocol Authors : Kurt Andersen Brandon Long Steven Jones Filename : draft-ietf-dmarc-arc-protocol-05.txt Pages : 45 Date : 2017-06-29 Abstract: Authenticated Received Chain (ARC) permits an organization which is creating or handling email to indicate its involvement with the handling process. It defines a set of cryptographically signed header fields in a manner analagous to that of DKIM. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Changes in the message that might break DKIM can be identified through the ARC set of header fields. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-protocol/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-05 https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-arc-protocol-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-arc-protocol-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 30 06:32:49 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5D06129AC6 for ; Fri, 30 Jun 2017 06:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PS4nQ71Os-L7 for ; Fri, 30 Jun 2017 06:32:46 -0700 (PDT) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89A22129AA8 for ; Fri, 30 Jun 2017 06:32:46 -0700 (PDT) Received: by mail-ua0-x233.google.com with SMTP id z22so75547018uah.1 for ; Fri, 30 Jun 2017 06:32: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:from:date:message-id :subject:to; bh=4JiYz+a0P67Kd+AKHpX7z0UUHHpXN48k6Okf5ZikmcM=; b=EPCwXJ+fht76DJphxNz6NQSU7RA5YzSDmi6eW3CIZhAWZc7MdwFkn4JAlAngSglKmW JVmC3KthIxJI4KeI3SsDaeZk6UzPDjZf4JVlyZNWGJ1RfykOjMRnbi0tlSUAs7CiI5bS fVcl1nhCn13ExtcmVjbfAyGkbAkxedFXlc5ro= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=4JiYz+a0P67Kd+AKHpX7z0UUHHpXN48k6Okf5ZikmcM=; b=m+V3Zyfpzfh75IcyeXYEXit16muNS15/bKqsNstCiCExR6uMZ1BURPgLwyoY/uLkft aY+pEsnL7pB/cGWRggnSzGpt2X2NIueoRxtiJP0FGdu1LPd4XvsGdahmSZI4YFnbLzCf k5cqMTBPiozc2MnCQlNvDyfL9RYqGgw0U556W0/Ovd81gf4BydKd1BHHFpBV+KVvaESD pflD9yChlE2PW3IOfmQhRHnISKWkmgf6W+E10s1L8m44glx1Zl0QQ755fKblGr3Ejm2d min1CJ0ik/nJG4tTlXExtE1qaTTtD1hyCbkfF/qlmF8isIASFEbS16UzKAgF96hidsHL Ocsg== X-Gm-Message-State: AKS2vOyG+YQjx1qGvPOX4Q4k/RlQrDfJq1bRCf6dULZhgKt+EOVw2p5o sQtnZhdwcPsfyNfAtqNon6Ycm5yDHiP9RgI= X-Received: by 10.176.2.203 with SMTP id 69mr13351247uah.36.1498829565369; Fri, 30 Jun 2017 06:32:45 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.159.34.49 with HTTP; Fri, 30 Jun 2017 06:32:44 -0700 (PDT) In-Reply-To: <149879934052.4573.15071593260685629727@ietfa.amsl.com> References: <149879934052.4573.15071593260685629727@ietfa.amsl.com> From: "Kurt Andersen (b)" Date: Fri, 30 Jun 2017 06:32:44 -0700 X-Google-Sender-Auth: bD-91afcxLcm0x3SPBtx85qOTw8 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a113db8bed2b01705532d7386" Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-05.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 13:32:48 -0000 --001a113db8bed2b01705532d7386 Content-Type: text/plain; charset="UTF-8" On Thu, Jun 29, 2017 at 10:09 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Authenticated Received Chain (ARC) Protocol (-05) > Date : 2017-06-29 > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-protocol/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-05 > https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-arc-protocol-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-arc-protocol-05 The changes in this version of the document are limited to removing the "cv=invalid" option, collapsing it into "cv=fail" and adding a little explanatory text in a couple of places regarding the handling and interpretation of "fail"ed chains for subsequent mediators. This change came from a dialog on the list last week and a follow-up verbal discussion. Please let me know if there are questions about it. --Kurt --001a113db8bed2b01705532d7386 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Jun 29, 2017 at 10:09 PM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Authenticated Received Chain (ARC) Protocol (-05)
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 2017-06-29

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc= /draft-ietf-dmarc-arc-protocol/

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

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

The changes in this version of the document are limited to removing= the "cv=3Dinvalid" option, collapsing it into "cv=3Dfail&qu= ot; and adding a little explanatory text in a couple of places regarding th= e handling and interpretation of "fail"ed chains for subsequent m= ediators.

This change came from a dialog on the li= st last week and a follow-up verbal discussion. Please let me know if there= are questions about it.

--Kurt

--001a113db8bed2b01705532d7386-- From nobody Fri Jun 30 14:37:39 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2D4212EC49 for ; Fri, 30 Jun 2017 14:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=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 3NdLIM-2jjcu for ; Fri, 30 Jun 2017 14:37:26 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1272212EACC for ; Fri, 30 Jun 2017 14:37:26 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id p187so102086215oif.3 for ; Fri, 30 Jun 2017 14:37:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=vSrhQ7seYADo91YR+MCu57eF8BT32acJvp/a8M6dmKg=; b=iVO5DScFvQ7cm3xIHnvbs8QxJ0nqlmc9aZ6Fn6nk/+nywa1mTJCQujZiT6XW59+UHz POrop7dWjaPkLFjYwjLGYXXRMOb4ogFkaxiK0hRWGxnytPmhZnbHWdOCqyYHkogebNze FUpSN8WiCINRZg6Cjwu/bMklrGR86Yn8Gt20fW30INjdUKmPQBfoUvOD3mTq1qgyr/LE ykYEcTGXIIZRc8qclKKIuu21jgIDq+485Dny2ZrjdH0nPwFGIV4CzlLEdp/4MAq5otQK mvfFex8QaMoHkn0iN1rBWzJ/nIVIEWwfueJp6oRKziaN9jJ4RIECIghuGvATj4BfM6Uz Z8kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=vSrhQ7seYADo91YR+MCu57eF8BT32acJvp/a8M6dmKg=; b=JoddnUl18RTBd32zBHItMJs8zeC5x7zfaqzvwkw69Af8c5UKbxFG3FNV+NknRiTGFH v8EDxlwkqLcvbQ2vq88PShzSdY/T9PFk23AJc54J1Ia+YJPM0ZpYAXHOTTaf1R+Nlk2O yOfNwhRZeMyvPmlMjnXSPE2yUfS/MTqbtltQre7+CjzxYKPnWQC2zqP6SSiCC00nKXYG VoDxEgEvT7FVz86LdKgj2H0d3tGJOEaB43ajeu0BO1Peocm3cu2tFQNkuWZZFLG46fg8 uTZh6ffJzrk5kXV6Oj7f/iJo2AVXmBPnTVPHXDujmJog/Sv/iQ1CG6UhchepUDhbdGlI oEDQ== X-Gm-Message-State: AIVw1100ZWKlPiwfqhU/JPgqTZflViZI9MkttXVyy+SbONC/hmmNka6b 1QKKxiyOZyTWheTMvgJoibdzaSA/ymBUh+Q= X-Received: by 10.202.230.139 with SMTP id d133mr6068605oih.110.1498858644809; Fri, 30 Jun 2017 14:37:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.131.17 with HTTP; Fri, 30 Jun 2017 14:37:24 -0700 (PDT) In-Reply-To: References: <149879934052.4573.15071593260685629727@ietfa.amsl.com> From: Brandon Long Date: Fri, 30 Jun 2017 14:37:24 -0700 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a1141000618197305533439ac" Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-05.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 21:37:38 -0000 --001a1141000618197305533439ac Content-Type: text/plain; charset="UTF-8" Looking through the changes, I see that in 5.2.2 we previously and still say that the AAR field should be unknown. Unknown is a valid value for result names for dkim-adsp and rrvs, but I'm curious why we would use that and not just fail? fail seems to match better, especially now that we don't differentiate between invalid and fail in the cv value. We also discussed signing/verifying a cv=fail differently, which isn't in the draft yet (I don't think, I was looking at the diff not the whole document). We discussed that the signing/verifying of a cv=fail would only do so based on the single (presumably last) hop that contained the cv=fail. So, the AMS would be added/verified like normal, but the AS would only sign the as/ams/aar of that hop. Brandon On Fri, Jun 30, 2017 at 6:32 AM, Kurt Andersen (b) wrote: > On Thu, Jun 29, 2017 at 10:09 PM, wrote: > >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : Authenticated Received Chain (ARC) Protocol >> (-05) >> Date : 2017-06-29 >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-protocol/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-05 >> https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-arc-protocol-05 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-arc-protocol-05 > > > The changes in this version of the document are limited to removing the > "cv=invalid" option, collapsing it into "cv=fail" and adding a little > explanatory text in a couple of places regarding the handling and > interpretation of "fail"ed chains for subsequent mediators. > > This change came from a dialog on the list last week and a follow-up > verbal discussion. Please let me know if there are questions about it. > > --Kurt > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --001a1141000618197305533439ac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Looking through the changes, I see that in 5.2.2 we previo= usly and still say that the AAR field should be unknown.=C2=A0 Unknown is a= valid value for result names for dkim-adsp and rrvs, but I'm curious w= hy we would use that and not just fail? =C2=A0fail seems to match better, e= specially now that we don't differentiate between invalid and fail in t= he cv value.

We also discussed signing/verifying a cv=3D= fail differently, which isn't in the draft yet (I don't think, I wa= s looking at the diff not the whole document).

We discussed t= hat the signing/verifying of a cv=3Dfail would only do so based on the sing= le (presumably last) hop that contained the cv=3Dfail.

=
So, the AMS would be added/verified like normal, but the AS would only= sign the as/ams/aar of that hop.

Brandon

On Fri, Jun 30= , 2017 at 6:32 AM, Kurt Andersen (b) <kboth@drkurt.com> wrote= :
On Thu, Jun 29, 2017 at 10= :09 PM, <internet-drafts@ietf.org> wrote:
=

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.

 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Authenticated Received Chain (ARC) Protocol (-05)
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 2017-06-29

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc= /draft-ietf-dmarc-arc-protocol/

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

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dmarc-arc-protocol-05
=
The changes in this version of the document are limited to r= emoving the "cv=3Dinvalid" option, collapsing it into "cv=3D= fail" and adding a little explanatory text in a couple of places regar= ding the handling and interpretation of "fail"ed chains for subse= quent mediators.

This change came from a dialog on= the list last week and a follow-up verbal discussion. Please let me know i= f there are questions about it.

--Kurt


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


--001a1141000618197305533439ac-- From nobody Fri Jun 30 14:45:08 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAA0C129B8D for ; Fri, 30 Jun 2017 14:45:06 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=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 S_vyHEw_wdx4 for ; Fri, 30 Jun 2017 14:45:04 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CB7E129B75 for ; Fri, 30 Jun 2017 14:45:04 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id 191so20691816oii.2 for ; Fri, 30 Jun 2017 14:45:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=KEakrmV502BohCWduzWt4D5+1yjOhPiPp43UPLN9cFE=; b=twOqIGGamkenMWj8Ti6OfQOtfZ4784UGsk4OwqVMObbx7aGqAYJfW2JSDj0/qkH8LV XYcn8pUQ679Gi6hq2h8rvdGLnKgpJBcAydAoea1kw4emxQUbAFwnueJSQET8NvK2MelN omCJ+j0Jow3GYE87PB+cI5I3c5GdGhRssB40vkydELFmLz1k3hjnxxKE+EZSmDDE0gPF CbsjpIyD0bpfvXFMw9lI6Qmc8SDa7iHu++wr+ETbeMo+UhTG2nGecwTjHRhPZk85/yG9 ZQTlhabxgik9vt4dAIU5Rd4k/z8GFWQK3citZQtL86P6L6qSbqTzWbL8eY5t9RwPHRF4 782A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=KEakrmV502BohCWduzWt4D5+1yjOhPiPp43UPLN9cFE=; b=oxTNlkkVSgQeon3QJbDuAATfCjFJ0Wq7hYg4DugvP1yQ8GQ5zf+YwNAO6UJkhNakp/ nwWwrc17rg9f8Usk4/kTkMtPAiyeLaW/NgZpB0Q0AygV50sXHT9Rgr+zqqHXhM66kGif U/kg+23XFv7rlbc5ykSzz1ha7Mpn1/p3gi/dWBOd/5ZWTrj1qrZ77G5pso0hTK4X8yp4 bg5MZ8FzeVHV3E7gPCd69uIZCJ18Aq4yVDXi38HLjXXx+DozpfvUckla0ktZvbTo11tk Bq8hP3A7OAa2Ta81DVnuqbHubT7L/HFiSdtceFVrZQ5o7i5CmFjoNJcwijq03ZUDdxFk NgDA== X-Gm-Message-State: AIVw110vqlGz7+Syyb24amQwH+unBAvib5cJCTH4Wgvgv3CXaU3oHDRL d4egDkDN4473SN0JvdXySWyjKHMjkocRFmw= X-Received: by 10.202.178.10 with SMTP id b10mr3366085oif.116.1498859102953; Fri, 30 Jun 2017 14:45:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.131.17 with HTTP; Fri, 30 Jun 2017 14:45:02 -0700 (PDT) From: Brandon Long Date: Fri, 30 Jun 2017 14:45:02 -0700 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a113ce01666ce590553345465" Archived-At: Subject: [dmarc-ietf] new arc usage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 21:45:07 -0000 --001a113ce01666ce590553345465 Content-Type: text/plain; charset="UTF-8" I know I complained recently that no one else was sending us arc signed mail, but that is no longer true. We're now seeing a smattering of low volume domains sending us arc-signed mail, about 190 of them in total (possibly from fewer servers). Glad to see it. Someone's using a keysize of 4098... that's odd. There's also one slightly larger sender is who quoting the existing header fields when we get the mail back from them, ie the arc-seal is coming back with d="google.com" a="rsa-sha256" s="arc-20160816". That may just be some weird mta. Brandon --001a113ce01666ce590553345465 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I know I complained recently that no one else was sending = us arc signed mail, but that is no longer true.

We'r= e now seeing a smattering of low volume domains sending us arc-signed mail,= about 190 of them in total (possibly from fewer servers).

Glad to see it.

Someone's using a key= size of 4098... that's odd.

There's also o= ne slightly larger sender is who quoting the existing header fields when we= get the mail back from them, ie the arc-seal is coming back with=C2=A0
d=3D"google.com" a=3D&qu= ot;rsa-sha256" s=3D"arc-20160816".=C2=A0 That may just be so= me weird mta.

Brandon
--001a113ce01666ce590553345465-- From nobody Fri Jun 30 16:48:23 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31165129436 for ; Fri, 30 Jun 2017 16:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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.001, 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=linkedin.com header.b=ZGMFKRax; dkim=pass (1024-bit key) header.d=microsoft.onmicrosoft.com header.b=CAhQMd0l 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 FknlmpE9UZ64 for ; Fri, 30 Jun 2017 16:48:20 -0700 (PDT) Received: from mail323.linkedin.com (mail323.linkedin.com [108.174.3.123]) (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 45D7612EAA5 for ; Fri, 30 Jun 2017 16:48:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; s=proddkim1024; t=1498866499; bh=QqKe29HMefUqZ6tOVeOm1RSujkMX0xRB8gxPHRTAGqU=; h=From:To:Subject:Date:Content-Type:MIME-Version; b=ZGMFKRaxnXlaFXZukTatSruABQ6WPaG6OESGcQmYOuUnFlEe6RgNF5JdAbkt/t8EP IBqEDUfoZspHjo1kUTio/zcUFbzOrGDZoWPZ2wKGxA4Xyow2jYNbOAu8Nq/g01qQ+s 9qU3TE0AsPUk5Got1nUDGBXu2z5dAUxGcZn4jX90= Authentication-Results: mail323.prod.linkedin.com x-tls.subject="/C=US/ST=WA/L=Redmond/O=Microsoft Corporation/OU=Microsoft Corporation/CN=mail.protection.outlook.com"; auth=pass (cipher=ECDHE-RSA-AES256-SHA384) Authentication-Results: mail323.prod.linkedin.com; iprev=pass policy.iprev="216.32.181.183"; spf=softfail smtp.mailfrom="kandersen@linkedin.com" smtp.helo="nam01-by2-obe.outbound.protection.outlook.com"; dkim=pass header.d=microsoft.onmicrosoft.com; tls=pass (verified) key.ciphersuite="TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384" key.length="256" tls.v="tlsv1.2" cert.client="C=US,ST=WA,L=Redmond,O=Microsoft Corporation,OU=Microsoft Corporation,CN=mail.protection.outlook.com" cert.clientissuer="C=US,ST=Washington,L=Redmond,O=Microsoft Corporation,OU=Microsoft IT,CN=Microsoft IT SSL SHA2" Received: from [216.32.181.183] ([216.32.181.183:38931] helo=NAM01-BY2-obe.outbound.protection.outlook.com) by mail323.prod.linkedin.com (envelope-from ) (ecelerity 3.6.21.53563 r(Core:3.6.21.0)) with ESMTPS (cipher=ECDHE-RSA-AES256-SHA384 subject="/C=US/ST=WA/L=Redmond/O=Microsoft Corporation/OU=Microsoft Corporation/CN=mail.protection.outlook.com") id F7/22-29494-243E6595; Fri, 30 Jun 2017 23:48:19 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.onmicrosoft.com; s=selector1-microsoft-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=QqKe29HMefUqZ6tOVeOm1RSujkMX0xRB8gxPHRTAGqU=; b=CAhQMd0li0B+WZKP+hNjJjX+YxnOOKATF+74ifKVOnQIt8cxO9R7/biBh9rHe7WcTk8fwRRIMNul3VJsg3sKwZyMliWQO+z4tTExOyGqXrZDspWBk/mWRy5KOTzjmH9NPWEVPlKrhXR4xeEDx6WnqTD8Kp/D2jhxs35r9tjwxLs= Received: from SN1PR21MB0112.namprd21.prod.outlook.com (10.161.254.20) by SN1PR21MB0031.namprd21.prod.outlook.com (10.161.254.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1220.9; Fri, 30 Jun 2017 23:48:16 +0000 Received: from SN1PR21MB0112.namprd21.prod.outlook.com ([10.161.254.20]) by SN1PR21MB0112.namprd21.prod.outlook.com ([10.161.254.20]) with mapi id 15.01.1240.007; Fri, 30 Jun 2017 23:48:16 +0000 From: Kurt Andersen To: Brandon Long CC: "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-05.txt Thread-Index: AQHS8ftYCWPjpNJGckGydFBT6gZhJA== Date: Fri, 30 Jun 2017 23:48:16 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=linkedin.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2600:1010:b015:514d:bdb8:da58:f0e6:e0b3] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN1PR21MB0031; 7:YASVrsTSPjfFd//M6wUHF6zH0vhMwu7KRXffGYeCqYi2jFrY6ZUFpGx/riM8DlTXdgpwpPFl+Wob1IZ53ZFQGqcnEwEIUm+IbS+6gYTKrAC8Te72D5ljqewFo3rg4RZMDxML6yRPXUwhnfvuTyhwiUycjSm6LOYpDx0IrR55OYJd2BKlOrjMH1V3jWpTSe+AQ8QG4lUph2Ya8CCSAhku+9hSDccVN1iIEwGYLYI8Sed2FutCnbR1bsX0kJm0j7aZj9iPf0bP5CeIERPLIFcnAEB2L95Lu5K66rAqFcZ9uYmgDYwEUPV735hRwFZge8NQeCfOx/nJ7vAfOwT22jGKRIUfDsHGGAZXGOF1KALLD/356Dmifl9jHHx7hWnpxZGXR/VmsK1f6PdpkdjhHSPOqkxRIWxiOQHFw7orlo5PDQ+xQ/59Bp4gUa0bTwWOtkWVtj4xDBnozpHJXuqc1tGc92wiLA9RsKqt3VfOg5Je897/TtcVLsivkjO8H1UuL8G+HX+KHpGhpordxG/ztJRm9l9FjroN6k5naJAoALDcV75UAbr1MsHq4OTzmwdzpcWNgno9ady8rg3FTV9m3Ah4m6LskCrLFA5842Cg+akypZPDpOghYAgy/EZ/McJNe0pJfVq7qWrQgWtMiqbyfLu2JPvyqLsDan7TwnPWPn/PWDrJuWXKAuu0g8E3hOx33QDwKyseKtC/DJiOWI7xJgSVaUBQHp8ppcJZmT6no+1DgltUoUnuJfFHGWj4p4/ar+WdhiaMntudwXU7iqgVfPkRXOS0T67A5FXwpnEXoibr/6mptkhXrx28YNjrhvN4aZBD x-ms-office365-filtering-correlation-id: 3a6f72de-c6db-4717-b99b-08d4c0127aac x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:SN1PR21MB0031; x-ms-traffictypediagnostic: SN1PR21MB0031: x-o365ent-eop-header: Message Processed By - CBR_LInkedIn_Mail_To_External x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278178393323532)(236129657087228)(211936372134217)(50300203121483); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(6055026)(61426038)(61427038)(6041248)(20161123558100)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SN1PR21MB0031; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN1PR21MB0031; x-forefront-prvs: 0354B4BED2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39840400002)(39860400002)(39850400002)(39400400002)(39410400002)(24454002)(47662002)(377454003)(54356999)(50986999)(10090500001)(6436002)(6506006)(305945005)(25786009)(33646002)(99286003)(6512007)(8676002)(9686003)(6916009)(3660700001)(81166006)(110136004)(6246003)(102836003)(6116002)(2906002)(7736002)(4326008)(53546010)(79102999)(230783001)(8936002)(6486002)(53936002)(38730400002)(478600001)(5660300001)(77096006)(54896002)(14454004)(2900100001)(3280700002)(31696002)(189998001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR21MB0031; H:SN1PR21MB0112.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_fe7b0008ea6c4891805e8d60d7f3d2afemailandroidcom_" MIME-Version: 1.0 X-OriginatorOrg: linkedin.com X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jun 2017 23:48:16.4604 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR21MB0031 Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-05.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 23:48:22 -0000 --_000_fe7b0008ea6c4891805e8d60d7f3d2afemailandroidcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiBKdW4gMzAsIDIwMTcgMjozNyBQTSwgQnJhbmRvbiBMb25nIDxibG9uZ0Bnb29nbGUuY29t PiB3cm90ZToNCkxvb2tpbmcgdGhyb3VnaCB0aGUgY2hhbmdlcywgSSBzZWUgdGhhdCBpbiA1LjIu MiB3ZSBwcmV2aW91c2x5IGFuZCBzdGlsbCBzYXkgdGhhdCB0aGUgQUFSIGZpZWxkIHNob3VsZCBi ZSB1bmtub3duLiAgVW5rbm93biBpcyBhIHZhbGlkIHZhbHVlIGZvciByZXN1bHQgbmFtZXMgZm9y IGRraW0tYWRzcCBhbmQgcnJ2cywgYnV0IEknbSBjdXJpb3VzIHdoeSB3ZSB3b3VsZCB1c2UgdGhh dCBhbmQgbm90IGp1c3QgZmFpbD8gIGZhaWwgc2VlbXMgdG8gbWF0Y2ggYmV0dGVyLCBlc3BlY2lh bGx5IG5vdyB0aGF0IHdlIGRvbid0IGRpZmZlcmVudGlhdGUgYmV0d2VlbiBpbnZhbGlkIGFuZCBm YWlsIGluIHRoZSBjdiB2YWx1ZS4NCg0KRmFpciBwb2ludC4gSSdsbCBsb29rIGF0IHJlcGhyYXNp bmcgdGhhdC4NCg0KV2UgYWxzbyBkaXNjdXNzZWQgc2lnbmluZy92ZXJpZnlpbmcgYSBjdj1mYWls IGRpZmZlcmVudGx5LCB3aGljaCBpc24ndCBpbiB0aGUgZHJhZnQgeWV0IChJIGRvbid0IHRoaW5r LCBJIHdhcyBsb29raW5nIGF0IHRoZSBkaWZmIG5vdCB0aGUgd2hvbGUgZG9jdW1lbnQpLg0KDQpX ZSBkaXNjdXNzZWQgdGhhdCB0aGUgc2lnbmluZy92ZXJpZnlpbmcgb2YgYSBjdj1mYWlsIHdvdWxk IG9ubHkgZG8gc28gYmFzZWQgb24gdGhlIHNpbmdsZSAocHJlc3VtYWJseSBsYXN0KSBob3AgdGhh dCBjb250YWluZWQgdGhlIGN2PWZhaWwuDQoNClNvLCB0aGUgQU1TIHdvdWxkIGJlIGFkZGVkL3Zl cmlmaWVkIGxpa2Ugbm9ybWFsLCBidXQgdGhlIEFTIHdvdWxkIG9ubHkgc2lnbiB0aGUgYXMvYW1z L2FhciBvZiB0aGF0IGhvcC4NCg0KVGhhdCBpcyBhbHJlYWR5IHRoZSBzcGVjaWZpZWQgaGFuZGxp bmcgaW4gdGhlIGNhc2Ugb2YgZmFpbC4NCg0KLS1LdXJ0DQoNCg== --_000_fe7b0008ea6c4891805e8d60d7f3d2afemailandroidcom_ Content-Type: text/html; charset="utf-8" Content-ID: <815C9BA0145E7D4390D02CFFE33FDEA1@microsoft.onmicrosoft.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdiBkaXI9ImF1 dG8iPg0KPGRpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+DQo8ZGl2IGNsYXNzPSJn bWFpbF9xdW90ZSI+T24gSnVuIDMwLCAyMDE3IDI6MzcgUE0sIEJyYW5kb24gTG9uZyAmbHQ7Ymxv bmdAZ29vZ2xlLmNvbSZndDsgd3JvdGU6PGJyIHR5cGU9ImF0dHJpYnV0aW9uIj4NCjxibG9ja3F1 b3RlIGNsYXNzPSJxdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFw eCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPkxv b2tpbmcgdGhyb3VnaCB0aGUgY2hhbmdlcywgSSBzZWUgdGhhdCBpbiA1LjIuMiB3ZSBwcmV2aW91 c2x5IGFuZCBzdGlsbCBzYXkgdGhhdCB0aGUgQUFSIGZpZWxkIHNob3VsZCBiZSB1bmtub3duLiZu YnNwOyBVbmtub3duIGlzIGEgdmFsaWQgdmFsdWUgZm9yIHJlc3VsdCBuYW1lcyBmb3IgZGtpbS1h ZHNwIGFuZCBycnZzLCBidXQgSSdtIGN1cmlvdXMgd2h5IHdlIHdvdWxkIHVzZSB0aGF0IGFuZCBu b3QganVzdCBmYWlsPyAmbmJzcDtmYWlsDQogc2VlbXMgdG8gbWF0Y2ggYmV0dGVyLCBlc3BlY2lh bGx5IG5vdyB0aGF0IHdlIGRvbid0IGRpZmZlcmVudGlhdGUgYmV0d2VlbiBpbnZhbGlkIGFuZCBm YWlsIGluIHRoZSBjdiB2YWx1ZS48L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBkaXI9ImF1dG8iPjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9 ImF1dG8iPkZhaXIgcG9pbnQuIEknbGwgbG9vayBhdCByZXBocmFzaW5nIHRoYXQuPC9kaXY+DQo8 ZGl2IGRpcj0iYXV0byI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0iYXV0byI+DQo8ZGl2IGNsYXNz PSJnbWFpbF9leHRyYSI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8YmxvY2txdW90ZSBj bGFzcz0icXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2Nj YyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXY+ V2UgYWxzbyBkaXNjdXNzZWQgc2lnbmluZy92ZXJpZnlpbmcgYSBjdj1mYWlsIGRpZmZlcmVudGx5 LCB3aGljaCBpc24ndCBpbiB0aGUgZHJhZnQgeWV0IChJIGRvbid0IHRoaW5rLCBJIHdhcyBsb29r aW5nIGF0IHRoZSBkaWZmIG5vdCB0aGUgd2hvbGUgZG9jdW1lbnQpLjxicj4NCjwvZGl2Pg0KPGRp dj48YnI+DQpXZSBkaXNjdXNzZWQgdGhhdCB0aGUgc2lnbmluZy92ZXJpZnlpbmcgb2YgYSBjdj1m YWlsIHdvdWxkIG9ubHkgZG8gc28gYmFzZWQgb24gdGhlIHNpbmdsZSAocHJlc3VtYWJseSBsYXN0 KSBob3AgdGhhdCBjb250YWluZWQgdGhlIGN2PWZhaWwuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj5TbywgdGhlIEFNUyB3b3VsZCBiZSBhZGRlZC92ZXJpZmllZCBsaWtlIG5vcm1hbCwg YnV0IHRoZSBBUyB3b3VsZCBvbmx5IHNpZ24gdGhlIGFzL2Ftcy9hYXIgb2YgdGhhdCBob3AuPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdiBkaXI9ImF1dG8iPjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9ImF1dG8iPlRoYXQgaXMg YWxyZWFkeSB0aGUgc3BlY2lmaWVkIGhhbmRsaW5nIGluIHRoZSBjYXNlIG9mIGZhaWwuPC9kaXY+ DQo8ZGl2IGRpcj0iYXV0byI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0iYXV0byI+LS1LdXJ0PC9k aXY+DQo8ZGl2IGRpcj0iYXV0byI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+DQo8ZGl2IGNs YXNzPSJnbWFpbF9xdW90ZSI+DQo8YmxvY2txdW90ZSBjbGFzcz0icXVvdGUiIHN0eWxlPSJtYXJn aW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4 Ij4NCjxkaXY+PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxicj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_fe7b0008ea6c4891805e8d60d7f3d2afemailandroidcom_--