From nobody Tue Jul 5 16:33:15 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EDEB12D115 for ; Tue, 5 Jul 2016 16:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4NOQ4sVSLpUo for ; Tue, 5 Jul 2016 16:33:11 -0700 (PDT) Received: from mail-io0-x244.google.com (mail-io0-x244.google.com [IPv6:2607:f8b0:4001:c06::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA4EB12B02F for ; Tue, 5 Jul 2016 16:33:11 -0700 (PDT) Received: by mail-io0-x244.google.com with SMTP id u25so22248941iou.2 for ; Tue, 05 Jul 2016 16:33:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:from:date:message-id:subject:to:cc; bh=V/VrdpOrcHQ+YeB8NMkMfHbi43W5nmA0NZv+egIbsQ0=; b=LMielYtlpAlj9ERUfH2AWInqWr2XbO42YlH0wyLIEzKCIy7JPkN6qDoXKBclF/AZuu My+ZvXa6KDYrFbg6Z6C4lcoseeuFblE1CSJO6k3mb/ERxQTpNwSIkWmMJ6hbSo6imskT JKNEcRH8GOQS7juWh+ZU6J6UcvicZblwULKgA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:cc; bh=V/VrdpOrcHQ+YeB8NMkMfHbi43W5nmA0NZv+egIbsQ0=; b=RUcK1Zn1OT8XhENd5l73utI8ztwQTmiW00ekbsREt/+is101lFCb3qSTgg0/dRISVS eWYrt2bGujKw1e4QaZC6Om7UKtqXcqfdR30U6ezKLLogrM1YL4mRYPM/rVgvPucUZsiu 1fQj7szEJGBn1CkYT1KMxmtsD120IPXeSbUlA81js6RBZ+g8Dc82BeYIoWHV6HYeVY2Q qUA9AEIC6tA6YwszANw8QtZAeyJb8JhW89SA/PeG92qtJlJbR1tmdTrFSZ3NdGbOxeHD jrS3xd1gXXjlXZ4Dflj8GB7sUqb9ope9Rxni7PnVuq0FdbciA3vgO8s8iAFdFdB3XN1X zj0Q== X-Gm-Message-State: ALyK8tKSSPKulHzUOhPPCKcq+uYyFFqfrLzH4iWooypL7RqDqWLq/Hl8vxBfdEjmRVuVy749W4/xO6YWQPq2xA== X-Received: by 10.107.160.202 with SMTP id j193mr16652034ioe.113.1467761590739; Tue, 05 Jul 2016 16:33:10 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.107.25.67 with HTTP; Tue, 5 Jul 2016 16:33:10 -0700 (PDT) From: "Kurt Andersen (b)" Date: Tue, 5 Jul 2016 16:33:10 -0700 X-Google-Sender-Auth: y03WjCy1rmpQU-kpIE8fdxWsB_M Message-ID: To: Raymond van Venetie Content-Type: multipart/alternative; boundary=001a1140f2523b617a0536ebe0fa Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] [arc-discuss] Canonicalization X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 23:33:14 -0000 --001a1140f2523b617a0536ebe0fa Content-Type: text/plain; charset=UTF-8 ARC-Discuss to BCC, moving the conversation to DMARC-WG On Mon, Jul 4, 2016 at 5:19 AM, Raymond van Venetie via arc-discuss < arc-discuss@dmarc.org> wrote: > Hi, > > The ARC-Seal header does not include the canonicalization tag 'c' in the > current specification. The ARC-Message-Signature includes the tag, but > discards its value and uses relaxed/relaxed -- right? > Shouldn't ARC-Seal also include the tag and simply ignore the value? Would > be handy to have this tag in case a new (better) canonicalization algorithm > is released. > As per some earlier conversations, the latest draft (draft-ietf-dmarc-arc-protocol-00) adds back in the "c=" tag for AMS (to match DKIM usage), but since the ARC-Seal is only signing across headers fields, it does not use or support any usage other than relaxed/relaxed. --Kurt --001a1140f2523b617a0536ebe0fa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
ARC-= Discuss to BCC, moving the conversation to DMARC-WG

On Mon, Jul 4, 2016 at 5:19 A= M, Raymond van Venetie via arc-discuss <arc-discuss@dmarc.org><= /span> wrote:
Hi,

The ARC-Seal header does not include the canonicalization tag 'c' i= n the current specification. The ARC-Message-Signature includes the tag, bu= t discards its value and uses relaxed/relaxed -- right?
Shouldn't ARC-Seal also include the tag and simply ignore the value? Wo= uld be handy to have this tag in case a new (better) canonicalization algor= ithm is released.

=C2=A0As per some ear= lier conversations, the latest draft (draft-ietf-dmarc-arc-protocol-00) add= s back in the "c=3D" tag for AMS (to match DKIM usage), but since= the ARC-Seal is only signing across headers fields, it does not use or sup= port any usage other than relaxed/relaxed.

--Kurt<= /div>
--001a1140f2523b617a0536ebe0fa-- From nobody Thu Jul 7 11:39:11 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57DDA12D1AC for ; Thu, 7 Jul 2016 11:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.428 X-Spam-Level: X-Spam-Status: No, score=-3.428 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=crash.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jb3vQavHbH3k for ; Thu, 7 Jul 2016 11:39:08 -0700 (PDT) Received: from segv.crash.com (segv.crash.com [IPv6:2001:470:1:1e9::4415]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5041A12D13B for ; Thu, 7 Jul 2016 11:39:08 -0700 (PDT) Received: from abort.crash.com (70-36-157-26.dsl.static.fusionbroadband.com [70.36.157.26]) (authenticated bits=0) by segv.crash.com (8.14.5/8.14.5/cci-colo-1.6) with ESMTP id u67IctZb072688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 7 Jul 2016 11:39:01 -0700 (PDT) (envelope-from smj@crash.com) X-DKIM: OpenDKIM Filter v2.4.3 segv.crash.com u67IctZb072688 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=201506-2k; t=1467916741; bh=DfHUc/2/vbyj6M7p64OPDBORB7udxbNYAL+wkx+q+RY=; h=Subject:To:References:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=dJ9hStig6LTTLcJLMda1rp5oYXE9b+o6wCuyb1jMvZo7mYDOs3JOgUeovnRCxzmJl KvAFo1ZVnVNZ0BcKYsOT1R2xjzHBd1Ufu2MNyEHVZDAFZWpHBh++WxO4qY4WHNbBYl Pk0qZMyg/4VtFdgyos1BXBXunQh+8B99vZ5rwmSELRXsQ977w6F3gF7VVhOlfs+y1u HfzDn3P2ehEU5aO5ywcI9xIzpIr/++aNJKx2es43Z4VFH5yKkmkIW8gVVO24rGsMC1 mYI1EdqjuFWQxyy1UL7D7jdDk3q1S4F/do22UipgUc7FySjuhWva9ATGDA6VS55hOJ 09yYFC2Jj+dKA== X-Authentication-Warning: segv.crash.com: Host 70-36-157-26.dsl.static.fusionbroadband.com [70.36.157.26] claimed to be abort.crash.com To: dmarc@ietf.org References: <20160705074107.GA13987@openlib.org> <2116891601.118690.1467908211829.JavaMail.yahoo@mail.yahoo.com> From: Steven M Jones Organization: Crash Computing Message-ID: Date: Thu, 7 Jul 2016 11:38:58 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <2116891601.118690.1467908211829.JavaMail.yahoo@mail.yahoo.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (segv.crash.com [72.52.75.15]); Thu, 07 Jul 2016 11:39:01 -0700 (PDT) Archived-At: Subject: Re: [dmarc-ietf] [dmarc-discuss] exegesis: pass and fail together X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 18:39:10 -0000 I'm quoting the following response in a thread from the dmarc-discuss@dmarc.org mailing list, because I think it identifies work items or at least questions this WG may want to address. If this is already captured somewhere, my apologies. Here's the original thread: http://lists.dmarc.org/pipermail/dmarc-discuss/2016-July/003546.html Summary: How should DMARC aggregate reports reflect messages with multiple DKIM results? And should DKIM selectors be included in DMARC aggregate reports? On 07/07/2016 09:16, Elizabeth Zwicky via dmarc-discuss wrote: > > And yes, it's entirely possible for a message to have 2 or more DKIM > signatures, including signatures for the same domain with different > results. As long as there exists a DKIM signature that is aligned and > passes, the DMARC DKIM result is pass. (As I recall, the spec is unclear > about what you do if there are multiple DKIM results. That should > probably be fixed and it would be nice if we allowed the selector to be > reported as well.) AND: On 07/07/2016 09:53, Elizabeth Zwicky via dmarc-discuss wrote: > > I meant to say that the spec is unclear about what you do about > **reporting** multiple DKIM results. It's perfectly clear on how to > evaluate them. From nobody Thu Jul 7 11:55:04 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1C312D5AB for ; Thu, 7 Jul 2016 11:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.427 X-Spam-Level: X-Spam-Status: No, score=-3.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=otoh.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1IY6f9ytOt5y for ; Thu, 7 Jul 2016 11:54:59 -0700 (PDT) Received: from suricate.otoh.org (suricate.otoh.org [173.11.101.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 890A512D177 for ; Thu, 7 Jul 2016 11:54:59 -0700 (PDT) Received: from [10.87.3.247] (unknown [216.145.48.133]) (Authenticated sender: zwicky) by suricate.otoh.org (Postfix) with ESMTPSA id 358E99871; Thu, 7 Jul 2016 18:54:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=otoh.org; s=2014-12-30; t=1467917699; r=y; bh=7/IXrSmLBvZB6q2xG0D8glmWBU4Q/x/wjsK22DbUD0E=; h=Subject:From:In-Reply-To:Date:Cc:References:To; z=Subject:=20Re:=20[dmarc-ietf]=20[dmarc-discuss]=20exegesis:=20pas s=20and=20fail=20together|From:=20Elizabeth=20Zwicky=20|In-Reply-To:=20|Date:=20Thu,=207=20Jul=202016=2011:54:58=20-0700|Cc:=20dmarc@ ietf.org|References:=20<20160705074107.GA13987@openlib.org>=20<211 6891601.118690.1467908211829.JavaMail.yahoo@mail.yahoo.com>=20|To:=20Steven=20M=20Jo nes=20; b=a99kxNMCmF4Uob7DoZ/8VPNAdO1EV8Q0j1BRn5VYsP16vSBSXd3wC3rpcC1DO2Aeo mzjwG4tv4oG+QNuxWDjI6v5P1zi3d2ezyvRpbyT8yZl3QwqhfnrffZlxpYh7Y97pwU 0dnlhwLdKcJHoSuQkxlyRF6d0f6+nv4DVy5Z5dW8= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Elizabeth Zwicky X-Mailer: iPhone Mail (13F69) In-Reply-To: Date: Thu, 7 Jul 2016 11:54:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160705074107.GA13987@openlib.org> <2116891601.118690.1467908211829.JavaMail.yahoo@mail.yahoo.com> To: Steven M Jones Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] [dmarc-discuss] exegesis: pass and fail together X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 18:55:02 -0000 Tomki pointed out that I am completely wrong about selectors and lots of peo= ple report them. I should have checked.=20 Elizabeth=20 Zwicky@otoh.org > On Jul 7, 2016, at 11:38 AM, Steven M Jones wrote: >=20 > I'm quoting the following response in a thread from the > dmarc-discuss@dmarc.org mailing list, because I think it identifies work > items or at least questions this WG may want to address. If this is > already captured somewhere, my apologies. >=20 > Here's the original thread: >=20 > http://lists.dmarc.org/pipermail/dmarc-discuss/2016-July/003546.html >=20 >=20 > Summary: How should DMARC aggregate reports reflect messages with > multiple DKIM results? And should DKIM selectors be included in DMARC > aggregate reports? >=20 >=20 >> On 07/07/2016 09:16, Elizabeth Zwicky via dmarc-discuss wrote: >>=20 >> And yes, it's entirely possible for a message to have 2 or more DKIM >> signatures, including signatures for the same domain with different >> results. As long as there exists a DKIM signature that is aligned and >> passes, the DMARC DKIM result is pass. (As I recall, the spec is unclear >> about what you do if there are multiple DKIM results. That should >> probably be fixed and it would be nice if we allowed the selector to be >> reported as well.) >=20 > AND: >=20 >> On 07/07/2016 09:53, Elizabeth Zwicky via dmarc-discuss wrote: >>=20 >> I meant to say that the spec is unclear about what you do about >> **reporting** multiple DKIM results. It's perfectly clear on how to >> evaluate them. >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Thu Jul 7 12:08:59 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B45F12D50D for ; Thu, 7 Jul 2016 12:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.719 X-Spam-Level: X-Spam-Status: No, score=-1.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 z-VgNfGOTfK2 for ; Thu, 7 Jul 2016 12:08:53 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F92512D1BD for ; Thu, 7 Jul 2016 12:08:52 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id f189so36239479oig.3 for ; Thu, 07 Jul 2016 12:08:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+gfbNHbwJuHuqK2xBPK98EC8gJJHVzSp+y7lFL9cDLw=; b=ctzSxD/OFM0akjQh3lBe2x5QnLgQPuWc7Xpn1znorwVK8nQjUPQ+aLbHMoE0wqYEpj JptP5MPaA4jXdNnegVV5MiPYFrISzQrbYYdnTjaHhy52jfrdC+w3Kl2gah5BoiAf8+3+ 3xiMMz7TUwSe2sYGF3EYWqc72FFPTB3GdDQTg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+gfbNHbwJuHuqK2xBPK98EC8gJJHVzSp+y7lFL9cDLw=; b=lcBf03zBMeTj0BvEBinPvQg8EUfM0Ncz3/UqLSecGQBcTfubTqI2Ix4Wo2EoYO5/ZD 5Ng4WtBs1xp/bSdMYr75SIK8euuSpm5UBTwYNmBci4xW4yYASvcLqu68h0Z6oD9ZMeoj mZLbzcvDOPs4I08ZA2Up9rEDIzWYuyUMMGlG87A3tSCn3rLRc+b6XFwUFq2EEaEjcOBp jVEWfAfXGBrdqR9WsQdA6EQOTDdh/2+b2j202fmEC1PvmMWqr+SZpAcUdtCFVJfIl38a ZaUK96jh71SFRY3iUaeFQL33KVZu2WoLDws/lMDTibsnLzlUekfuL4DlJHsQnaaelowO 2oRw== X-Gm-Message-State: ALyK8tIGGLZaMsior4RxtyQj/sY/IgP9rp5z1m3gnqcmMj2rDpJSorJLWt+WM7JIe+q0lNAyepJlRhLgKs7dNA== X-Received: by 10.202.172.23 with SMTP id v23mr1058889oie.184.1467918531454; Thu, 07 Jul 2016 12:08:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.158.5 with HTTP; Thu, 7 Jul 2016 12:08:50 -0700 (PDT) In-Reply-To: References: <20160705074107.GA13987@openlib.org> <2116891601.118690.1467908211829.JavaMail.yahoo@mail.yahoo.com> From: Peter Goldstein Date: Thu, 7 Jul 2016 12:08:50 -0700 Message-ID: To: Elizabeth Zwicky Content-Type: multipart/alternative; boundary=001a113cd924a2744c0537106a1f Archived-At: Cc: dmarc@ietf.org, Steven M Jones Subject: Re: [dmarc-ietf] [dmarc-discuss] exegesis: pass and fail together X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 19:08:57 -0000 --001a113cd924a2744c0537106a1f Content-Type: text/plain; charset=UTF-8 Being able to identify the service that originated a piece of email is extremely helpful in getting a domain to quarantine/reject. Including all DKIM signatures found on a message (not just those that are aligned or that pass) in the DMARC aggregate reports can be very helpful in ascertaining that originating service. DKIM signatures are footprints - not always unambiguous, but they can be very helpful in figuring out exactly what's going on. From our perspective it's preferable that receivers include all signatures in the aggregate reports. Similarly, I'd strongly urge that receivers include selectors in the DMARC aggregate reports for much the same reason. The presence of a DKIM signature with a selector is often enough to allow one to make that identification. While the spec marks the selector optional, it's an extremely valuable piece of information that (as Tomki notes) is already provided by some receivers. Best, Peter On Thu, Jul 7, 2016 at 11:54 AM, Elizabeth Zwicky wrote: > Tomki pointed out that I am completely wrong about selectors and lots of > people report them. I should have checked. > > Elizabeth > > Zwicky@otoh.org > > > On Jul 7, 2016, at 11:38 AM, Steven M Jones wrote: > > > > I'm quoting the following response in a thread from the > > dmarc-discuss@dmarc.org mailing list, because I think it identifies work > > items or at least questions this WG may want to address. If this is > > already captured somewhere, my apologies. > > > > Here's the original thread: > > > > http://lists.dmarc.org/pipermail/dmarc-discuss/2016-July/003546.html > > > > > > Summary: How should DMARC aggregate reports reflect messages with > > multiple DKIM results? And should DKIM selectors be included in DMARC > > aggregate reports? > > > > > >> On 07/07/2016 09:16, Elizabeth Zwicky via dmarc-discuss wrote: > >> > >> And yes, it's entirely possible for a message to have 2 or more DKIM > >> signatures, including signatures for the same domain with different > >> results. As long as there exists a DKIM signature that is aligned and > >> passes, the DMARC DKIM result is pass. (As I recall, the spec is unclear > >> about what you do if there are multiple DKIM results. That should > >> probably be fixed and it would be nice if we allowed the selector to be > >> reported as well.) > > > > AND: > > > >> On 07/07/2016 09:53, Elizabeth Zwicky via dmarc-discuss wrote: > >> > >> I meant to say that the spec is unclear about what you do about > >> **reporting** multiple DKIM results. It's perfectly clear on how to > >> evaluate them. > > > > _______________________________________________ > > 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 > -- Peter Goldstein CTO & Co-Founder, ValiMail peter@valimail.com (415) 793-5783 --001a113cd924a2744c0537106a1f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Being able to identify the service that originated a = piece of email is extremely helpful in getting a domain to quarantine/rejec= t. =C2=A0

Including all DKIM signatures found = on a message (not just those that are aligned or that pass) in the DMARC ag= gregate reports can be very helpful in ascertaining that originating servic= e.=C2=A0 DKIM signatures are footprints - not always unambiguous, but they = can be very helpful in figuring out exactly what's going on.=C2=A0 From= our perspective it's preferable that receivers include all signatures = in the aggregate reports.

Similarly, I'd stron= gly urge that receivers include selectors in the DMARC aggregate reports fo= r much the same reason.=C2=A0 The presence of a DKIM signature with a selec= tor is often enough to allow one to make that identification.=C2=A0 While t= he spec marks the selector optional, it's an extremely valuable piece o= f information that (as Tomki notes)=C2=A0is already provided by some receivers.

B= est,

Peter


On Thu, Jul 7, 2016 at 11:54 AM, Elizabeth Zwicky = <zwicky@otoh.org> wrote:
Tomki pointed out tha= t I am completely wrong about selectors and lots of people report them. I s= hould have checked.

Elizabeth

Zwicky@otoh.org

> On Jul 7, 2016, at 11:38 AM, Steven M Jones <smj@crash.com> wrote:
>
> I'm quoting the following response in a thread from the
> dmarc-discuss@dmarc.org= mailing list, because I think it identifies work
> items or at least questions this WG may want to address. If this is > already captured somewhere, my apologies.
>
> Here's the original thread:
>
> http://lists.dmarc.org/pipe= rmail/dmarc-discuss/2016-July/003546.html
>
>
> Summary: How should DMARC aggregate reports reflect messages with
> multiple DKIM results? And should DKIM selectors be included in DMARC<= br> > aggregate reports?
>
>
>> On 07/07/2016 09:16, Elizabeth Zwicky via dmarc-discuss wrote:
>>
>> And yes, it's entirely possible for a message to have 2 or mor= e DKIM
>> signatures, including signatures for the same domain with differen= t
>> results. As long as there exists a DKIM signature that is aligned = and
>> passes, the DMARC DKIM result is pass. (As I recall, the spec is u= nclear
>> about what you do if there are multiple DKIM results. That should<= br> >> probably be fixed and it would be nice if we allowed the selector = to be
>> reported as well.)
>
> AND:
>
>> On 07/07/2016 09:53, Elizabeth Zwicky via dmarc-discuss wrote:
>>
>> I meant to say that the spec is unclear about what you do about >> **reporting** multiple DKIM results. It's perfectly clear on h= ow to
>> evaluate them.
>
> _______________________________________________
> 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



--
=
=
Peter Goldstein
CTO & Co-Founder= , ValiMail
(415) 793-5783

=
=
--001a113cd924a2744c0537106a1f-- From nobody Thu Jul 7 12:09:23 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 646B712D864 for ; Thu, 7 Jul 2016 12:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.428 X-Spam-Level: X-Spam-Status: No, score=-3.428 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=crash.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UV3zTnETECq4 for ; Thu, 7 Jul 2016 12:09:17 -0700 (PDT) Received: from segv.crash.com (segv.crash.com [IPv6:2001:470:1:1e9::4415]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31E3912D863 for ; Thu, 7 Jul 2016 12:09:13 -0700 (PDT) Received: from abort.crash.com (70-36-157-26.dsl.static.fusionbroadband.com [70.36.157.26]) (authenticated bits=0) by segv.crash.com (8.14.5/8.14.5/cci-colo-1.6) with ESMTP id u67J92JK073001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 7 Jul 2016 12:09:07 -0700 (PDT) (envelope-from smj@crash.com) X-DKIM: OpenDKIM Filter v2.4.3 segv.crash.com u67J92JK073001 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=201506-2k; t=1467918547; bh=knKHtkF/mlQg4S4uhHsg+d4DSuh2fV7JJ2JcnpRusGY=; h=Subject:To:References:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=TMtAHGPxkSmWYS4JE5CyEpeWwcplHuLyPDkHNnhPusZv2Dhne94qccmoKPImjFqk6 n822nxIhEVengRvEniN9HgOOL6eBbPCDkNf2BwIC9Yi4h7tqShdL7oMPMf/objKJIt ZCZc21Xzdxbe1xxivijcX0J0W0rTNJSd5ZCkmEZLGCBr37HJjrGIZkp4W62ZMyzTg0 XNowYCD/iBDB0iaPw46kmBptLdngSQNnbmF7dTxj2uu/F5+Oj0kPJmKDUxpZCD/tKR Ly6QaDZ4qoov6Pel8EzSA7MOtstm/tbYfObUxglhhenitlUWWRucYPj1UgYQgZC+ch AAlAfwlO4oF1w== X-Authentication-Warning: segv.crash.com: Host 70-36-157-26.dsl.static.fusionbroadband.com [70.36.157.26] claimed to be abort.crash.com To: dmarc@ietf.org References: <20160705074107.GA13987@openlib.org> <2116891601.118690.1467908211829.JavaMail.yahoo@mail.yahoo.com> From: Steven M Jones Organization: Crash Computing Message-ID: <92416059-a827-6670-0f1e-b4c7ab2b0d28@crash.com> Date: Thu, 7 Jul 2016 12:09:04 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (segv.crash.com [72.52.75.15]); Thu, 07 Jul 2016 12:09:07 -0700 (PDT) Archived-At: Subject: Re: [dmarc-ietf] [dmarc-discuss] exegesis: pass and fail together X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 19:09:21 -0000 On 07/07/2016 11:54, Elizabeth Zwicky wrote: > > Tomki [Camp] pointed out that I am completely wrong about selectors and > lots of people report them. I should have checked. And I didn't check - I do see provision for selectors in the aggregate report XML in RFC7489. Is the question of messages with multiple DKIM signatures in aggregate reports is still open? --S. From nobody Thu Jul 7 13:59:45 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4489912D8BD for ; Thu, 7 Jul 2016 13:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=agari.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 xemPmmS3gIs8 for ; Thu, 7 Jul 2016 13:59:41 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::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 064C612D0CD for ; Thu, 7 Jul 2016 13:59:40 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id g4so100594683ith.1 for ; Thu, 07 Jul 2016 13:59:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=agari.com; s=s1024; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ioY/TADwsLpmSLEE6PAsV0Hw24Be3hyEol+59FjuuUY=; b=kUb8bHKRMSfp3B6Q3JUUHiAZ+e1Xena+k8AStWDyUnfaE3Ztrbeyndu8l9YF0qvsD4 OUHG/zm3cASBJgd3vCUgztikL8gnYH1hSS4N9Wx7gQtYlfrmxT0BnBZM463A1JgkKZlK wP2cRMrAqv5gL+mwPAkO1CeG65CuEVeQ3QsN8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ioY/TADwsLpmSLEE6PAsV0Hw24Be3hyEol+59FjuuUY=; b=Rwf0I3wTsE+Ok4ZSwC9+V7J1PRbSKKeXkWrnC99wsljaziVb+BkZROGRFf2cXppCpq ggqWMZGunjZ+96M3LOF2BCWSi4j9q7vMrsoVeWhDzHOo3s0iaCb2260epRuu0W+KJ+hH tDR3MFnqR3Vq7iBhQ7946jrITfY+MIx3VvPjFnIfGlEZ+SARJRrysVf1QClhDiKFpdX8 RpPr+1uBFAGBgxfDhO0WVUqIE6oUFz7CKPcDYdlwYad2g5cUBvL4awP9tPjtqdBMGhdg EHbDagHn3AeWhGZI2ge7QwRawC1Q1sZteoMn0poPXsRSmQ+VurmSb3Dv753rrElcbwXK d5Cg== X-Gm-Message-State: ALyK8tLhdRc1IwSsBVwkBAXQ2G1TSXxm2STpNvjDgaRm29FZv2aNofROM1eRXmfJ3N//9BYauJhX0l/xuMkT/5Zk X-Received: by 10.36.93.6 with SMTP id w6mr5051288ita.52.1467925180288; Thu, 07 Jul 2016 13:59:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.184.165 with HTTP; Thu, 7 Jul 2016 13:59:20 -0700 (PDT) In-Reply-To: <92416059-a827-6670-0f1e-b4c7ab2b0d28@crash.com> References: <20160705074107.GA13987@openlib.org> <2116891601.118690.1467908211829.JavaMail.yahoo@mail.yahoo.com> <92416059-a827-6670-0f1e-b4c7ab2b0d28@crash.com> From: Tomki Camp Date: Thu, 7 Jul 2016 13:59:20 -0700 Message-ID: To: Steven M Jones Content-Type: multipart/alternative; boundary=001a11462fc6edcb3c053711f6a8 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] [dmarc-discuss] exegesis: pass and fail together X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 20:59:43 -0000 --001a11462fc6edcb3c053711f6a8 Content-Type: text/plain; charset=UTF-8 Multiple DKIM signature reporting is reasonable. However there have been report instances which overdid it, inserting multiple instances of the same domain+result[+selector]. It's certainly possible to re-sign a message with the same domain+selector and obtain the same verification result, but I do not feel that reporting this in DMARC XML is useful. To be explicit, any instance which wants to show up as agari.com sel1 fail nexthop.agari.com sel2 pass forwarderdomain.com sel3 pass is great. Any instance which shows this is not useful: agari.com blah pass agari.com blah pass it should simply show up as agari.com blah pass The current Comcast reporting raw data has a comment inline when this occur, which is fine, XML parsers will ignore it: agari.com pass blah --Tomki On Thu, Jul 7, 2016 at 12:09 PM, Steven M Jones wrote: > On 07/07/2016 11:54, Elizabeth Zwicky wrote: > > > > Tomki [Camp] pointed out that I am completely wrong about selectors and > > lots of people report them. I should have checked. > > And I didn't check - I do see provision for selectors in the aggregate > report XML in RFC7489. > > Is the question of messages with multiple DKIM signatures in aggregate > reports is still open? > > --S. > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --001a11462fc6edcb3c053711f6a8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Multiple DKIM signature reporting is r= easonable.=C2=A0 However there have been report instances which overdid it,= inserting multiple instances of the same domain+result[+selector].=C2=A0 <= br>It's certainly possible to re-sign a message with the same domain+se= lector and obtain the same verification result, but I do not feel that repo= rting this in DMARC XML is useful.


To be explicit, any ins= tance which wants to show up as

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <d= kim>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <domain>agari.com</domain>
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 <selector>sel1</selector>
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <result>fail</result>
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 </dkim>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 &l= t;dkim>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <domain>nexthop.agari.com</domain>
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <selector>sel2</selecto= r>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <result>pass</= result>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </dkim>
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 <dkim>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 <domain>forwarderdomain.co= m</domain>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <sele= ctor>sel3</selector>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= <result>pass</result>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </d= kim>

is great.


Any instance whic= h shows this is not useful:

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 <dkim>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <domain&g= t;agari.com</domain>
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <selector>blah</selector>
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <result>pass</result>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </dkim>
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 <dkim>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <domai= n>agari.com</domain>
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <selector>blah</selector>
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <result>pass</result>= ;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </dkim>

it should si= mply show up as
=C2=A0=C2=A0=C2=A0=C2=A0 <dkim>
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 <domain>agar= i.com</domain>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <= selector>blah</selector>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 <result>pass</result>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = </dkim>

The current Comcast reporting raw data has a com= ment inline when this occur, which is fine, XML parsers will ignore it:
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <dkim>
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 <domain>agari.com<= ;/domain>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <result>pa= ss</result>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <selecto= r>blah</selector>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 &l= t;!-- This selector was repeated 2 times. -->
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 </dkim>


--Tomki



On Thu, Jul 7, = 2016 at 12:09 PM, Steven M Jones <smj@crash.com> wrote:
On 07/07/2016 11:54, Elizabeth Zwicky wrote:
>
> Tomki [Camp] pointed out that I am completely wrong about selectors an= d
> lots of people report them. I should have checked.
And I didn't check - I do see provision for selectors in the agg= regate
report XML in RFC7489.

Is the question of messages with multiple DKIM signatures in aggregate
reports is still open?

--S.

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

--001a11462fc6edcb3c053711f6a8-- From nobody Mon Jul 18 02:30:18 2016 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1735F12D623; Mon, 18 Jul 2016 02:30:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.28.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160718093017.24838.80578.idtracker@ietfa.amsl.com> Date: Mon, 18 Jul 2016 02:30:17 -0700 Archived-At: Cc: dmarc@ietf.org Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-interoperability-18.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 09:30:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain-based Message Authentication, Reporting & Conformance of the IETF. Title : Interoperability Issues Between DMARC and Indirect Email Flows Authors : Franck Martin Eliot Lear Tim Draegen Elizabeth Zwicky Kurt Andersen Filename : draft-ietf-dmarc-interoperability-18.txt Pages : 26 Date : 2016-07-18 Abstract: DMARC (Domain-based Message Authentication, Reporting, and Conformance) introduces a mechanism for expressing domain-level policies and preferences for email message validation, disposition, and reporting. However, the DMARC mechanism enables potentially disruptive interoperability issues when messages do not flow directly from the author's administrative domain to the final recipients. Collectively these email flows are referred to as indirect email flows. This document describes these interoperability issues, and presents possible methods for addressing them. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperability/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dmarc-interoperability-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-interoperability-18 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 Jul 19 06:41:22 2016 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D7C512E234; Tue, 19 Jul 2016 06:41:10 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.28.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160719134110.20855.13743.idtracker@ietfa.amsl.com> Date: Tue, 19 Jul 2016 06:41:10 -0700 Archived-At: Cc: draft-ietf-dmarc-interoperability@ietf.org, Ned Freed , dmarc@ietf.org, The IESG , alexey.melnikov@isode.com, dmarc-chairs@ietf.org, rfc-editor@rfc-editor.org Subject: [dmarc-ietf] Document Action: 'Interoperability Issues Between DMARC and Indirect Email Flows' to Informational RFC (draft-ietf-dmarc-interoperability-18.txt) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 13:41:10 -0000 The IESG has approved the following document: - 'Interoperability Issues Between DMARC and Indirect Email Flows' (draft-ietf-dmarc-interoperability-18.txt) as Informational RFC This document is the product of the Domain-based Message Authentication, Reporting & Conformance Working Group. The IESG contact persons are Alexey Melnikov, Ben Campbell and Alissa Cooper. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperability/ Technical Summary: DMARC introduces a mechanism for expressing domain-level policies and preferences for email message validation, disposition, and reporting. The DMARC mechanism can encounter interoperability issues when messages do not flow directly from the author's administrative domain to the final recipients. Collectively these email flows are referred to as indirect email flows. This document describes interoperability issues between DMARC and indirect email flows. Possible methods for addressing interoperability issues are presented. Working Group Summary: This document was initially posted on January 29, 2015. The WGLC began September 30, 2015, with no substantive comments being made during the last call period. Document Quality: This is an informational specification; it does not specify a standard or best practices. Personnel: Ned Freed is acting as the Document Shepherd. The responsible Area Director is Alexey Melnikov .