From nobody Tue Feb 2 15:56:59 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7091A9106 for ; Tue, 2 Feb 2016 15:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=ham 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 N0MGMrgi4Bm4 for ; Tue, 2 Feb 2016 15:56:57 -0800 (PST) Received: from mail-qg0-x264.google.com (mail-qg0-x264.google.com [IPv6:2607:f8b0:400d:c04::264]) (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 1F9151A90FD for ; Tue, 2 Feb 2016 15:56:57 -0800 (PST) Received: by mail-qg0-x264.google.com with SMTP id o11so622985qge.3 for ; Tue, 02 Feb 2016 15:56:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verisign-com.20150623.gappssmtp.com; s=20150623; h=from:to:subject:thread-topic:thread-index:date:message-id :accept-language:content-language:user-agent:content-type :mime-version; bh=2GcQmnVKFB2aVsPgk9aicDEjRXQzb21AWapixLepZ90=; b=f1uT5b7AhtNfZyiDmfo7dT2FUh/rBGxvhxK41LdQu5YAwJ0uf//gYOSlX0arAh8deK FWVTxJwFV36sw3rX2ikML57ZAkwBMcSBfPeKL6d06fyZpytp0s1DdXKZYdDhBryNS7gh LIexwPrhFNNqKve5jcuIvn2/ohy4vtqPMLp1Gvw/iaNqK9Vv8tHW2GFRzd069n/kBEcv psX9tTgPaDjiaoEeDqisGtcJT9/jIu8rNxc441MrAJCcyEe+JDKyixT6m4Ekk+hgYsHt 57HB8R1GcUVmemNoeOQ+k6kSyiYE95BBTgwgzyWR4vO1IsN0RjQREINFt0GVOyWwM3ZW agxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:accept-language:content-language:user-agent:content-type :mime-version; bh=2GcQmnVKFB2aVsPgk9aicDEjRXQzb21AWapixLepZ90=; b=LZTu6ofQSZsHL2jOvFCpN2ziARG2gxIG3wFQC+24R44onw+geMadTzxsCvfT2iLPaV Zcn2YR4NIXVJy/IVwxSEw0997dXJJpkR/6TrbKLWpgvfv4sjrMnu+mFN63xRnHtcpeDU GrzcnyNCgSHtoD6KNosodr2kTHfKubvKYrnVmNCoN3U4sus5YTQyLgsfiRKyNDvT5GU6 /0V/luujydMeIpNz9Uzk/oCtR/mlrxvrvGvzvg4rOMYwiSQmTNKAYj9Jfih8JwxMENud VWOn7aJqmgELdA/hnrOgnZqa2Y+X6X2W2El4kzSGL9ukF96GthRbT2Cok3ud14hp2rKI /Iag== X-Gm-Message-State: AG10YORbbfQg8HpefQh1TGrPNhoD5YY9zSEbi9rshW91NRUOYqLfDrykzAITmWPVShg8xdcY1wQjT7mGdaLUbwDvC1s5WC9n X-Received: by 10.140.130.85 with SMTP id 82mr40395402qhc.15.1454457416238; Tue, 02 Feb 2016 15:56:56 -0800 (PST) Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by smtp-relay.gmail.com with ESMTPS id e14sm517830qka.13.2016.02.02.15.56.56 for (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 02 Feb 2016 15:56:56 -0800 (PST) X-Relaying-Domain: verisign.com Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01 [10.173.152.205]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id u12NutUN022644 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 2 Feb 2016 18:56:55 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 2 Feb 2016 18:56:53 -0500 From: "Wiley, Glen" To: "dmarc@ietf.org" Thread-Topic: using DMARC to signal policy for email canonicalization, signing and encryption Thread-Index: AQHRXhVj1GvAhWOLPUqLVLnbuU0D6w== Date: Tue, 2 Feb 2016 23:56:52 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [10.173.152.4] Content-Type: multipart/alternative; boundary="_000_D2D6AC8224CA7gwileyverisigncom_" MIME-Version: 1.0 Archived-At: Subject: [dmarc-ietf] using DMARC to signal policy for email canonicalization, signing and encryption X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 23:56:59 -0000 --_000_D2D6AC8224CA7gwileyverisigncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In light of all of the discussion about how the LHS of email addresses are = normalized and encoded/hashed in order to be used to publish certificates a= nd keys via DANE records like SMIMEA and OPENPGPKEY we have put together an= approach that lets a zone owner signal the policy that is used for their d= omain by adding a few keywords to the DMARC record. The draft is at: https://datatracker.ietf.org/doc/draft-osterweil-dmarc-dan= e-names/ We welcome discussion about this approach. -- Glen Wiley Principal Engineer Verisign, Inc. (571) 230-7917 A5E5 E373 3C75 5B3E 2E24 6A0F DC65 2354 9946 C63A --_000_D2D6AC8224CA7gwileyverisigncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <68BA01764237B843A159FD74DB31C1EA@verisign.com> Content-Transfer-Encoding: quoted-printable
In light of all of the discussion about how the LHS of email addresses= are normalized and encoded/hashed in order to be used to publish certifica= tes and keys via DANE records like SMIMEA and OPENPGPKEY we have put togeth= er an approach that lets a zone owner signal the policy that is used for their domain by adding a few keyw= ords to the DMARC record.


We welcome discussion about this approach.
-- 
Glen Wiley
Principal Engineer
Verisign, Inc.
(571) 230-7917

A5E5 E373 3C75 5B= 3E 2E24 &n= bsp;
6A0F DC65 2354 99= 46 C63A
--_000_D2D6AC8224CA7gwileyverisigncom_-- From nobody Tue Feb 2 16:51:46 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE12B1ACE81 for ; Tue, 2 Feb 2016 16:51:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 v-p7Lt4-1M6C for ; Tue, 2 Feb 2016 16:51:43 -0800 (PST) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::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 3C4F31ACE80 for ; Tue, 2 Feb 2016 16:51:43 -0800 (PST) Received: by mail-qk0-x230.google.com with SMTP id x1so2590944qkc.1 for ; Tue, 02 Feb 2016 16:51:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Op4jiR2rJLKfztBoZd79MMsqDgRjWpKv/tsax1gRVUc=; b=G1bTQv+OQt/zbRY6LK6CxXlX/sk2bMeQriezY2maXiVnMr8gG73bVfp0h/h88aeLTn PV2Iq+RDKw08i/MeuYBft0vBCRg32LSRm1RjYpwzGg/V5FBqHzv4seaMbBwT+p1fywIl eNg95iFJRHvyv3N875Mdd7kChoomn+eiWORSA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Op4jiR2rJLKfztBoZd79MMsqDgRjWpKv/tsax1gRVUc=; b=J9nuqxExTO8txj/fKAzxI2h4SH/5EaWri3JtKsL6AhY0OcJTJRQ7f1ZEqgBSgg7aw2 SuBE63V4t/YPMdB7VZpWXMM8qDwP1YatVFtykacL01qNl8dfXmaqpUO8D/d4B7A6679m 7WW4ityKpBG0i3W0SKXz56kUbWHZL9cx48l+k17JKt8B1cqZcnureJnbXrx6U7OgPqDT UKSeSNpD1aZelQAWZBY95kX6XVdL9aszmdJyTQw/sXbpt/DSPEaxV3Af6i92/keeNubo 3SF6UAU40YyDQa0B22EyV/V7qZODCaeXslmLtNuzIZxspxq0J+s1UzDzfjshWiCyUaWz y3uw== X-Gm-Message-State: AG10YORio83neGXfolfum2kahWUu3ceM/J9FT3Y6vlaDi3wZEkemVD//BkZhoGw/W31F2GgxFB9FD3dZWdcK/A== MIME-Version: 1.0 X-Received: by 10.55.22.204 with SMTP id 73mr38359419qkw.41.1454460702374; Tue, 02 Feb 2016 16:51:42 -0800 (PST) Sender: kurta@drkurt.com Received: by 10.55.44.129 with HTTP; Tue, 2 Feb 2016 16:51:42 -0800 (PST) In-Reply-To: References: Date: Tue, 2 Feb 2016 16:51:42 -0800 X-Google-Sender-Auth: 1gB3h2qWWC498GlT32w0pEKLjyM Message-ID: From: "Kurt Andersen (b)" To: "Wiley, Glen" Content-Type: multipart/alternative; boundary=001a114916ac8156c2052ad30540 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] using DMARC to signal policy for email canonicalization, signing and encryption X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 00:51:45 -0000 --001a114916ac8156c2052ad30540 Content-Type: text/plain; charset=UTF-8 On Tue, Feb 2, 2016 at 3:56 PM, Wiley, Glen wrote: > . . .we have put together an approach that lets a zone owner signal the > policy that is used for their domain by adding a few keywords to the DMARC > record. > > The draft is at: > https://datatracker.ietf.org/doc/draft-osterweil-dmarc-dane-names/ > Section 1.2 of your I-D says: > The previous specification of DMARC is almost entirely relevant to the MTA > and transparent to the end user. The additions in this document are also > relevant to the MUA. . . I'm not sure that mixing the features to be used by the MUA into the MTA oriented specs for DMARC makes sense. For instance what would a receiver be expected to do if they attempted to lookup an encoded recipient and could not find the cited record? Would you expect them to enforce a non-pass policy against that message? I think it would be more appropriate to communicate this information at a distinct end service point in the DNS - for example _mailenc. rather than overloading the DMARC semantics with something that only has a peripheral relationship to message domain authentication. Your proposal seems more in the vein of "Encryption-Based Message Authentication, Reporting and Conformance". --Kurt Andersen --001a114916ac8156c2052ad30540 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Feb 2, 2016 at 3:56 PM, Wiley, Glen <gwiley@verisign.com> wrote:
. . .we have put together an approach that lets a zone owner signal the policy that is used for their domain by adding a few keyw= ords to the DMARC record.

<= /blockquote>
=C2=A0
Section 1.2 of your I-D says:=C2=A0
=
The previous specification of DMARC is almost entirely rel= evant to the MTA and transparent to the end user.=C2=A0 The additions in th= is document are also relevant to the MUA. . .

I'm not sure that mixing the features to be used by the MUA into the= MTA oriented specs for DMARC makes sense. For instance what would a receiv= er be expected to do if they attempted to lookup an encoded recipient and c= ould not find the cited record? Would you expect them to enforce a non-pass= policy against that message?

I think it would be = more appropriate to communicate this information at a distinct end service = point in the DNS - for example _mailenc.<domain> rather than overload= ing the DMARC semantics with something that only has a peripheral relations= hip to message domain authentication. Your proposal seems more in the vein = of "Encryption-Based Message Authentication, Reporting and Conformance= ".

--Kurt Andersen=C2=A0
--001a114916ac8156c2052ad30540-- From nobody Tue Feb 2 17:37:15 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B65201B2CD4 for ; Tue, 2 Feb 2016 17:37:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.863 X-Spam-Level: X-Spam-Status: No, score=0.863 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, KHOP_DYNAMIC=0.001, SPF_PASS=-0.001] autolearn=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 dOvKNqsiA751 for ; Tue, 2 Feb 2016 17:37:13 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4399E1B2BE9 for ; Tue, 2 Feb 2016 17:37:13 -0800 (PST) Received: (qmail 80796 invoked from network); 3 Feb 2016 01:37:11 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 3 Feb 2016 01:37:11 -0000 Date: 3 Feb 2016 01:36:48 -0000 Message-ID: <20160203013648.60063.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: gwiley@verisign.com Subject: Re: [dmarc-ietf] using DMARC to signal policy for email canonicalization, signing and encryption X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 01:37:14 -0000 In article you write: >-=-=-=-=-=- >-=-=-=-=-=- > >In light of all of the discussion about how the LHS of email addresses are normalized and encoded/hashed in order to be used to >publish certificates and keys via DANE records like SMIMEA and OPENPGPKEY we have put together an approach that lets a zone owner >signal the policy that is used for their domain by adding a few keywords to the DMARC record. > >The draft is at: https://datatracker.ietf.org/doc/draft-osterweil-dmarc-dane-names/ Since this is a a draft about mail operations, I would strongly suggest that you post it to the ietf-smtp list, where people with experience in nontrival mail systems hang out. In particular, you might ask about "canonicalization policy of LHS portions of email addresses", and to move things along, you might want to review RFC 5321 and find a better term than LHS. I also share Kurt's concern that it seems like a bad idea to mix advice intended for MUAs with the existing DMARC advice which is purely for MTAs. R's, John From nobody Wed Feb 3 05:35:54 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F5CF1A8A0B for ; Wed, 3 Feb 2016 05:35:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=ham 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 Gsy_n7juQBb7 for ; Wed, 3 Feb 2016 05:35:49 -0800 (PST) Received: from mail-qg0-x263.google.com (mail-qg0-x263.google.com [IPv6:2607:f8b0:400d:c04::263]) (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 D66B91A8A04 for ; Wed, 3 Feb 2016 05:35:48 -0800 (PST) Received: by mail-qg0-x263.google.com with SMTP id t74so2248370qgt.2 for ; Wed, 03 Feb 2016 05:35:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verisign-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language:user-agent :content-type:mime-version; bh=8Su5NnSHozaJVpy4TUGcdiT9U6dUYWheQSIL9lx+d8c=; b=0fTtBv0IW9jg3k6p4kqJge25DRq9OVkTEpLCyq2YPohvQRBXOEyL7IjX3+rIup6czj OrWYdHySL9Por/uP6yzAKfWZ03rNDwmSaWstRLMhrmPS+Gs8+vGHTHDxbRJxLnBwrOiO 1kVc7VMNHVMeBrqStRDBOZ2Y+wysktVHlu2meLrGeFI2ciAd3SA/R7WwG3RksuxI8h1o tOvpfXW5w+WSQTF+vBAb9s24n2P15VFXb6N6u0WuPhZf56rtQLvmNRkrq5VSY7VIANBf h9CqW1q2oQ4TUqCcaHbdIZitf/S668s3uYpkT3c0SqzKUaKvPqaI7rEdo6sJWhc4M3ME +1LQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:user-agent:content-type:mime-version; bh=8Su5NnSHozaJVpy4TUGcdiT9U6dUYWheQSIL9lx+d8c=; b=Ll+SfW5pEWkRBn0+1uUtouUWJKgQJmA3dsM0N2W41eGsSpBG7Y3AKQGKUYRJCoOV8u PoQ35Fpi8PNqxu8GRbJ2oAxugLDZLHrHyraV+fZR6xOeNPXkyjF5sWYHYw7Yp3pU6QIn uo/hwsjERf/+hsN6QwOm4YQVsAGYdIdAsiU5GwUQQTcLBnYSLJsDymPkUzw4AzbMTtfb sWR4hQlq3Euacjmuh4NrFdjYyjP7ZcGuGf/MmqcRyua8sp/VGMbSvaqwKL1JGAhY93G6 w2iv7e6W0bIbqGJ351SufNXAG+UWUsTNYvrBhUsMsurcc6JftERaCm6jYmvSFIkVyFjl VIFg== X-Gm-Message-State: AG10YOQ5SPoyaQv2yqk/P8jD/PRoWZ7fe7xaXVaTEv+9vuGz6yvuBJCSKfXDFv58RvRwVswSF2r8XWO+YLRRQ44uJne+XBXv X-Received: by 10.55.77.17 with SMTP id a17mr1560876qkb.40.1454506547833; Wed, 03 Feb 2016 05:35:47 -0800 (PST) Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by smtp-relay.gmail.com with ESMTPS id v20sm849906qka.8.2016.02.03.05.35.47 (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 03 Feb 2016 05:35:47 -0800 (PST) X-Relaying-Domain: verisign.com Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02 [10.173.152.206]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id u13DZlYb019366 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 3 Feb 2016 08:35:47 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Wed, 3 Feb 2016 08:35:44 -0500 From: "Wiley, Glen" To: "Kurt Andersen (b)" Thread-Topic: [dmarc-ietf] using DMARC to signal policy for email canonicalization, signing and encryption Thread-Index: AQHRXhVj1GvAhWOLPUqLVLnbuU0D658Z0b8AgACBtYA= Date: Wed, 3 Feb 2016 13:35:44 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [10.173.152.4] Content-Type: multipart/alternative; boundary="_000_D2D7699D24CD5gwileyverisigncom_" MIME-Version: 1.0 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] using DMARC to signal policy for email canonicalization, signing and encryption X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 13:35:51 -0000 --_000_D2D7699D24CD5gwileyverisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks Kurt. Let me see if I can articulate our reasons for proposing DMAR= C as the signaling mechanism more clearly. 1. Although this proposal appears to be an MUA feature, it has meaningfu= l relevance to the typical transfer agent as well. If it is fair to summar= ize DMARC as a means for reducing the delivery of forged email then this pr= oposal fits in nicely. If an MTA can determine for example that a domain e= nforces a policy of signing all outbound messages (by the email sender, not= using DKIM) and can easily locate the sender=92s signing key with an appr= opriate chain of trust then the MTA can make a reliable decision about whet= her that email originated from the sender=92s domain. This =93feels=94 ver= y similar to the way we use SPF and DKIM now. 2. Signaling mechanisms are most effective when they can leverage a beac= hhead already established by a deployed technology. DMARC has a growing de= ployed base with building momentum so it makes an attractive mechanism for = signaling. If a domain originating email signals a policy that all outbound messages a= re signed and the recipient is unable to validate that signature then the r= ecipient should do something interesting with the message. Bear in mind th= at the domain originating the records will have published the keys using a = DNSSEC signed domain and will have published keys/certs for the users who o= riginate mail from the domain. There would need to be a DNS resolution fai= lure in order for a recipient to not be able to locate the key. Although t= here are currently still some deficiencies in the DNSSEC deployment, the op= erational picture for DNSSEC is continuing to improve. This proposal antici= pates DNSSEC reaching critical mass. -- Glen Wiley Principal Engineer Verisign, Inc. (571) 230-7917 A5E5 E373 3C75 5B3E 2E24 6A0F DC65 2354 9946 C63A From: "Kurt Andersen (b)" > Date: Tuesday, February 2, 2016 at 7:51 PM To: Wiley Glen > Cc: "dmarc@ietf.org" > Subject: Re: [dmarc-ietf] using DMARC to signal policy for email canonicali= zation, signing and encryption On Tue, Feb 2, 2016 at 3:56 PM, Wiley, Glen > wrote: . . .we have put together an approach that lets a zone owner signal the pol= icy that is used for their domain by adding a few keywords to the DMARC rec= ord. The draft is at: https://datatracker.ietf.org/doc/draft-osterweil-dmarc-dan= e-names/ Section 1.2 of your I-D says: The previous specification of DMARC is almost entirely relevant to the MTA = and transparent to the end user. The additions in this document are also r= elevant to the MUA. . . I'm not sure that mixing the features to be used by the MUA into the MTA or= iented specs for DMARC makes sense. For instance what would a receiver be e= xpected to do if they attempted to lookup an encoded recipient and could no= t find the cited record? Would you expect them to enforce a non-pass policy= against that message? I think it would be more appropriate to communicate this information at a d= istinct end service point in the DNS - for example _mailenc. rather= than overloading the DMARC semantics with something that only has a periph= eral relationship to message domain authentication. Your proposal seems mor= e in the vein of "Encryption-Based Message Authentication, Reporting and Co= nformance". --Kurt Andersen --_000_D2D7699D24CD5gwileyverisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <15CF5D3FD6FC514B9F645F18D660736C@verisign.com> Content-Transfer-Encoding: quoted-printable
Thanks Kurt.  Let me see if I can articulate our reasons for prop= osing DMARC as the signaling mechanism more clearly.

  1. Although this proposal appears to be an MUA feature, it has meaningful = relevance to the typical transfer agent as well.  If it is fair to sum= marize DMARC as a means for reducing the delivery of forged email then this= proposal fits in nicely.  If an MTA can determine for example that a domain enforces a policy of signing all o= utbound messages (by the email sender, not using DKIM) and can easily locat= e the sender=92s signing  key with an appropriate chain of trust then = the MTA can make a reliable decision about whether that email originated from the sender=92s domain.  This =93fe= els=94 very similar to the way we use SPF and DKIM now. 
  2. Signa= ling mechanisms are most effective when they can leverage a beachhead alrea= dy established by a deployed technology.  DMARC has a growing deployed= base with building momentum so it makes an attractive mechanism for signal= ing.
