From nobody Tue Feb 5 00:06:57 2019 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 D9B1D130E13 for ; Tue, 5 Feb 2019 00:06:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.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 ibnH73ImuWqV for ; Tue, 5 Feb 2019 00:06:53 -0800 (PST) Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9982129C6A for ; Tue, 5 Feb 2019 00:06:52 -0800 (PST) Authentication-Results: mail.aegee.org/x1586kvn027018; auth=pass (PLAIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1549354007; i=dkim+MSA-tls@aegee.org; r=y; bh=s38JXSeG+bYbx5vh7XB6qltB/+nysnnJkZZr2bPgDK8=; h=Subject:From:To:Date:In-Reply-To:References; b=Cri5QXge6do8p1FxIZUXoDuE591UsyJ5jN35cU75WRpX/CKnUPu61IM4gUiQOHAMQ 28xAdmsFyBAgNHHTKHOw0CtIEbxd32u1JFvuvTRxhaE4VHK3PrnbMd8PtTUXpF/0qv rWZSTZjlOT1hXWMgXPczAkXYTmixehrDldc/3OXObETx9A+nTT/Fo34gPMxcsAdsAq s/jcuJd0yjXh0plJMiuzQwGPLJjll4QcLwQOoMI8akUn5d31h9a459d0iCetcv/1h+ Jv3Lvt2EnQG4/7nBO9CMMGhp4apOGMs7uuhbYqNz7Lj6Gw+C7hQRi4JdcixEJenV+p 9iUv0GEUm9eNlxRkzaa2jCMA5amAWEuOtPVo2E1bnzE4yH14fg2jNCHpf+txQSjYLz OEmtEbShjTRXAxXownSWS4lLMfcBpWRZ2D4ABM+PQEEls1Xgtl46tCIcRK+f+PHVQl fMOCxLDEwl/5+GWRJONwJe1jMBMUjCungqHY8evXPPnR9ITEAEK936ePng6WJHbEdF F7T2Vm22xgApvEyD+lOdvidsb63VG2cxsIHo1bF1i9xd1MZ0foW91Nj8rFluQFBHVP CF2VkiUG9Klf4L2u+RW7m7spJpRr2V9o0p0vtueDOtGR1xsdDN16uDlOQ0RccG0qZv jGP/TtzbZMAQAda1MNy2KyOs= Authentication-Results: mail.aegee.org/x1586kvn027018; dkim=none Received: from Tylan (x2f36bf1.dyn.telefonica.de [2.243.107.241]) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id x1586kvn027018 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 5 Feb 2019 08:06:47 GMT Message-ID: <974c2d00017358cdf3b78037e4276234db2cfdee.camel@aegee.org> From: =?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?= To: John Levine , dmarc@ietf.org Date: Tue, 05 Feb 2019 08:06:46 +0000 In-Reply-To: <20190126163123.AAA4B200D39816@ary.qy> References: <20190126163123.AAA4B200D39816@ary.qy> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.31.91 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.101.1 at mail.aegee.org X-Virus-Status: Clean Archived-At: Subject: Re: [dmarc-ietf] DMARC forensic reports (ruf=) and privacy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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 Feb 2019 08:06:56 -0000 Hello John, On Sat, 2019-01-26 at 11:31 -0500, John Levine wrote: > … The failure reports are almost > entirely useless. Of the ones I get, the majority are random Chinese > spam that happened to forge one of my domains on the From line, the > rest are from mailing lists where I wouldn't expect DMARC to pass. You have published DNS TXT _dmarc.taugh.com “v=DMARC1; p=none; rf=afrf; rua= mailto:dmarc-a@abuse.net; ruf=mailto:dmarc-f@abuse.net”. How do you define a useful report and for which purpose do you want to receive reports? I mean, when does sending reports to p=none make sense. Regards Дилян From nobody Tue Feb 5 12:18:44 2019 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 B0522130EF1 for ; Tue, 5 Feb 2019 12:18:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=b0ryou6Q; dkim=pass (2048-bit key) header.d=kitterman.com header.b=d10snEWY 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 AiAMpaZuAsQU for ; Tue, 5 Feb 2019 12:18:39 -0800 (PST) Received: from softlayer.kitterman.com (softlayer.kitterman.com [IPv6:2607:f0d0:3a01:a3::9]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84503130EED for ; Tue, 5 Feb 2019 12:18:39 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812e; t=1549397915; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=ejU/IbxveFih2NI868AB/XSdpyE+nk44B/Wldeg+O5M=; b=b0ryou6Q7BIluid+hYtT/E+wezdltNM5EWxrov1wx2yGHLEWUdcU78Vu GsYrURKKYwOYGVcS2RlSx8oEdeCIBw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812r; t=1549397915; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=ejU/IbxveFih2NI868AB/XSdpyE+nk44B/Wldeg+O5M=; b=d10snEWYhRv77HT8Uep721GiLr8sQxr0HhW6lTVOL69sZWRcyAOxGj69 5QOydrZ3hnQSRL7WgqhjnFJpwy18KCgd1NSGQhQv7hAXXxMCbtZjmyPnSe V/oY7hPaUjarzf+hFkX7q5w9LtNDIWx51sx9iCHetstImTYEwxCBm/ubAh 2MQePFfQ3TJF2cRK0E5w22OpuOeTC5U2FgtS8VUxYGrm71BDV4nc6pFJt9 JKSkReD1fOI+Sg/pGR1vE1+1yi2c93DNuSNxMYvcQVUYJcTRHm9KzAGW7p I5S/ICDzeOl7BCYkXfj0a8puu3wYSZIwmo2gb85tA/fnRiMn5yJFYA== Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by softlayer.kitterman.com (Postfix) with ESMTPSA id AC4312D40033 for ; Tue, 5 Feb 2019 14:18:35 -0600 (CST) From: Scott Kitterman To: dmarc@ietf.org Date: Tue, 05 Feb 2019 15:18:35 -0500 Message-ID: <6596039.Rh8MxG5e5K@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-164-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <11058591.22vd1BysGP@kitterma-e6430> References: <20190117185019.16153200CDA113@ary.qy> <11058591.22vd1BysGP@kitterma-e6430> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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 Feb 2019 20:18:42 -0000 On Friday, January 18, 2019 04:14:42 AM Scott Kitterman wrote: > On Thursday, January 17, 2019 01:50:18 PM John Levine wrote: > > In article <3104294.rU99Ex2XNH@kitterma-e6430> you write: > > >My understanding is that, since, as you say, PSOs (like .bank) have a > > >pre- > > >existing relationship with their registrants, they don't need PSD DMARC > > >to > > >audit their registrant's policies. For an entity like that, it offers > > >the > > >chance to get feedback on other, presumably non-existent, domains so as > > >to > > >better understand abuse patterns within the PSD they manage. It also > > >gives > > >them a mechanism to express a reject policy for those domains, which does > > >not currently exist. This may help improve rejection of cousin domains > > >by > > >receivers. > > > > > >For single entity PSDs, like for a very large Internet company that is, > > >conveniently not named after a large South American rain forest (so they > > >can get it registered), it offers other advantages. In cases like this, > > >the PSD operates like an organizational domain except for the fact that > > >in > > >the current DMARC instantiation, their record won't work for subdomains. > > >PSD DMARC would enable '.example' to publish a single record for all > > >lower > > >level entries in the zone. > > > > That all seems reasonable but it still feels like a lot of mechanism for > > marginial benefit, particularly since we have no clue who's going to run > > it > > if we can't foist it off on Mozilla. > > > > I wonder if there's any way to get the PSL to tag vanity TLDs. > > There are two parts to the PSL; a section called "ICANN DOMAINS" and another > called "PRIVATE DOMAINS". All the TLDs (single user or not) are in the > ICANN DOMAINS section. > > I don't know if it would be enough to have them also listed in PRIVATE > DOMAINS. I don't expect they would want to remove them from ICANN DOMAINS, > since that's not wrong, it just doesn't fit out use case. > > It would require some adjustments to the current DMARC algorithm for > organizational domain identification. > > The current process is to take the 2822.From domain and (assuming there is > no DMARC record for that domain) look-up in the PSL and reduce the > 2822.From domain to the PSL ICANN DOMAIN + one level. If that level has no > DMARC record, then the domain does not participate in DMARC. > > If Mozilla would add these single user TLDs to the PRIVATE DOMAINS section > also, we could adjust this slightly and for this use case (which is only one > of three in the draft) it would work: > > After checking PSL ICANN DOMAIN + one level, if there is no DMARC record, > then check the PSL PRIVATE DOMAIN list and if the domain is listed there, > check for a DMARC record. > > I don't know that this would violate the sematics of the PSL and they are, > in fact, both ICANN domains and private. Based on the description at > https://publicsuffix.org/list/ it seems like it might be accepted. > > Regardless of exactly how we do this for PSD DMARC, it is probably work > documenting that for DMARC (the regular kind), only the ICANN domain section > of the PSL is used. > > Does anyone know someone at Mozilla to ask? > > For the other, non-single user domains, maybe the best we can do is an > appendix that describes the characteristics of PSDs for which PSD DMARC > checks are suitable and lists our three from the initial registry as > examples. Otherwise, I think we need a new list somewhere because those > (like .bank) are clearly not private. If IANA is not the right place to > host a list, does anyone have any other suggestions for the ones that won't > work on the PSL? After some off-list discussion with someone who knew someone who knew about PSL, it seems PSL probably isn't the right choice for this (meh). The current PSL is over 12K lines long. What we're talking about here is probably .1% to 1% that size. Leaving aside for a moment the mechanism, would people review the latest draft and see if they think the privacy issues are adequately described and if they require some kind of mitigation? Scott K From nobody Tue Feb 5 17:01:17 2019 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 B3C5C128BCC for ; Tue, 5 Feb 2019 17:01:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=KI4yqO1d; dkim=pass (1536-bit key) header.d=taugh.com header.b=ILGg1WQs 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 GvDZa2vIPkQy for ; Tue, 5 Feb 2019 17:01:13 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD711128B01 for ; Tue, 5 Feb 2019 17:01:12 -0800 (PST) Received: (qmail 40349 invoked from network); 6 Feb 2019 01:01:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=9d99.5c5a31d7.k1902; bh=9RmCT0kC6p21M7LgOyCM7C+eqwkWE9WRyKGlZxYg3Rs=; b=KI4yqO1dyUJX2FeO7irGsNA+BPJtbTNNyQODkD2YCDgabGuym4EqG+Qm126GbiPU3oW5KaGlwOMvAp8cp+yNHKOrjcXDNDcExXhr03Lgbw5HCX7Li0xbjCZlU+gljZPgPBFqnKk6r3mgNJ9e70zxxKxLJM50faBGLeKwCxzwJnvO6mCcN0tbXh0DLbH+7msENmjQb4Qdewult/jTJIWWjWUjVqlIEH4oeXxcdMO13ckFvXhdRl8BAZmEEb9WTeZm DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=9d99.5c5a31d7.k1902; bh=9RmCT0kC6p21M7LgOyCM7C+eqwkWE9WRyKGlZxYg3Rs=; b=ILGg1WQsffwqZNEBSfZ/Ua2zHNCQoV83lqb9t2+P6Gghw7BfCPWrlwmG19tKe4SjCmnl//2WJXgqZgt9A/ZmaT8h6AEaN8uGnAbf7Exe3DGDDwlHioFiA1Y8nuAb/MM+DYgilVm52VCwSgbqcN3lh1DuxTNlIyEZFy7Q2aOsegEv1PC1lY3TSy+Mb40Ex7gbHtqAhuDxPp5CKq4rLmimGEMUajeFfc0lwcXLDKP9sbj3D3HlfBDeHSIdgLAVcbrp Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 06 Feb 2019 01:01:11 -0000 Received: by ary.qy (Postfix, from userid 501) id ED53C200DD2BA4; Tue, 5 Feb 2019 20:01:10 -0500 (EST) Date: 5 Feb 2019 20:01:10 -0500 Message-Id: <20190206010110.ED53C200DD2BA4@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: dilyan.palauzov@aegee.org In-Reply-To: <974c2d00017358cdf3b78037e4276234db2cfdee.camel@aegee.org> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] DMARC forensic reports (ruf=) and privacy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 01:01:15 -0000 In article <974c2d00017358cdf3b78037e4276234db2cfdee.camel@aegee.org> you write: >Hello John, > >On Sat, 2019-01-26 at 11:31 -0500, John Levine wrote: >> … The failure reports are almost >> entirely useless. Of the ones I get, the majority are random Chinese >> spam that happened to forge one of my domains on the From line, the >> rest are from mailing lists where I wouldn't expect DMARC to pass. >How do you define a useful report and for which purpose do you want to receive reports? A useful report would be one that was a message that one of my users had actually sent and was smashed in a way I didn't expect. > I mean, when does sending reports to p=none make sense. The feedback reporting doesn't depend on the policy. Please review section 7 of RFC 7489. From nobody Tue Feb 5 17:59:24 2019 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 61DF81288BD for ; Tue, 5 Feb 2019 17:59:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=GdKyzv1e; dkim=pass (1536-bit key) header.d=taugh.com header.b=Oekl8bAg 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 ijT9Vba7h9fT for ; Tue, 5 Feb 2019 17:59:19 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96DD012D7EA for ; Tue, 5 Feb 2019 17:59:19 -0800 (PST) Received: (qmail 55021 invoked from network); 6 Feb 2019 01:59:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=d6eb.5c5a3f76.k1902; bh=0Y1+AfzMVOIznsk38EblhdePzmYn4WPydYfGtGLF+nc=; b=GdKyzv1enI/CRUDT0S/TYmeV2nN22X1PZYds4Qs3Up4CLXQbRG0cpNH//Vxc3DBXBJkEqn7b9LTNg8zN/G0/9ifSxIKfyw2N6OipnQ0HtyWlnoguJbb2QNFPk/oGJYAHaRpkk7uKrz6gOTpb9kFOtGA+4XLzNRyK4jxzB9LC3HUR79fVLk4z6cickd6XGw+Qnv0y4IO7OseXfK3uDlWMg5zLe3iRmpbvHIFGmgvyitW7+kBw+Y83zrkSZX9+jXYA DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=d6eb.5c5a3f76.k1902; bh=0Y1+AfzMVOIznsk38EblhdePzmYn4WPydYfGtGLF+nc=; b=Oekl8bAgXtjUt6KenZw/MJJi1y4U/TJNg5l0t9/za53fCPJwV1u9GgqO2GTv8sv3O1UCgghzW2xCsULZ8yToPCzwpeuLNXeAgb8DYOOlxqRi9KN2ZT3BUF7kiX+tpRgHHi5yNpdGLppejBUsYjMCxwFtBfGZjq9ywn6KmoEuCruD4SLNp0VZEcheMF+LP/EdTdSwUGi4Nm1XHb666YzdKITQoUfYU0ZJe6nz4nMPtXWnGZUwmZaYv1BXyquYMvhG Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 06 Feb 2019 01:59:18 -0000 Received: by ary.qy (Postfix, from userid 501) id 05BBA200DD44EF; Tue, 5 Feb 2019 20:59:17 -0500 (EST) Date: 5 Feb 2019 20:59:17 -0500 Message-Id: <20190206015918.05BBA200DD44EF@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: sklist@kitterman.com In-Reply-To: <6596039.Rh8MxG5e5K@kitterma-e6430> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 01:59:21 -0000 In article <6596039.Rh8MxG5e5K@kitterma-e6430> you write: >The current PSL is over 12K lines long. What we're talking about here is >probably .1% to 1% that size. Indeed, but since everyone has the PSL anyway to find organizational domains, who cares about the size? The point of asking the PSL people to do it is to find a credible third party to evaluate "all your domains belong to us" assertions. > Leaving aside for a moment the mechanism, would >people review the latest draft and see if they think the privacy issues are >adequately described and if they require some kind of mitigation? I think it's fine. At the end where you talk about failure reports, you might note that since they contain actual messages, any domain where the admistrator does not normally read its users' mail already has the same issues. R's, John From nobody Wed Feb 6 14:12:02 2019 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 8AB7B130E62 for ; Wed, 6 Feb 2019 14:12:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.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 Ck7qNi-PWjjp for ; Wed, 6 Feb 2019 14:11:58 -0800 (PST) Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CEA712D4F3 for ; Wed, 6 Feb 2019 14:11:58 -0800 (PST) Authentication-Results: mail.aegee.org/x16MBtpU031557; auth=pass (PLAIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1549491116; i=dkim+MSA-tls@aegee.org; r=y; bh=LodIfTzoTme/eC9doO9HeTk5F3ntXADUZXNeHJ5WZLM=; h=Subject:From:To:Date:In-Reply-To:References; b=AbxQ/6I1oznY7IylFO7SHGoKTFCBbSM42z/Z429H/J6D2LKMiojQb/RSRSyN/3Aht 0FBSh6L+ZOOzUhBOL6xSf0fP3wNyqDggRk1VXwbVTsz0wxp7l1pb9MIwGgKfQkEpgN I/LzpjnJd0kRj30CfqeyyGjt8r/5wFc5Q2/hvRBirqZ2+PUYuji32OaTNbInm4xZsn I94nrgoo2VUYo/VLIrJynTsU7SBlgVUs5/Za2SUs1P2YMpJ5pPcd0Q8m3m4GaBrEtg eqBViW+0IjA72U9jRJXCJG10fgrgitmz6w3nzQhEB2IeJkGTGx6Dsk65oKW6y4bHer iER3J3hz86QxZ3ud7TuYrdmnuY32lTaWoB5XP29IMRtMWNckaF0uiBDVBNs6FAB79T QGhuh+b4SKvROSxKb8YyDVxJJt3/rjpUgCskKihuV3mTg7wcNO3ALYekUN0aK6TJ3J /eWER0JUEp7KC/S+VW96jwsPOMC5kBxgabP5YDip7dn0TkN2/HEAN99C/6Eq5vFsdw jnWYg2gQfS3QYaj/o6UXB8pWM+1unLe22hMTnYIGM3HT2CHIuzNIxtel1RJqln4fFy uEA/jXICNqXNu7wIY0vGuGkGOeuWIfIh/4+RbUFnf4+8HSF+1qgT5kSBA8VsmiSBnp POXTwZkcbGpw1S+cIG3PIVAs= Authentication-Results: mail.aegee.org/x16MBtpU031557; dkim=none Received: from Tylan (x5d877ef8.dyn.telefonica.de [93.135.126.248]) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id x16MBtpU031557 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 6 Feb 2019 22:11:56 GMT Message-ID: From: =?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?= To: John Levine , dmarc@ietf.org Date: Wed, 06 Feb 2019 22:11:55 +0000 In-Reply-To: <20190206010110.ED53C200DD2BA4@ary.qy> References: <20190206010110.ED53C200DD2BA4@ary.qy> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.31.91 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.101.1 at mail.aegee.org X-Virus-Status: Clean Archived-At: Subject: Re: [dmarc-ietf] DMARC forensic reports (ruf=) and privacy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 22:12:00 -0000 Hello John, DMARC reports for p=none are not supposed to be useful, as they do not depend on the policy. If the question is about how to get reports on failing DKIM validation only on unexpectedly smashed messages, then I recall the last discussion on Ietf-dkim@ietf.org: - this is not DMARC, but DKIM domain - when the DKIM-Signature does not validate, contains r=y and the remainign provisions from RFC6651 do apply, a (usefull) report shall be sent - when a message is intentionally modified, in way that the DKIM-Signature gets invalidated, the modified message shall adapt somehow the fact that it was intentionally modified for particular DKIM-Signatures, so that no useless report is sent - Nobody wants to modify DKIM-Signature, so it is unclear where to add the information that the message was intentionally smashed in regards the first and second DKIM-Signature, but not for the third one. I proposed at the time to add a r=a tag, sending only report, when DKIM aligns to From:, so that after passing a MLM rewriting From: no reports shall be sent (contrary to r=y). Now I realize, that for p=none there is no added usefulness, since - DKIM-Signature gets usually intentionally broken, while passing over the MLM, and - From: is not rewritten, therefore From: alignes to the signature, so a useless report will be sent for the message. Regards Дилян On Tue, 2019-02-05 at 20:01 -0500, John Levine wrote: > In article <974c2d00017358cdf3b78037e4276234db2cfdee.camel@aegee.org> you write: > > Hello John, > > > > On Sat, 2019-01-26 at 11:31 -0500, John Levine wrote: > > > … The failure reports are almost > > > entirely useless. Of the ones I get, the majority are random Chinese > > > spam that happened to forge one of my domains on the From line, the > > > rest are from mailing lists where I wouldn't expect DMARC to pass. > > How do you define a useful report and for which purpose do you want to receive reports? > > A useful report would be one that was a message that one of my users > had actually sent and was smashed in a way I didn't expect. > > > I mean, when does sending reports to p=none make sense. > > The feedback reporting doesn't depend on the policy. Please review > section 7 of RFC 7489. > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Wed Feb 6 14:28:10 2019 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 F2259130EEC for ; Wed, 6 Feb 2019 14:28:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=ROFi3ufN; dkim=pass (2048-bit key) header.d=kitterman.com header.b=w7bp24OE 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 Fw6FLgfKSpNg for ; Wed, 6 Feb 2019 14:28:06 -0800 (PST) Received: from softlayer.kitterman.com (softlayer.kitterman.com [IPv6:2607:f0d0:3a01:a3::9]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3AA2130E25 for ; Wed, 6 Feb 2019 14:28:06 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812e; t=1549492083; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=wgpXu5iWOynAbiq2u+E74BYbb84yTBDUr0Vyf+tnfk8=; b=ROFi3ufNfuutlUWQK9eoybpc2Qx2525xpo6mTG3K6KUI32qcvvl8GkDh +24jcetVqXTrm2yLrgpWsPG3wKlhAw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812r; t=1549492083; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=wgpXu5iWOynAbiq2u+E74BYbb84yTBDUr0Vyf+tnfk8=; b=w7bp24OEVsQLTpZihkTNJNAkF3lMODrzcrpac25v5CyC9+GqKgEBXdDt sbYntZeNaFu8u9sSzZs/n0ttLdUiAGW1WVdk4IGYpDiJ9aJWLpB4iiwwbg QF4/azC99/IaQu0HQZhnTB/a+Ac9H5qdGOtzvP2o+2DwuJJldGtBWh75+4 dc4zQDbFBTHFTbeC3Yfw+ufKVgYQWdt7eZy09SnlJPRx6iXhIx0BQ6vVJ8 n+DSAOgtep4Rcr3k09fkim0vG6LGF8/KCOJV6LnqHW9mRROjN0X+eRLhI7 hdI762Ocft+rhCYIhYw706XmqU7R1ijU1gQuzQ0wfvD5j9ODWKXO0g== Received: from [10.151.116.119] (mobile-166-170-33-41.mycingular.net [166.170.33.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by softlayer.kitterman.com (Postfix) with ESMTPSA id 368AF2D4001E; Wed, 6 Feb 2019 16:28:02 -0600 (CST) Date: Wed, 06 Feb 2019 22:28:00 +0000 In-Reply-To: References: <20190206010110.ED53C200DD2BA4@ary.qy> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dmarc@ietf.org From: Scott Kitterman Message-ID: <8C673EB6-5DEA-458D-BE81-64ECA6BE6DBA@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] DMARC forensic reports (ruf=) and privacy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 22:28:09 -0000 I completely disagree=2E I have p=3Dnone and I find the reports very useful=2E The policy is about action taken, not DMARC results, which is what feedbac= k is about=2E Scott K On February 6, 2019 10:11:55 PM UTC, "=D0=94=D0=B8=D0=BB=D1=8F=D0=BD =D0= =9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2" wrote: >Hello John, > >DMARC reports for p=3Dnone are not supposed to be useful, as they do not >depend on the policy=2E > >If the question is about how to get reports on failing DKIM validation >only on unexpectedly smashed messages, then I >recall the last discussion on Ietf-dkim@ietf=2Eorg: > >- this is not DMARC, but DKIM domain >- when the DKIM-Signature does not validate, contains r=3Dy and the >remainign provisions from RFC6651 do apply, a >(usefull) report shall be sent >- when a message is intentionally modified, in way that the >DKIM-Signature gets invalidated, the modified message shall >adapt somehow the fact that it was intentionally modified for >particular DKIM-Signatures, so that no useless report is >sent >- Nobody wants to modify DKIM-Signature, so it is unclear where to add >the information that the message was >intentionally smashed in regards the first and second DKIM-Signature, >but not for the third one=2E > >I proposed at the time to add a r=3Da tag, sending only report, when DKIM >aligns to From:, so that after passing a MLM >rewriting From: no reports shall be sent (contrary to r=3Dy)=2E Now I >realize, that for p=3Dnone there is no added >usefulness, since >- DKIM-Signature gets usually intentionally broken, while passing over >the MLM, and >- From: is not rewritten, therefore From: alignes to the signature, > >so a useless report will be sent for the message=2E > >Regards > =D0=94=D0=B8=D0=BB=D1=8F=D0=BD > > >On Tue, 2019-02-05 at 20:01 -0500, John Levine wrote: >> In article <974c2d00017358cdf3b78037e4276234db2cfdee=2Ecamel@aegee=2Eor= g> >you write: >> > Hello John, >> >=20 >> > On Sat, 2019-01-26 at 11:31 -0500, John Levine wrote: >> > > =E2=80=A6 The failure reports are almost >> > > entirely useless=2E Of the ones I get, the majority are random >Chinese >> > > spam that happened to forge one of my domains on the From line, >the >> > > rest are from mailing lists where I wouldn't expect DMARC to >pass=2E >> > How do you define a useful report and for which purpose do you want >to receive reports?=20 >>=20 >> A useful report would be one that was a message that one of my users >> had actually sent and was smashed in a way I didn't expect=2E >>=20 >> > I mean, when does sending reports to p=3Dnone make sense=2E >>=20 >> The feedback reporting doesn't depend on the policy=2E Please review >> section 7 of RFC 7489=2E >>=20 >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf=2Eorg >> https://www=2Eietf=2Eorg/mailman/listinfo/dmarc > >_______________________________________________ >dmarc mailing list >dmarc@ietf=2Eorg >https://www=2Eietf=2Eorg/mailman/listinfo/dmarc From nobody Wed Feb 6 15:25:58 2019 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 E4AA2130F50 for ; Wed, 6 Feb 2019 15:25:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=NAe58862; dkim=pass (1536-bit key) header.d=taugh.com header.b=hVh/+yLY 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 rgQr9jxKsz5S for ; Wed, 6 Feb 2019 15:25:55 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A34F130F4F for ; Wed, 6 Feb 2019 15:25:55 -0800 (PST) Received: (qmail 45204 invoked from network); 6 Feb 2019 23:25:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=b092.5c5b6d01.k1902; bh=gHNkk72bOkb1giNqUPea3ki8dxby+qKCNvRfG1IG0HY=; b=NAe58862vJOai5E8N+PuZyXTZPeVZZw4pzMqWndYnto1wqE9Bhu803RtzkWE/JalskHY2BZCjJKRarM+wsCSEeVaUOE+a3eY6kAYWTMdaHybC5oPjlUgcv5o158p0spciuGQ36YnRnOqpI1hdWC/bWHba8enhpHz1Eq9dm0HjlKdzCCxPLQIXCeIwQtbA3+S1J9WWoSKKQ17t19vBbX97ZdKNpu0A+AkmfHFU1K2VJGkOhB7BkYkWZO5b2JPNviA DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=b092.5c5b6d01.k1902; bh=gHNkk72bOkb1giNqUPea3ki8dxby+qKCNvRfG1IG0HY=; b=hVh/+yLYrE0lfhPCckp/9TRqoSdKNFzxlCotkFQK354LbhOxLmMFHYVQ8xLtVhr1sGCWJihqXccdHNFJ0ihuWPEc65LvKJXbRSIPsF3VbSi4JeOpXwmlMC9ZnU9b4gcpS7kolIdXbCewZAhFHj4vtfLR5eOD15qNzMbtB22lI41gv3levqPq/jQSUfZ4I/m43PjSKSGBN4NFDVcVIYc1MtTMMw9cwNeKDr7IxVos94MIie7Ocl13/EWw/qyGnWHn Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 06 Feb 2019 23:25:53 -0000 Received: by ary.qy (Postfix, from userid 501) id 4C281200DE5492; Wed, 6 Feb 2019 18:25:52 -0500 (EST) Date: 6 Feb 2019 18:25:52 -0500 Message-Id: <20190206232553.4C281200DE5492@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: dilyan.palauzov@aegee.org In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] DMARC forensic reports (ruf=) and privacy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 23:25:57 -0000 In article you write: >Hello John, > >DMARC reports for p=none are not supposed to be useful, as they do not depend on the policy. Sorry, but that assertion is completely wrong. Please see RFC 7489. >If the question is about how to get reports on failing DKIM validation only on unexpectedly smashed >messages, then I >recall the last discussion on Ietf-dkim@ietf.org: No, that is not the question. Please review the previous messages. R's, John From nobody Thu Feb 7 17:33:50 2019 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 8A87C127598 for ; Thu, 7 Feb 2019 17:33:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-6VETYO4sI2 for ; Thu, 7 Feb 2019 17:33:47 -0800 (PST) Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) (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 8301D1274D0 for ; Thu, 7 Feb 2019 17:33:47 -0800 (PST) Received: by mail-vs1-xe31.google.com with SMTP id x28so1172090vsh.12 for ; Thu, 07 Feb 2019 17:33:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6cO75r2UH2JwFbzP8otcEfAl73T5B4pJwAqpqhRvZrQ=; b=kycaoon6uW+SX8Ab/rxsHM0zDS0mpuuzED6zhutbannvSDfA1sS15d23eyhkp9cVq1 N2vXO/My4DcZDYrWW/HzA9ZY8lhPLytOnIH6zz5AqTUYLAQT0BUZt33nvMggjoP/Oxjs QaMbGDivfsYPwvxkKFXi5KnW8ENPGxP7cdQ5aGh+KbT4JOMGbCjaf7KCM12SAEKXaTox yPzKlvwhiqikAdBR73QaseBf8ozvoJk4SmI0L1hQoq2Zskn0pev5X9JaniTjbCarftC3 Kxi3P6vgU5jOgSlerxbQFxB/Cwg3Pl2ha58OjncEJhRvubtZZos2mYGLzyYJr7beu4ZR +reg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6cO75r2UH2JwFbzP8otcEfAl73T5B4pJwAqpqhRvZrQ=; b=db/m6Eb03rZlXFW/+GCJjuy2a9/ECs9Caz2/NaEAHJUxgvB9mstPGcDUA82R4Aaan8 GzKt7xAUC95ROb4gehShqxlNlxQ4goGXZNhKzz2qSJjqHgKedY1D+isSTa6XZFcbAd/u 3USXVHqF+OZiDFEfYpl4WmlTLpJ5hxc98GbkRvW1dnM/eVRn/X//DU+srhdTHUB0LOtZ wUF6bJlEHdG7t8wuTwLXKIbkRleOoqLIhpfxa06V+aJWbUKwYr3Oxg/1IEzily8OdKTx VYJSC8XgxLMrQJZb3k1EMz38NdNQLGtaIWy2bZgrH9Xa3H5vhRhW+Jm+qpeu/+kOQtbY CsnQ== X-Gm-Message-State: AHQUAubVI6slaYoaeTyP43m7K/VRnc2OivEBPGoDKrkIP/zxBabLtDTe wNDpxkZcQgMhB0/7BI+MSPj09aIKgeypqSMEiDcx X-Google-Smtp-Source: AHgI3Ia5EX3dfy6U6QLNJtlq1dxZ+sJECoL1Zh1NMPJKReKeKJ9DwEPaWfeVnQTPPwEJPOsyo2CBelBAIqWNcM9IajE= X-Received: by 2002:a67:dc92:: with SMTP id g18mr8095903vsk.76.1549589626053; Thu, 07 Feb 2019 17:33:46 -0800 (PST) MIME-Version: 1.0 References: <20190206232553.4C281200DE5492@ary.qy> In-Reply-To: <20190206232553.4C281200DE5492@ary.qy> From: Brandon Long Date: Thu, 7 Feb 2019 17:33:34 -0800 Message-ID: To: John Levine Cc: IETF DMARC WG , =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= Content-Type: multipart/alternative; boundary="00000000000035f854058157f3b7" Archived-At: Subject: Re: [dmarc-ietf] DMARC forensic reports (ruf=) and privacy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 08 Feb 2019 01:33:49 -0000 --00000000000035f854058157f3b7 Content-Type: text/plain; charset="UTF-8" The reason you want reports at p=NONE is so that you can fix the issues and then move on to higher enforcement levels. And mailing lists aren't the only way that messages can be modified. Brandon On Wed, Feb 6, 2019 at 3:26 PM John Levine wrote: > In article you > write: > >Hello John, > > > >DMARC reports for p=none are not supposed to be useful, as they do not > depend on the policy. > > Sorry, but that assertion is completely wrong. Please see RFC 7489. > > >If the question is about how to get reports on failing DKIM validation > only on unexpectedly smashed > >messages, then I > >recall the last discussion on Ietf-dkim@ietf.org: > > No, that is not the question. Please review the previous messages. > > R's, > John > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --00000000000035f854058157f3b7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The reason you want reports at p=3DNONE is so that you can= fix the issues and then move on to higher enforcement levels.

And mailing lists aren't the only way that messages can be modif= ied.

Brandon

On Wed, Feb 6, 2019 at 3:26 PM J= ohn Levine <johnl@taugh.com> w= rote:
In article= <e5763e2e64cae01a7b53f94e521b9f2d103f6708.camel@aege= e.org> you write:
>Hello John,
>
>DMARC reports for p=3Dnone are not supposed to be useful, as they do no= t depend on the policy.

Sorry, but that assertion is completely wrong.=C2=A0 Please see RFC 7489.
>If the question is about how to get reports on failing DKIM validation = only on unexpectedly smashed
>messages, then I
>recall the last discussion on Ietf-dkim@ietf.org:

No, that is not the question.=C2=A0 Please review the previous messages.
R's,
John

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--00000000000035f854058157f3b7-- From nobody Fri Feb 8 13:12:35 2019 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 EA421131012 for ; Fri, 8 Feb 2019 13:12:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.018, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvl0WNejDDe5 for ; Fri, 8 Feb 2019 13:12:32 -0800 (PST) Received: from mail-it1-f171.google.com (mail-it1-f171.google.com [209.85.166.171]) (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 A6C50130FFA for ; Fri, 8 Feb 2019 13:12:32 -0800 (PST) Received: by mail-it1-f171.google.com with SMTP id g85so12324881ita.3 for ; Fri, 08 Feb 2019 13:12:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=uo2s0AUaz26N8bi0pRj65T3CT2cjiKbMK5+ipcsuHIk=; b=G9Cp4w/r7KRuZtvNmMcuBsm//6tmj3LM3wfWDflr8fF4D8vqAAFZ7lwX5K7FjSd8HP 0m7lEX7sZ8BKm8wHUCwDtClDm3bzQ1aho/upx1Jsa8So2Ycnzw0bV16B2gEdGPSmc9WL qpPWOs077FTud5XHte9MhsjstWnyiNct+2wZ/zOda+uc4UNt+qV96gN+MmdrL45Le5XS PSFQD8kwz8ZWWm4RgxipwPtiiL4CgPh9Ihzm+WHWEeiRLr2frL6Qzldn3f/gn3RQiwe4 QzSP+yXO3MjpCrL65y6c6iMKoDrhv38H183RrFxVQHQmz7M9ebcvKyItu2PUajpjIg4M V4Iw== X-Gm-Message-State: AHQUAua83Vp2vADGyNNJtdwQbvaIfiW+J8y1jjNGXx/8E6EkVPiut3S8 zLlpZH4aRs1TvEevbcoiPE/k16hNSEZj7+WfrrTeqQ== X-Google-Smtp-Source: AHgI3IYiXCy8vlkxDbo7wyB8co2rwJWcYHpxBl9dFMS3oF72ukfp24gDOJosZo6LVfLCQXC1MQGLKDNiX1d5s0BWI7w= X-Received: by 2002:a6b:dd1a:: with SMTP id f26mr4471666ioc.10.1549660351461; Fri, 08 Feb 2019 13:12:31 -0800 (PST) MIME-Version: 1.0 From: Barry Leiba Date: Fri, 8 Feb 2019 16:12:44 -0500 Message-ID: To: dmarc@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [dmarc-ietf] Do we need a session at IETF 104 in Prague? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 08 Feb 2019 21:12:34 -0000 It's time to decide whether we'll meet at IETF 104, so: Please post here if you think we *should* meet in Prague, and tell us what agenda items you're suggesting. Thanks, Barry, still chair for now From nobody Fri Feb 8 14:21:47 2019 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 37A8F130F84 for ; Fri, 8 Feb 2019 14:21:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.882 X-Spam-Level: X-Spam-Status: No, score=-1.882 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.018, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-Rl81fKCXet for ; Fri, 8 Feb 2019 14:21:44 -0800 (PST) Received: from mail-it1-f180.google.com (mail-it1-f180.google.com [209.85.166.180]) (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 23A56129A85 for ; Fri, 8 Feb 2019 14:21:44 -0800 (PST) Received: by mail-it1-f180.google.com with SMTP id c9so12955396itj.1 for ; Fri, 08 Feb 2019 14:21:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=9QmKUQULXW2NbooJ+Y5itpQWLKGRKfVtSrqAD/JTBsI=; b=JdKmDgtT+LnIRtk/EJE7yGadhZnQHWCpWk2mLHhnpzfSA4hf5zw/OmHGtKqnZ2l9Is gMCiDN6Q94STZFDWCAYCm7iJ0VCpfP+qKmLRvhInxRqom67iguxoqmv8YaFJed/ficY4 yq7e5Q8FtzciMZNe7+TkkDTevRSRgRdaDsQAmOIaEuuscVp4Zr7aOfOWwPLSZ/Xj+5o7 qN1QUZAVdRz6d8L93pFFHM50Jn3pdbTo25/YZn7WR/1NIzNWlzHnJoAD9vodsBoN9WZn mmgAqvCpBRI7wZ6hu3R98AuAlyy5ut5+o1HP1AV/22IAH/H8yBLkrzHQGxXU2m7RWgGl ntqQ== X-Gm-Message-State: AHQUAuZsVIzIonKX4QeJONBnGGXxWdN+Jeq0RVPYxMwissi3bnaEuJ/L HS+AFTdiopq9aDeNoBZgoBJAbxkLzRZxmjGhX+1zw0E8 X-Google-Smtp-Source: AHgI3IZOreF+shrSOv5tlfMyJu70b9fyjvd1CmuQeqr+thkWKItN5ZrE6T4zoNsUWO9TrrnAbTVTAWs/GURsGEFQYrc= X-Received: by 2002:a5d:8491:: with SMTP id t17mr12982558iom.11.1549664502847; Fri, 08 Feb 2019 14:21:42 -0800 (PST) MIME-Version: 1.0 From: Barry Leiba Date: Fri, 8 Feb 2019 17:21:32 -0500 Message-ID: To: dmarc@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [dmarc-ietf] We're ready with draft-ietf-dmarc-eaiauth X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 08 Feb 2019 22:21:45 -0000 As far as I can tell, draft-ietf-dmarc-eaiauth is ready for us to request publication. Kurt Andersen has agreed to be document shepherd, so while we're waiting for his writeup: Does anyone have any issues to raise with draft-ietf-dmarc-eaiauth? If I don't see anything within the next week, I will hit the "request publication" button in the datatracker. Barry From nobody Fri Feb 8 14:38:51 2019 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 1FE2A13102C for ; Fri, 8 Feb 2019 14:38:49 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8-uxKUcBWEy for ; Fri, 8 Feb 2019 14:38:47 -0800 (PST) Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (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 D5DFC12D84D for ; Fri, 8 Feb 2019 14:38:46 -0800 (PST) Received: by mail-ot1-x332.google.com with SMTP id t5so8629940otk.1 for ; Fri, 08 Feb 2019 14:38:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=mMisSWhm50x6aWJfqT1doize+wxjYV7T3lhXw2CtftY=; b=gWrbCVYbbz2fdA5X+rk5n1YYyhMGjHkEOQdqv/TINZq9S+HbkXOSIqOeG/wgCRGGq4 ik3MnIaxS6Dw0RUGB3wSA0yDhF+2bPJrjRG54qlxesK0puaJC3pgEFEaFerjzcz+P8BC 5ANGMhxayPHLRe/lNzJz2EG8PhtZLlV6LWaJJVcDpO2LgGl3yOcPwjAtDQPRFbJJ2ust odMIJy+CG7Ct60oLKFktAwP64mXSexvIu0btd3nbNICLctarX7mt+7/dfEzlzIk7pIFU ke+viAtZSrQCh9Gejd2yYmPJUDMRkYhyde2LubTn6SrVGQLdblanlIuUwNd6Z+E57Glw Boxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=mMisSWhm50x6aWJfqT1doize+wxjYV7T3lhXw2CtftY=; b=iVCIP2pmehx3wmiOkAvSdblqQGPgiiA/OticS6Jokjq0Qu3Ue2T9t8vZ5DYKkrR5T7 dNT4XJDah+cEQkZfL28WZabFP7Dd+Gw1SOIigh8JAWvaxwdhIHFVqhpFcqBiX8Evb//N +w27AAutphpt6JBltjfPP6NM1J/pzZJWH+QjnYebz/eO6YRr7oZhj8L+nZAjtMvnZuF1 gV25KgOEyNh4cnyZ7azZjjn8l6eX6vRKU5BsedzJ16j6E2k1zA2wt4SZq3ZKS+dwGmTl Zv/YCh+6rxP2ndMgvauxOJQNy1QxIX4A0x5G/KXtvE8bN/w8lo5CoXWB51bUFszhy6fr ebMg== X-Gm-Message-State: AHQUAua2IluPfVLSw82/MFgIshu6SnTYQiwICdEIIDleUgaWeKf7vuEg kOSwkBPzpwyxPOsZEK9ViPumo6lhfLjU25M59O4ZdsRIcKJBQw== X-Google-Smtp-Source: AHgI3IaWbI273L+6JiS6PlhwaEGFL+kxSeZvFoB8O8fpkAlHo6+6tkb+MWzRNBBNBmrPBaZYcK0G8GQ3KINOxz8Dx9M= X-Received: by 2002:a9d:7685:: with SMTP id j5mr15565012otl.150.1549665525669; Fri, 08 Feb 2019 14:38:45 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Seth Blank Date: Fri, 8 Feb 2019 14:38:22 -0800 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000002db84d0581699f88" Archived-At: Subject: Re: [dmarc-ietf] We're ready with draft-ietf-dmarc-eaiauth X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 08 Feb 2019 22:38:49 -0000 --0000000000002db84d0581699f88 Content-Type: text/plain; charset="UTF-8" The draft looks good to me. There was one typo in Section 2 that I sent to John privately. On Fri, Feb 8, 2019 at 2:21 PM Barry Leiba wrote: > As far as I can tell, draft-ietf-dmarc-eaiauth is ready for us to > request publication. Kurt Andersen has agreed to be document > shepherd, so while we're waiting for his writeup: > > Does anyone have any issues to raise with draft-ietf-dmarc-eaiauth? > If I don't see anything within the next week, I will hit the "request > publication" button in the datatracker. > > Barry > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --0000000000002db84d0581699f88 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The draft looks good to me. There was one typo in Section = 2 that I sent to John privately.

On Fri, Feb 8, 2019 at 2:21 PM Barry Le= iba <barryleiba@computer.org<= /a>> wrote:
A= s far as I can tell, draft-ietf-dmarc-eaiauth is ready for us to
request publication.=C2=A0 Kurt Andersen has agreed to be document
shepherd, so while we're waiting for his writeup:

Does anyone have any issues to raise with draft-ietf-dmarc-eaiauth?
If I don't see anything within the next week, I will hit the "requ= est
publication" button in the datatracker.

Barry

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--0000000000002db84d0581699f88-- From nobody Fri Feb 8 14:54:22 2019 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 765B0131067 for ; Fri, 8 Feb 2019 14:54:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=UyWiWZEy; dkim=pass (1536-bit key) header.d=taugh.com header.b=NZpkj4bd 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 QI-fSFIwEGoY for ; Fri, 8 Feb 2019 14:54:18 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20123131066 for ; Fri, 8 Feb 2019 14:54:18 -0800 (PST) Received: (qmail 88635 invoked from network); 8 Feb 2019 22:54:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=15a39.5c5e0898.k1902; bh=2Jd6vexsCrmBaPonuLhC/BfZc5fUpcDRBePN/CuDS14=; b=UyWiWZEyXMOqr2dyGMkoRiRZDwb1aPY/5yqXsJlGULbRklLHHWcX7aTH/h4xoHs2y4AVJ+ndI8+Dh60pAMKZ5zUYqyGgQBYvG/rfojQaDGHilyUXr/IdH1l7xNm3NeT/y2njBppJZPE869cvclTy7jAptoQXC5qD36TKqF21O6bErcaarpp6mT5g7Hm3jnk7XntK916cUEZRrL5AE5VxBzvZYciUq8DOLXhtFRh38F5DU96hkYvaV6RQvevyuZm8 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=15a39.5c5e0898.k1902; bh=2Jd6vexsCrmBaPonuLhC/BfZc5fUpcDRBePN/CuDS14=; b=NZpkj4bdfvmnh/KYUv9T48qJF+6MBqHB8IezdA3sB7FFHw3as7jiWeT1X+Kkz0vr1U26RDgX0NrsvRQWD1PrZj6S8IfCIakXGWSRcJhEz23MVkhBu+FClSQavD0UTJZ9NmymQUVL0TdOVs/tbfPMC82a3xtALROx6AltszFraneAe6FFLSXxWmUv8JCj8mIQMNELzd7kNt5D9sYLQOgHL7EO6uDR1K0KpZmFLKI53EGqloCkdpLjb2pyJixA3dCP Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 08 Feb 2019 22:54:16 -0000 Received: by ary.qy (Postfix, from userid 501) id 628D9200DFF277; Fri, 8 Feb 2019 17:54:16 -0500 (EST) Date: 8 Feb 2019 17:54:16 -0500 Message-Id: <20190208225416.628D9200DFF277@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: seth@sethblank.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] We're ready with draft-ietf-dmarc-eaiauth X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 08 Feb 2019 22:54:19 -0000 In article you write: >> Does anyone have any issues to raise with draft-ietf-dmarc-eaiauth? >> If I don't see anything within the next week, I will hit the "request >> publication" button in the datatracker. I have a version that fixes a few typos and has a new paragraph pointing out that DKIM relaxed header canonicalization folds the header names to lower case, but those names are still restricted to ASCII so nothing changes. From nobody Fri Feb 8 15:13:05 2019 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 4818412D4E8 for ; Fri, 8 Feb 2019 15:13:03 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tjlD5fB3aPNY for ; Fri, 8 Feb 2019 15:13:01 -0800 (PST) Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (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 E80F7127AC2 for ; Fri, 8 Feb 2019 15:13:00 -0800 (PST) Received: by mail-ot1-x335.google.com with SMTP id e24so8614143otp.11 for ; Fri, 08 Feb 2019 15:13:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=6f9Xi/gOoyp3kYiZqAtG+PYSHdB9sNGJfzWyM7O8UYI=; b=VzgAv4JxmxR+pjCIE8OvhgO60edLxe2Vc2yTJ0howHrCGCJbtsP71C5CIuqV5Ph8M3 aj756e239tYVaEoPXAInmkvhXYzSk7NHec0xglSbaNh/QEGZaeUl1hINIh1BLvy3DGPa FKSMo9S+Cq5KLPkApoTp597VecnassA5UzZOvzu5pXQ42hSD5TRqmAY+jJoLwoF4bq7l qqzISMATo6mij+UfEVpq1YMHIdhXbhE7eB12N4hsBLonGkNhA4RjavbVspWiuEf85tMw BpHqvOo7b9n7+nuasFEcUMQARU81JXvvIiOCUUph5F2eF3+47ujYOZgVY3oNeE6yJqFJ FCCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=6f9Xi/gOoyp3kYiZqAtG+PYSHdB9sNGJfzWyM7O8UYI=; b=cIOM+doFnxCQvGAP6/ZsU8ARhidg6D2LstN9zTgkytDU7aJ8um856jAwGQwnh0oeex 2Pj+izlaxD3+IR7IR+jgPVFRhV2y8ojqbjcrLQtT2rckXMplfak6sFMzFOgyWeMxQNma 4UWT69U9sycLQRU7gXfPFn9B/Nk6M547d+PJnDESHWgpx4g1+VXnIQZusqtk3OEQ5rSJ SRkyeFOzlSrJ+jF4d3h0UZ/A5QJmnvmbkYwS5kNVOEFVMXMv1acTPGIvrVq4wFkw0f3k 801LmLsSpVizUHMLu+i5ofaIhg6gHlOiJwnGVA8XJjufisXMo0ZajETeo6Y3E/xeEwMt jOEQ== X-Gm-Message-State: AHQUAuav5eDdRqXpH5JcJDaiKfpqODyeCaK63+blsiBUiPYr0GjrtQVo j8bZiO+t94XepgwJtLZs2kM83Bk4c762oTZFATaI29E7D88= X-Google-Smtp-Source: AHgI3IYsT4Un/IxR9PPvVor11G6pt6Vyeiihr1tQu/GXG8y7IsV7EU2vFexft3hHSr2MJuKudwThXTgyDUfRfnpwefw= X-Received: by 2002:a9d:4c18:: with SMTP id l24mr2072401otf.120.1549667580006; Fri, 08 Feb 2019 15:13:00 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Seth Blank Date: Fri, 8 Feb 2019 15:12:36 -0800 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000a06fb305816a19ca" Archived-At: Subject: Re: [dmarc-ietf] Do we need a session at IETF 104 in Prague? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 08 Feb 2019 23:13:04 -0000 --000000000000a06fb305816a19ca Content-Type: text/plain; charset="UTF-8" On Fri, Feb 8, 2019 at 1:12 PM Barry Leiba wrote: > It's time to decide whether we'll meet at IETF 104, so: > > Please post here if you think we *should* meet in Prague, and tell us > what agenda items you're suggesting. > If Kitterman's Public Suffix Domain draft - and the proposed mechanisms for controlling abuse - haven't reached consensus by the meeting, I think that's ripe for a face to face. At IETF99 we also discussed next steps for DMARC phase 3 and driving a standards-track version of DMARC. Now that ARC is in the RFC Editor's queue, it feels like the appropriate time to pick that conversation back up. Realistically, IETF104 feels like the appropriate venue for both of these. --000000000000a06fb305816a19ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --000000000000a06fb305816a19ca-- From nobody Fri Feb 8 16:06:35 2019 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 C62E6130E79 for ; Fri, 8 Feb 2019 16:06:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AYP55S10ibSA for ; Fri, 8 Feb 2019 16:06:31 -0800 (PST) Received: from mail-it1-x134.google.com (mail-it1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 C2079130E62 for ; Fri, 8 Feb 2019 16:06:31 -0800 (PST) Received: by mail-it1-x134.google.com with SMTP id r6so13510158itk.0 for ; Fri, 08 Feb 2019 16:06:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cktlhFuzLu/ptXuKuBAzWOQyHA6dVs6B3LS3SxH6amE=; b=BsU37Ww6UoMAiLtIDasYTqvRLuzBA0hL3PeW4Lx6gYkrozkE+6gmzW69UnXu9g7zSW NtXPhjSsWbs+RATwMH9NHssTA+gM1R0aSYoq0Y0wWCzWe1xtr3KOwlySzVipaYz1UN4i jZlcdW2k0kCvrfqRXd/EPfLOLP405O7Xmiahc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cktlhFuzLu/ptXuKuBAzWOQyHA6dVs6B3LS3SxH6amE=; b=gSdwcWcYUQRuNv/JVYCwDUycRFLsNHqNb4p/J4ut4O10A4vCY4xPuN7PTbUFRICnep KrSRUHZy5b7RNg6elrZrpYa+MN3D9HgxVUZ4Wr8JS9UGOMLLolyWNr24nEd1yWWI5tRA +lwld+qHpvHZAziy6klYK7N3rkLiWDb7cdOuyvMd8D35p3cD5IW9bJR3InVcagYF7d2u sI971z5brG8bQUs1tJ5XnMOSC/ED3NZ6a+X373J/sxBJmySBs+yKvGOzdpqb3rSsPAau qPrMNvuy3oXwPVNu3GWopP6iyziUWuLUHt1JtMmGQXIIbDs/XPaBPAiva4rgx6UtjxTO 29FQ== X-Gm-Message-State: AHQUAubGICQMnCm52vYSXrtOqGICTYoGcM/zvkvEqQ/Y+ZHd3seBq16q yjZvLT7ErYxqy8uiMScq8+FVg2kwd9NIyEqSiBFJxA== X-Google-Smtp-Source: AHgI3IahDeEMOBqLQdrp89gviFaLUySxZ0YrkNLPIjXWYzqkRaU0BxZzk4hbvInCZPjIwZTkJWqeLVRaoCstzSjgSr8= X-Received: by 2002:a6b:6306:: with SMTP id p6mr14282794iog.196.1549670790478; Fri, 08 Feb 2019 16:06:30 -0800 (PST) MIME-Version: 1.0 References: <20190208225416.628D9200DFF277@ary.qy> In-Reply-To: <20190208225416.628D9200DFF277@ary.qy> From: Kurt Andersen Date: Fri, 8 Feb 2019 16:06:16 -0800 Message-ID: To: John Levine Cc: dmarc@ietf.org Content-Type: multipart/alternative; boundary="000000000000fc544605816ad889" Archived-At: Subject: Re: [dmarc-ietf] We're ready with draft-ietf-dmarc-eaiauth X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 09 Feb 2019 00:06:34 -0000 --000000000000fc544605816ad889 Content-Type: text/plain; charset="UTF-8" Would you care to post that version? The nits check is whining about some out of date refs and one down level citation. --Kurt On Fri, Feb 8, 2019, 14:54 John Levine In article < > CAD2i3WPm8VyRN7yCnQYNdpWLATb2XYaq-9jzOcmpcDNz6taSHQ@mail.gmail.com> you > write: > >> Does anyone have any issues to raise with draft-ietf-dmarc-eaiauth? > >> If I don't see anything within the next week, I will hit the "request > >> publication" button in the datatracker. > > I have a version that fixes a few typos and has a new paragraph pointing > out that DKIM relaxed header canonicalization folds the header names to > lower case, but those names are still restricted to ASCII so nothing > changes. > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --000000000000fc544605816ad889 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Would you care to post that version? The nits check is wh= ining about some out of date refs and one down level citation.

--Kurt

In article <CAD2i3WPm8VyRN7yCnQYNdpWLATb2XYaq-9jzOcmpcDNz6taSHQ@mail.gmail.com<= /a>> you write:
>> Does anyone have any issues to raise with draft-ietf-dmarc-eaiauth= ?
>> If I don't see anything within the next week, I will hit the &= quot;request
>> publication" button in the datatracker.

I have a version that fixes a few typos and has a new paragraph pointing out that DKIM relaxed header canonicalization folds the header names to
lower case, but those names are still restricted to ASCII so nothing
changes.

_______________________________________________
dmarc mailing list
dmar= c@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--000000000000fc544605816ad889-- From nobody Fri Feb 8 16:59:23 2019 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 0D98C131069; Fri, 8 Feb 2019 16:59:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dmarc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dmarc@ietf.org Message-ID: <154967396202.31180.18310867484527571037@ietfa.amsl.com> Date: Fri, 08 Feb 2019 16:59:22 -0800 Archived-At: Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-eaiauth-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 09 Feb 2019 00:59:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain-based Message Authentication, Reporting & Conformance WG of the IETF. Title : E-mail Authentication for Internationalized Mail Author : John Levine Filename : draft-ietf-dmarc-eaiauth-01.txt Pages : 6 Date : 2019-02-08 Abstract: SPF, DKIM, and DMARC enable a domain owner to publish e-mail authentication and policy information in the DNS. In internationalized e-mail, domain names can occur both as U-labels and A-labels. The Authentication-Results header reports the result of authentication checks made with SPF, DKIM, DMARC, and other schemes. This specification clarifies when to use which form of domain names when using SPF, DKIM, and DMARC and when creating Authentication- Results headers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-eaiauth/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmarc-eaiauth-01 https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-eaiauth-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-eaiauth-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 8 17:00:39 2019 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 52DFA1310D5 for ; Fri, 8 Feb 2019 17:00:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=jWpMQcoG; dkim=pass (1536-bit key) header.d=taugh.com header.b=GM4VrVHX 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 calWyrvlCAS1 for ; Fri, 8 Feb 2019 17:00:24 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AA7C131071 for ; Fri, 8 Feb 2019 17:00:21 -0800 (PST) Received: (qmail 29297 invoked from network); 9 Feb 2019 01:00:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=726f.5c5e2624.k1902; bh=tC7D4YLQrF1RGkrevn0AFrHsbS/aNx1yry8CCD8841Y=; b=jWpMQcoGqHwDGGw8zk8f77wOuqODvlagh5LIkudWzMwagkhxqAWoZ84OT10l4W6HG9h3vXL8dHAzYJQApYmTteLoDeM1mNeVuZehL+mFdUYNNbmzIgPBCxELZt8T4OrXU1og29pB5sAXilcVtQ4DzHW/GgCBglWk/k4P8Z9r9yx/aA20AWA2Ur1kkw2XpiJ27UABy97ndIku2zFLX7EVRFhKQlIgxq4u643kvZpFuWPy968MAYQHlBmW5rjsJ7U4 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=726f.5c5e2624.k1902; bh=tC7D4YLQrF1RGkrevn0AFrHsbS/aNx1yry8CCD8841Y=; b=GM4VrVHXiIX1vYEi4+BeGlw+g7CV0PPlkUlvRlhupkr318K+VsfoZqpPMHzRs1kG4AnZN9eUMJIaVMTzqiL/WaO0friY1GyK0Epgd0MBXD/K3opO1rVT1Q9Q8QZGktYBw5mAX6IcJd4BOeBvrU+mp4A6Pz1go/S8CaO6oF/DDTGfyaW3QS7LPvQRft2T9QdkQmtS/l6q6jLjPzkCSNJlaA5pekmEY5a7mLLlXFq9vkmzifjt4TJRsOUEvA4s8pEk Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 09 Feb 2019 01:00:19 -0000 Date: 8 Feb 2019 20:00:19 -0500 Message-ID: From: "John R Levine" To: "Kurt Andersen" Cc: dmarc@ietf.org In-Reply-To: References: <20190208225416.628D9200DFF277@ary.qy> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] We're ready with draft-ietf-dmarc-eaiauth X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 09 Feb 2019 01:00:37 -0000 > Would you care to post that version? The nits check is whining about some > out of date refs and one down level citation. Done. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Fri Feb 15 09:56:13 2019 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 DC3161271FF for ; Fri, 15 Feb 2019 09:56:11 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=IrYKjXm8; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Nk74VEGW 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 0aw4oxsqvYDR for ; Fri, 15 Feb 2019 09:56:10 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A65BA1274D0 for ; Fri, 15 Feb 2019 09:56:10 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 1A61D22089; Fri, 15 Feb 2019 12:56:09 -0500 (EST) Received: from imap1 ([10.202.2.51]) by compute7.internal (MEProxy); Fri, 15 Feb 2019 12:56:09 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= message-id:date:from:to:cc:subject:content-type; s=fm2; bh=Jbdwi TyDJdBXUQhD0KRAToQCQYdbm+O2Xi7j4s8TsTQ=; b=IrYKjXm83BVpwdrMOlRMt jCm9Gd7nd4K9sCwm+dhYyHg+pTG/Ge4Hq3mEyu33wzqtKhBrQ0av8IGujBSBhlQ9 ag5nXETAjJq6hUkvy2/mIiDNpLgJcP2gUJRlMlS9QZgQuEC0xoQvvF68nRvdd3Fa rOxsBJVqfqa87dRxLJrJBTW5iyzy71lNmwvLM59ydQWxrXVAtXGOtOWjLM2iryA+ 8b4Bxj+gmeSDmFtjlZLWbp1odoq+8z80w0TtuPTpuReBEL3T0mcDOb94wiNauTR8 XJ9JigwnE5ogrtWlky+ODvx3afVZWndEC9GbTlihyNxoLbiwdcobjOOWj4VhK3Ng w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:message-id :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=JbdwiTyDJdBXUQhD0KRAToQCQYdbm+O2Xi7j4s8Ts TQ=; b=Nk74VEGW6lVq3i49MXdWLcUpRqlzy3lC4etgb7J2pD8M4EediKa96cT5E 7YIJwJMSBq3RIav0TZUKDtSJx3gWOM0y3pofU2OoZmQEKdEu3OUEX0xDUQIJwGKM A6WNA7wQU4zC8LS3Jj4BP+hCobAZny6+TXo2oEKSLNVaAOl06oGELuwzquKwL5E8 D+1x7sI5Kt9T0LyvYVPXr/Zbf9ZM4w6yX99775f1sXLM4XJrlvbtHxIp+Ly7+Od2 819L6xay+Q/Ke3iarr6ZC8EuxQO/YDbj3qBOP/jjhd/TcYUnKcWtTwV115dtkYey m+IY16EEZzIyRc3n2bAxWA+Mf3kNQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledruddtjedguddtjecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecu fedttdenucenucfjughrpefofgfkfffhvffutgesthdtredtreertdenucfhrhhomhepfd etlhgvgigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghlnhhikhhovhesfhgrshhtmhgr ihhlrdhfmheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrrghmvghlnhhikhhovhesfh grshhtmhgrihhlrdhfmhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id C653CD43B7; Fri, 15 Feb 2019 12:56:08 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-832-gba113d7-fmstable-20190201v1 X-Me-Personality: 21611513 Message-Id: <04ab15f9-6257-4db0-a046-6381670047f4@www.fastmail.com> Date: Fri, 15 Feb 2019 12:55:41 -0500 From: "Alexey Melnikov" To: dmarc@ietf.org Cc: "Murray S. Kucherawy" , "Tim Wicinski" Content-Type: text/plain Archived-At: Subject: [dmarc-ietf] New chairs for DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 15 Feb 2019 17:56:12 -0000 Dear WG participants, After talking to various candidates and discussing them with my ART co-ADs, I am pleased to announce that Murray Kucherawy and Tim Wicinski agreed to co-chair the DMARC going forward. I would like to thank Tim Draegen, Ned Freed and Barry Leiba for helping the WG to complete ARC and draft-ietf-dmarc-rfc7601bis. Best Regards, Alexey, as AD From nobody Fri Feb 22 11:08:36 2019 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 72433130F66; Fri, 22 Feb 2019 11:08:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dmarc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dmarc@ietf.org Message-ID: <155086251443.5492.6412543069631896433@ietfa.amsl.com> Date: Fri, 22 Feb 2019 11:08:34 -0800 Archived-At: Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-eaiauth-02.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2019 19:08:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain-based Message Authentication, Reporting & Conformance WG of the IETF. Title : E-mail Authentication for Internationalized Mail Author : John Levine Filename : draft-ietf-dmarc-eaiauth-02.txt Pages : 6 Date : 2019-02-22 Abstract: SPF (RFC7208), DKIM (RFC6376), and DMARC (RFC7489) enable a domain owner to publish e-mail authentication and policy information in the DNS. In internationalized e-mail, domain names can occur both as U-labels and A-labels. The Authentication-Results header reports the result of authentication checks made with SPF, DKIM, DMARC, and other schemes. This specification updates the SPF, DKIM, and DMARC specifications to clarify which form of internationalized domain names to use in those specifications, and when creating Authentication-Results headers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-eaiauth/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmarc-eaiauth-02 https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-eaiauth-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-eaiauth-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Feb 23 10:08:04 2019 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 6F80212F19D for ; Sat, 23 Feb 2019 10:07:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable 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 ToIU34bDNfPC for ; Sat, 23 Feb 2019 10:07:54 -0800 (PST) Received: from mail-it1-x135.google.com (mail-it1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (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 3A0BC130DC8 for ; Sat, 23 Feb 2019 10:07:54 -0800 (PST) Received: by mail-it1-x135.google.com with SMTP id z131so7554947itf.5 for ; Sat, 23 Feb 2019 10:07:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:from:date:message-id:subject:to:cc; bh=OxrETRP9W0S7/ucM2//IinFG/6Tl9DIFogHtWfaBGt8=; b=RL8pERAvCXrhNeVqs+2oHJ575lLtzgnYagmS6K70zYmyO9KRIVVz0XnR03M7GdMkKK xppJiRRxOCvqM8xzjxCfiHzEC0rNL3VBey1Xr0VLGVccVkdYbVqyTXnmk+hM0TWz2uwY 1vD+HIKRjUxHUcOCGyU4BDl36vq1A29mxd23g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=OxrETRP9W0S7/ucM2//IinFG/6Tl9DIFogHtWfaBGt8=; b=r3/0BvBuSjIzjQSqJXnYAMJ7cukTfgWSjPotJmt1vLA2lOD5x3iskS/BCjkDOUd4Ye e7ed53hefVCpB9jS+LR0FBFdG3fbH+0gRR6B/YfI84/djgtEZYMWMfEpbJdA12roHCzN t/uDf9+ivx+iTI7jcfa/t7tu+UZqQrjRMBCMuSnc/hneqOLIx3f+oRk9sZ+JkcCu58rO 9lbJ9WAOWj9SNV4Dsq0+FrsDbZ5DIf9uOcTX/VLAxb4Gz8iDFiOTSABEFPOp6tu3X9E2 u9CGSbIjrrXCoNQByXqonPWy5AcCtpub2vPCeFuoZCgaAIH2ojXix1gAHrvnDODhYn1X ue0w== X-Gm-Message-State: AHQUAubVlMC+Lz7yPLidoo9kxahSG6ZxDFlLYczpuALlL5Mp5C6gvMFn URBNhMcpvLK3W6SnAsBlKUNB+B8bP0R1oUqS/mRJyLuK X-Google-Smtp-Source: AHgI3IbJwDd/9Ex4/FjEuSFducVUs4L2KkSKQSMhQ803l6HszyVq8cqs2KUWi6yOBaHI5jPSOs8PcVqnvS6LG7elLps= X-Received: by 2002:a24:3c05:: with SMTP id m5mr6037961ita.78.1550945272700; Sat, 23 Feb 2019 10:07:52 -0800 (PST) MIME-Version: 1.0 From: "Kurt Andersen (b)" Date: Sat, 23 Feb 2019 10:07:31 -0800 Message-ID: To: "dmarc@ietf.org" Cc: spfbis@ietf.org Content-Type: multipart/alternative; boundary="0000000000000bbbb5058293963e" Archived-At: Subject: [dmarc-ietf] Should we encourage the use of SPF "soft include" for common platforms? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 23 Feb 2019 18:07:57 -0000 --0000000000000bbbb5058293963e Content-Type: text/plain; charset="UTF-8" With the growth of huge platforms that emit mail from the same common set of IPs (such as GSuite, O365, or large ESPs), regular SPF "include" ends up granting a DMARC pass to a lot more potential authors than most organizations would necessarily choose to grant. Instead of using the standard "(+)include:" approach, if domain owners used "?include:" as their mechanism, then that would prevent the SPF result from granting a DMARC PASS result when traffic is coming from one of these massively included platforms. It would essentially force the DMARC result to be driven only by the DKIM evaluation. Thoughts? --Kurt Andersen (I'm copying the spfbis list too because there may be folks lurking there who are not on the DMARC list) --0000000000000bbbb5058293963e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
With the growth of huge platforms that emit mail from the = same common set of IPs (such as GSuite, O365, or large ESPs), regular SPF &= quot;include" ends up granting a DMARC pass to a lot more potential au= thors than most organizations would necessarily choose to grant.=C2=A0
=
Instead of using the standard "(+)include:" approa= ch, if domain owners used "?include:" as their mechanism, then th= at would prevent the SPF result from granting a DMARC PASS result when traf= fic is coming from one of these massively included platforms. It would esse= ntially force the DMARC result to be driven only by the DKIM evaluation.