If a domain originating email signals a policy that all outbound messa= ges are signed and the recipient is unable to validate that signature then = the recipient should do something interesting with the message.  Bear = in mind that the domain originating the records will have published the keys using a DNSSEC signed domain and will= have published keys/certs for the users who originate mail from the domain= .  There would need to be a DNS resolution failure in order for a reci= pient to not be able to locate the key.  Although there are currently still some deficiencies in the DNSSEC d= eployment, the operational picture for DNSSEC is continuing to improve. Thi= s proposal anticipates DNSSEC reaching critical mass.
-- 
Glen Wiley
Principal Engineer
Verisign, Inc.
(571) 230-7917

A5E5 E373 3C75 5B= 3E 2E24 &n= bsp;
6A0F DC65 2354 99= 46 C63A

From: "Kurt Andersen (b)"= <kboth@drkurt.com>
Date: Tuesday, February 2, 2016 at = 7:51 PM
To: Wiley Glen <gwiley@verisign.com>
Cc: "dmarc@ietf.org" <dma= rc@ietf.org>
Subject: Re: [dmarc-ietf] using DMA= RC to signal policy for email canonicalization, signing and encryption

On Tue, Feb 2, 2016 at 3:56 PM, Wiley, Glen <gwiley@verisig= n.com> wrote:
. . .we have put together an approach that lets a zone owner signal th= e policy that is used for their domain by adding a few keywords to the DMAR= C record.

 
Section 1.2 of your I-D says: 
The previous specification of DMARC is almost entirely relevant to the MTA = and transparent to the end user.  The additions in this document are a= lso relevant to the MUA. . .

I'm not sure that mixing the features to be used by the MUA into the M= TA oriented specs for DMARC makes sense. For instance what would a receiver= be expected to do if they attempted to lookup an encoded recipient and cou= ld not find the cited record? Would you expect them to enforce a non-pass policy against that message?

I think it would be more appropriate to communicate this information a= t a distinct end service point in the DNS - for example _mailenc.<domain= > rather than overloading the DMARC semantics with something that only h= as a peripheral relationship to message domain authentication. Your proposal seems more in the vein of "Encry= ption-Based Message Authentication, Reporting and Conformance".

--Kurt Andersen 
 --_000_D2D7699D24CD5gwileyverisigncom_-- From nobody Wed Feb 3 05:36:55 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE0C91A8A1D for ; Wed, 3 Feb 2016 05:36:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham 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 8mDo1kFqdNUh for ; Wed, 3 Feb 2016 05:36:52 -0800 (PST) Received: from mail-qg0-x263.google.com (mail-qg0-x263.google.com [IPv6:2607:f8b0:400d:c04::263]) (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 BC1841A8A04 for ; Wed, 3 Feb 2016 05:36:51 -0800 (PST) Received: by mail-qg0-x263.google.com with SMTP id t74so2251005qgt.2 for ; Wed, 03 Feb 2016 05:36:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verisign-com.20150623.gappssmtp.com; s=20150623; h=from:to:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language:user-agent :content-type:content-id:content-transfer-encoding:mime-version; bh=VFB7LvMHH1BJlJxwwP1Y1r8/sc1b3c97vEoVbmf5ioQ=; b=FCcYUlFiGYnlAqq0JyBGSH1ZEkL+pfHylsluvTCorOKA4+MjZNqS/IfKTdZdBCXYzw NeRZHYTwYUruLolrC9Xb5hQibwes0yfEwD1DozP/kTyRMehRkRSnGxhxLaNIyJFXzK07 qVYAhyTIvXY4/7ofbU37Qe1rWoM5htjjPG1b7xWfyO5DTqOj0whhgb+BrbvpC0mD/ETm mWP8374TggARNqDrjzWw3whoepDQ4sWFKnuVrK1ehlPHLILRfKh/K9iO3QMNjw3pRKfL QwUd0n7nVqTd+YMhy49whDxIeK1V97LFkjuANG1Pr+jewnRA5+ECJ/ISGUBbB2jC0ZmZ dMIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :user-agent:content-type:content-id:content-transfer-encoding :mime-version; bh=VFB7LvMHH1BJlJxwwP1Y1r8/sc1b3c97vEoVbmf5ioQ=; b=BG38umkb/CEhb1ancUvYo6RJP+7PpOfadt5IXD4MErEU/evmNFe6sTFgue+kRUz6f9 bLb7GaEUrQLMOj1Ui14PL8mL/Qc0k/hYKVewB1GHT43ZICeCof3ANxCv/7QGugIp00VV Eauucwt6vjvgmw0T5pLg1SYVoZZJQdWwU46hiWqRAOxxksXk4iThdkjSdq/UULNYBibU jgXPgUsrTpHasq68I+rIZXFi0wn9roC/0x7zQ0JViFR+SuRILzpOtFqVXqM695cwXxRl ds4Lw95tia0Lz4zN3E2kNZgRGa89TkNFnE81/XJFp7eN/g5S+mP74jMp+nZ+KwJ5v8Ji AWcg== X-Gm-Message-State: AG10YOSPPeBXK+9binobWbzVW080/lgI0ooYzOXQRUwWvDbvCRQmIMJFOUt2wRJdM6jMb94S4pe0DOzLsUm6cRtsth/QyEAI X-Received: by 10.55.20.4 with SMTP id e4mr1528577qkh.74.1454506611001; Wed, 03 Feb 2016 05:36:51 -0800 (PST) Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by smtp-relay.gmail.com with ESMTPS id x75sm927056qkx.7.2016.02.03.05.36.50 (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 03 Feb 2016 05:36:50 -0800 (PST) X-Relaying-Domain: verisign.com Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01 [10.173.152.255]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id u13DaoGn019503 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 3 Feb 2016 08:36:50 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Wed, 3 Feb 2016 08:36:49 -0500 From: "Wiley, Glen" To: John Levine , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] using DMARC to signal policy for email canonicalization, signing and encryption Thread-Index: AQHRXhVj1GvAhWOLPUqLVLnbuU0D658Z3lgAgAB1agA= Date: Wed, 3 Feb 2016 13:36:48 +0000 Message-ID: References: <20160203013648.60063.qmail@ary.lan> In-Reply-To: <20160203013648.60063.qmail@ary.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [dmarc-ietf] using DMARC to signal policy for email canonicalization, signing and encryption X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 13:36:54 -0000 Thanks for taking the time to look at the draft John. I=B9ll post this to the smtp list as well. I just responded to Kurt=B9s concerns and would like to hear your opinion o= n the answers. --=20 Glen Wiley Principal Engineer Verisign, Inc. (571) 230-7917 A5E5 E373 3C75 5B3E 2E24 6A0F DC65 2354 9946 C63A On 2/2/16, 8:36 PM, "John Levine" wrote: >In article you write: >>-=3D-=3D-=3D-=3D-=3D- >>-=3D-=3D-=3D-=3D-=3D- >> >>In light of all of the discussion about how the LHS of email addresses >>are normalized and encoded/hashed in order to be used to >>publish certificates and keys via DANE records like SMIMEA and >>OPENPGPKEY we have put together an approach that lets a zone owner >>signal the policy that is used for their domain by adding a few keywords >>to the DMARC record. >> >>The draft is at:=20 >>https://datatracker.ietf.org/doc/draft-osterweil-dmarc-dane-names/ > >Since this is a a draft about mail operations, I would strongly >suggest that you post it to the ietf-smtp list, where people with >experience in nontrival mail systems hang out. > >In particular, you might ask about "canonicalization policy of LHS >portions of email addresses", and to move things along, you might want >to review RFC 5321 and find a better term than LHS. > >I also share Kurt's concern that it seems like a bad idea to mix >advice intended for MUAs with the existing DMARC advice which is >purely for MTAs. > >R's, >John From nobody Wed Feb 3 13:55:59 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 764811B30E0 for ; Wed, 3 Feb 2016 13:55:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 3MCNQOkr33b8 for ; Wed, 3 Feb 2016 13:55:55 -0800 (PST) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8F111B30EC for ; Wed, 3 Feb 2016 13:55:54 -0800 (PST) Received: by mail-ig0-x229.google.com with SMTP id ik10so143830igb.1 for ; Wed, 03 Feb 2016 13:55:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6SptGhuhtfAjPsxGybs0FcHnS06I4zZnFJYnfLVnnM8=; b=G0YRXNpSOdInrhEBL+CiFqpUVFmQGLkSjktIBBrcXKX5igagOA+u2x6zAZ0g7rkR5T nx/j2FOXyDCTmsO6GKtGjZvrJ+t4neDpDVOF9gB7Z1hk7cdbIA7a9Z+wQ96IBtZGknW0 hvGloo2V8Qgy+JJuJ67GwFhIAj8EQQbrpBivMBbB4o8TDIqBEjKs8veGxV5+GsIJfwBS WLsZXogalFaJkxjFnzVN87wneesPDMVRA4ZuyHa/SZaMdsdxDE+YDDHeiWhDdVnzNXCK bf25mc4ddUMLt9zBHI9jNCy8XPO5QjIR4cx4i73jv1HavnwAPbvZSFW13s8TREvDjeEJ 2x+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=6SptGhuhtfAjPsxGybs0FcHnS06I4zZnFJYnfLVnnM8=; b=C0dhyFSlCG06AqmGJ+HJTFSyqv2NHz/wazCCKi734Qh0vCeb7NnZH3bS0AYR0iFDzL et5Oso9mS0Me0adEFY5RUMjKED12htUjGtnPKqsv2reTanN+jr9k64/ilOxFviCBt54I URK4HsnqmKmeurDiUtNhiZYi7Z+Tzm7BktQ4aV4X4Dh/ILfInZYZUfwITLDpiSV/9Ji6 3tpgxgO+5GmpnM8uBWLfiDBZ/Bp1ZkDWQRRr74Q6qLQyM2y8QC9AJ/QuvpQ/xXBTJQc/ 5Atfi3HAi96CS9TFku5ElqatTfwqG1MLSI3G8M2qIZ0tVC0DjmACF/QidlJ9NV6/sqMw 5/nQ== X-Gm-Message-State: AG10YOT5kE4KAfmN03DVyq1BSzhjJGbUf4zThFULtuWA/ky3SfSYtMaBxnKR/alnVRF5FmWy6Ko/gw3UAwcStFrs MIME-Version: 1.0 X-Received: by 10.50.32.103 with SMTP id h7mr6203566igi.34.1454536553881; Wed, 03 Feb 2016 13:55:53 -0800 (PST) Received: by 10.64.62.194 with HTTP; Wed, 3 Feb 2016 13:55:53 -0800 (PST) In-Reply-To: References: Date: Wed, 3 Feb 2016 13:55:53 -0800 Message-ID: From: Brandon Long To: "Wiley, Glen" Content-Type: multipart/alternative; boundary=047d7b10c8bb9bf135052ae4ae18 Archived-At: Cc: "dmarc@ietf.org" , "Kurt Andersen \(b\)" Subject: Re: [dmarc-ietf] using DMARC to signal policy for email canonicalization, signing and encryption X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 21:55:57 -0000 --047d7b10c8bb9bf135052ae4ae18 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable As far as adding S/MIME or SMIMEA as an authentication mechanism, ie to make DMARC act on "SPF/DKIM/SMIME" authentication, then adding it to DMARC makes sense. To include other domain email information that is unrelated to the underlying p=3DREJECT/QUARANTINE concept, doesn't make sense. Brandon On Wed, Feb 3, 2016 at 5:35 AM, Wiley, Glen wrote: > Thanks Kurt. Let me see if I can articulate our reasons for proposing > DMARC as the signaling mechanism more clearly. > > > 1. Although this proposal appears to be an MUA feature, it has > meaningful relevance to the typical transfer agent as well. If it is = fair > to summarize DMARC as a means for reducing the delivery of forged emai= l > then this proposal fits in nicely. If an MTA can determine for exampl= e > that a domain enforces a policy of signing all outbound messages (by t= he > email sender, not using DKIM) and can easily locate the sender=E2=80= =99s signing > key with an appropriate chain of trust then the MTA can make a reliab= le > decision about whether that email originated from the sender=E2=80=99s= domain. > This =E2=80=9Cfeels=E2=80=9D very similar to the way we use SPF and DK= IM now. > 2. Signaling mechanisms are most effective when they can leverage a > beachhead already established by a deployed technology. DMARC has a > growing deployed base with building momentum so it makes an attractive > mechanism for signaling. > > If a domain originating email signals a policy that all outbound messages > are signed and the recipient is unable to validate that signature then th= e > recipient should do something interesting with the message. Bear in mind > that the domain originating the records will have published the keys usin= g > a DNSSEC signed domain and will have published keys/certs for the users w= ho > originate mail from the domain. There would need to be a DNS resolution > failure in order for a recipient to not be able to locate the key. > Although there are currently still some deficiencies in the DNSSEC > deployment, the operational picture for DNSSEC is continuing to improve. > This proposal anticipates DNSSEC reaching critical mass. > -- > Glen Wiley > Principal Engineer > Verisign, Inc. > (571) 230-7917 > > A5E5 E373 3C75 5B3E 2E24 > 6A0F DC65 2354 9946 C63A > > From: "Kurt Andersen (b)" > Date: Tuesday, February 2, 2016 at 7:51 PM > To: Wiley Glen > Cc: "dmarc@ietf.org" > Subject: Re: [dmarc-ietf] using DMARC to signal policy for email > canonicalization, signing and encryption > > On Tue, Feb 2, 2016 at 3:56 PM, Wiley, Glen wrote: > >> . . .we have put together an approach that lets a zone owner signal the >> policy that is used for their domain by adding a few keywords to the DMA= RC >> record. >> >> The draft is at: >> https://datatracker.ietf.org/doc/draft-osterweil-dmarc-dane-names/ >> > > Section 1.2 of your I-D says: > >> The previous specification of DMARC is almost entirely relevant to the >> MTA and transparent to the end user. The additions in this document are >> also relevant to the MUA. . . > > > I'm not sure that mixing the features to be used by the MUA into the MTA > oriented specs for DMARC makes sense. For instance what would a receiver = be > expected to do if they attempted to lookup an encoded recipient and could > not find the cited record? Would you expect them to enforce a non-pass > policy against that message? > > I think it would be more appropriate to communicate this information at a > distinct end service point in the DNS - for example _mailenc. > rather than overloading the DMARC semantics with something that only has = a > peripheral relationship to message domain authentication. Your proposal > seems more in the vein of "Encryption-Based Message Authentication, > Reporting and Conformance". > > --Kurt Andersen > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --047d7b10c8bb9bf135052ae4ae18 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As far as adding S/MIME or SMIMEA as an authentication mec= hanism, ie to make DMARC act on "SPF/DKIM/SMIME" authentication, = then adding it to DMARC makes sense.

To include other do= main email information that is unrelated to the underlying p=3DREJECT/QUARA= NTINE concept, doesn't make sense.

Brandon
=

On Wed, Feb 3, 20= 16 at 5:35 AM, Wiley, Glen <gwiley@verisign.com> wrote:
Thanks Kurt.=C2=A0 Let me see if I can articulate our reasons for prop= osing DMARC as the signaling mechanism more clearly.

  1. Although this proposal appears to be an MUA feature, it has meaningful = relevance to the typical transfer agent as well.=C2=A0 If it is fair to sum= marize DMARC as a means for reducing the delivery of forged email then this= proposal fits in nicely.=C2=A0 If an MTA can determine for example that a domain enforces a policy of signing all o= utbound messages (by the email sender, not using DKIM) and can easily locat= e the sender=E2=80=99s signing =C2=A0key with an appropriate chain of trust= then the MTA can make a reliable decision about whether that email originated from the sender=E2=80=99s domain.=C2=A0 This= =E2=80=9Cfeels=E2=80=9D very similar to the way we use SPF and DKIM now.= =C2=A0
  2. Signaling mechanisms are most effective when they can levera= ge a beachhead already established by a deployed technology.=C2=A0 DMARC ha= s a growing deployed base with building momentum so it makes an attractive = mechanism for signaling.
If a domain originating email signals a policy that all outbound messa= ges are signed and the recipient is unable to validate that signature then = the recipient should do something interesting with the message.=C2=A0 Bear = in mind that the domain originating the records will have published the keys using a DNSSEC signed domain and will= have published keys/certs for the users who originate mail from the domain= .=C2=A0 There would need to be a DNS resolution failure in order for a reci= pient to not be able to locate the key. =C2=A0Although there are currently still some deficiencies in the DNSSEC d= eployment, the operational picture for DNSSEC is continuing to improve. Thi= s proposal anticipates DNSSEC reaching critical mass.
--=C2=A0
Glen Wiley
Principal Engineer
Verisign, Inc.

A5E5 E373 3C75 5B3E 2= E24=C2=A0=C2=A0
6A0F DC65 2354 9946 C= 63A

From: "Kurt Andersen (b)"= <kboth@drkurt.com= >
Date: Tuesday, February 2, 2016 at = 7:51 PM
To: Wiley Glen <gwiley@verisign.com>
Cc: "dmarc@ietf.org" <dmarc@ietf.org>
Subject: Re: [dmarc-ietf] using DMA= RC to signal policy for email canonicalization, signing and encryption

On Tue, Feb 2, 2016 at 3:56 PM, Wiley, Glen <gwiley@verisig= n.com> wrote:
. . .we have put together an approach that lets a zone owner signal th= e policy that is used for their domain by adding a few keywords to the DMAR= C record.

=C2=A0
Section 1.2 of your I-D says:=C2=A0
The previous specification of DMARC is almost entirely relevant to the MTA = and transparent to the end user.=C2=A0 The additions in this document are a= lso relevant to the MUA. . .

I'm not sure that mixing the features to be used by the MUA into t= he MTA oriented specs for DMARC makes sense. For instance what would a rece= iver be expected to do if they attempted to lookup an encoded recipient and= could not find the cited record? Would you expect them to enforce a non-pass policy against that message?

I think it would be more appropriate to communicate this information a= t a distinct end service point in the DNS - for example _mailenc.<domain= > rather than overloading the DMARC semantics with something that only h= as a peripheral relationship to message domain authentication. Your proposal seems more in the vein of "Encry= ption-Based Message Authentication, Reporting and Conformance".

--Kurt Andersen=C2=A0

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


--047d7b10c8bb9bf135052ae4ae18-- From nobody Wed Feb 3 16:26:05 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6D471B3775 for ; Wed, 3 Feb 2016 16:26:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 aZ1Hh8Svmb8h for ; Wed, 3 Feb 2016 16:25:58 -0800 (PST) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id 800301B3774 for ; Wed, 3 Feb 2016 16:25:58 -0800 (PST) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id B3BDF563DC0; Wed, 3 Feb 2016 18:25:52 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 9692DA0330; Wed, 3 Feb 2016 18:25:52 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhGpeo7BEy8I; Wed, 3 Feb 2016 18:25:52 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 335BCA03A2; Wed, 3 Feb 2016 18:25:52 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-1.01.com 335BCA03A2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1454545552; bh=cSBkC+pEwSFMhy1ombwnAh0toF8/98N3Q/2coBGU6Jk=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; b=ojHxsazDc+gInoc7DxFXPxRyYkynhr798xENcjIDEdF+yyCF4pF1cigFm7bRIJkva c13Jq9e4qfPES0VIan/hxqkxx7bZrUiZ8ClxxPow8dT/TVoaMxCuKkvN42a3AZgNlv tDjNdPWVoy7CL/a+h5kt5pu19k7AmfUqJFTftII0= Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 18092A0390; Wed, 3 Feb 2016 18:25:52 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id W10IDQ6WMAGm; Wed, 3 Feb 2016 18:25:51 -0600 (CST) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-1.01.com (Postfix) with ESMTP id 653DCA0330; Wed, 3 Feb 2016 18:25:51 -0600 (CST) Date: Wed, 3 Feb 2016 18:25:50 -0600 (CST) From: Franck Martin To: Brandon Long Message-ID: <246588976.38105.1454545550181.JavaMail.zimbra@peachymango.org> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_38104_1060276426.1454545550181" X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF43 (Mac)/8.0.5_GA_5839) Thread-Topic: using DMARC to signal policy for email canonicalization, signing and encryption Thread-Index: o6CDmuGb05Ktl8zoEtvGcIpG3RtqQg== Archived-At: Cc: Glen Wiley , dmarc@ietf.org, "Kurt Andersen \(b\)" Subject: Re: [dmarc-ietf] using DMARC to signal policy for email canonicalization, signing and encryption X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 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, 04 Feb 2016 00:26:01 -0000 ------=_Part_38104_1060276426.1454545550181 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Or TLS, plenty emails on our systems provide a client certificate to our se= rvers. The domain in the CN=3D could be used for alignment.=20 I don't know if this is useful, as usually the emails have SPF or DKIM, but= I see a sizeable portion of emails with no SPF nor DKIM providing a client= TLS certificate signed by a trusted CA, and and an equivalent portion with= self signed certificates.=20 Overall it would cut by about half the number of unauthenticated emails (th= e ones with no valid SPF nor valid DKIM) if I would count the client TLS ce= rtificate as an authentication.=20 ----- Original Message ----- From: "Brandon Long" =20 To: "Glen Wiley" =20 Cc: dmarc@ietf.org, "Kurt Andersen (b)" =20 Sent: Wednesday, February 3, 2016 1:55:53 PM=20 Subject: Re: [dmarc-ietf] using DMARC to signal policy for email canonicali= zation, signing and encryption=20 As far as adding S/MIME or SMIMEA as an authentication mechanism, ie to mak= e DMARC act on "SPF/DKIM/SMIME" authentication, then adding it to DMARC mak= es sense.=20 To include other domain email information that is unrelated to the underlyi= ng p=3DREJECT/QUARANTINE concept, doesn't make sense.=20 Brandon=20 On Wed, Feb 3, 2016 at 5:35 AM, Wiley, Glen < gwiley@verisign.com > wrote:= =20 Thanks Kurt. Let me see if I can articulate our reasons for proposing DMARC= as the signaling mechanism more clearly.=20 1. Although this proposal appears to be an MUA feature, it has meaningf= ul relevance to the typical transfer agent as well. If it is fair to summar= ize DMARC as a means for reducing the delivery of forged email then this pr= oposal fits in nicely. If an MTA can determine for example that a domain en= forces a policy of signing all outbound messages (by the email sender, not = using DKIM) and can easily locate the sender=E2=80=99s signing key with an = appropriate chain of trust then the MTA can make a reliable decision about = whether that email originated from the sender=E2=80=99s domain. This =E2=80= =9Cfeels=E2=80=9D very similar to the way we use SPF and DKIM now.=20 2. Signaling mechanisms are most effective when they can leverage a bea= chhead already established by a deployed technology. DMARC has a growing de= ployed base with building momentum so it makes an attractive mechanism for = signaling.=20 If a domain originating email signals a policy that all outbound messages a= re signed and the recipient is unable to validate that signature then the r= ecipient should do something interesting with the message. Bear in mind tha= t the domain originating the records will have published the keys using a D= NSSEC signed domain and will have published keys/certs for the users who or= iginate mail from the domain. There would need to be a DNS resolution failu= re in order for a recipient to not be able to locate the key. Although ther= e are currently still some deficiencies in the DNSSEC deployment, the opera= tional picture for DNSSEC is continuing to improve. This proposal anticipat= es DNSSEC reaching critical mass.=20 --=20 Glen Wiley=20 Principal Engineer=20 Verisign, Inc.=20 (571) 230-7917=20 A5E5 E373 3C75 5B3E 2E24=20 6A0F DC65 2354 9946 C63A=20 From: "Kurt Andersen (b)" < kboth@drkurt.com >=20 Date: Tuesday, February 2, 2016 at 7:51 PM=20 To: Wiley Glen < gwiley@verisign.com >=20 Cc: " dmarc@ietf.org " < dmarc@ietf.org >=20 Subject: Re: [dmarc-ietf] using DMARC to signal policy for email canonicali= zation, signing and encryption=20 On Tue, Feb 2, 2016 at 3:56 PM, Wiley, Glen < gwiley@verisign.com > wrote:= =20
. . .we have put together an approach that lets a zone owner signal the pol= icy that is used for their domain by adding a few keywords to the DMARC rec= ord.=20 The draft is at: https://datatracker.ietf.org/doc/draft-osterweil-dmarc-dan= e-names/=20 Section 1.2 of your I-D says:=20
The previous specification of DMARC is almost entirely relevant to the MTA = and transparent to the end user. The additions in this document are also re= levant to the MUA. . .=20
I'm not sure that mixing the features to be used by the MUA into the MTA or= iented specs for DMARC makes sense. For instance what would a receiver be e= xpected to do if they attempted to lookup an encoded recipient and could no= t find the cited record? Would you expect them to enforce a non-pass policy= against that message?=20 I think it would be more appropriate to communicate this information at a d= istinct end service point in the DNS - for example _mailenc. rather= than overloading the DMARC semantics with something that only has a periph= eral relationship to message domain authentication. Your proposal seems mor= e in the vein of "Encryption-Based Message Authentication, Reporting and Co= nformance".=20 --Kurt Andersen=20 _______________________________________________=20 dmarc mailing list=20 dmarc@ietf.org=20 https://www.ietf.org/mailman/listinfo/dmarc=20
_______________________________________________=20 dmarc mailing list=20 dmarc@ietf.org=20 https://www.ietf.org/mailman/listinfo/dmarc=20 ------=_Part_38104_1060276426.1454545550181 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Or TLS, plenty emails on our systems provide = a client certificate to our servers. The domain in the CN=3D could be used = for alignment.

I don't know if this is useful= , as usually the emails have SPF or DKIM, but I see a sizeable portion of e= mails with no SPF nor DKIM providing a client TLS certificate signed by a t= rusted CA, and and an equivalent portion with self signed certificates.

Overall it would cut by about half the number of unau= thenticated emails (the ones with no valid SPF nor valid DKIM) if I would c= ount the client TLS certificate as an authentication.

From: "Brandon Long" <blong@google.com>
To:= "Glen Wiley" <gwiley@verisign.com>
Cc: dmarc@ietf.org,= "Kurt Andersen (b)" <kboth@drkurt.com>
Sent: Wednesday, Fe= bruary 3, 2016 1:55:53 PM
Subject: Re: [dmarc-ietf] using DMARC t= o signal policy for email canonicalization, signing and encryption
=
As far as adding S/MIME or SMIMEA as an authenti= cation mechanism, ie to make DMARC act on "SPF/DKIM/SMIME" authentication, = then adding it to DMARC makes sense.

To include other do= main email information that is unrelated to the underlying p=3DREJECT/QUARA= NTINE concept, doesn't make sense.

Brandon

On Wed, Feb 3, 2016 a= t 5:35 AM, Wiley, Glen <gwi= ley@verisign.com> wrote:
Thanks Kurt.  Let me see if I can articulate our reasons for proposi= ng DMARC as the signaling mechanism more clearly.

    <= li>Although this proposal appears to be an MUA feature, it has meaningful r= elevance to the typical transfer agent as well.  If it is fair to summ= arize DMARC as a means for reducing the delivery of forged email then this = proposal fits in nicely.  If an MTA can determine for example that a d= omain enforces a policy of signing all outbound messages (by the email send= er, not using DKIM) and can easily locate the sender=E2=80=99s signing &nbs= p;key with an appropriate chain of trust then the MTA can make a reliable d= ecision about whether that email originated from the sender=E2=80=99s domai= n.  This =E2=80=9Cfeels=E2=80=9D very similar to the way we use SPF an= d DKIM now. 
  1. Signaling mechanisms are most effective when they= can leverage a beachhead already established by a deployed technology.&nbs= p; DMARC has a growing deployed base with building momentum so it makes an = attractive mechanism for signaling.
If a domain originating e= mail signals a policy that all outbound messages are signed and the recipie= nt is unable to validate that signature then the recipient should do someth= ing interesting with the message.  Bear in mind that the domain origin= ating the records will have published the keys using a DNSSEC signed domain= and will have published keys/certs for the users who originate mail from t= he domain.  There would need to be a DNS resolution failure in order f= or a recipient to not be able to locate the key.  Although there are c= urrently still some deficiencies in the DNSSEC deployment, the operational = picture for DNSSEC is continuing to improve. This proposal anticipates DNSS= EC reaching critical mass.
-- 
Glen Wile= y
Principal Engineer
Verisign, Inc.
<= br>

A5E5 E373 3C75 5= B3E 2E24  
= 6A0F DC65 2354 9946 C63A

From: "Kurt Andersen (b)" <kboth@drkurt.com>
Date: Tuesday, February 2, 2016 at 7= :51 PM
To: Wiley Glen <gwiley@verisign= .com>
Cc: "dmarc@ietf.org" <dmarc@ietf.org>
Subject: Re: [dmarc-ietf] using DMA= RC to signal policy for email canonicalization, signing and encryption
<= /div>

On Tue, Feb 2, 2016 at 3:5= 6 PM, Wiley, Glen <gwiley@= verisign.com> wrote:
. . .we have put together= an approach that lets a zone owner signal the policy that is used for thei= r domain by adding a few keywords to the DMARC record.

=
 
Sectio= n 1.2 of your I-D says: 
The previous specification of= DMARC is almost entirely relevant to the MTA and transparent to the end us= er.  The additions in this document are also relevant to the MUA. . .<= /blockquote>

I'm not sure that mixing the features to be= used by the MUA into the MTA oriented specs for DMARC makes sense. For ins= tance what would a receiver be expected to do if they attempted to lookup a= n encoded recipient and could not find the cited record? Would you expect t= hem to enforce a non-pass policy against that message?

=
I think it would be more appropriate to communicate this information a= t a distinct end service point in the DNS - for example _mailenc.<domain= > rather than overloading the DMARC semantics with something that only h= as a peripheral relationship to message domain authentication. Your proposa= l seems more in the vein of "Encryption-Based Message Authentication, Repor= ting and Conformance".

--Kurt Andersen 
=

_______________________= ________________________
dmarc mailing list
dmarc@= ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
<= br>


___________________________= ____________________
dmarc mailing list
dmarc@ietf.org
https://www= .ietf.org/mailman/listinfo/dmarc

------=_Part_38104_1060276426.1454545550181-- From nobody Wed Feb 3 18:39:07 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E358F1B3170 for ; Wed, 3 Feb 2016 18:39:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.608 X-Spam-Level: X-Spam-Status: No, score=0.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RP_MATCHES_RCVD=-0.001] autolearn=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 ZdBzRAEahamr for ; Wed, 3 Feb 2016 18:39:05 -0800 (PST) Received: from turnbull.sk.tsukuba.ac.jp (turnbull.sk.tsukuba.ac.jp [130.158.96.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25F4D1B3882 for ; Wed, 3 Feb 2016 18:39:02 -0800 (PST) Received: from steve by turnbull.sk.tsukuba.ac.jp with local (Exim 4.86) (envelope-from ) id 1aR9ox-00080C-9I; Thu, 04 Feb 2016 11:38:59 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22194.47555.255365.546355@turnbull.sk.tsukuba.ac.jp> Date: Thu, 4 Feb 2016 11:38:59 +0900 From: "Stephen J. Turnbull" To: "Wiley, Glen" In-Reply-To: References: X-Mailer: VM 8.2.0b under 21.5 (beta34) "kale" dcd7dca8d70b XEmacs Lucid (x86_64-apple-darwin15.2.0) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: steve@turnbull.sk.tsukuba.ac.jp X-SA-Exim-Scanned: No (on turnbull.sk.tsukuba.ac.jp); SAEximRunCond expanded to false Archived-At: Cc: "dmarc@ietf.org" Subject: [dmarc-ietf] using DMARC to signal policy for email canonicalization, signing and encryption X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 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, 04 Feb 2016 02:39:07 -0000 Glen Wiley writes: > In light of all of the discussion about how the LHS of email > addresses are normalized and encoded/hashed in order to be used to > publish certificates and keys via DANE records like SMIMEA and > OPENPGPKEY we have put together an approach that lets a zone owner > signal the policy that is used for their domain by adding a few > keywords to the DMARC record. This makes no sense to me. DMARC by design expresses policies centralized in the administrative domain (AD) for email, and it efficiently centralizes implementation in the MTA. On the other hand, draft-ietf-dane-openpgpkey-07 clearly states that it will be used to distributes keys (plural!) linked to individual email addresses. I see no reason why the "typical" organization won't choose to have equally individualized policies, especially in light of the fact that DMARC and its lower-level components of DKIM and SPF already cover the generic aspect of AD policy (though they don't mention encryption). draft-ietf-dane-smime-09 refers to this possibility indirectly by mentioning that the "trust anchor" might usefully be wild-carded -- which implies that in some cases it would not be, ie, it would be individualized. On the other hand, draft-ietf-dane-openpgpkey-07 acknowledges that "It is unclear if this RRtype will scale to some of the larger email service deployments." Given the success of DMARC in reducing the effect if not the quantity of malicious mail, as a mail admin I would be dubious about linking an experimental protocol which could potentially involve a large burden on my DNS to DMARC. I don't see any way for anybody on the Internet to use DNSSEC for traditional operations, but opt out of DANE extensions here. I think it should be added if you're going to have AD-level policy discovery: you should be able to say "we sign our A records but please don't ask us for PGP keys". One thing that worries me is that individuals or departments smaller than an AD may choose to PGP sign and distribute keys by one of the already established channels. The protocol values "required", "optional", "forbidden" are not expressive enough for this, unless there is coordination between the AD and the smaller units, and you proliferate subdomains and corresponding _dmarc subdomains merely to express policy. AIUI avoiding that proliferation and making the _dmarc result cacheable for whole ADs is considered an advantage of the DMARC scheme. As far as I can see the main advantage of this proposal vs. having a separate _dane_name_policy subdomain is that you can register the new tags in the DMARC registry rather than establish a separate one. Are there any advantages to DMARC participating sites that don't want to participate in DANE? I imagine that if the dane-openpgpkey and dane-smime proposals were widely implemented, with policy records to match, information about mail flows that disregard those policies and those that respect them would be of value for reasons similar to the value of information about DMARC alignment. Have you given any consideration to integration of reports of that information with the existing DMARC reporting? From nobody Thu Feb 4 12:28:05 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6C1E1ACDBA for ; Thu, 4 Feb 2016 12:28:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.298 X-Spam-Level: * X-Spam-Status: No, score=1.298 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 7bEZBqf1K_ct for ; Thu, 4 Feb 2016 12:28:03 -0800 (PST) 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 A46FE1AD0C4 for ; Thu, 4 Feb 2016 12:28:03 -0800 (PST) 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 u14KRsL2034505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 4 Feb 2016 12:27:59 -0800 (PST) (envelope-from smj@crash.com) X-DKIM: OpenDKIM Filter v2.4.3 segv.crash.com u14KRsL2034505 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=201506-2k; t=1454617679; bh=oi44zfGWLoaSavCQhJmcBXVgsdVV01ph/D2XnPhpR3A=; h=To:From:Subject:Message-ID:Date:MIME-Version:Content-Type; b=wfULBwFE0ujBv7IplXjBkL7lLomklKmPelE0JQAElpZ2/eXD+FeW0Cn7pBhSt/2Cj +Yt1nOX3H/oEtY2pUcFUZcDHUTcRsYCTNNwRLOxp8E/MKjAim+7k8CkRhzYR2mNvb+ U1e6+z62DhZ9SQzeNDFPsE5hRSCw0Ho/axliYKbtdy6ys0X0f2f3+LAfpWiu0bP3pk L0l0TRcPxCx1Pufbh3mAndBk1RIRuWQmwMfttB53HZMv6IIFsIpXR9D5uJ9D80/zYL FoPPolYUNW4A7f3fE2Dxl1pFZmY4lA0u9pkDzTyqQzpvpYW8Xx+fH6RR2kYOXulBUo aYFVA7unAP4bQ== X-Authentication-Warning: segv.crash.com: Host 70-36-157-26.dsl.static.fusionbroadband.com [70.36.157.26] claimed to be abort.crash.com To: dmarc@ietf.org From: Steven M Jones X-Enigmail-Draft-Status: N1110 Organization: Crash Computing Message-ID: <56B3B44C.7080901@crash.com> Date: Thu, 4 Feb 2016 12:27:56 -0800 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------050404010908030909080302" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (segv.crash.com [72.52.75.15]); Thu, 04 Feb 2016 12:27:59 -0800 (PST) Archived-At: Subject: [dmarc-ietf] ARC interoperability testing day: Friday, Feb 19th X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 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, 04 Feb 2016 20:28:05 -0000 This is a multi-part message in MIME format. --------------050404010908030909080302 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit With the chair's indulgence, I'd like to share a reminder with this list about an upcoming. related event. Follow-ups may be more appropriate on the arc-discuss list. See http://lists.dmarc.org/mailman/listinfo/arc-discuss for details of that list; see http://arc-spec.org for more information on ARC. The interoperability testing event mentioned when the Authenticated Received Chain (ARC) was announced back in October has been scheduled for Friday, February 19th, 2016 in San Francisco - which is the same week as the M3AAWG meeting there. We've got a line on some lovely nearby office space we can borrow for Friday and potentially Saturday, if we needed a second day for any reason. This is a request for anybody implementing ARC to express interest in participating in the interoperability testing event. You can think of this as a "bake off" where you send/receive messages with other participants to see that various ARC implementations are working correctly, and working with each other. We may develop a series of cases to test before or during the event. We expect to be able to accommodate virtual participation as well as in-person. You can reply to me privately if you don't wish to advertise your participation publicly. Feel free to share this message with people not on this list whom you think might be interested in participating (if they are involved in implementing ARC). What do I mean by implementing ARC? - Writing code (library, milter, MTA) that implements ARC functionality (signing, verifying, etc) - Building a free/commercial product that includes ARC functionality, whether you wrote the ARC code or not - Deploying ARC functionality in an intermediary (e.g. MLM) or receiver (e.g. mailbox provider) Feel free to ask any questions you may have about this event here or on the arc-discuss list, or again feel free to contact me directly if you'd prefer. Thanks for your interest, --Steve. --------------050404010908030909080302 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit With the chair's indulgence, I'd like to share a reminder with this list about an upcoming. related event. Follow-ups may be more appropriate on the arc-discuss list. See http://lists.dmarc.org/mailman/listinfo/arc-discuss for details of that list; see http://arc-spec.org for more information on ARC.


The interoperability testing event mentioned when the Authenticated Received Chain (ARC) was announced back in October has been scheduled for Friday, February 19th, 2016 in San Francisco - which is the same week as the M3AAWG meeting there. We've got a line on some lovely nearby office space we can borrow for Friday and potentially Saturday, if we needed a second day for any reason.

This is a request for anybody implementing ARC to express interest in participating in the interoperability testing event. You can think of this as a "bake off" where you send/receive messages with other participants to see that various ARC implementations are working correctly, and working with each other. We may develop a series of cases to test before or during the event. We expect to be able to accommodate virtual participation as well as in-person.

You can reply to me privately if you don't wish to advertise your participation publicly. Feel free to share this message with people not on this list whom you think might be interested in participating (if they are involved in implementing ARC).

What do I mean by implementing ARC?

- Writing code (library, milter, MTA) that implements ARC functionality
  (signing, verifying, etc)
- Building a free/commercial product that includes ARC functionality,
  whether you wrote the ARC code or not
- Deploying ARC functionality in an intermediary (e.g. MLM) or receiver
  (e.g. mailbox provider)

Feel free to ask any questions you may have about this event here or on the arc-discuss list, or again feel free to contact me directly if you'd prefer.

Thanks for your interest,
 --Steve.

  


--------------050404010908030909080302--


From nobody Fri Feb 12 12:32:20 2016
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F5A21A8994 for ; Fri, 12 Feb 2016 12:32:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 8QuLY-lPL5Bu for ; Fri, 12 Feb 2016 12:32:18 -0800 (PST)
Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 524931A8993 for ; Fri, 12 Feb 2016 12:32:18 -0800 (PST)
Received: by mail-io0-x231.google.com with SMTP id g203so77885876iof.2 for ; Fri, 12 Feb 2016 12:32:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=enm9yOTV2Y8JaWglgYbb5+xL3Mu2AIalZpbe3XSg4ow=; b=Bi1Q0Gq08ocYC/aHM0k/d+k7zxMJvIBv3urY8FTEfevVQFxNjGxhhXZc5YbKnn1gYO EiQEdJwYxTodqOdVPUfKFPpaMnv6ZO1Bs0gQkzTwUvFDvXlMm40f5gDT98KcAbKEV8Qk YLpk9/K2W7w87THmUOhppt15UdhOHTYlzgLSc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to:content-type; bh=enm9yOTV2Y8JaWglgYbb5+xL3Mu2AIalZpbe3XSg4ow=; b=NcPKmAFmLUZ8W8uoJxagYwyKZMJJBI6wwnV0oDWf3r0KM2i50DhDpWB8BVgffxVAyH m8E77Gvc0T9EF6fa9l9K1+lC3DYVud6uqkPd2iL0wSFlJ+y2vzINHFOFP0yUb6IFHreV XXWvqpqzN83+HLohP9/Au98Nj0GETcWuJ2921/mo0yZMQXlAubG9jUlFXm14LUsgGOyM rsmS470fGha8i2lahQ8Oc61FAuLTZYk/kf/VNgJ3LxZu9hwty3fsNWc3RVgNFgwMEQYk Vz/+et+U0JtnhFZiBx8wD/l9vBs+m0YgSaHRU7fTW+0LYbW10iuI3oLW3GI2A7c+Y8rw 4tYQ==
X-Gm-Message-State: AG10YOTjS0ONlqspM1EgtDkA8Z4MjQRkfmIWmxdcyHC+7jnsuusBgVDWaIXNbDhevO9CXZO9mYOjrMIwtWWtug==
MIME-Version: 1.0
X-Received: by 10.107.170.140 with SMTP id g12mr5661931ioj.44.1455309137501; Fri, 12 Feb 2016 12:32:17 -0800 (PST)
Sender: kurta@drkurt.com
Received: by 10.79.14.15 with HTTP; Fri, 12 Feb 2016 12:32:17 -0800 (PST)
Date: Fri, 12 Feb 2016 12:32:17 -0800
X-Google-Sender-Auth: lBzQ4JJk8chuvNuiTPlqVhSSFf0
Message-ID: 
From: "Kurt Andersen (b)" 
To: "dmarc@ietf.org" 
Content-Type: multipart/alternative; boundary=001a1142767a2dfdc8052b9890fb
Archived-At: 
Subject: [dmarc-ietf] Are we done with last call on the interop document?
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.15
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, 12 Feb 2016 20:32:19 -0000

--001a1142767a2dfdc8052b9890fb
Content-Type: text/plain; charset=UTF-8

On Mon, Jan 18, 2016 at 11:54 AM,  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.

        Filename        : draft-ietf-dmarc-interoperability-14.txt
>         Pages           : 25
>         Date            : 2016-01-18
>

Since there have been no further comments since this version was posted,
does that mean that we are done with "last call"?

--Kurt

--001a1142767a2dfdc8052b9890fb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On Mon, Jan 18, 2016 at 11:54 A=
M,  <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 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet=
f-dmarc-interoperability-14.txt

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=
 25

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :=
 2016-01-18

Since=
 there have been no further comments since this version was posted, does th=
at mean that we are done with "last call"?

--Kurt=C2=A0


--001a1142767a2dfdc8052b9890fb--


From nobody Sat Feb 13 12:12:19 2016
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 126CA1A6FA7 for ; Sat, 13 Feb 2016 12:12:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.009
X-Spam-Level: 
X-Spam-Status: No, score=-0.009 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 TjHCrowRRg0R for ; Sat, 13 Feb 2016 12:12:18 -0800 (PST)
Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id E3D2D1A6FA3 for ; Sat, 13 Feb 2016 12:12:17 -0800 (PST)
Received: from [192.168.1.9] (unknown [67.58.115.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id DFE9DCB46; Sat, 13 Feb 2016 15:11:05 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Tim Draegen 
X-Mailer: iPhone Mail (13D15)
In-Reply-To: 
Date: Sat, 13 Feb 2016 15:12:16 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <86B1703C-CA54-4255-A71D-D9F76248926B@eudaemon.net>
References: 
To: "Kurt Andersen (b)" 
Archived-At: 
Cc: "dmarc@ietf.org" 
Subject: Re: [dmarc-ietf] Are we done with last call on the interop document?
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.15
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, 13 Feb 2016 20:12:19 -0000

Kurt, I believe so.  AFAICT, there was one paragraph you were runnin down, b=
ut if you're asking, I'm assuming that's it.   Right?

=3D- Tim


> On Feb 12, 2016, at 3:32 PM, Kurt Andersen (b)  wrote:
>=20
> Since there have been no further comments since this version was posted, d=
oes that mean that we are done with "last call"?