Thoughts?

--Kurt Andersen

(I'm copying the spfbis list too because there = may be folks lurking there who are not on the DMARC list)
--0000000000000bbbb5058293963e-- From nobody Sat Feb 23 10:39:26 2019 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 93F7A130DE9; Sat, 23 Feb 2019 10:39:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FdnC2HRpRdMU; Sat, 23 Feb 2019 10:39:15 -0800 (PST) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 DFDDD12008F; Sat, 23 Feb 2019 10:39:14 -0800 (PST) Received: by mail-io1-xd35.google.com with SMTP id p18so4455271ioh.5; Sat, 23 Feb 2019 10:39:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4xHEsg0hs5sFBAHveQfbBLV0VSwGDNlzUYLi6wI0yxg=; b=RHfpVJyokNw9hpu5ZaNNQ54jjx5uLeFxEFcn43m/kmMbchPBlWGFUiJ6/TjMAKuM4n rA5smKUwhaYFrLiuygOrx+uJWk/BMh/luTFnXOhvileGQUh5YZrf2SiMMx7phsWEWpuk iekGa3Y92LMXU8D4wCQT/Sf/VuulQdKSoycPrIkLfSOWSnMbOLw7v4+uxJR67qlxul+z S6YFGn5xN/5yvqbphC9qfzwI1mnwWOZvMEfP45FOlQe9Q09vhvKzGk//9RqJHtWjfRpg ds1SSh2zklptLI7uGa2kGNGSS0NOkqtU8RNzdRV+RMSjXm/o38R1tlE2VI3OEaK/bJ/Y e5Fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4xHEsg0hs5sFBAHveQfbBLV0VSwGDNlzUYLi6wI0yxg=; b=sxL4Wx7iB1KbFanRUS6xSE+f0jE8eeA1b8xE9AB8qVHtM5J/NTcuybcS7lMc+Y6IpN DmvgffPOU+ihj+ZhHTf5BInUzCzVb7/dqDSFjHaJNK7mZX1/FdkxKkvQ9WRvJcSEGU6Z 88KfCOeMIIZzm/0Obd7pgDLn0iqjxCIF0VI8njffowPYTmVpoWC2J0e159za/gl07Ca4 mHgc+NkT6+wTf/QCbaVGWjkH+jeIpqEkSgyMZ5wM7u9PYqpzq8v8NeKgwSOW7WyQNTYD 5to0Xi4/lBXmK23unq71GATvflEVklQtZfnUwajZpgPzcGWo0QR6G1DRnihCFc3dGY96 I6tw== X-Gm-Message-State: AHQUAubOUlwuGn9nffi7nwJbah/sHlJv+tq0CaXe2cwWOOhAI2kfZ5lp zwBQnp55o82Qz9xyHEPRfcaqJ0pxZM/OuWxd968= X-Google-Smtp-Source: AHgI3IYCCjORNnROjuuO+2kdpF7RTWSs4qhZeCcDU82leDABKU8c7YdNy0MWCbSTziffn9SKoMkpjZaMLh0wxmuxAQM= X-Received: by 2002:a5e:8d0e:: with SMTP id m14mr5909049ioj.30.1550947153771; Sat, 23 Feb 2019 10:39:13 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Tim Wicinski Date: Sat, 23 Feb 2019 13:39:02 -0500 Message-ID: To: "Kurt Andersen (b)" Cc: "dmarc@ietf.org" , spfbis@ietf.org Content-Type: multipart/alternative; boundary="0000000000002a814d05829406cf" Archived-At: Subject: Re: [dmarc-ietf] Should we encourage the use of SPF "soft include" for common platforms? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 23 Feb 2019 18:39:18 -0000 --0000000000002a814d05829406cf Content-Type: text/plain; charset="UTF-8" Kurt This is pretty interesting. I've been assisting several teams as we have been (very) slow rolling the DMARC policy out of reporting through quarantine into reject. They been pulling all the disparate teams into deploying DKIM, but I was pointing out they have been guessing on who is using DKIM vs. being in our datacenter (and thus our SPF records). Doing the ?include would assist especially on operational type deployments. Tim On Sat, Feb 23, 2019 at 1:08 PM Kurt Andersen (b) wrote: > With the growth of huge platforms that emit mail from the same common set > of IPs (such as GSuite, O365, or large ESPs), regular SPF "include" ends up > granting a DMARC pass to a lot more potential authors than most > organizations would necessarily choose to grant. > > Instead of using the standard "(+)include:" approach, if domain owners > used "?include:" as their mechanism, then that would prevent the SPF result > from granting a DMARC PASS result when traffic is coming from one of these > massively included platforms. It would essentially force the DMARC result > to be driven only by the DKIM evaluation. > > Thoughts? > > --Kurt Andersen > > (I'm copying the spfbis list too because there may be folks lurking there > who are not on the DMARC list) > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --0000000000002a814d05829406cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Kurt

This is pretty interesting.=C2=A0 = I've been assisting several teams as we have been (very) slow rolling t= he DMARC policy out of reporting through quarantine into reject. They been = pulling all the disparate teams into deploying DKIM, but I was pointing out= they have been guessing on who is using DKIM vs. being in our datacenter (= and thus our SPF records).=C2=A0
Doing the ?include would assist especi= ally on operational type deployments.=C2=A0

= Tim

On Sat, Feb 23, 2019 at 1:08 PM Kurt Andersen (b) <kboth@drkurt.com> wrote:
With the growth of huge platforms that emit mail fr= om the same common set of IPs (such as GSuite, O365, or large ESPs), regula= r SPF "include" ends up granting a DMARC pass to a lot more poten= tial authors than most organizations would necessarily choose to grant.=C2= =A0

Instead of using the standard "(+)include:"= ; approach, if domain owners used "?include:" as their mechanism,= then that would prevent the SPF result from granting a DMARC PASS result w= hen traffic is coming from one of these massively included platforms. It wo= uld essentially force the DMARC result to be driven only by the DKIM evalua= tion.

Thoughts?

--Kurt An= dersen

(I'm copying the spfbis list too becaus= e there may be folks lurking there who are not on the DMARC list)
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--0000000000002a814d05829406cf-- From nobody Sat Feb 23 11:00:05 2019 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 C4A6B130E13 for ; Sat, 23 Feb 2019 11:00:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=lOG48ZrH; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=eMGXLU8L 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 EopeTtuSZwOT for ; Sat, 23 Feb 2019 11:00:00 -0800 (PST) Received: from mail.winserver.com (ntbbs.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id B81DB1286E7 for ; Sat, 23 Feb 2019 10:59:59 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2230; t=1550948391; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=P6v8RuYFj4602tCm8hjnIfoGiRw=; b=lOG48ZrHbp+ISkw+vrVnBIuAEV0U2zB0YIyqVjgXP4X6Fnf1w+cPsUXwzlCcn1 HEYWE6GqZBOe9sM3Uju/lFhpgy+UXDXnsf8mapFIOFjWkATflNgt/JDC+YEvkiTK 6EXZY+PbsfNMWj2mrWhbuP76Pbhb6Rx/BxMJHmBpzyI90= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Sat, 23 Feb 2019 13:59:51 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 1355302072.1.2820; Sat, 23 Feb 2019 13:59:49 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2230; t=1550948087; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=fyrbf/s mdH6rhk7cQixiPrKpB9/Ce5qL4z6ZfunXq2s=; b=eMGXLU8LVp8Jc+zLhLhCDYS ojGUn1yxImGayeNty+GkSs4D3LXPa/nzpV0q5RT4BUz+xmyUUClSh5TPGFkT8X25 vXSEx5mFNzf7+D47u1yvRyT0350Hkm1eWijplqFMjntTR12kDOVrPqP1piUjK9Fp KA2+54afjJga3IqsOE1M= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Sat, 23 Feb 2019 13:54:47 -0500 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 1903197283.9.355064; Sat, 23 Feb 2019 13:54:46 -0500 Message-ID: <5C719828.1000802@isdg.net> Date: Sat, 23 Feb 2019 13:59:52 -0500 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: "Kurt Andersen (b)" , "dmarc@ietf.org" CC: spfbis@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Should we encourage the use of SPF "soft include" for common platforms? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 23 Feb 2019 19:00:03 -0000 On 2/23/2019 1:07 PM, Kurt Andersen (b) wrote: > With the growth of huge platforms that emit mail from the same common set > of IPs (such as GSuite, O365, or large ESPs), regular SPF "include" ends up > granting a DMARC pass to a lot more potential authors than most > organizations would necessarily choose to grant. > > Instead of using the standard "(+)include:" approach, if domain owners used > "?include:" as their mechanism, then that would prevent the SPF result from > granting a DMARC PASS result when traffic is coming from one of these > massively included platforms. It would essentially force the DMARC result > to be driven only by the DKIM evaluation. > > Thoughts? > Kurt, In general, in the name of cooperative competition, I am *always* in favor of a protocol "standard" that applies to all scales. So it shouldn't matter it its huge or tiny, the protocol applies equally. It helps to use an example. For example: gmail.com has: v=spf1 redirect=_spf.google.com which returns: v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all The SPF processor result SHOULD be based on each one. In this case, each include results in a softfail (~all) when there is no match. Keeping in mind the recursive complexity that can occur here with multiple layers of includes, it sounds like you are proposing an include prefix result should override matching result, including the default/final result. So for example, using one the includes for gmail.com: v=spf1 include:_netblocks.google.com include:_netblocks2.google.com ?include:_netblocks3.google.com ~all where you want to override the results of _netblock3 with a neutral result rather than use the matching result or final/default result of the specific include. Unless the conditions were limited to when this can be applied, I can see where this can become really complex because of higher recursion potentials. You also have compatibility concerns as well. I have to recheck to how my legacy platform SPF code is designed for such a recursive include result override "change request" but is this what you are basically asking for here? -- HLS From nobody Sat Feb 23 11:35:30 2019 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 E925E12F1AC; Sat, 23 Feb 2019 11:35:20 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=corp.mail.ru 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 Fs1Bp7g2YewT; Sat, 23 Feb 2019 11:35:17 -0800 (PST) Received: from smtp43.i.mail.ru (smtp43.i.mail.ru [94.100.177.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A24D512870E; Sat, 23 Feb 2019 11:35:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=corp.mail.ru; s=mail; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=ovTN3St5/G0cNoq/LN6G24V8hJ7DaC2gMzZom5psiZc=; b=b5uU2qOV6yUimVk8V2QTxuQd9bVq9rdKStTcyOuPzSVtWLAvUPC8dOmJaPctJvFMg7Zjz1ZdirsjfMCcXFSPn/CC1U9GgoPJNdIsFfdIKVVobbD1sFS3KMwvv7uMhiTLODL+X98iMW4WOdVE4K/wD1qzbn4ZMcFYfSrzwlZfT7A=; Received: by smtp43.i.mail.ru with esmtpa (envelope-from ) id 1gxd4q-0006Ld-Vk; Sat, 23 Feb 2019 22:35:13 +0300 To: "Kurt Andersen (b)" , "dmarc@ietf.org" Cc: spfbis@ietf.org References: From: Vladimir Dubrovin Openpgp: preference=signencrypt Autocrypt: addr=dubrovin@corp.mail.ru; prefer-encrypt=mutual; keydata= mQINBFkuo0YBEADhYgaiCbZjws9eRBKJAYMIeuo9x6cArdmG5lcDgyVrtIPz/7MGL/HJua0v xKJtfhk77fb2YKcJvIdCf6HMoJfU412Y/5Bjq7eLmXTBsf7KmpQ9Z6auYujrzLCEb6gHC4gp gauesj6+igIyd8YULbbbCieIht7FVEIQv1Hn6F3eIok6wC3UJi2gEUiRbN4p5fw1RI5IB8yJ /4iFTtZi2iKUvSxZt/6eMAGNYm+OrFFGSfCP6l3uD93ZO3M9x8TluMXXrUQM6J190LOUUeh7 jGklgyUxrJXi44pRLFMbirrBcCQwEcY/lpUb1tvq2Ohb9nhBFBWLoJ1Kplxpi9ueXAsNJ7zw K1R15EElpIYQEmXM7t3dvC+zRIwZOiYTEI+cTqi3+fe/89lVQB15R43lrALl3+GEOj2F9/HP eCJtTzn+ie8+p0lSIWhNb2ozRPaKv1vxEGqkA+1wcgF2EOh3melRKGnf5VKJ4ZL5LZi+55nV NV/MiHv6WuA6QEB08qxgkF1vmpy3olQmpxzRHGnLcKClAnkfgn3Gp4Kkf/cKZ/jmgycf3QiZ OX9pJmChkp7florVmb31gXnZwiwa3AM5j063+JE6r0Uwt5R4TZsOx109U9a0ta4eS6fE22+O pEPKddpaOPnCTB/RDcxFbyXWJw8J5FW6EUbNSaBQTIjZn6jUnQARAQABtClWbGFkaW1pciBE dWJyb3ZpbiA8ZHVicm92aW5AY29ycC5tYWlsLnJ1PokCPwQTAQgAKQUCWS6jRgIbIwUJCWYB gAcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEKxNqiqt3SqHr3kQAInNgkXiRv61Zs4g B2mxrPtTRij+iDF+UOJVA/A5SjHaMWPVbT0PblbwWkxQvaxBDEPN4NRp+5mLkxD6ETmJJFZx gfmB3N9vhqFjHVb9K6AqGc7qlhlGwoIj6x27F07lmNkYHXMqqdt9Nbk+FvjukDU4WMZYFtXu 4c43hclKCg2i+bgZ5rXNJFsLioaY2Z/6Yml4COwvhDSg+IXF8oZtnf0Y8EP9qPeC3DHpL5n1 IgcB5mpzcBdsQchIVVCYCljVf0g5wslfs0tKvyrOsSF1gX8NK6gY3mZb44f5M2yviL/DFCS2 lmZDX2HqCmgyI0GwLTEW9zuZKE0WT6FF2KbWv3QbkwplygCQYlwCeEDOiemIsGiM11ubvDNe Iotvv06IsC5+6VYb63GBqRty+wEOjBNgz8AsHdljGxZjavQRBHa24+lYASMfLUqqoGPPM9wj mgiyOfS9p+VZumNzjk11mHrTe+Y7HujHVCjC74Ue+QHeyuIjk0bxDQSISh+w1jw9v/nyN8wh /tugEC4DO9LhyJPprZcduHQtlIFXEeZbmvapXqLjgMIz1WUB7hGcUMUkZZWqlkGyLhOdFpJL DkTMxqmazRL/jWLHSIRKWx1tmTn0GXLpXitP8ud8P67jY8mI2A04seuFNZLmtQLxP9qIIdrd f7WYPo19e+0b83BiC7rGuQINBFkuo0YBEADmrX6Ho18GYRk2GJZ3sy4g61oVuwAED+zGSsFt pYGGsOo/3rp9HRRcWR9qQ0osO14oB7swEhWnv4BMpab2WQ2BXM10W6B94yJsRMcZK4VJVSrP o/IEBrXe4roug+iG60wh4Cmi6Ojoi9OCarl+JVZCSclDy6cEv/MQRgwlNV+jvEqxVokdAwTY HrXpYpISnwCGcR6/eA+CHFvLQOkR+oHFqNuJsdx9e+OXP9MA5YLgi1atyHfkhGdDraLLTyGD aAqOaiOt7LdRL5xlaFejlHydkWEXbxSmIro7hHAFmyreslQ63V1vpLa6czylRqQ/us6iOidu rc+zsNAd7dbKVuOW/YEbiTrKwX7xjOa7lxYkOCBc+xa0Jj57FUoNQQdr678olgF5zqKvgZKa qiYSH6WR/wnKVmB8KQItyGZneq2f3Tqkc/S9Z45Olz7uYnN32uJAgn6awezkcK4iGSjQMzzg onP28LuLGoJVX92HWcYNBRW5T0Jqdro3i+XWLKWNsRSe8ifguH87CPfAtIsUJRUDvdR+XKF8 /TeXZfpdeU5tzOnRXPrST8L3Yw3Hpa//JtCmAXo02uer+fZm0e2+rB0cjn2P65fb5sb0jJNy mp1dwUEs+u0xHN3gHVBtPixCqnPVzFBygBtaPZF+6B6fhFLABNokIyii5NHYNS/NqEGTzwAR AQABiQIlBBgBCAAPBQJZLqNGAhsMBQkJZgGAAAoJEKxNqiqt3SqHOMQQAIojVofS2i1fAmML cnqhJVjB7nNZNTYGPGuqaSOk+P3nViihhkA+dhbntDRAipIzIoCOzBYQ69mY0LQAA1cAxC0T tqoDidp96OoGZfp1zWJu2pQrubfY8iR8+fxWPfQnPakVItp4Rexzg5oWsy070ysMhWemqRps DaozbJJU0dPCxIRCO28H20DLYF9LzK0BUQBJUcrGT7pLwyI2UXT8UdKBkyzezh53en+mnV2W a1U/syFstNBv5Y+XTemh882butmbBqGU4V47FK8BeBZdfrbqyz9fJMPQuV8esA3ucRP5gwDY S4z8QiofEfkPZ0V3ldGnpjJyCXdeYzMFgA/+cTmTO0lAA96+zB0Z/gcNwL/Nq1bX6P31mPsC PrBjlOUUCCBgek4D//oUKzoBF2YPQeMsqt7PKboHtTVeE0279vRifbIRF295X4nKVA4sWHpx V/HrSdpNQraWw7Sq4/iTbcqETNY48oWQBSeilGD+ZXKxtdUte8plVPDFoUxQZ6iQp3YqrEgi eNAwkMkiWb5zQ3YKd3JfsTOd1wd9Cc2jKaSE7fj3moAkSxQNZsgiQzMFThK7S/wcESpJfRxH hicIfJtLXgoQZOjH1zePjmdHxidhD65P8cfey++AYYSYWPyRrN5BW1Aam8FDOBpzU8pvNjWL NXdphurqQpFSRlvcRvXY Message-ID: Date: Sat, 23 Feb 2019 22:34:28 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------F1534899CDA50ABE1BEA522A" Content-Language: en-US Authentication-Results: smtp43.i.mail.ru; auth=pass smtp.auth=dubrovin@corp.mail.ru smtp.mailfrom=dubrovin@corp.mail.ru X-618D5548: 05BA0F6AFA56F0D4CFECA6684D9AEF712F75FAB5E32BBE4E58F036E8D5F096F0 X-77F55803: CF41D5CA8C6D3C0C7F9F52485CB584D75945EECDF71DA5B36C04DA8CBDE389CF8AC1FD7ED340D6969F2CE8D267E3E01208D917D6130B1AFB X-7FA49CB5: 0D63561A33F958A58D5E7056FF0EE46A45B44C49A58D2D93403C3DAF84A848BA8941B15DA834481FA18204E546F3947CEDCF5861DED71B2F389733CBF5DBD5E9C8A9BA7A39EFB7666BA297DBC24807EA117882F44604297287769387670735209ECD01F8117BC8BEA471835C12D1D977C4224003CC8364767815B9869FA544D8D32BA5DBAC0009BE9E8FC8737B5C224931C0090ACECF247D3AA81AA40904B5D9CF19DD082D7633A0E7DDDDC251EA7DABD81D268191BDAD3D78DA827A17800CE79C648FADE979CBA9CD04E86FAF290E2D40A5AABA2AD3711975ECD9A6C639B01B78DA827A17800CE797E5B4CC63BA20E2E8D63C8E5283DC2875ECD9A6C639B01B4E70A05D1297E1BBC6867C52282FAC85C89CB6F4BC741D5127F269C8F02392CD5571747095F342E88FB05168BE4CE3AF X-Mailru-Sender: C5364AD02485212F436E8F04DAC399FA05BA0F6AFA56F0D4CFECA6684D9AEF7132DC3239582C72120BAB88DF5F162B013DDE9B364B0DF2892C9BDF2E11C8A96B6C1AAAEF533A82E5AE208404248635DF X-Mras: OK Archived-At: Subject: Re: [dmarc-ietf] Should we encourage the use of SPF "soft include" for common platforms? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 23 Feb 2019 19:35:21 -0000 This is a multi-part message in MIME format. --------------F1534899CDA50ABE1BEA522A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit It's bad idea, because "?" does not grant SPF authentication. SPF is important even if message is DKIM signed and regardless of DMARC, because it authenticates envelope address. As an example, NDR/MDN  may not be generated to envelope address which is not SPF authenticated, we actually use this rule in practice to eliminate secondary spam. GSuite, O365 and large ESPs should not allow to use unvalidated/spoofed e-mail address. If somebody allows to spoof sender, there is also a good chance it DKIM signs spoofed message, because DKIM signature is applied by the same party. 23.02.2019 21:07, Kurt Andersen (b) пишет: > With the growth of huge platforms that emit mail from the same common > set of IPs (such as GSuite, O365, or large ESPs), regular SPF > "include" ends up granting a DMARC pass to a lot more potential > authors than most organizations would necessarily choose to grant.  > > Instead of using the standard "(+)include:" approach, if domain owners > used "?include:" as their mechanism, then that would prevent the SPF > result from granting a DMARC PASS result when traffic is coming from > one of these massively included platforms. It would essentially force > the DMARC result to be driven only by the DKIM evaluation. > > Thoughts? > > --Kurt Andersen > > (I'm copying the spfbis list too because there may be folks lurking > there who are not on the DMARC list) > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc -- Vladimir Dubrovin @Mail.Ru --------------F1534899CDA50ABE1BEA522A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

It's bad idea, because "?" does not grant SPF authentication. SPF is important even if message is DKIM signed and regardless of DMARC, because it authenticates envelope address. As an example, NDR/MDN  may not be generated to envelope address which is not SPF authenticated, we actually use this rule in practice to eliminate secondary spam.

GSuite, O365 and large ESPs should not allow to use unvalidated/spoofed e-mail address. If somebody allows to spoof sender, there is also a good chance it DKIM signs spoofed message, because DKIM signature is applied by the same party.

23.02.2019 21:07, Kurt Andersen (b) пишет:
With the growth of huge platforms that emit mail from the same common set of IPs (such as GSuite, O365, or large ESPs), regular SPF "include" ends up granting a DMARC pass to a lot more potential authors than most organizations would necessarily choose to grant. 

Instead of using the standard "(+)include:" approach, if domain owners used "?include:" as their mechanism, then that would prevent the SPF result from granting a DMARC PASS result when traffic is coming from one of these massively included platforms. It would essentially force the DMARC result to be driven only by the DKIM evaluation.

Thoughts?

--Kurt Andersen

(I'm copying the spfbis list too because there may be folks lurking there who are not on the DMARC list)

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



-- 
Vladimir Dubrovin
@Mail.Ru
--------------F1534899CDA50ABE1BEA522A-- From nobody Sat Feb 23 11:56:51 2019 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 76BAC130E5A for ; Sat, 23 Feb 2019 11:56:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oERH1-xOmEb7 for ; Sat, 23 Feb 2019 11:56:47 -0800 (PST) Received: from mail-io1-xd43.google.com (mail-io1-xd43.google.com [IPv6:2607:f8b0:4864:20::d43]) (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 DF307130F06 for ; Sat, 23 Feb 2019 11:56:46 -0800 (PST) Received: by mail-io1-xd43.google.com with SMTP id k21so4497279ior.13 for ; Sat, 23 Feb 2019 11:56:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=svyJFAs5h9cwIULcn1slUPLh8RDmacGJRbgw08tdPmg=; b=Cy2gOLlXpKjIZi9QT5tJB1A0tpvw5xIPQLU3qWe/FslPg/d5RI6hV036xMTRVmHX6i aX+AZAa5vUopR7V/7T8kS/Nbm3hE+aTcDW3IQIrF2aQa7nyEBl3+FCKbeeqLpdAfg1sF es7T+6Fn81Ktdq1NcRzPpOlWCRP+/9SLoS9Wk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=svyJFAs5h9cwIULcn1slUPLh8RDmacGJRbgw08tdPmg=; b=L427ErtYhRQ+WcYUtYU2XLutQ+nZ+MOoqysAkHrN/uqAhZu2WQQmJgI3d3M8UhA/pT ho0ei4qXit23Nwksr8FRwAqMQV9SeK3xw/ZwnADdLL3+kEv+NJHEC2joTWhYwdtXkxy2 IhsXgs7V5i9xrGRepetxcDhEgm7ii1kg4WjZOEgj/xYzM0ONKjgraZ6fYuQHWbk/8uYk 1GjpR6wfCmNXCQvu0NZur6c8WfBQL1jc2nVPyjlRJXT0yeVQ24WYpqgyU6TpWPYtEpKU goXf7ufF+PQqYxTgQXjdBNVkMDDvFBDwEU7qd/2+HuGK9EOq2n1GiHQT8U/3VSC5sDsO toiQ== X-Gm-Message-State: AHQUAuYKNz1DMToVwDwWnRJ8bomzUTh9EnuDdfRe6OhE7O8WDcWyXA5s Zk4fTDclGJcABiO7hxp+xazDa/Wf3UCUWrmwZ3pD7w== X-Google-Smtp-Source: AHgI3IbE89cyO328x7ZYxZ/g3V/cfEfkEXzkfDYRJaSUv2xWdKZRSAJw/WfWBTFqF+DAxZn8aZbgloV9uizfLIThGwQ= X-Received: by 2002:a5d:8190:: with SMTP id u16mr6178195ion.238.1550951805745; Sat, 23 Feb 2019 11:56:45 -0800 (PST) MIME-Version: 1.0 References: <5C719828.1000802@isdg.net> In-Reply-To: <5C719828.1000802@isdg.net> From: "Kurt Andersen (b)" Date: Sat, 23 Feb 2019 11:56:24 -0800 Message-ID: To: Hector Santos Cc: "dmarc@ietf.org" , spfbis@ietf.org Content-Type: multipart/alternative; boundary="0000000000007211e80582951b87" Archived-At: Subject: Re: [dmarc-ietf] Should we encourage the use of SPF "soft include" for common platforms? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 23 Feb 2019 19:56:51 -0000 --0000000000007211e80582951b87 Content-Type: text/plain; charset="UTF-8" On Sat, Feb 23, 2019 at 11:00 AM Hector Santos wrote: > On 2/23/2019 1:07 PM, Kurt Andersen (b) wrote: > > > > Instead of using the standard "(+)include:" approach, if domain owners > used > > "?include:" as their mechanism, then that would prevent the SPF result > from > > granting a DMARC PASS result when traffic is coming from one of these > > massively included platforms. It would essentially force the DMARC result > > to be driven only by the DKIM evaluation. > > > > Thoughts? > > > > it shouldn't matter it its huge or tiny, the protocol applies equally. > Quite so - however, some of the mechanisms and common usage patterns do differ depending on the scale and complexity of the sender asserting the record. > It helps to use an example. For example: gmail.com has: [redirect elided] > > v=spf1 include:_netblocks.google.com include:_netblocks2.google.com > include:_netblocks3.google.com ~all > > The SPF processor result SHOULD be based on each one. In this case, each > include results in a softfail (~all) when there is no match. > Note that terminal "all" mechanisms are ignored in the handling of the include evaluation (RFC7208 section 5.2). > it sounds like you are proposing an include prefix result should override > matching result, including the default/final result. No, I'm suggesting that the neutral mechanism prefix should be promoted as a "better way" to cite includes of large common sending platforms. "Better" than the default pass evaluation result. So for example, using one the includes for gmail.com: > > v=spf1 include:_netblocks.google.com include:_netblocks2.google.com > ?include:_netblocks3.google.com ~all > > where you want to override the results of _netblock3 with a neutral > result rather than use the matching result or final/default result of > the specific include. > Not an override - just a different result. > Unless the conditions were limited to when this can be applied, I can > see where this can become really complex because of higher recursion > potentials. You also have compatibility concerns as well. > I think that the biggest problem with nested includes (I'm intentionally avoiding the "recursion" term because it should not be recursive or circular) is the table in RFC7208 section 5.2 which asserts that a neutral result from check_host ends up being treated as a "not-match" condition. The way I read that is that if d1.example has ?include:d2.example which in turn has a ?include:d3.example, then a check_host match on the d3.example record would not end up percolating up to d1.example as a neutral final result. --Kurt --0000000000007211e80582951b87 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Feb 23, 2019 at 11:00 AM Hector S= antos <hsantos@isdg.net> wrot= e:
On 2/23/2019 1:07 PM, Kurt Andersen (b) wrote:
>
> Instead of using the standard "(+)include:" approach, if dom= ain owners used
> "?include:" as their mechanism, then that would prevent the = SPF result from
> granting a DMARC PASS result when traffic is coming from one of these<= br> > massively included platforms. It would essentially force the DMARC res= ult
> to be driven only by the DKIM evaluation.
>
> Thoughts?
>

it shouldn't matter it its huge or tiny, the protocol applies equal= ly.

Quite so - however, some of the mec= hanisms and common usage patterns do differ depending on the scale and comp= lexity of the sender asserting the record.
=C2=A0
It helps to use an example. For exa= mple:=C2=A0 gmail.com has: [redirect elided]

v=3Dspf1 include:_netblocks.google.com include:_netblocks2.google.= com
include:_netblocks3.google.com ~all

The SPF processor result SHOULD be based on each one.=C2=A0 In this case, e= ach include results in a softfail (~all) when there is no match.

Note that terminal "all" mechanisms are= ignored in the handling of the include evaluation (RFC7208 section 5.2).
=C2=A0
it s= ounds like you are proposing an include prefix result should override match= ing result, including the default/final result.=C2=A0
No, I'm suggesting that the neutral mechanism prefix should= be promoted as a "better way" to cite includes of large common s= ending platforms. "Better" than the default pass evaluation resul= t.

So= for example, using one the includes for gmail.com:

v=3Dspf1 include:_netblocks.google.com include:_netblocks2.google.= com
?include:_netblocks3.google.com ~all

where you want to override the results of _netblock3 with a neutral
result rather than use the matching result or final/default result of
the specific include.

Not an override -= just a different result.=C2=A0=C2=A0
=C2=A0
Unless the conditions were limited to wh= en this can be applied, I can
see where this can become really complex because of higher recursion
potentials.=C2=A0 =C2=A0You also have compatibility concerns as well.

I think that the biggest problem with nested= includes (I'm intentionally avoiding the "recursion" term be= cause it should not be recursive or circular) is the table in RFC7208 secti= on 5.2 which asserts that a neutral result from check_host ends up being tr= eated as a "not-match" condition. The way I read that is that if = d1.example has ?include:d2.example which in turn has a ?include:d3.example,= then a check_host match on the d3.example record would not end up percolat= ing up to d1.example as a neutral final result.

--= Kurt=C2=A0
--0000000000007211e80582951b87-- From nobody Sat Feb 23 13:03:48 2019 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 0FC7C130EE5; Sat, 23 Feb 2019 13:03:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHLDPTiGNZDt; Sat, 23 Feb 2019 13:03:44 -0800 (PST) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 EF3D0130ECD; Sat, 23 Feb 2019 13:03:43 -0800 (PST) Received: by mail-wr1-x42e.google.com with SMTP id t18so5925234wrx.2; Sat, 23 Feb 2019 13:03:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dlFAv+WYqIWxtzz0emGRF2Dkvqd8OQ+1UAabmXAQgX4=; b=SHhXjUde02ePlpxLuTfKKzQZbZxfSo9caaWBlORMxoiF6bFAvLtvRSQ9/R3VqbtL9e iobDSk9OYSdqjKWOxT9rQf0rgwx1fEXuIKViRGcLQ9B20kk3/5Si1zuOu57Up5uMbGYO +RSffq7kdpmVWj/fB4Khu5DwPg8Uxl0wSqI2BnnRHbH9TnXY+aRItunyTGuE9k0IlbMZ QeGmPq5oFXS4P61RE6mvY+7i/H0nR37eHLHqKKZKnb9suM24OzoGLDUF51ZP+wixqK1W jmpjUPbGB669k6vAmphrAp0oLLwb0znYIZfVAZgWMv7FiTlSQvphsGA76rwXiX0Ix9/i HjFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dlFAv+WYqIWxtzz0emGRF2Dkvqd8OQ+1UAabmXAQgX4=; b=qv2TBlRMIYOoEMqi94ThahOpkpITOQLx2XaGPDTzUdcUwylEMzrwui9W5zcb+TbjHs 1VaIp4nF4J+nEajuo1lrL87cxUyKQbkjgITcjepF+LE0vv5Mn5KPpaDhYRm2qQ1IVlkl oGBa1Mozpn5VIw/gldBTmSmjClWaLq1N/YIjx6+Di2rx4Ux7c29ire8NWRtypcc8dO93 cS8l3/jJOpDY3OEMkZcFNAxGepsiiGi9IhkrMM++5ypPJpqYDgZem429lNrtuw1/ldnk QSA6DSASvlJl+FUnBH+eKNQVw4c62S0AcVpQRiYQh4ZK1YUuR7vwCSxxCriJHoV4zzkj lw0Q== X-Gm-Message-State: AHQUAub4FJV2HMPYZSkRtnp8/gssW6X0ajF1GZu0U8sPP7xAS08R+YKQ xfJI08cXMCiJr8DNAvme0Ey/tauZ4OP5IBfU5ES4Cw== X-Google-Smtp-Source: AHgI3IaeJElp1GWkbOawZS/E89CpVnvs+snjnTOxmSSfztzqz7oIjS+RLkbXt4CQajA5dwp491aET67T5U8ZMORMVSs= X-Received: by 2002:adf:d845:: with SMTP id k5mr7490015wrl.145.1550955821984; Sat, 23 Feb 2019 13:03:41 -0800 (PST) MIME-Version: 1.0 References: <5C719828.1000802@isdg.net> In-Reply-To: From: Dotzero Date: Sat, 23 Feb 2019 16:03:32 -0500 Message-ID: To: "Kurt Andersen (b)" Cc: Hector Santos , spfbis@ietf.org, "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d4efcd0582960a90" Archived-At: Subject: Re: [dmarc-ietf] Should we encourage the use of SPF "soft include" for common platforms? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 23 Feb 2019 21:03:47 -0000 --000000000000d4efcd0582960a90 Content-Type: text/plain; charset="UTF-8" Just provide a DKIM only mechanism/option. Michael Hammer On Sat, Feb 23, 2019 at 2:56 PM Kurt Andersen (b) wrote: > On Sat, Feb 23, 2019 at 11:00 AM Hector Santos wrote: > >> On 2/23/2019 1:07 PM, Kurt Andersen (b) wrote: >> > >> > Instead of using the standard "(+)include:" approach, if domain owners >> used >> > "?include:" as their mechanism, then that would prevent the SPF result >> from >> > granting a DMARC PASS result when traffic is coming from one of these >> > massively included platforms. It would essentially force the DMARC >> result >> > to be driven only by the DKIM evaluation. >> > >> > Thoughts? >> > >> >> it shouldn't matter it its huge or tiny, the protocol applies equally. >> > > Quite so - however, some of the mechanisms and common usage patterns do > differ depending on the scale and complexity of the sender asserting the > record. > > >> It helps to use an example. For example: gmail.com has: [redirect >> elided] >> >> v=spf1 include:_netblocks.google.com include:_netblocks2.google.com >> include:_netblocks3.google.com ~all >> >> The SPF processor result SHOULD be based on each one. In this case, each >> include results in a softfail (~all) when there is no match. >> > > Note that terminal "all" mechanisms are ignored in the handling of the > include evaluation (RFC7208 section 5.2). > > >> it sounds like you are proposing an include prefix result should override >> matching result, including the default/final result. > > > No, I'm suggesting that the neutral mechanism prefix should be promoted as > a "better way" to cite includes of large common sending platforms. "Better" > than the default pass evaluation result. > > So for example, using one the includes for gmail.com: >> >> v=spf1 include:_netblocks.google.com include:_netblocks2.google.com >> ?include:_netblocks3.google.com ~all >> >> where you want to override the results of _netblock3 with a neutral >> result rather than use the matching result or final/default result of >> the specific include. >> > > Not an override - just a different result. > > >> Unless the conditions were limited to when this can be applied, I can >> see where this can become really complex because of higher recursion >> potentials. You also have compatibility concerns as well. >> > > I think that the biggest problem with nested includes (I'm intentionally > avoiding the "recursion" term because it should not be recursive or > circular) is the table in RFC7208 section 5.2 which asserts that a neutral > result from check_host ends up being treated as a "not-match" condition. > The way I read that is that if d1.example has ?include:d2.example which in > turn has a ?include:d3.example, then a check_host match on the d3.example > record would not end up percolating up to d1.example as a neutral final > result. > > --Kurt > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --000000000000d4efcd0582960a90 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just provide a DKIM only mechanism/option.=C2=A0

<= /div>
Michael Hammer

On Sat, Feb 23, 2019 at 2:56 PM Kurt Andersen= (b) <kboth@drkurt.com> wrote= :
On Sat, Feb 23, 2019 at 11:00 AM Hector Santos <hsantos@isdg.net> = wrote:
On 2/23/2019 1:07 PM, Kurt Andersen (b) wrote:
> > Instead of using the standard "(+)include:" approach, if dom= ain owners used
> "?include:" as their mechanism, then that would prevent the = SPF result from
> granting a DMARC PASS result when traffic is coming from one of these<= br> > massively included platforms. It would essentially force the DMARC res= ult
> to be driven only by the DKIM evaluation.
>
> Thoughts?
>

it shouldn't matter it its huge or tiny, the protocol applies equal= ly.

Quite so - however, some of the mec= hanisms and common usage patterns do differ depending on the scale and comp= lexity of the sender asserting the record.
=C2=A0
It helps to use an example. For exa= mple:=C2=A0 gmail.com has: [redirect elided]

v=3Dspf1 include:_netblocks.google.com include:_netblocks2.google.= com
include:_netblocks3.google.com ~all

The SPF processor result SHOULD be based on each one.=C2=A0 In this case, e= ach include results in a softfail (~all) when there is no match.

Note that terminal "all" mechanisms are= ignored in the handling of the include evaluation (RFC7208 section 5.2).
=C2=A0
it s= ounds like you are proposing an include prefix result should override match= ing result, including the default/final result.=C2=A0
No, I'm suggesting that the neutral mechanism prefix should= be promoted as a "better way" to cite includes of large common s= ending platforms. "Better" than the default pass evaluation resul= t.

So= for example, using one the includes for gmail.com:

v=3Dspf1 include:_netblocks.google.com include:_netblocks2.google.= com
?include:_netblocks3.google.com ~all

where you want to override the results of _netblock3 with a neutral
result rather than use the matching result or final/default result of
the specific include.

Not an override -= just a different result.=C2=A0=C2=A0
=C2=A0
Unless the conditions were limited to wh= en this can be applied, I can
see where this can become really complex because of higher recursion
potentials.=C2=A0 =C2=A0You also have compatibility concerns as well.

I think that the biggest problem with nested= includes (I'm intentionally avoiding the "recursion" term be= cause it should not be recursive or circular) is the table in RFC7208 secti= on 5.2 which asserts that a neutral result from check_host ends up being tr= eated as a "not-match" condition. The way I read that is that if = d1.example has ?include:d2.example which in turn has a ?include:d3.example,= then a check_host match on the d3.example record would not end up percolat= ing up to d1.example as a neutral final result.

--= Kurt=C2=A0
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--000000000000d4efcd0582960a90-- From nobody Sun Feb 24 11:19:51 2019 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 4351112D4F3 for ; Sun, 24 Feb 2019 11:19:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=IMUSUwJ1; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=vvu11Q80 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 i4nXibFALwcI for ; Sun, 24 Feb 2019 11:19:41 -0800 (PST) Received: from mail.winserver.com (news.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id E63F212D7F8 for ; Sun, 24 Feb 2019 11:19:40 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2342; t=1551035973; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=qXkYlxj9J6UczRvCIVaxsvRIi1Y=; b=IMUSUwJ1USnaeScg6wj6ytoWnHrhoI9LParvH79BVZWDpVbpR2Ww2DHX0+FWqd RCv+w+zRURlOfrzwWIRn1mIe86ebec+ziFBceFDBWzUb6cbFpndzmNYAbCUh152U 808dX4p9ztuNehspnTUXmpAwx0Bs0I+Wm4s920o0ioQdU= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Sun, 24 Feb 2019 14:19:33 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 1442883888.1.3908; Sun, 24 Feb 2019 14:19:32 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2342; t=1551035667; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=KoPN+XD 74YhDIuJWe994JtWPb8GcO1q39Wwz4kEfZIY=; b=vvu11Q80hllrawce8ToFDR1 gNd//R5w4Mcdp7008S69BICSA/AuPReqYlW9CUoLC73svQJkCJFn2DMnNsM+ApNs 7MitW4XWRqStU7IRkIlTvHdIlvLr8xnzJZgtMvLQwANbvnCWqfGXxoBDWkRekVpz wFexmxiMBFZxA5PKOG28= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Sun, 24 Feb 2019 14:14:27 -0500 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 1990777518.9.360968; Sun, 24 Feb 2019 14:14:26 -0500 Message-ID: <5C72EE3E.2060907@isdg.net> Date: Sun, 24 Feb 2019 14:19:26 -0500 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: "Kurt Andersen (b)" CC: spfbis@ietf.org, "dmarc@ietf.org" References: <5C719828.1000802@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Should we encourage the use of SPF "soft include" for common platforms? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2019 19:19:44 -0000 On 2/23/2019 2:56 PM, Kurt Andersen (b) wrote: > On Sat, Feb 23, 2019 at 11:00 AM Hector Santos wrote: > >> Unless the conditions were limited to when this can be applied, I can >> see where this can become really complex because of higher recursion >> potentials. You also have compatibility concerns as well. >> > > I think that the biggest problem with nested includes (I'm intentionally > avoiding the "recursion" term because it should not be recursive or > circular) is the table in RFC7208 section 5.2 which asserts that a neutral > result from check_host ends up being treated as a "not-match" condition. > The way I read that is that if d1.example has ?include:d2.example which in > turn has a ?include:d3.example, then a check_host match on the d3.example > record would not end up percolating up to d1.example as a neutral final > result. +1 One question is, can each nested domain SPF record stand on its own, independent of its administrative domain's INCLUDE assertion to relax a potential hard pass/fail result to a relaxed neutral/softfail? In other words, if d1 includes d2 which includes d3, it is possible to see d2 or d3 directly via a direct return path domain reference? I think it continues to be an organizational issue, in particular when SPF network gets larger it is easier to see the complexities especially when augmenting SPF with additional protocols, i.e. DMARC. It is also local policy with SPF trust considerations. For example, in our SPF parser, it has the following local policy options: ; SPF can return low trust results. A pass means the sender has ; a valid SPF record and is accepted. Softfail and Neutral means ; no match is found but rejection is not automatic. Setting a ; true accept can provide a loop for potential spoofers who have ; SPF records and think they will allow them in. The options ; below allow you to control this. Accept-SPF-Pass True ; if false, continue testing Accept-SPF-SoftFail False ; if false, continue testing Accept-SPF-Neutral False ; if false, continue testing In our case, continue testing means to "pass the buck" to the next real-time AVS filter to see what it can find. Out of the box, it is a pass for Accept-SPF-PASS results which means SPF compliant "bad guys" with matching IPs get a pass. -- HLS From nobody Mon Feb 25 02:24:42 2019 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 9E7F812F1A5; Mon, 25 Feb 2019 02:24:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aTuF3HonTgAN; Mon, 25 Feb 2019 02:24:33 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 147F412D4E6; Mon, 25 Feb 2019 02:24:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=gamma; t=1551090271; bh=ovwrj9n6tIIPY5973h1kFH33/r0P1WIhw88ADXw5Tig=; l=1174; h=To:Cc:References:From:Date:In-Reply-To; b=CSws7D93vD5h0KsbnwZMWHs4jsV2N+MqqamZHqzDhFD7ix0wfpGRzt2BWCfmsyIPj Vzezbv9ILEdiFsFZ+1Xa6Vt+lZKzQs5QERgdu5zn4z0dv1K/TV/wU+FftJnxAHVf/m yRWNCkRjUvFVaMCQCSNHhUtTjMjMXqY+oO/34Cbzb0d1Lua2fHVCa0oUF+ohM Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Mon, 25 Feb 2019 11:24:30 +0100 id 00000000005DC085.000000005C73C25E.0000546F To: "Kurt Andersen (b)" , "dmarc@ietf.org" Cc: spfbis@ietf.org References: From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: <789e8c23-1826-4447-f072-45ce4bfec2fe@tana.it> Date: Mon, 25 Feb 2019 11:24:30 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] [spfbis] Should we encourage the use of SPF "soft include" for common platforms? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2019 10:24:35 -0000 On Sat 23/Feb/2019 19:07:31 +0100 Kurt Andersen (b) wrote: > With the growth of huge platforms that emit mail from the same common set of > IPs (such as GSuite, O365, or large ESPs), regular SPF "include" ends up > granting a DMARC pass to a lot more potential authors than most organizations > would necessarily choose to grant. Hopefully, large organizations have a policy which enables them to drop non-compliant users contracts. The admin attitude. Alternatively, they could expunge offending IP addresses from their SPF records. The whitelist attitude. The rest is reputation. > Instead of using the standard "(+)include:" approach, if domain owners used > "?include:" as their mechanism, then that would prevent the SPF result from > granting a DMARC PASS result when traffic is coming from one of these massively > included platforms. It would essentially force the DMARC result to be driven > only by the DKIM evaluation. -1. If DKIM were flawless, maybe... Authentication of email messages forwarded through various providers is already DKIM-only driven, but that doesn't seem to improve reliability, does it? Best Ale -- From nobody Wed Feb 27 05:56:49 2019 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 19CBC130ED9 for ; Wed, 27 Feb 2019 05:56:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 M2JhjiZDlGZg for ; Wed, 27 Feb 2019 05:56:44 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 2C69E130FCB for ; Wed, 27 Feb 2019 05:56:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1551275803; d=isode.com; s=june2016; i=@isode.com; bh=86z56JD9/ybNfWF0q0B6zjey5y15Ew8KFXcbKzOIBSU=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=iw9Ktf/2PpieYHW07H3eUBnvxj61+9T+oMKPNOlojGMemY3YU/TL0CxpqA9jtfTCGy+JN1 G0ycANoZ/6BPHTKRIlji7aAXoMBqkBODbVAmekj9mFWwJmtknmP7y6JoahYftuIfjInQbB qYh/Ko0ojjlZ6BP2tRoHUo3Ko6q2Nos=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 27 Feb 2019 13:56:42 +0000 To: dmarc@ietf.org From: Alexey Melnikov Message-ID: Date: Wed, 27 Feb 2019 13:56:25 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-transfer-encoding: quoted-printable Archived-At: Subject: [dmarc-ietf] AD review draft-ietf-dmarc-eaiauth-02 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 27 Feb 2019 13:56:46 -0000 Hi all, This document is in a good shape, but I have a couple of minor things=20 that I would like to see fixed before initiating IETF LC: 4.=C2=A0 SPF and internationalized mail =C2=A0=C2=A0 SPF macros %s and %l expand the local-part of the sender's mai= lbox. =C2=A0=C2=A0 If the local-part contains non-ASCII characters, terms that in= clude =C2=A0=C2=A0 %s or %l do not match anything.=C2=A0 (Note that unlike U-labe= ls, there is =C2=A0=C2=A0 no way to rewrite non-ASCII local parts into ASCII.) The SPF RFC is using %{s} and %{p}, so I appreciate if the text above is=20 updated appropriately. 5.=C2=A0 DKIM and internationalized mail =C2=A0=C2=A0 dkim-safe-char=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D= =C2=A0 %x21-3A / %x3C / %x3E-7E / %x80-FF =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ; '!' - ':',= '<', '>' - '~', non-ASCII Addition of UTF-8 is not precise enough and will encourage buggy=20 implementations. So please replace the last alternative "%x80-FF" with: =C2=A0UTF8-2 / UTF8-3 / UTF8-4 UTF8-2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D UTF8-3=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D UTF8-4=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D So RFC 3629 would be another normative reference. Thank you, Alexey From nobody Wed Feb 27 06:25:27 2019 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 0AEDC131038 for ; Wed, 27 Feb 2019 06:25:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=z9e2FYdG; dkim=pass (2048-bit key) header.d=kitterman.com header.b=E7zpmwQE 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 JBN809VCZXbd for ; Wed, 27 Feb 2019 06:25:17 -0800 (PST) Received: from softlayer.kitterman.com (softlayer.kitterman.com [IPv6:2607:f0d0:3a01:a3::9]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8504A131029 for ; Wed, 27 Feb 2019 06:25:16 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812e; t=1551277511; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=aPbsSDi+YLs6SPdD4lcCg7LASgVmM5kX5EkRCeLhxeo=; b=z9e2FYdGWGdr0YCgx9yjgMxSBPnv3HXc9Go4iNlmDBuZWAMqZBTpSQkq ea3X1m8eaygt5gRCnnFqvnk5pEhcBQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812r; t=1551277511; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=aPbsSDi+YLs6SPdD4lcCg7LASgVmM5kX5EkRCeLhxeo=; b=E7zpmwQEo/N6PL7+mdHadccaIS/7L1QDKNvUN7ClTtr/itHk728V83YP fNj3F1NpTMzUvhY6YG1xM6kQectuchjhR73JOC3SofNC19BC7TmV/yhUTg PtKL96ieFuyAbVZsgkb/F8A1OsAI05BJAlBhda/upHmHgFo6JWXo4r2jyM eMtqD6U6YsnLFoOfeJ7GyjGz9V7w7P6EGK3Cgdsn7qcZ3k6dng3Snl4uZw sVfaU7UCwVnQ3JWVwtawudP5ag3xOIgXSEcozVegKjlP63YNGCFGJqrGTw X5X0IN4CveBCM/RtFts8smjY3c12VPxG2AXuQcY2xfijMTUOtflEGQ== Received: from [10.249.149.26] (mobile-166-170-35-113.mycingular.net [166.170.35.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by softlayer.kitterman.com (Postfix) with ESMTPSA id 563802D4016A; Wed, 27 Feb 2019 08:25:11 -0600 (CST) Date: Wed, 27 Feb 2019 14:25:09 +0000 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dmarc@ietf.org From: Scott Kitterman Message-ID: <43798E02-A35B-413E-9D10-1A7E1360C361@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] AD review draft-ietf-dmarc-eaiauth-02 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 27 Feb 2019 14:25:26 -0000 On February 27, 2019 1:56:25 PM UTC, Alexey Melnikov wrote: >Hi all, > >This document is in a good shape, but I have a couple of minor things=20 >that I would like to see fixed before initiating IETF LC: > >4=2E=C2=A0 SPF and internationalized mail > > =C2=A0=C2=A0 SPF macros %s and %l expand the local-part of the sender's = mailbox=2E > =C2=A0=C2=A0 If the local-part contains non-ASCII characters, terms that= include >=C2=A0=C2=A0 %s or %l do not match anything=2E=C2=A0 (Note that unlike U-= labels, there >is > =C2=A0=C2=A0 no way to rewrite non-ASCII local parts into ASCII=2E) > >The SPF RFC is using %{s} and %{p}, so I appreciate if the text above >is=20 >updated appropriately=2E A related point =2E=2E=2E The draft currently says it updates RFC 7208, but is that right? It only = explicitly documents what's already defined there=2E Should that be remove= d? Scott K From nobody Wed Feb 27 18:35:19 2019 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 AA8EC130ED7 for ; Wed, 27 Feb 2019 18:35:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com 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 SAlCp9n6xDgc for ; Wed, 27 Feb 2019 18:35:16 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4F5A130ECF for ; Wed, 27 Feb 2019 18:35:15 -0800 (PST) Received: (qmail 79858 invoked from network); 28 Feb 2019 02:35:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=137ee.5c7748e2.k1902; bh=JJ41XPf7WooYxbhgnb0l/WWcgRa66E8Q7w7Ck+2SXR8=; b=GSul4I/H8pKWktSvUqZUi5nvuVV9yT2pOn6+SR+EsmmXNaSaKmNKmlrbD39kAF+nrclC7sTm9SLLVuneh+Iwa98NHQ9rjgqDs/pTt2VKXubegCKhtUuf3PwNU4/ByLSUQhp39s1D/GyRNDG0KMldOllWQ05YqGIXelx3JQoM7iCEBrcr+LS51y/w8XjIP5iTseQ1GPzd7LhHH8zz37keDI7Rec+wtCqUkpOmwYocsSJY66D7wgCSfjykwtMhC2wp Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 28 Feb 2019 02:35:14 -0000 Date: 27 Feb 2019 21:35:14 -0500 Message-ID: From: "John R. Levine" To: "Scott Kitterman" Cc: dmarc@ietf.org In-Reply-To: <43798E02-A35B-413E-9D10-1A7E1360C361@kitterman.com> References: <43798E02-A35B-413E-9D10-1A7E1360C361@kitterman.com> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] AD review draft-ietf-dmarc-eaiauth-02 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 02:35:18 -0000 > A related point ... > > The draft currently says it updates RFC 7208, but is that right? It only explicitly documents what's already defined there. Should that be removed? It does say that matching a UTF-8 local part fails, which is new. If you write code the way I write code, a current implementation might just stuff the UTF-8 into a DNS lookup. The DNS is mostly 8-bit clean, after all, so it hypothetically might find something. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Wed Feb 27 18:49:33 2019 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 712D5130F01; Wed, 27 Feb 2019 18:49:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dmarc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dmarc@ietf.org Message-ID: <155132217243.14057.5307669335000262933@ietfa.amsl.com> Date: Wed, 27 Feb 2019 18:49:32 -0800 Archived-At: Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-eaiauth-03.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 02:49:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain-based Message Authentication, Reporting & Conformance WG of the IETF. Title : E-mail Authentication for Internationalized Mail Author : John Levine Filename : draft-ietf-dmarc-eaiauth-03.txt Pages : 7 Date : 2019-02-27 Abstract: SPF (RFC7208), DKIM (RFC6376), and DMARC (RFC7489) enable a domain owner to publish e-mail authentication and policy information in the DNS. In internationalized e-mail, domain names can occur both as U-labels and A-labels. The Authentication-Results header reports the result of authentication checks made with SPF, DKIM, DMARC, and other schemes. This specification updates the SPF, DKIM, and DMARC specifications to clarify which form of internationalized domain names to use in those specifications, and when creating Authentication-Results headers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-eaiauth/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmarc-eaiauth-03 https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-eaiauth-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-eaiauth-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 28 06:38:29 2019 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 9153C130F43; Thu, 28 Feb 2019 06:38:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk CC: alexey.melnikov@isode.com, dmarc@ietf.org, kurta@drkurt.com, draft-ietf-dmarc-eaiauth@ietf.org, dmarc-chairs@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Message-ID: <155136469958.28684.8810231208348252093.idtracker@ietfa.amsl.com> Date: Thu, 28 Feb 2019 06:38:19 -0800 Archived-At: Subject: [dmarc-ietf] Last Call: (E-mail Authentication for Internationalized Mail) to Proposed Standard X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 14:38:27 -0000 The IESG has received a request from the Domain-based Message Authentication, Reporting & Conformance WG (dmarc) to consider the following document: - 'E-mail Authentication for Internationalized Mail' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-03-14. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract SPF (RFC7208), DKIM (RFC6376), and DMARC (RFC7489) enable a domain owner to publish e-mail authentication and policy information in the DNS. In internationalized e-mail, domain names can occur both as U-labels and A-labels. The Authentication-Results header reports the result of authentication checks made with SPF, DKIM, DMARC, and other schemes. This specification updates the SPF, DKIM, and DMARC specifications to clarify which form of internationalized domain names to use in those specifications, and when creating Authentication-Results headers. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dmarc-eaiauth/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dmarc-eaiauth/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) (Informational - Independent Submission Editor stream) From nobody Thu Feb 28 08:25:54 2019 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 D4B1C130EDB for ; Thu, 28 Feb 2019 08:25:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKsKDKCCBT0j for ; Thu, 28 Feb 2019 08:25:47 -0800 (PST) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 9E732130ED8 for ; Thu, 28 Feb 2019 08:25:47 -0800 (PST) Received: by mail-io1-xd31.google.com with SMTP id x3so17050266ior.6 for ; Thu, 28 Feb 2019 08:25:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dwtgS5S1KTSsQWPl/S6ovyr9KlKV74W3Zd+9u7OABN4=; b=S8RUbjj0JaOyVYHtTCt7j+PVaF4ocNa11m/JdOfSN8+p5jGNs8Tp3G6fmuzpb0+CXs dBubiJlugT2ml3v07FzpOhwICyiyH6UlVLzV0m1AyCvHppAJ6N00ckWENZf+vfAGhTB0 HQ8EzIQImlRK0ELnJTJyzsK5OUnIi/JYh+YaY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dwtgS5S1KTSsQWPl/S6ovyr9KlKV74W3Zd+9u7OABN4=; b=f5m74tP+zQ29/gjUbVmMJdWUJfBCnXJ9/DwSxUzyPmnG2szBKekMg5agMpq1dnRa8l B0E7m8SDGBDf058LzYQB2UvsH/12F/YrnVqpU+6SHAqPsGkS98p+k9JhPNvsuYO1lnm8 NCioK6gfcHap0kij5awmhnqP4ANeOsBcbgLfVT1iIo+uVdUI7is1POF7b2Q26wxRohOf 9Ez70oXwJy7j00mHBx2HJ6ZCCG5pg2StcBHF1rDlcHfrVgLVPrdUVcZp6fKAH0d3PheN 0dkEERKSz20SSmq+TP3WzkvTUeZR7/K6BA321EAfuJKEw8x9+MKefnV83m6Z4FoSJpUu fqhg== X-Gm-Message-State: APjAAAWiZE7U/nZ2vsEgQ1pW2ZRbQU/W6AlppogvMb/VecI/vrcBpXn0 /GekE2KiwsAjSqXikW0Wfp5vf6qF+5X9KZ6P6qJGxxhG X-Google-Smtp-Source: APXvYqy0zpKF8b+5a342o3jrlZ6oby7tpsvVNX8JSzwq2frTnaQT+hpW7YNgIxRWlu8iTepZ40WRnTk6bsYZ+L43m8Q= X-Received: by 2002:a6b:d304:: with SMTP id s4mr75620iob.228.1551371146243; Thu, 28 Feb 2019 08:25:46 -0800 (PST) MIME-Version: 1.0 References: <43798E02-A35B-413E-9D10-1A7E1360C361@kitterman.com> In-Reply-To: From: "Kurt Andersen (b)" Date: Thu, 28 Feb 2019 08:25:28 -0800 Message-ID: To: "John R. Levine" Cc: Scott Kitterman , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="00000000000016491f0582f6bee3" Archived-At: Subject: Re: [dmarc-ietf] AD review draft-ietf-dmarc-eaiauth-02 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 16:25:51 -0000 --00000000000016491f0582f6bee3 Content-Type: text/plain; charset="UTF-8" On Wed, Feb 27, 2019 at 6:35 PM John R. Levine wrote: > > A related point ... > > > > The draft currently says it updates RFC 7208, but is that right? It > only explicitly documents what's already defined there. Should that be > removed? > > It does say that matching a UTF-8 local part fails, which is new. > > If you write code the way I write code, a current implementation might > just stuff the UTF-8 into a DNS lookup. The DNS is mostly 8-bit clean, > after all, so it hypothetically might find something. > I haven't seen "might" listed in 2119 so it seems like a sketchy construct for interoperability :-D --Kurt --00000000000016491f0582f6bee3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Feb 27, 2019 at 6:35 PM John R. L= evine <johnl@iecc.com> wrote:
> A related point ...
>
> The draft currently says it updates RFC 7208, but is that right?=C2=A0= It only explicitly documents what's already defined there.=C2=A0 Shoul= d that be removed?

It does say that matching a UTF-8 local part fails, which is new.

If you write code the way I write code, a current implementation might
just stuff the UTF-8 into a DNS lookup.=C2=A0 The DNS is mostly 8-bit clean= ,
after all, so it hypothetically might find something.
=
I haven't seen "might" listed in 2119 so it se= ems like a sketchy construct for interoperability :-D

<= div>--Kurt=C2=A0
--00000000000016491f0582f6bee3--