From nobody Thu Mar 10 14:18:15 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0B2712DE26 for ; Thu, 10 Mar 2016 14:18:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.603 X-Spam-Level: X-Spam-Status: No, score=-0.603 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=crash.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvtRZe6ax9Za for ; Thu, 10 Mar 2016 14:18:13 -0800 (PST) Received: from segv.crash.com (segv.crash.com [IPv6:2001:470:1:1e9::4415]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDEFF12DE11 for ; Thu, 10 Mar 2016 14:18:09 -0800 (PST) Received: from abort.crash.com (70-36-157-26.dsl.static.fusionbroadband.com [70.36.157.26]) (authenticated bits=0) by segv.crash.com (8.14.5/8.14.5/cci-colo-1.6) with ESMTP id u2AMHwQo006117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 10 Mar 2016 14:18:03 -0800 (PST) (envelope-from smj@crash.com) X-DKIM: OpenDKIM Filter v2.4.3 segv.crash.com u2AMHwQo006117 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=201506-2k; t=1457648283; bh=yOlPf58/0r6BMrLvV+QZKwiydn+HXFWs2t2GBfdlQvA=; h=To:From:Subject:Message-ID:Date:MIME-Version:Content-Type: Content-Transfer-Encoding; b=z7eLMBdnacXWLkw9wUpDu95EQ6zurNOrom9i/FN/V4mlCXQBLdbP7c1Iz7wq/rz3A 4Nft1CElK+qsXXOjgvUDFn7H6IUqDMbjc4PqQ6Dq5KNgWaSM6vaVV1IspizkTJd/bx eZISJAP6A2enU8ouIUqGfv1KXToZrOkUjEhMfCFUFZQEhbAQdUH5MV9KvGYXuZWbhJ SHrIC1AqGm9V8ncyT7nW2bOu7oAoyKHkSu6j2xpwV3oguFjr6N109bn4lKwkB6x1UE vrSx6c9K7T1uJ3P1jG8jAleuRJmkpsI09MXdF+q3E9SCPDliglnTI+KpyOenFo5uyK sdCQWv55hSnfw== X-Authentication-Warning: segv.crash.com: Host 70-36-157-26.dsl.static.fusionbroadband.com [70.36.157.26] claimed to be abort.crash.com To: dmarc@ietf.org From: Steven M Jones X-Enigmail-Draft-Status: N1110 Organization: Crash Computing Message-ID: <56E1F29B.504@crash.com> Date: Thu, 10 Mar 2016 14:18:03 -0800 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (segv.crash.com [72.52.75.15]); Thu, 10 Mar 2016 14:18:03 -0800 (PST) Archived-At: Subject: [dmarc-ietf] Two ARC implementations tested at interoperability event X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 22:18:15 -0000 On February 19th AOL and Google successfully tested their implementations of ARC at the interoperability event held on February 19th. More details here: https://dmarc.org/2016/03/two-arc-implementations-tested-at-interoperability-event/ Many thanks to LinkedIn for hosting the event. I'm looking forward to more implementations and more testing by mid-year. --Steve. Steve Jones DMARC.org From nobody Mon Mar 14 23:28:32 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC9812D700; Mon, 14 Mar 2016 23:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YbT4ZkhE2qb; Mon, 14 Mar 2016 23:28:28 -0700 (PDT) Received: from lepidum.jp (lepidum.jp [60.32.83.213]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F7A312D7B9; Mon, 14 Mar 2016 23:28:25 -0700 (PDT) Received: from okadakoujinombp.local.lepidum.net (lepidum.net [60.32.83.208]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: okd@lepidum.co.jp) by mail06.server.lepidum.net (Postfix) with ESMTPSA id 9DA852F806A92; Tue, 15 Mar 2016 15:28:23 +0900 (JST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Kouji Okada Date: Tue, 15 Mar 2016 15:28:23 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <58630132-33D2-491B-9EC0-A98328F2BCD4@lepidum.co.jp> References: <20160314043043.31115.73657.idtracker@ietfa.amsl.com> To: dmarc@ietf.org X-Mailer: Apple Mail (2.3112) X-Clamav-Info: Checked(Clean) X-LepidumMailFilterAgent-by: mailfromd (5.1) X-LepidumMailFilterAgent-Info: Original (mailfrom:Inbound) Archived-At: Cc: Kouji Okada , draft-akagiri-dmarc-virtual-verification@ietf.org Subject: [dmarc-ietf] Fwd: I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 06:28:31 -0000 We have submitted a draft about DMARC default verification for domains not publishing DMARC records. Any comments will be appreciated. Best wishes Kouji Okada > =E8=BB=A2=E9=80=81=E3=81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=83=83=E3=82=BB= =E3=83=BC=E3=82=B8=EF=BC=9A >=20 > =E5=B7=AE=E5=87=BA=E4=BA=BA: internet-drafts@ietf.org > =E4=BB=B6=E5=90=8D: I-D Action: = draft-akagiri-dmarc-virtual-verification-00.txt > =E6=97=A5=E4=BB=98: 2016=E5=B9=B43=E6=9C=8814=E6=97=A5 13:30:43 JST > =E5=AE=9B=E5=85=88: > =E8=BF=94=E4=BF=A1=E5=85=88: internet-drafts@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : DMARC verification without record definitions > Authors : Takehito Akagiri > Genki Yasutaka > Masaki Kase > Kouji Okada > Kaoru Maeda > Filename : = draft-akagiri-dmarc-virtual-verification-00.txt > Pages : 7 > Date : 2016-03-13 >=20 > Abstract: > DMARC is a powerful architecture to defend mail end users from > malicious mail activities, but its deployment is still under = process. > To encourage the installations of DMARC, we propose an incremental > deployment procedure in this document. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-akagiri-dmarc-virtual-verification/= >=20 > There's also a htmlized version available at: > = https://tools.ietf.org/html/draft-akagiri-dmarc-virtual-verification-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Tue Mar 15 05:33:01 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC8D712D9E8 for ; Tue, 15 Mar 2016 05:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wordtothewise.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 Rxcs7MqgCIZ7 for ; Tue, 15 Mar 2016 05:32:58 -0700 (PDT) Received: from mail.wordtothewise.com (mail.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id 5223E12D9E7 for ; Tue, 15 Mar 2016 05:32:58 -0700 (PDT) Received: from satsuke.wordtothewise.com (204.11.227.194.static.etheric.net [204.11.227.194]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 0ECAE8055D for ; Tue, 15 Mar 2016 05:32:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1458045177; bh=2F1zCQCPEw25ktKP1RO2TFhVma8Ty6f12k6KPUImUP8=; h=Subject:From:In-Reply-To:Date:References:To:From; b=KF37Ml9htI3M+0zO6RjDKPRkdNRvk8Mj4ySHQ1Fx89Bl1558WZJXrtzvj0zaNKiEF svhdOuUMCHetS28ni/PsyFu1G04VlBd1H0C6gk395Z43/OIs+CooepWoWfdczj0yeR YwEzhxpIaFux85+ABab2KWX3loytBtaQdZcBXMvc= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Steve Atkins In-Reply-To: <58630132-33D2-491B-9EC0-A98328F2BCD4@lepidum.co.jp> Date: Tue, 15 Mar 2016 05:32:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <84979E86-150D-487C-962C-72E945293ACE@wordtothewise.com> References: <20160314043043.31115.73657.idtracker@ietfa.amsl.com> <58630132-33D2-491B-9EC0-A98328F2BCD4@lepidum.co.jp> To: dmarc X-Mailer: Apple Mail (2.3112) Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 12:33:00 -0000 > On Mar 14, 2016, at 11:28 PM, Kouji Okada wrote: >=20 > We have submitted a draft about DMARC default verification > for domains not publishing DMARC records. > Any comments will be appreciated. Summary: If a domain does not opt-in to using DMARC, treat the domain as though it had opted-in to using DMARC with "p=3Dnone adkim=3Ds = aspf=3Ds". Once that's deployed, change it to "p=3Dreject adkim=3Ds aspf=3Ds". = Possibly do "p=3Dquarantine" between the two. There are multiple problems with this suggestion. Firstly, DMARC is an opt-in protocol for good reason. It's a lot of work = to clean up all the mail streams for a domain such that all email is = authenticated. In many cases it is impossible to do so. Those domains that have not = done so should not publish a DMARC record. Requiring DMARC-esque authentication (let alone strict alignment) from = domains that are not ready to use DMARC will cause a lot of wanted email to be = treated as having failed that test. In your first phase, p=3Dnone, this will have no effect. The value of = using p=3Dnone in DMARC is so that domains can take advantage of DMARC reporting = without loss of legitimate email. You have no reporting, so this provides no = value. In your middle phase, p=3Dquarantine, this will cause massive loss of = wanted email while still providing no feedback to senders. In your final phase, p=3Dreject, there will continue to be massive loss = of wanted email. In none of those phases does your draft add any value. If a receiver = wants to pay attention to whether mail is authenticated or not it can already do so, and it can do = so much more effectively than any approach that requires strict DMARC style = alignment. Cheers, Steve From nobody Tue Mar 15 06:43:20 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4F1912DA4D for ; Tue, 15 Mar 2016 06:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonnection.nl 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 KI6zR5jPs0eJ for ; Tue, 15 Mar 2016 06:43:15 -0700 (PDT) Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id 08DE012D5B4 for ; Tue, 15 Mar 2016 06:43:11 -0700 (PDT) Received: from mx24.mailtransaction.com (mx21.mailtransaction.com [78.46.16.236]) by mx20.mailtransaction.com (Postfix) with ESMTP id 3qPbRK2ZSRz1L8dF; Tue, 15 Mar 2016 14:43:09 +0100 (CET) Received: from tiger.sonnection.nl (D57E1706.static.ziggozakelijk.nl [213.126.23.6]) by mx24.mailtransaction.com (Postfix) with ESMTP id 3qPbRK0VXjz1L8d0; Tue, 15 Mar 2016 14:43:09 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by tiger.sonnection.nl (Postfix) with ESMTP id E460C421129; Tue, 15 Mar 2016 14:43:08 +0100 (CET) X-Virus-Scanned: amavisd-new at tiger.sonnection.nl Received: from tiger.sonnection.nl ([127.0.0.1]) by localhost (tiger.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id RjzmQAICOu24; Tue, 15 Mar 2016 14:43:08 +0100 (CET) Received: from lion.sonnection.nl (lion.sonnection.nl [192.168.30.2]) by tiger.sonnection.nl (Postfix) with ESMTP id 140254210E0; Tue, 15 Mar 2016 14:43:08 +0100 (CET) Date: Tue, 15 Mar 2016 14:43:07 +0100 (CET) From: "Rolf E. Sonneveld" To: Steve Atkins Message-ID: <2001037006.955710.1458049387855.JavaMail.zimbra@sonnection.nl> In-Reply-To: <84979E86-150D-487C-962C-72E945293ACE@wordtothewise.com> References: <20160314043043.31115.73657.idtracker@ietfa.amsl.com> <58630132-33D2-491B-9EC0-A98328F2BCD4@lepidum.co.jp> <84979E86-150D-487C-962C-72E945293ACE@wordtothewise.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [192.168.20.2] X-Mailer: Zimbra 8.6.0_GA_1182 (ZimbraWebClient - FF44 (Linux)/8.6.0_GA_1182) Thread-Topic: I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt Thread-Index: +bWm4tzbsqbKJk1eUaNf01trOI+U0A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1458049389; bh=rT+zPHG4mW1W+voJtSWKXbA0tX46hJfEGQ2AAQYoROQ=; h=Date:From:To:Message-ID:Subject:From; b=cWWwJsmT6ye2nSTgXy2J7Vfox1UokvnW/bKqkAA1WiQfNgD7rEXc3Ezt/GbAeksex vwm1+6hAQ97LJXQBmwieXs+4IrkOhsm/dRtnIrU+IBiEX1faAdNiWrnnUrLCVcdDj3 tBP6lnVRttlNeE9Da26G2wvPumRH1QnPknH43T3c= DKIM-Filter: OpenDKIM Filter v2.8.2 mx20.mailtransaction.com 3qPbRK2ZSRz1L8dF Archived-At: Cc: dmarc Subject: Re: [dmarc-ietf] I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 13:43:20 -0000 >> On Mar 14, 2016, at 11:28 PM, Kouji Okada wrote: >> >> We have submitted a draft about DMARC default verification >> for domains not publishing DMARC records. >> Any comments will be appreciated. > > Summary: If a domain does not opt-in to using DMARC, treat the domain > as though it had opted-in to using DMARC with "p=none adkim=s aspf=s". > Once that's deployed, change it to "p=reject adkim=s aspf=s". Possibly > do "p=quarantine" between the two. > > There are multiple problems with this suggestion. > > Firstly, DMARC is an opt-in protocol for good reason. It's a lot of work to > clean up all the mail streams for a domain such that all email is authenticated. > In many cases it is impossible to do so. Those domains that have not done > so should not publish a DMARC record. > > Requiring DMARC-esque authentication (let alone strict alignment) from domains > that are not ready to use DMARC will cause a lot of wanted email to be treated > as > having failed that test. > > In your first phase, p=none, this will have no effect. The value of using p=none > in DMARC is so that domains can take advantage of DMARC reporting without > loss of legitimate email. You have no reporting, so this provides no value. > > In your middle phase, p=quarantine, this will cause massive loss of wanted email > while > still providing no feedback to senders. > > In your final phase, p=reject, there will continue to be massive loss of wanted > email. > > In none of those phases does your draft add any value. If a receiver wants to > pay attention to > whether mail is authenticated or not it can already do so, and it can do so much > more effectively than any approach that requires strict DMARC style alignment. Well said, +1. /rolf From nobody Tue Mar 15 08:47:26 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50FCA12DC99 for ; Tue, 15 Mar 2016 08:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.303 X-Spam-Level: X-Spam-Status: No, score=-4.303 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 ZoeAJwdpBiUl for ; Tue, 15 Mar 2016 08:47:20 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D302212DC95 for ; Tue, 15 Mar 2016 08:47:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1458056824; bh=29hGm2cO/bNZ/21A+UYPbcIA01JHQ8DcS3XgDk5v/Sc=; l=1000; h=To:References:From:Cc:Date:In-Reply-To; b=liENGByuOVonPlbEqdbyNvmkI9YDtzr2yNjK5/J21mBPdpp0potIn75FyM+g7uz4h 3tohJo//YXye0R5k/c/SOSGivE8YWyZVyePvtf+uRGHAH56vBIg/Tfnj6pwgyNDGFB bkWL+g2843ePaXa01ETOXPmU7FP8K3Keh7Q8aB0k= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.88] (pcale.tana [172.25.197.88]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Tue, 15 Mar 2016 16:47:04 +0100 id 00000000005DC053.0000000056E82E78.000044EA To: Kouji Okada References: <20160314043043.31115.73657.idtracker@ietfa.amsl.com> <58630132-33D2-491B-9EC0-A98328F2BCD4@lepidum.co.jp> From: Alessandro Vesely Message-ID: <56E82E78.8000201@tana.it> Date: Tue, 15 Mar 2016 16:47:04 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.6.0 MIME-Version: 1.0 In-Reply-To: <58630132-33D2-491B-9EC0-A98328F2BCD4@lepidum.co.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Fwd: I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 15:47:25 -0000 On Tue 15/Mar/2016 07:28:23 +0100 Kouji Okada wrote: > We have submitted a draft about DMARC default verification > for domains not publishing DMARC records. > Any comments will be appreciated. Maybe it's me, but I'm unable to make sense of the last paragraph of Section 3: When a DKIM verification passes, the virtual DMARC verification for the same email always passes. DMARC verification compares the RFC5322.from and domains described in the d tags of DKIM-Signature field of the received email. To pass the DKIM verification those two fields must be identical. Therefore, when the DKIM verification passes, the virtual verification of DMARC also passes. The mail message I'm replying to has dkim=pass (header.i=@ietf.org), but wouldn't have passed a virtual DMARC verification. Hence the first sentence is false. The second and third sentences express lepidum.co.jp != ietf.org correctly, but the fourth sentence infers the thesis wrongly. What am I missing? Ale From nobody Tue Mar 15 11:14:04 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93D1812D694; Tue, 15 Mar 2016 11:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=peachymango.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8v-M2R9VUyLh; Tue, 15 Mar 2016 11:14:00 -0700 (PDT) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id 3A63912DA02; Tue, 15 Mar 2016 11:13:59 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 52BB3563D9E; Tue, 15 Mar 2016 13:13:59 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 47227602B0; Tue, 15 Mar 2016 13:13:59 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNJ-AdLwsmEt; Tue, 15 Mar 2016 13:13:59 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 1855D602B3; Tue, 15 Mar 2016 13:13:59 -0500 (CDT) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-2.01.com 1855D602B3 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1458065639; bh=d4kNIwv7bqv+Guk12b9eFW+YyRPAklZI2Qzg96FoWnk=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=bIARqKbKm2rVx0ODXAwqMAjw8s3jXX93sWSHxgXVA7Vj2X1V+GE2oOCYDMZhdDyzb /ABJOe1UedXgHwYjz48Ze3yYgP0vOyj/SOueu8Ne92BpzqKXupESXc7R/U/Tocpddd 6i99cR5IBSdRQIiqv7kDfP+DIyw7t2qwm1hBrZeg= Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 01CBD602B2; Tue, 15 Mar 2016 13:13:59 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id gjRNEAiL6qhg; Tue, 15 Mar 2016 13:13:58 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-2.01.com (Postfix) with ESMTP id CF3DA602B0; Tue, 15 Mar 2016 13:13:58 -0500 (CDT) Date: Tue, 15 Mar 2016 13:13:54 -0500 (CDT) From: Franck Martin To: Kouji Okada Message-ID: <370708887.22336.1458065634277.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <20160314043043.31115.73657.idtracker@ietfa.amsl.com> <58630132-33D2-491B-9EC0-A98328F2BCD4@lepidum.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF44 (Mac)/8.0.5_GA_5839) Thread-Topic: I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt Thread-Index: 0fjj/+tN/Wv0ica5NWL5juLyqYRGpA== Archived-At: Cc: dmarc@ietf.org, draft-akagiri-dmarc-virtual-verification@ietf.org Subject: Re: [dmarc-ietf] Fwd: I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 18:14:02 -0000 ----- Original Message ----- > From: "Kouji Okada" > To: dmarc@ietf.org > Cc: "Kouji Okada" , draft-akagiri-dmarc-virtual-verification@ietf.org > Sent: Monday, March 14, 2016 11:28:23 PM > Subject: [dmarc-ietf] Fwd: I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt > > We have submitted a draft about DMARC default verification > for domains not publishing DMARC records. > Any comments will be appreciated. > I have used to some form of success where all is considered in relaxed mode and with p=none. If I get a dmarc "pass" then I know the email is really coming from the domain it claims to be coming from, so for specific use cases the higher layers don't need to challenge the sender to prove who it is. Some of this code can be found at: https://github.com/linkedin/dmarc-msys/ This is mainly for internal use. From nobody Tue Mar 15 12:42:29 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE02612D740 for ; Tue, 15 Mar 2016 12:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qF2fREaCXHJB for ; Tue, 15 Mar 2016 12:42:26 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73DA612DCE1 for ; Tue, 15 Mar 2016 12:42:13 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id m184so37311575iof.1 for ; Tue, 15 Mar 2016 12:42:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:date:message-id:subject:from:to:cc; bh=jxpCcwGu9pfgao2suozkmgcHlQWfXL3D5GCMKbaWLME=; b=eqUIWv1PIw0NKJ2ZWz+3tfIA9GY/PQpBYAVh2SHUOysKn205TxcDcDTBTzbb5/gFy9 BlpeDmSAI1CKteoKfvMkAbDPHvnMaSO3bJOz4gRSglX3RzOtBwFGudwdIdUN0GtVfgPn tO+YHZqcTwv9Xv9KbjlMU/6GRvYxbNCzwuK0o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to:cc; bh=jxpCcwGu9pfgao2suozkmgcHlQWfXL3D5GCMKbaWLME=; b=lNzdCt1cYCyppbhnnJc8o/lMDqwToFuscak7oWeEb3MYM96QEhgmQngvqFGxV8p0Sa lT9oZgT6/oEetYF+i5zCOjyUsnxnaFd6AA0+ZWToqBtNGptjroT9MEP3pghuNkzczDaB L1DbIVRuL9Jy+YYSXImk71PqDGGLovUN1TmhYqqz/l0CHoAakvzv5bjtxkNlU26r67UU fmASEZbSaCO0+/2eFFkFXZ6SSRidsDjJeOc/dfFQr3Dc7B0GY87Hybtmagb2Gzy8+FDX J9qtmFSeWvU/CPKvPrJBxhC2T0g48l1cShTopoE30YP/OD2HdZEQE7vt6XAL9Cuv3Xlr 936w== X-Gm-Message-State: AD7BkJLKKw+/mVx2/tf/SLg7JozbZsAtWXNPP1acxyik0IEA4txNMC2Ba6ZvcgV5fQlOHclcET/D11LgkaMSkA== MIME-Version: 1.0 X-Received: by 10.107.129.84 with SMTP id c81mr516827iod.102.1458070932668; Tue, 15 Mar 2016 12:42:12 -0700 (PDT) Sender: kurta@drkurt.com Received: by 10.107.201.16 with HTTP; Tue, 15 Mar 2016 12:42:12 -0700 (PDT) Date: Tue, 15 Mar 2016 12:42:12 -0700 X-Google-Sender-Auth: tqET7RwjgYYSPkTsIP_oTD8Fdvw Message-ID: From: "Kurt Andersen (b)" To: dmarc Content-Type: multipart/alternative; boundary=001a113fbcc2004fef052e1b9886 Archived-At: Cc: "Rolf E. Sonneveld" , Steve Atkins Subject: Re: [dmarc-ietf] I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 19:42:29 -0000 --001a113fbcc2004fef052e1b9886 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 15, 2016 at 6:43 AM, Rolf E. Sonneveld < r.e.sonneveld@sonnection.nl> wrote: > >> On Mar 14, 2016, at 11:28 PM, Kouji Okada wrote: > >> > >> We have submitted a draft about DMARC default verification > >> for domains not publishing DMARC records. > >> Any comments will be appreciated. > > > > Summary: If a domain does not opt-in to using DMARC, treat the domain > > as though it had opted-in to using DMARC with "p=none adkim=s aspf=s". > > Once that's deployed, change it to "p=reject adkim=s aspf=s". Possibly > > do "p=quarantine" between the two. > > > > There are multiple problems with this suggestion. > > > > Firstly, DMARC is an opt-in protocol for good reason. > > > > > In none of those phases does your draft add any value. If a receiver > wants to > > pay attention to > > whether mail is authenticated or not it can already do so, and it can do > so much > > more effectively than any approach that requires strict DMARC style > alignment. > > Well said, +1. At the risk of piling on, but feeling the need to have an assertive "hum" on the topic, I think that Steve Atkin's critiques are spot on. A receiver may reject mail for any reason that they so choose (subject to whatever jurisdictional rules and regulations they operate under), but calling it DMARC or "inferred DMARC" is abusing the term to no good effect. --Kurt --001a113fbcc2004fef052e1b9886 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Mar 15, 2016 at 6:43 AM, Rolf E. Sonneveld <r.e.sonneveld@so= nnection.nl> wrote:
>> On M= ar 14, 2016, at 11:28 PM, Kouji Okada <okd@lepidum.co.jp> wrote:
>>
>> We have submitted a draft about DMARC default verification
>> for domains not publishing DMARC records.
>> Any comments will be appreciated.
>
> Summary: If a domain does not opt-in to using DMARC, treat the domain<= br> > as though it had opted-in to using DMARC with "p=3Dnone adkim=3Ds= aspf=3Ds".
> Once that's deployed, change it to "p=3Dreject adkim=3Ds aspf= =3Ds". Possibly
> do "p=3Dquarantine" between the two.
>
> There are multiple problems with this suggestion.
>
> Firstly, DMARC is an opt-in protocol for good reason.
=
<elided>=C2=A0
=
>
> In none of those phases does your draft add any value. If a receiver w= ants to
> pay attention to
> whether mail is authenticated or not it can already do so, and it can = do so much
> more effectively than any approach that requires strict DMARC style al= ignment.

Well said, +1.

At the risk of p= iling on, but feeling the need to have an assertive "hum" on the = topic, I think that Steve Atkin's critiques are spot on. A receiver may= reject mail for any reason that they so choose (subject to whatever jurisd= ictional rules and regulations they operate under), but calling it DMARC or= "inferred DMARC" is abusing the term to no good effect.

--Kurt=C2=A0
--001a113fbcc2004fef052e1b9886-- From nobody Tue Mar 15 13:05:24 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A049712D567 for ; Tue, 15 Mar 2016 13:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=exchange.microsoft.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 9ZD_jodVa3Ok for ; Tue, 15 Mar 2016 13:05:19 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0722.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:722]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F69812DC74 for ; Tue, 15 Mar 2016 13:05:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=exchange.microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Ji/dGcHnviGkax57oYDtn7+0KuMKu4BUm/JH89jLod0=; b=Kvo7asxRJJfBJd8cKEXLVFz8wIOwAT7K+XYoeG90TPISi6A0wmJM92STd/uJFKZOKRBdMTSeKaTjqRIZNV1MzFB1xSHmeRm0QENhM/KqC0iNBk7eYrizWFmqWsz5vxmYCvic0siEjQhDURCAS3R8EfVFywKKHJPLHjKTbZCprjI= Received: from CY1PR00MB0009.namprd00.prod.outlook.com (10.160.144.156) by CY1PR00MB0010.namprd00.prod.outlook.com (10.160.148.19) with Microsoft SMTP Server (TLS) id 15.1.447.3; Tue, 15 Mar 2016 20:04:53 +0000 Received: from CY1PR00MB0009.namprd00.prod.outlook.com ([10.160.144.156]) by CY1PR00MB0009.namprd00.prod.outlook.com ([10.160.144.156]) with mapi id 15.01.0447.011; Tue, 15 Mar 2016 20:04:53 +0000 From: Terry Zink To: dmarc Thread-Topic: [dmarc-ietf] I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt Thread-Index: AQHRfrbXOv7CJWcfnEWf13ajirEjOp9a6tsQ Date: Tue, 15 Mar 2016 20:04:52 +0000 Message-ID: References: <20160314043043.31115.73657.idtracker@ietfa.amsl.com> <58630132-33D2-491B-9EC0-A98328F2BCD4@lepidum.co.jp> <84979E86-150D-487C-962C-72E945293ACE@wordtothewise.com> In-Reply-To: <84979E86-150D-487C-962C-72E945293ACE@wordtothewise.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=exchange.microsoft.com; x-originating-ip: [2001:4898:80e8:d::91] x-ms-office365-filtering-correlation-id: b9027e10-11d5-4b8e-cd82-08d34d0d129a x-microsoft-exchange-diagnostics: 1; CY1PR00MB0010; 5:QQWhPfjavCkvP8n7m0Kj3/3IdncuCMS4cNCLyrwotQzL6gSRxBWPpfLqDiH4ciAv6evCjhssrZd2is6+ITx+q7xXCE2NOORd7BbJCgioaDN3Dqzwibvkb4jcI2MmL5DNSzGdb5UP91LStHBTzTBS7Q==; 24:/M+rmqiEmYTzw96Ee1RN8zRj9TEQwyOgoQv+N/zBHyOSnCEu3VN6d8FWJAu6Xf6yodzP0bj5OBSSHakXcJgTG5e1ect4qHdg8TelfZAzxTY= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR00MB0010; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(61426038)(61427038); SRVR:CY1PR00MB0010; BCL:0; PCL:0; RULEID:; SRVR:CY1PR00MB0010; x-forefront-prvs: 08828D20BC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(24454002)(377454003)(10290500002)(110136002)(122556002)(3280700002)(11100500001)(5005710100001)(1096002)(15650500001)(2900100001)(2950100001)(81166005)(10400500002)(107886002)(2420400007)(15198665003)(450100001)(54356999)(33656002)(92566002)(76176999)(15395725005)(50986999)(189998001)(99286002)(74316001)(230783001)(10090500001)(3660700001)(15975445007)(586003)(2906002)(1220700001)(102836003)(5008740100001)(5003600100002)(77096005)(5002640100001)(19580395003)(10710500007)(19580405001)(6116002)(86362001)(87936001)(106116001)(5004730100002)(76576001)(3826002)(10090945008); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR00MB0010; H:CY1PR00MB0009.namprd00.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Mar 2016 20:04:52.8764 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR00MB0010 Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 20:05:23 -0000 +1 to virtual DMARC, -1 to the arguments against it. Office 365 already supports something like this for our customers to cut do= wn on Business Email Compromise. Maybe 5% of our customers have DMARC recor= ds, yet we treat all inbound email destined to them as having p=3Dquarantin= e and then we figure out roughly who is allowed to send email as them even = when (especially when) they don't authenticate. I talk about this here: htt= p://aka.ms/AntispoofingInOffice365. We've been doing DMARC lookups on the header.from and stamping the result f= or a while now, and if it doesn't publish DMARC but would have passed if it= did, we stamp the result and call it "Best Guess Pass". However, we use re= laxed alignment, not strict. I talk about this here: http://blogs.msdn.com/= b/tzink/archive/2015/05/06/what-is-dmarc-bestguesspass-in-office-365.aspx Figuring out implicit/virtual DMARC for everyone else is a much bigger body= of water to boil, but is roughly the same problem. As a large receiver we = have overrides for DMARC failures anyway, so implicit/virtual DMARC would h= ave those same overrides. > Firstly, DMARC is an opt-in protocol for good reason. I'm saying this tongue-in-cheek, but that "good reason" is "very limited de= ployment in practice." If we would have waited for customers to publish DMA= RC records we'd be at 6% adoption rate. > In your first phase, p=3Dnone, this will have no effect. In your middle p= hase,=20 > p=3Dquarantine, this will cause massive loss of wanted email ... In your > final phase, p=3Dreject, there will continue to be massive loss of wanted= email. If large email receivers start junking messages because of implicit/virtual= DMARC failures, senders figure it out eventually even without DMARC report= ing. There's more tools in our toolbox than just junking. For example, we c= an add visual warnings to the message. We can choose not to extract/promote= content if the header.from doesn't align with the SPF/DKIM domain (i.e., a= n airline sends a flight confirmation and that info is not shown to the use= r in a rich manner). We can add throttling limits. And so forth. -- Terry -----Original Message----- From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Steve Atkins Sent: Tuesday, March 15, 2016 5:33 AM To: dmarc Subject: Re: [dmarc-ietf] I-D Action: draft-akagiri-dmarc-virtual-verificat= ion-00.txt > On Mar 14, 2016, at 11:28 PM, Kouji Okada wrote: >=20 > We have submitted a draft about DMARC default verification > for domains not publishing DMARC records. > Any comments will be appreciated. Summary: If a domain does not opt-in to using DMARC, treat the domain as though it had opted-in to using DMARC with "p=3Dnone adkim=3Ds aspf=3Ds"= . Once that's deployed, change it to "p=3Dreject adkim=3Ds aspf=3Ds". Possibl= y do "p=3Dquarantine" between the two. There are multiple problems with this suggestion. Firstly, DMARC is an opt-in protocol for good reason. It's a lot of work to clean up all the mail streams for a domain such that all email is authentic= ated. In many cases it is impossible to do so. Those domains that have not done so should not publish a DMARC record. Requiring DMARC-esque authentication (let alone strict alignment) from doma= ins that are not ready to use DMARC will cause a lot of wanted email to be trea= ted as having failed that test. In your first phase, p=3Dnone, this will have no effect. The value of using= p=3Dnone in DMARC is so that domains can take advantage of DMARC reporting without loss of legitimate email. You have no reporting, so this provides no value. In your middle phase, p=3Dquarantine, this will cause massive loss of wante= d email while still providing no feedback to senders. In your final phase, p=3Dreject, there will continue to be massive loss of = wanted email. In none of those phases does your draft add any value. If a receiver wants = to pay attention to whether mail is authenticated or not it can already do so, and it can do so= much more effectively than any approach that requires strict DMARC style alignme= nt. Cheers, Steve _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc From nobody Tue Mar 15 14:06:46 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 992EB12D7A5 for ; Tue, 15 Mar 2016 14:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=peachymango.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id suD81hS92Y5Q for ; Tue, 15 Mar 2016 14:06:43 -0700 (PDT) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id 9011812D77E for ; Tue, 15 Mar 2016 14:06:43 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 1D783563DBC; Tue, 15 Mar 2016 16:06:43 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 0B316A045E; Tue, 15 Mar 2016 16:06:43 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNLaL9RYSOj1; Tue, 15 Mar 2016 16:06:42 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id C776EA0467; Tue, 15 Mar 2016 16:06:42 -0500 (CDT) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-1.01.com C776EA0467 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1458076002; bh=ZhBDROpoiB4fNDuqcwXBkIudwntR1a9c5lCEaSnYdDc=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=icKlf4Pznmj6nAQ9zN3DWcIaDSPeBOsvsoEfQmEG1Uz2DFW4mZDt44AKH/18egd4Z ezg9mXjU7k/j0pzfMr1tmBp0T92t52iJjliALFCXl8SgEOM6zSh7aUaLzBLsumA7D/ muafFhxBSv6CcxqBI3ZM87EZJDaQdm0L6QOu0BJQ= Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id A7B59A0462; Tue, 15 Mar 2016 16:06:42 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id sWj6mEtZ9_LN; Tue, 15 Mar 2016 16:06:42 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-1.01.com (Postfix) with ESMTP id 60FA0A045E; Tue, 15 Mar 2016 16:06:42 -0500 (CDT) Date: Tue, 15 Mar 2016 16:06:42 -0500 (CDT) From: Franck Martin To: Terry Zink Message-ID: <1954977995.24967.1458076002108.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <20160314043043.31115.73657.idtracker@ietfa.amsl.com> <58630132-33D2-491B-9EC0-A98328F2BCD4@lepidum.co.jp> <84979E86-150D-487C-962C-72E945293ACE@wordtothewise.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF44 (Mac)/8.0.5_GA_5839) Thread-Topic: [dmarc-ietf] I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt Thread-Index: AQHRfrbXOv7CJWcfnEWf13ajirEjOp9a6tsQh07P2gc= Archived-At: Cc: dmarc Subject: Re: [dmarc-ietf] I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 21:06:45 -0000 ----- Original Message ----- > From: "Terry Zink" > To: "dmarc" > Sent: Tuesday, March 15, 2016 1:04:52 PM > Subject: Re: [dmarc-ietf] I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt > > +1 to virtual DMARC, -1 to the arguments against it. > > Office 365 already supports something like this for our customers to cut down > on Business Email Compromise. Maybe 5% of our customers have DMARC records, > yet we treat all inbound email destined to them as having p=quarantine and > then we figure out roughly who is allowed to send email as them even when > (especially when) they don't authenticate. I talk about this here: > http://aka.ms/AntispoofingInOffice365. > > We've been doing DMARC lookups on the header.from and stamping the result for > a while now, and if it doesn't publish DMARC but would have passed if it > did, we stamp the result and call it "Best Guess Pass". However, we use > relaxed alignment, not strict. I talk about this here: > http://blogs.msdn.com/b/tzink/archive/2015/05/06/what-is-dmarc-bestguesspass-in-office-365.aspx > > Figuring out implicit/virtual DMARC for everyone else is a much bigger body > of water to boil, but is roughly the same problem. As a large receiver we > have overrides for DMARC failures anyway, so implicit/virtual DMARC would > have those same overrides. > > > Firstly, DMARC is an opt-in protocol for good reason. > > I'm saying this tongue-in-cheek, but that "good reason" is "very limited > deployment in practice." If we would have waited for customers to publish > DMARC records we'd be at 6% adoption rate. > > > In your first phase, p=none, this will have no effect. In your middle > > phase, > > p=quarantine, this will cause massive loss of wanted email ... In your > > final phase, p=reject, there will continue to be massive loss of wanted > > email. > > If large email receivers start junking messages because of implicit/virtual > DMARC failures, senders figure it out eventually even without DMARC > reporting. There's more tools in our toolbox than just junking. For example, > we can add visual warnings to the message. We can choose not to > extract/promote content if the header.from doesn't align with the SPF/DKIM > domain (i.e., an airline sends a flight confirmation and that info is not > shown to the user in a rich manner). We can add throttling limits. And so > forth. > Yes, it may not be cool to call it Virtual DMARC, but basically it is applying the DMARC logic, to pass information to other layers. Google has been doing virtual SPF (aka best guess SPF) for a while. The name is confusing, and mixing the results of two systems may produce non-comparable metrics. I think the point, is that several of us have been doing this for quite a while and this has been useful in our own internal networks, I'm not sure it needs to be formalized to the rest of Internet, except may be under informational status or under a (B)CP. From nobody Tue Mar 15 15:10:44 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37A1F12DDEE for ; Tue, 15 Mar 2016 15:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonnection.nl 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 uxs0uXhb7hvn for ; Tue, 15 Mar 2016 15:10:39 -0700 (PDT) Received: from mx10.mailtransaction.com (mx10.mailtransaction.com [88.198.59.241]) by ietfa.amsl.com (Postfix) with ESMTP id 363FA12D7A6 for ; Tue, 15 Mar 2016 15:10:39 -0700 (PDT) Received: from mx24.mailtransaction.com (mx21.mailtransaction.com [78.46.16.236]) by mx10.mailtransaction.com (Postfix) with ESMTP id 3qPpht0Lxyz5Mgg2; Tue, 15 Mar 2016 23:10:38 +0100 (CET) Received: from tiger.sonnection.nl (D57E1706.static.ziggozakelijk.nl [213.126.23.6]) by mx24.mailtransaction.com (Postfix) with ESMTP id 3qPphs67Llz1L8d0; Tue, 15 Mar 2016 23:10:37 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by tiger.sonnection.nl (Postfix) with ESMTP id CFBE6421129; Tue, 15 Mar 2016 23:10:36 +0100 (CET) X-Virus-Scanned: amavisd-new at tiger.sonnection.nl Received: from tiger.sonnection.nl ([127.0.0.1]) by localhost (tiger.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id k3WEZ0H3T8Un; Tue, 15 Mar 2016 23:10:36 +0100 (CET) Received: from [192.168.40.49] (unknown [192.168.40.49]) by tiger.sonnection.nl (Postfix) with ESMTPSA id A23AE4210E0; Tue, 15 Mar 2016 23:10:36 +0100 (CET) To: Franck Martin , Terry Zink References: <20160314043043.31115.73657.idtracker@ietfa.amsl.com> <58630132-33D2-491B-9EC0-A98328F2BCD4@lepidum.co.jp> <84979E86-150D-487C-962C-72E945293ACE@wordtothewise.com> <1954977995.24967.1458076002108.JavaMail.zimbra@peachymango.org> From: "Rolf E. Sonneveld" Message-ID: <56E8885C.4090808@sonnection.nl> Date: Tue, 15 Mar 2016 23:10:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <1954977995.24967.1458076002108.JavaMail.zimbra@peachymango.org> Content-Type: multipart/alternative; boundary="------------010505040504030403080404" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1458079838; bh=csOGFkU5JaMSh/ILimTQwF3nkbf5x69wNjvSW7WQATk=; h=Subject:To:From:Message-ID:Date:From; b=fX45wAXX2vsre/iauk1M+TbtMnOSjoPFAbmL0vdnMSghExYNHnYoUSz5gspHKGoGQ l1YWcXDQ8CYzGo9VKPBjuy4qAXrr/fEOF0pqO9xRXRD7Ht1kQeQ//sLY0FEOV3CLEy H7/KQEdm4sYVFlBYDIl5ltnjz2jsepaPewCUhtOo= DKIM-Filter: OpenDKIM Filter v2.8.2 mx10.mailtransaction.com 3qPpht0Lxyz5Mgg2 Archived-At: Cc: dmarc Subject: Re: [dmarc-ietf] I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 22:10:43 -0000 This is a multi-part message in MIME format. --------------010505040504030403080404 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 15-03-16 22:06, Franck Martin wrote: > > > > ----- Original Message ----- >> From: "Terry Zink" >> To: "dmarc" >> Sent: Tuesday, March 15, 2016 1:04:52 PM >> Subject: Re: [dmarc-ietf] I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt >> >> +1 to virtual DMARC, -1 to the arguments against it. >> >> Office 365 already supports something like this for our customers to cut down >> on Business Email Compromise. Maybe 5% of our customers have DMARC records, >> yet we treat all inbound email destined to them as having p=quarantine and >> then we figure out roughly who is allowed to send email as them even when >> (especially when) they don't authenticate. I talk about this here: >> http://aka.ms/AntispoofingInOffice365. >> >> We've been doing DMARC lookups on the header.from and stamping the result for >> a while now, and if it doesn't publish DMARC but would have passed if it >> did, we stamp the result and call it "Best Guess Pass". However, we use >> relaxed alignment, not strict. I talk about this here: >> http://blogs.msdn.com/b/tzink/archive/2015/05/06/what-is-dmarc-bestguesspass-in-office-365.aspx >> >> Figuring out implicit/virtual DMARC for everyone else is a much bigger body >> of water to boil, but is roughly the same problem. As a large receiver we >> have overrides for DMARC failures anyway, so implicit/virtual DMARC would >> have those same overrides. >> >>> Firstly, DMARC is an opt-in protocol for good reason. >> I'm saying this tongue-in-cheek, but that "good reason" is "very limited >> deployment in practice." If we would have waited for customers to publish >> DMARC records we'd be at 6% adoption rate. >> >>> In your first phase, p=none, this will have no effect. In your middle >>> phase, >>> p=quarantine, this will cause massive loss of wanted email ... In your >>> final phase, p=reject, there will continue to be massive loss of wanted >>> email. >> If large email receivers start junking messages because of implicit/virtual >> DMARC failures, senders figure it out eventually even without DMARC >> reporting. There's more tools in our toolbox than just junking. For example, >> we can add visual warnings to the message. We can choose not to >> extract/promote content if the header.from doesn't align with the SPF/DKIM >> domain (i.e., an airline sends a flight confirmation and that info is not >> shown to the user in a rich manner). We can add throttling limits. And so >> forth. >> > Yes, it may not be cool to call it Virtual DMARC, but basically it is applying the DMARC logic, to pass information to other layers. > > Google has been doing virtual SPF (aka best guess SPF) for a while. The name is confusing, and mixing the results of two systems may produce non-comparable metrics. > > I think the point, is that several of us have been doing this for quite a while and this has been useful in our own internal networks, I'm not sure it needs to be formalized to the rest of Internet, except may be under informational status or under a (B)CP. the fact that a number of big receivers already deploy similar techniques doesn't mean this draft is a good idea: * big receivers do have the resources to maintain and extend a rich toolbox to 'balance' the results of a DMARC analysis. There are however huge numbers of small to medium receivers who do not have this tooling and for whom a virtual/best guess DMARC 'mechanism' might remove the nuances there can be in the outcome of a spam analysis of real world mail; * suppose this draft would evolve into a BCP or Informational RFC, who will decide when to move from p=none to p=quarantine and from p=quarantine to p=reject, and on what criteria would such a decision be based? * like Kurt already said, associating this with the name of 'DMARC' doesn't sound the right thing to do. /rolf --------------010505040504030403080404 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit On 15-03-16 22:06, Franck Martin wrote:



----- Original Message -----

From: "Terry Zink" <tzink@exchange.microsoft.com>
To: "dmarc" <dmarc@ietf.org>
Sent: Tuesday, March 15, 2016 1:04:52 PM
Subject: Re: [dmarc-ietf] I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt

+1 to virtual DMARC, -1 to the arguments against it.

Office 365 already supports something like this for our customers to cut down
on Business Email Compromise. Maybe 5% of our customers have DMARC records,
yet we treat all inbound email destined to them as having p=quarantine and
then we figure out roughly who is allowed to send email as them even when
(especially when) they don't authenticate. I talk about this here:
http://aka.ms/AntispoofingInOffice365.

We've been doing DMARC lookups on the header.from and stamping the result for
a while now, and if it doesn't publish DMARC but would have passed if it
did, we stamp the result and call it "Best Guess Pass". However, we use
relaxed alignment, not strict. I talk about this here:
http://blogs.msdn.com/b/tzink/archive/2015/05/06/what-is-dmarc-bestguesspass-in-office-365.aspx

Figuring out implicit/virtual DMARC for everyone else is a much bigger body
of water to boil, but is roughly the same problem. As a large receiver we
have overrides for DMARC failures anyway, so implicit/virtual DMARC would
have those same overrides.


Firstly, DMARC is an opt-in protocol for good reason.

I'm saying this tongue-in-cheek, but that "good reason" is "very limited
deployment in practice." If we would have waited for customers to publish
DMARC records we'd be at 6% adoption rate.


In your first phase, p=none, this will have no effect. In your middle
phase,
p=quarantine, this will cause massive loss of wanted email ...  In your
final phase, p=reject, there will continue to be massive loss of wanted
email.

If large email receivers start junking messages because of implicit/virtual
DMARC failures, senders figure it out eventually even without DMARC
reporting. There's more tools in our toolbox than just junking. For example,
we can add visual warnings to the message. We can choose not to
extract/promote content if the header.from doesn't align with the SPF/DKIM
domain (i.e., an airline sends a flight confirmation and that info is not
shown to the user in a rich manner). We can add throttling limits. And so
forth.


Yes, it may not be cool to call it Virtual DMARC, but basically it is applying the DMARC logic, to pass information to other layers.

Google has been doing virtual SPF (aka best guess SPF) for a while. The name is confusing, and mixing the results of two systems may produce non-comparable metrics.

I think the point, is that several of us have been doing this for quite a while and this has been useful in our own internal networks, I'm not sure it needs to be formalized to the rest of Internet, except may be under informational status or under a (B)CP.

the fact that a number of big receivers already deploy similar techniques doesn't mean this draft is a good idea:

  • big receivers do have the resources to maintain and extend a rich toolbox to 'balance' the results of a DMARC analysis. There are however huge numbers of small to medium receivers who do not have this tooling and for whom a virtual/best guess DMARC 'mechanism' might remove the nuances there can be in the outcome of a spam analysis of real world mail;
  • suppose this draft would evolve into a BCP or Informational RFC, who will decide when to move from p=none to p=quarantine and from p=quarantine to p=reject, and on what criteria would such a decision be based?
  • like Kurt already said, associating this with the name of 'DMARC' doesn't sound the right thing to do.


/rolf


--------------010505040504030403080404-- From nobody Tue Mar 15 15:27:28 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD9812DE12 for ; Tue, 15 Mar 2016 15:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 M8D6vgIcnnZF for ; Tue, 15 Mar 2016 15:27:23 -0700 (PDT) Received: from mailscan.turtlesys.net (mailscan.turtlesys.net [IPv6:2001:470:4a:7:241f:acff:fe66:5236]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C5E712DE17 for ; Tue, 15 Mar 2016 15:27:20 -0700 (PDT) Received: from www01.turtlesys.net (www01.turtlesys.net [207.135.97.24]) by mailscan.turtlesys.net (Postfix) with ESMTPS id 2EA312242E44 for ; Tue, 15 Mar 2016 18:26:25 -0400 (EDT) Received: from 71-6-26-18.static-ip.telepacific.net ([71.6.26.18]:63536 helo=silverado.co.agari.com) by www01.turtlesys.net with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.86_1) (envelope-from ) id 1afxQq-0000af-DE for dmarc@ietf.org; Tue, 15 Mar 2016 15:27:16 -0700 To: dmarc From: Tomki Message-ID: <56E88C43.2050806@tomki.com> Date: Tue, 15 Mar 2016 15:27:15 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------040906070402090904040208" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - www01.turtlesys.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tomki.com X-Get-Message-Sender-Via: www01.turtlesys.net: authenticated_id: tki@tomki.com X-Authenticated-Sender: www01.turtlesys.net: tki@tomki.com X-tsmailscan01-MailScanner-Information: Please contact the ISP for more information X-tsmailscan01-MailScanner-ID: 2EA312242E44.AE029 X-tsmailscan01-MailScanner: Found to be clean X-tsmailscan01-MailScanner-From: dmarcietf@tomki.com Archived-At: Subject: [dmarc-ietf] SPFAuthResultType unbounded X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dmarcietf@tomki.com 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, 15 Mar 2016 22:27:26 -0000 This is a multi-part message in MIME format. --------------040906070402090904040208 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Does it make sense that SPFAuthResultType element counts are allowed to be unbounded? I would think that it should be a maximum of 2, and then only if the scope is indicated (helo/mfrom) from https://tools.ietf.org/html/rfc7489 --Tomki -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --------------040906070402090904040208 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit 
Does it make sense that SPFAuthResultType element counts are allowed to be unbounded?
I would think that it should be a maximum of 2, and then only if the scope is indicated (helo/mfrom)

from https://tools.ietf.org/html/rfc7489

   <xs:complexType name="AuthResultType">
     <xs:sequence>
       <!-- There may be no DKIM signatures, or multiple DKIM
            signatures. -->
       <xs:element name="dkim" type="DKIMAuthResultType"
         minOccurs="0" maxOccurs="unbounded"/>
       <!-- There will always be at least one SPF result. -->
       <xs:element name="spf" type="SPFAuthResultType" minOccurs="1"
                   maxOccurs="unbounded"/>
     </xs:sequence>
   </xs:complexType>


--Tomki

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. --------------040906070402090904040208-- From nobody Tue Mar 15 16:09:37 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA53112DE60 for ; Tue, 15 Mar 2016 16:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=peachymango.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0SLRjHwRnC7j for ; Tue, 15 Mar 2016 16:09:33 -0700 (PDT) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id A900112DE5B for ; Tue, 15 Mar 2016 16:09:33 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 2E829563D53; Tue, 15 Mar 2016 18:09:33 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 2524C602C7; Tue, 15 Mar 2016 18:09:33 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMHy_Fjw9npU; Tue, 15 Mar 2016 18:09:33 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id EC11F602CF; Tue, 15 Mar 2016 18:09:32 -0500 (CDT) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-2.01.com EC11F602CF DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1458083373; bh=vnZhVrL5A1HJaBpjrfZhahqRFcZxd0k15qUfww/Uzm4=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; b=nWw4uDoxgaIwQNQHZNJBFEhkeTRuvaMLPg9jc2tp4LDx8bi8L1tIhtxzxkrbaJC2H ZnOv3HGtfMp/VR5LDmx5VsYKrTVvxjq+QTwmwa5W5ycOFhFkKcLNyJdvKqiuiZ51Ol 5+57Cn5mc6iHxAhdP7EKzL7cQomD9NhC8hIGaDFY= Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id D5919602C8; Tue, 15 Mar 2016 18:09:32 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id eWEsZVGUHim5; Tue, 15 Mar 2016 18:09:32 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-2.01.com (Postfix) with ESMTP id B5249602C7; Tue, 15 Mar 2016 18:09:32 -0500 (CDT) Date: Tue, 15 Mar 2016 18:09:32 -0500 (CDT) From: Franck Martin To: "Rolf E. Sonneveld" Message-ID: <428613560.26857.1458083372594.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <20160314043043.31115.73657.idtracker@ietfa.amsl.com> <58630132-33D2-491B-9EC0-A98328F2BCD4@lepidum.co.jp> <84979E86-150D-487C-962C-72E945293ACE@wordtothewise.com> <1954977995.24967.1458076002108.JavaMail.zimbra@peachymango.org> <56E8885C.4090808@sonnection.nl> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_26856_1833953793.1458083372593" X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF44 (Mac)/8.0.5_GA_5839) Thread-Topic: I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt Thread-Index: qQff0SRH0jlWFePbSDm5/3ZXdUNlaQ== Archived-At: Cc: dmarc , Terry Zink Subject: Re: [dmarc-ietf] I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 23:09:35 -0000 ------=_Part_26856_1833953793.1458083372593 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit ----- Original Message ----- > From: "Rolf E. Sonneveld" > To: "Franck Martin" , "Terry Zink" > > Cc: "dmarc" > Sent: Tuesday, March 15, 2016 3:10:36 PM > Subject: Re: [dmarc-ietf] I-D Action: > draft-akagiri-dmarc-virtual-verification-00.txt > On 15-03-16 22:06, Franck Martin wrote: > the fact that a number of big receivers already deploy similar techniques > doesn't mean this draft is a good idea: > * big receivers do have the resources to maintain and extend a rich toolbox > to 'balance' the results of a DMARC analysis. There are however huge numbers > of small to medium receivers who do not have this tooling and for whom a > virtual/best guess DMARC 'mechanism' might remove the nuances there can be > in the outcome of a spam analysis of real world mail; > * suppose this draft would evolve into a BCP or Informational RFC, who will > decide when to move from p=none to p=quarantine and from p=quarantine to > p=reject, and on what criteria would such a decision be based? > * like Kurt already said, associating this with the name of 'DMARC' doesn't > sound the right thing to do. 1) Small receivers use community toolboxes, like spamassassin, I don't see where is the problem. Even, often, big receivers contribute to community toolboxes... 2) you are confusing applying a policy and getting an authentication flag for other layers 3) yes, I'm not keen either to call it DMARCX to avoid confusion, but DMARC is just a block and anyone can add other blocks to this construction. ------=_Part_26856_1833953793.1458083372593 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit




From: "Rolf E. Sonneveld" <R.E.Sonneveld@sonnection.nl>
To: "Franck Martin" <franck@peachymango.org>, "Terry Zink" <tzink@exchange.microsoft.com>
Cc: "dmarc" <dmarc@ietf.org>
Sent: Tuesday, March 15, 2016 3:10:36 PM
Subject: Re: [dmarc-ietf] I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt

On 15-03-16 22:06, Franck Martin wrote:

the fact that a number of big receivers already deploy similar techniques doesn't mean this draft is a good idea:

  • big receivers do have the resources to maintain and extend a rich toolbox to 'balance' the results of a DMARC analysis. There are however huge numbers of small to medium receivers who do not have this tooling and for whom a virtual/best guess DMARC 'mechanism' might remove the nuances there can be in the outcome of a spam analysis of real world mail;
  • suppose this draft would evolve into a BCP or Informational RFC, who will decide when to move from p=none to p=quarantine and from p=quarantine to p=reject, and on what criteria would such a decision be based?
  • like Kurt already said, associating this with the name of 'DMARC' doesn't sound the right thing to do.

1) Small receivers use community toolboxes, like spamassassin, I don't see where is the problem. Even, often, big receivers contribute to community toolboxes...
2) you are confusing applying a policy and getting an authentication flag for other layers
3) yes, I'm not keen either to call it DMARCX to avoid confusion, but DMARC is just a block and anyone can add other blocks to this construction.


------=_Part_26856_1833953793.1458083372593-- From nobody Tue Mar 15 16:10:32 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6D8112DE5F for ; Tue, 15 Mar 2016 16:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=peachymango.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6KMmJ2tq8e3E for ; Tue, 15 Mar 2016 16:10:29 -0700 (PDT) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id 32CA612DE65 for ; Tue, 15 Mar 2016 16:10:25 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id BCE6B563D53; Tue, 15 Mar 2016 18:10:24 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id B3980602CF; Tue, 15 Mar 2016 18:10:24 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8_VxH_Ycoq7A; Tue, 15 Mar 2016 18:10:24 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 84851602D3; Tue, 15 Mar 2016 18:10:24 -0500 (CDT) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-2.01.com 84851602D3 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1458083424; bh=pnOWeIAoD1WP51f1lQmHtC9DGhT8E5MFfAhdlcO59do=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; b=hbkU250n4XYG5J5ARL2zAq8aeQhy5BiAuLurBl8LcFUX1YHBmPcPMIHcEwxqVxfj6 3KtGzZ5SLqWjUIP7MbRHJDGBVZjcjvZIBf2QSLsjpxqAV20Z4tgNqNEQ8s9KXqsOdD HXN7arTMKrBl3zTKYNhTa5pfY6+1sVpR8n4XpaG4= Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 768F7602D2; Tue, 15 Mar 2016 18:10:24 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id RejOaO-penN7; Tue, 15 Mar 2016 18:10:24 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-2.01.com (Postfix) with ESMTP id 25E63602CF; Tue, 15 Mar 2016 18:10:24 -0500 (CDT) Date: Tue, 15 Mar 2016 18:10:23 -0500 (CDT) From: Franck Martin To: dmarcietf@tomki.com Message-ID: <2039296774.26888.1458083423836.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <56E88C43.2050806@tomki.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_26887_1552309790.1458083423835" X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF44 (Mac)/8.0.5_GA_5839) Thread-Topic: SPFAuthResultType unbounded Thread-Index: PINgS5MJ0cdfZKxC35rwN9RQb3qV2g== Archived-At: Cc: dmarc Subject: Re: [dmarc-ietf] SPFAuthResultType unbounded X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 23:10:31 -0000 ------=_Part_26887_1552309790.1458083423835 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit ----- Original Message ----- > From: "Tomki" > To: "dmarc" > Sent: Tuesday, March 15, 2016 3:27:15 PM > Subject: [dmarc-ietf] SPFAuthResultType unbounded > Does it make sense that SPFAuthResultType element counts are allowed to be > unbounded? > I would think that it should be a maximum of 2, and then only if the scope is > indicated (helo/mfrom) > from https://tools.ietf.org/html/rfc7489 name="AuthResultType"> > > > minOccurs="0" maxOccurs="unbounded"/> > > maxOccurs="unbounded"/> > > Makes sense, does it matter? ------=_Part_26887_1552309790.1458083423835 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit





From: "Tomki" <dmarcietf@tomki.com>
To: "dmarc" <dmarc@ietf.org>
Sent: Tuesday, March 15, 2016 3:27:15 PM
Subject: [dmarc-ietf] SPFAuthResultType unbounded

Does it make sense that SPFAuthResultType element counts are allowed to be unbounded?
I would think that it should be a maximum of 2, and then only if the scope is indicated (helo/mfrom)

from https://tools.ietf.org/html/rfc7489

   <xs:complexType name="AuthResultType">
     <xs:sequence>
       <!-- There may be no DKIM signatures, or multiple DKIM
            signatures. -->
       <xs:element name="dkim" type="DKIMAuthResultType"
         minOccurs="0" maxOccurs="unbounded"/>
       <!-- There will always be at least one SPF result. -->
       <xs:element name="spf" type="SPFAuthResultType" minOccurs="1"
                   maxOccurs="unbounded"/>
     </xs:sequence>
   </xs:complexType>

Makes sense, does it matter?
------=_Part_26887_1552309790.1458083423835-- From nobody Tue Mar 15 16:46:55 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79ECA12DE66 for ; Tue, 15 Mar 2016 16:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kitterman.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 CUmjtV8kTKhx for ; Tue, 15 Mar 2016 16:46:52 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F64212DE30 for ; Tue, 15 Mar 2016 16:46:52 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 63B00C40211 for ; Tue, 15 Mar 2016 18:46:49 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1458085609; bh=Kg/VXr++LcdCh2cCd0zRpDOJIqreVvjjo+jyKy8NX2Y=; h=From:To:Subject:Date:In-Reply-To:References:From; b=vGc7T3yNG6s/KEUWixZbARLOPirFkyrT06iJ0juvHay3t9ZqyhQ8OdMKMIBujPO+p WvFDlmSkD4us1R3FdJdU9qeIyARO6cwUCPFh5MRMzQZsc4hQY2YbskqtkjIZjiJ2o8 fRGEftw2DERRSTpajtnbJyOXw3YpmZNf7E+HziWA= From: Scott Kitterman To: dmarc@ietf.org Date: Tue, 15 Mar 2016 19:46:35 -0400 Message-ID: <1702142.4XcoOorNjj@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-83-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <1954977995.24967.1458076002108.JavaMail.zimbra@peachymango.org> References: <20160314043043.31115.73657.idtracker@ietfa.amsl.com> <1954977995.24967.1458076002108.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 23:46:54 -0000 On Tuesday, March 15, 2016 04:06:42 PM Franck Martin wrote: > ----- Original Message ----- > > > From: "Terry Zink" > > To: "dmarc" > > Sent: Tuesday, March 15, 2016 1:04:52 PM > > Subject: Re: [dmarc-ietf] I-D Action: > > draft-akagiri-dmarc-virtual-verification-00.txt > > > > +1 to virtual DMARC, -1 to the arguments against it. > > > > Office 365 already supports something like this for our customers to cut > > down on Business Email Compromise. Maybe 5% of our customers have DMARC > > records, yet we treat all inbound email destined to them as having > > p=quarantine and then we figure out roughly who is allowed to send email > > as them even when (especially when) they don't authenticate. I talk about > > this here: http://aka.ms/AntispoofingInOffice365. > > > > We've been doing DMARC lookups on the header.from and stamping the result > > for a while now, and if it doesn't publish DMARC but would have passed if > > it did, we stamp the result and call it "Best Guess Pass". However, we > > use relaxed alignment, not strict. I talk about this here: > > http://blogs.msdn.com/b/tzink/archive/2015/05/06/what-is-dmarc-bestguesspa > > ss-in-office-365.aspx > > > > Figuring out implicit/virtual DMARC for everyone else is a much bigger > > body > > of water to boil, but is roughly the same problem. As a large receiver we > > have overrides for DMARC failures anyway, so implicit/virtual DMARC would > > have those same overrides. > > > > > Firstly, DMARC is an opt-in protocol for good reason. > > > > I'm saying this tongue-in-cheek, but that "good reason" is "very limited > > deployment in practice." If we would have waited for customers to publish > > DMARC records we'd be at 6% adoption rate. > > > > > In your first phase, p=none, this will have no effect. In your middle > > > phase, > > > p=quarantine, this will cause massive loss of wanted email ... In your > > > final phase, p=reject, there will continue to be massive loss of wanted > > > email. > > > > If large email receivers start junking messages because of > > implicit/virtual > > DMARC failures, senders figure it out eventually even without DMARC > > reporting. There's more tools in our toolbox than just junking. For > > example, we can add visual warnings to the message. We can choose not to > > extract/promote content if the header.from doesn't align with the SPF/DKIM > > domain (i.e., an airline sends a flight confirmation and that info is not > > shown to the user in a rich manner). We can add throttling limits. And so > > forth. > > Yes, it may not be cool to call it Virtual DMARC, but basically it is > applying the DMARC logic, to pass information to other layers. > > Google has been doing virtual SPF (aka best guess SPF) for a while. The name > is confusing, and mixing the results of two systems may produce > non-comparable metrics. > > I think the point, is that several of us have been doing this for quite a > while and this has been useful in our own internal networks, I'm not sure > it needs to be formalized to the rest of Internet, except may be under > informational status or under a (B)CP. SPF Best Guess is a horrible idea that should never have been invented and should die as soon as possible. http://www.openspf.org/FAQ/Best_guess_record SPF (and DMARC) are opt-in protocols. Trying to infer DMARC like things about non-participants in DMARC is just wrong. It is not an accident that SPF Best Guess apperas nowhere in RFC 4408 nor RFC 7208. It shouldn't be a model for anything. Scott K From nobody Tue Mar 15 17:18:58 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C162812D5CC for ; Tue, 15 Mar 2016 17:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kitterman.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 DzXzzccPtVTl for ; Tue, 15 Mar 2016 17:18:51 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B131012D551 for ; Tue, 15 Mar 2016 17:18:51 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id B6017C402B1 for ; Tue, 15 Mar 2016 19:18:49 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1458087529; bh=5faYblecIl5EHXlwI9ofWQWEIaAIiBgPc9VWWjdm1yM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=0u7H9L+ZlmYNXzM1wvK7MDLToX7PrwSH2Gqi7QRBzCEtSSY7TE1rHS4rjNwVRIUfR kvrm0SDmR4zaXUgKy/HmLxEBeQTZd/YVx0jcvc31JmfL9QWSrus1pKkTfnwsLkGvKH 2Ywz2l5onK/+D4OmAniT/tRy5+c36vNPBKSOtxpI= From: Scott Kitterman To: dmarc@ietf.org Date: Tue, 15 Mar 2016 20:18:49 -0400 Message-ID: <27004362.2IUWXUHgSF@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-83-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <20160314043043.31115.73657.idtracker@ietfa.amsl.com> <84979E86-150D-487C-962C-72E945293ACE@wordtothewise.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 00:18:57 -0000 It also cuts down on legitimate mail that users get sent. Probably 90% of the email I send fails DMARC even though I have SPF set up and DKIM sign everything because it tends to go via lists that have not adapted to the world of DMARC. I did publish a p=None DMARC record, so presumably I don't personally need to care about this, but typically small senders don't pay a huge amount of attention to things like new email authentication technologies. Based on your blog post, I see you're only using this for positive assertions. That's something which, as a receiver, I think you are certainly free to do, but it's not something that should be standardized. Since it's strictly an internal processing issue, there's no need to put this in an RFC and lots of reason not to. Scott K On Tuesday, March 15, 2016 08:04:52 PM Terry Zink wrote: > +1 to virtual DMARC, -1 to the arguments against it. > > Office 365 already supports something like this for our customers to cut > down on Business Email Compromise. Maybe 5% of our customers have DMARC > records, yet we treat all inbound email destined to them as having > p=quarantine and then we figure out roughly who is allowed to send email as > them even when (especially when) they don't authenticate. I talk about this > here: http://aka.ms/AntispoofingInOffice365. > > We've been doing DMARC lookups on the header.from and stamping the result > for a while now, and if it doesn't publish DMARC but would have passed if > it did, we stamp the result and call it "Best Guess Pass". However, we use > relaxed alignment, not strict. I talk about this here: > http://blogs.msdn.com/b/tzink/archive/2015/05/06/what-is-dmarc-bestguesspas > s-in-office-365.aspx > > Figuring out implicit/virtual DMARC for everyone else is a much bigger body > of water to boil, but is roughly the same problem. As a large receiver we > have overrides for DMARC failures anyway, so implicit/virtual DMARC would > have those same overrides. > > Firstly, DMARC is an opt-in protocol for good reason. > > I'm saying this tongue-in-cheek, but that "good reason" is "very limited > deployment in practice." If we would have waited for customers to publish > DMARC records we'd be at 6% adoption rate. > > In your first phase, p=none, this will have no effect. In your middle > > phase, p=quarantine, this will cause massive loss of wanted email ... In > > your final phase, p=reject, there will continue to be massive loss of > > wanted email. > If large email receivers start junking messages because of implicit/virtual > DMARC failures, senders figure it out eventually even without DMARC > reporting. There's more tools in our toolbox than just junking. For > example, we can add visual warnings to the message. We can choose not to > extract/promote content if the header.from doesn't align with the SPF/DKIM > domain (i.e., an airline sends a flight confirmation and that info is not > shown to the user in a rich manner). We can add throttling limits. And so > forth. > > -- Terry > > -----Original Message----- > From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Steve Atkins > Sent: Tuesday, March 15, 2016 5:33 AM > To: dmarc > Subject: Re: [dmarc-ietf] I-D Action: > draft-akagiri-dmarc-virtual-verification-00.txt > > On Mar 14, 2016, at 11:28 PM, Kouji Okada wrote: > > > > We have submitted a draft about DMARC default verification > > for domains not publishing DMARC records. > > Any comments will be appreciated. > > Summary: If a domain does not opt-in to using DMARC, treat the domain > as though it had opted-in to using DMARC with "p=none adkim=s aspf=s". > Once that's deployed, change it to "p=reject adkim=s aspf=s". Possibly > do "p=quarantine" between the two. > > There are multiple problems with this suggestion. > > Firstly, DMARC is an opt-in protocol for good reason. It's a lot of work to > clean up all the mail streams for a domain such that all email is > authenticated. In many cases it is impossible to do so. Those domains that > have not done so should not publish a DMARC record. > > Requiring DMARC-esque authentication (let alone strict alignment) from > domains that are not ready to use DMARC will cause a lot of wanted email to > be treated as having failed that test. > > In your first phase, p=none, this will have no effect. The value of using > p=none in DMARC is so that domains can take advantage of DMARC reporting > without loss of legitimate email. You have no reporting, so this provides > no value. > > In your middle phase, p=quarantine, this will cause massive loss of wanted > email while still providing no feedback to senders. > > In your final phase, p=reject, there will continue to be massive loss of > wanted email. > > In none of those phases does your draft add any value. If a receiver wants > to pay attention to whether mail is authenticated or not it can already do > so, and it can do so much more effectively than any approach that requires > strict DMARC style alignment. > > Cheers, > Steve > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Tue Mar 15 23:35:12 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 360BE12D686 for ; Tue, 15 Mar 2016 23:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_FAIL=0.001] autolearn=no 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 kHjP-FLIE3Ej for ; Tue, 15 Mar 2016 23:35:09 -0700 (PDT) Received: from mailscan.turtlesys.net (router02-vlan100.fmt0.turtlesys.net [207.135.97.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9728412D539 for ; Tue, 15 Mar 2016 23:35:08 -0700 (PDT) Received: from www01.turtlesys.net (www01.turtlesys.net [207.135.97.24]) by mailscan.turtlesys.net (Postfix) with ESMTPS id 8D2C22242E43 for ; Wed, 16 Mar 2016 02:34:12 -0400 (EDT) Received: from c-98-210-250-66.hsd1.ca.comcast.net ([98.210.250.66]:50719 helo=silverado.local) by www01.turtlesys.net with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.86_1) (envelope-from ) id 1ag52t-0003ss-Uf; Tue, 15 Mar 2016 23:35:04 -0700 References: <56E88C43.2050806@tomki.com> <2039296774.26888.1458083423836.JavaMail.zimbra@peachymango.org> To: Franck Martin From: Tomki Message-ID: <56E8FE96.20101@tomki.com> Date: Tue, 15 Mar 2016 23:35:02 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <2039296774.26888.1458083423836.JavaMail.zimbra@peachymango.org> Content-Type: multipart/alternative; boundary="------------060601040300040204040407" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - www01.turtlesys.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tomki.com X-Get-Message-Sender-Via: www01.turtlesys.net: authenticated_id: tki@tomki.com X-Authenticated-Sender: www01.turtlesys.net: tki@tomki.com X-tsmailscan01-MailScanner-Information: Please contact the ISP for more information X-tsmailscan01-MailScanner-ID: 8D2C22242E43.AB35C X-tsmailscan01-MailScanner: Found to be clean X-tsmailscan01-MailScanner-From: dmarcietf@tomki.com Archived-At: Cc: dmarc Subject: Re: [dmarc-ietf] SPFAuthResultType unbounded X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dmarcietf@tomki.com 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, 16 Mar 2016 06:35:11 -0000 This is a multi-part message in MIME format. --------------060601040300040204040407 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Yes, it does matter. Because one very large DMARC reporter has read this item in the specification's XML, and actually *is* providing far more than 2 SPF results per record object. I've counted 312 blocks in one instance. I'm not clear on the logic behind that, perhaps it's an aggregation level. But I don't grok it, and I want to either understand how it makes sense, or fix the spec to be entirely clear. On 3/15/16 16:10, Franck Martin wrote: > > > > > > ------------------------------------------------------------------------ > > *From: *"Tomki" > *To: *"dmarc" > *Sent: *Tuesday, March 15, 2016 3:27:15 PM > *Subject: *[dmarc-ietf] SPFAuthResultType unbounded > > Does it make sense that SPFAuthResultType element counts are allowed to be unbounded? > I would think that it should be a maximum of 2, and then only if the scope is indicated (helo/mfrom) > > fromhttps://tools.ietf.org/html/rfc7489 > > > > > minOccurs="0" maxOccurs="unbounded"/> > > maxOccurs="unbounded"/> > > > > > Makes sense, does it matter? > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --------------060601040300040204040407 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Yes, it does matter. Because one very large DMARC reporter has read this item in the specification's XML, and actually *is* providing far more than 2 SPF results per record object. I've counted 312 <spf> blocks in one instance.  I'm not clear on the logic behind that, perhaps it's an aggregation level.  But I don't grok it, and I want to either understand how it makes sense, or fix the spec to be entirely clear.



On 3/15/16 16:10, Franck Martin wrote:





From: "Tomki" <dmarcietf@tomki.com>
To: "dmarc" <dmarc@ietf.org>
Sent: Tuesday, March 15, 2016 3:27:15 PM
Subject: [dmarc-ietf] SPFAuthResultType unbounded

Does it make sense that SPFAuthResultType element counts are allowed to be unbounded?
I would think that it should be a maximum of 2, and then only if the scope is indicated (helo/mfrom)

from https://tools.ietf.org/html/rfc7489

   <xs:complexType name="AuthResultType">
     <xs:sequence>
       <!-- There may be no DKIM signatures, or multiple DKIM
            signatures. -->
       <xs:element name="dkim" type="DKIMAuthResultType"
         minOccurs="0" maxOccurs="unbounded"/>
       <!-- There will always be at least one SPF result. -->
       <xs:element name="spf" type="SPFAuthResultType" minOccurs="1"
                   maxOccurs="unbounded"/>
     </xs:sequence>
   </xs:complexType>

Makes sense, does it matter?


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


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. --------------060601040300040204040407-- From nobody Wed Mar 16 07:27:18 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1CA312D989 for ; Wed, 16 Mar 2016 07:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=otoh.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKF7DnZahvKM for ; Wed, 16 Mar 2016 07:27:10 -0700 (PDT) Received: from suricate.otoh.org (suricate.otoh.org [173.11.101.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0AA312D765 for ; Wed, 16 Mar 2016 07:27:10 -0700 (PDT) Received: from [192.168.1.190] (108-68-105-225.lightspeed.sntcca.sbcglobal.net [108.68.105.225]) (Authenticated sender: zwicky) by suricate.otoh.org (Postfix) with ESMTPSA id 9A24F7914; Wed, 16 Mar 2016 14:27:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=otoh.org; s=2014-12-30; t=1458138430; bh=1qkXkXUwleKtrRMqDugsDLTcnAIzXOgCQYYNCiOLka8=; h=Subject:From:In-Reply-To:Date:Cc:References:To; z=Subject:=20Re:=20[dmarc-ietf]=20SPFAuthResultType=20unbounded|Fro m:=20Elizabeth=20Zwicky=20|In-Reply-To:=20<203929 6774.26888.1458083423836.JavaMail.zimbra@peachymango.org>|Date:=20 Wed,=2016=20Mar=202016=2007:27:04=20-0700|Cc:=20dmarcietf@tomki.co m,=20dmarc=20|References:=20<56E88C43.2050806@tomk i.com>=20=20<203 9296774.26888.1458083423836.JavaMail.zimbra@peachymango.org>|To:=2 0Franck=20Martin=20; b=XoKDHyegxX4nWNKuPVdwLDP5hY0tBp0XTZ3+3D2KKOjtfNBv9/zmSrx+jgQWMflkI u1Vfqy2aynhqd6VuCVSLcIHvRQ80l0lY6Gv9XOGEr2vYZSHhhwV8w943viS1ojmZbn sseRnkI7kKKeEE5Gmy7kNaQXHTu6WlVT8DeofjEw= Content-Type: multipart/alternative; boundary=Apple-Mail-66870BC8-408E-4D7E-82AC-F4ED19FA59AD Mime-Version: 1.0 (1.0) From: Elizabeth Zwicky X-Mailer: iPhone Mail (13D20) In-Reply-To: <2039296774.26888.1458083423836.JavaMail.zimbra@peachymango.org> Date: Wed, 16 Mar 2016 07:27:04 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <56E88C43.2050806@tomki.com> <2039296774.26888.1458083423836.JavaMail.zimbra@peachymango.org> To: Franck Martin Archived-At: Cc: dmarc , dmarcietf@tomki.com Subject: Re: [dmarc-ietf] SPFAuthResultType unbounded X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 14:27:17 -0000 --Apple-Mail-66870BC8-408E-4D7E-82AC-F4ED19FA59AD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Rows are defined by IP; if the same IP uses multiple MAILFROM and SPF is bou= nded what is the reporter supposed to do? Duplicate rows?=20 Limiting SPF changes the row key in bad ways. (Unless all senders are well-b= ehaved in ways they are not required to be.) Elizabeth Zwicky@otoh.org > On Mar 15, 2016, at 4:10 PM, Franck Martin wrote:= >=20 >=20 >=20 >=20 >=20 >=20 > From: "Tomki" > To: "dmarc" > Sent: Tuesday, March 15, 2016 3:27:15 PM > Subject: [dmarc-ietf] SPFAuthResultType unbounded >=20 > Does it make sense that SPFAuthResultType element counts are allowed to be= unbounded? > I would think that it should be a maximum of 2, and then only if the scope= is indicated (helo/mfrom) >=20 > from https://tools.ietf.org/html/rfc7489 >=20 > > > > minOccurs=3D"0" maxOccurs=3D"unbounded"/> > > maxOccurs=3D"unbounded"/> > > >=20 >=20 > Makes sense, does it matter? > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc --Apple-Mail-66870BC8-408E-4D7E-82AC-F4ED19FA59AD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Rows are defined by IP; if the same IP uses multiple MAILFROM and SPF is b= ounded what is the reporter supposed to do? Duplicate rows? 

Limiting S= PF changes the row key in bad ways. (Unless all senders are well-behaved in w= ays they are not required to be.)

Elizabeth

<= a href=3D"mailto:Zwicky@otoh.org">Zwicky@otoh.org
=

On Mar 15, 2016, at 4:10 PM, Franck Martin <franck@peachymango.org> wrote:



<= br>


From: "Tomki" <dmarcietf@tomki.com>
To: "dmarc" &= lt;dmarc@ietf.org>
Sent: = Tuesday, March 15, 2016 3:27:15 PM
Subject: [dmarc-ietf] SPFAuthRe= sultType unbounded

Does it make sen=
se that SPFAuthResultType element counts are allowed to be unbounded?
I would think that it should be a maximum of 2, and then only if the scope i=
s indicated (helo/mfrom)

from https://tools.ietf.org/html/rfc7489

   <xs:complexType name=3D"AuthResultType">
     <xs:sequence>
       <!-- There may be no DKIM signatures, or multiple DKIM
            signatures. -->
       <xs:element name=3D"dkim" type=3D"DKIMAuthResultType"
         minOccurs=3D"0" maxOccurs=3D"unbounded"/>
       <!-- There will always be at least one SPF result. -->
       <xs:element name=3D"spf" type=3D"SPFAuthResultType" minOccurs=3D"1=
"
                   maxOccurs=3D"unbounded"/>
     </xs:sequence>
   </xs:complexType>

Makes sense, does it matter?
________________________= _______________________
dmarc mailing list
<= a href=3D"mailto:dmarc@ietf.org">dmarc@ietf.org
https://www.ietf.org/mailman/l= istinfo/dmarc
= --Apple-Mail-66870BC8-408E-4D7E-82AC-F4ED19FA59AD-- From nobody Wed Mar 16 10:00:22 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB6BA12DA00 for ; Wed, 16 Mar 2016 10:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=returnpath.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 ROQcLUgkiF3V for ; Wed, 16 Mar 2016 10:00:17 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06CF412D628 for ; Wed, 16 Mar 2016 10:00:15 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id l83so24068074lfd.3 for ; Wed, 16 Mar 2016 10:00:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=returnpath.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=Fx37F3V1zLidzf+zPLbfiq07roJc0DT4fPVNNF5r5Vw=; b=Az53ejt6Ez5TP5a8PN7om6l/GoV7mi9VLE+MFsvTM/z1XCRx4W93+eDOLlqZZFQtAc W0pPNUYkU90M+W+1bvCGRqDr2jl5ovH6/3q9YhyRjrMCjQShPtiOR5WyW3lv+9U+KrHi GqCTYg6vCownvfMex3JmSi9eDibYadwPZ/j6I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Fx37F3V1zLidzf+zPLbfiq07roJc0DT4fPVNNF5r5Vw=; b=EBqLUqc5CBKf0mRePIKE2rZwU42KjENIv4oycsn9plE7lszXXGAV3IZuQYWED+vN/f BcgE6eb7dGioXmycyaQzH56p0qQ8tKYCZ4WcRuDJdwCre549M9SiGjE9b9CZ1vfI81N+ flrPIWIH5at4pIQxCANT8UpCKu+/f6/RtgLkO4ytEAnS6yDQEGiiHWrn0WP3/peekjVz 1KWq/+5YIKy/DYnYd4ylxu/BR9KWcrDQQvwzBXx7PNCUXRMBC0b7q8SHO5J2x1xxGbBY gtmlWJhIlkJEBctkx9IRl68uJOlKnrlwsFroiULKE+NHwHlWFgKcSdeb/1mnZvnFQiFa JS3A== X-Gm-Message-State: AD7BkJLVP3AuUi1C5JgROauBjQjzI4zrllKYOlp5H5owHu1m0V+0IPfrvpcrrXy+HvpZ7AGje1xIGvcHgrmbOCtETufiqqRTGH6UfBWQ3hNy0Rv9vyMePSrkYlhdHpvr/DiRQKdbhw9u2klVpMNhJBjxJek3EK3+Vhnm8iJT6a8TjOTWThgIU7W1WvNrpQabb1xU5KZLSG/ptBkj7PvmvDqPSEWDciUpe1gxsGzVGrj3Mh7WDvHcGyS98xI7r4mvI/S1EMhA9X5JuoU= MIME-Version: 1.0 X-Received: by 10.25.39.146 with SMTP id n140mr1897430lfn.23.1458147614168; Wed, 16 Mar 2016 10:00:14 -0700 (PDT) Received: by 10.114.57.170 with HTTP; Wed, 16 Mar 2016 10:00:14 -0700 (PDT) In-Reply-To: References: <56E88C43.2050806@tomki.com> <2039296774.26888.1458083423836.JavaMail.zimbra@peachymango.org> Date: Wed, 16 Mar 2016 11:00:14 -0600 Message-ID: From: Les Barstow To: Elizabeth Zwicky Content-Type: multipart/alternative; boundary=001a114111a492e078052e2d7254 Archived-At: Cc: dmarc , dmarcietf@tomki.com, Franck Martin Subject: Re: [dmarc-ietf] SPFAuthResultType unbounded X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 17:00:22 -0000 --001a114111a492e078052e2d7254 Content-Type: text/plain; charset=UTF-8 The question then is - how does a report receiver interpret the multiple SPF results? A row has only a single auth message count; if there are three SPF rows, then which SPF result goes with how many messages? It's ambiguous (not to mention hard to render to an end user). If an IP has multiple auth result combinations, shouldn't it have one row per combination so that the report receiver can get an accurate idea of how many instances of each combination are being reported? -- Les Barstow On Wed, Mar 16, 2016 at 8:27 AM, Elizabeth Zwicky wrote: > > Rows are defined by IP; if the same IP uses multiple MAILFROM and SPF is > bounded what is the reporter supposed to do? Duplicate rows? > > Limiting SPF changes the row key in bad ways. (Unless all senders are > well-behaved in ways they are not required to be.) > > Elizabeth > > Zwicky@otoh.org > > On Mar 15, 2016, at 4:10 PM, Franck Martin wrote: > > > > > > > ------------------------------ > > *From: *"Tomki" > *To: *"dmarc" > *Sent: *Tuesday, March 15, 2016 3:27:15 PM > *Subject: *[dmarc-ietf] SPFAuthResultType unbounded > > Does it make sense that SPFAuthResultType element counts are allowed to be unbounded? > I would think that it should be a maximum of 2, and then only if the scope is indicated (helo/mfrom) > > from https://tools.ietf.org/html/rfc7489 > > > > > minOccurs="0" maxOccurs="unbounded"/> > > maxOccurs="unbounded"/> > > > > > > Makes sense, does it matter? > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --001a114111a492e078052e2d7254 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The question then is - how does a report receiver interpre= t the multiple SPF results? A row has only a single auth message count; if = there are three SPF rows, then which SPF result goes with how many messages= ? It's ambiguous (not to mention hard to render to an end user).
If an IP has multiple auth result combinations, shouldn't = it have one row per combination so that the report receiver can get an accu= rate idea of how many instances of each combination are being reported?

--
Les Barstow

On Wed, Mar 16, 2016 at 8:27 AM, E= lizabeth Zwicky <zwicky@otoh.org> wrote:

Rows are defined by IP;= if the same IP uses multiple MAILFROM and SPF is bounded what is the repor= ter supposed to do? Duplicate rows?=C2=A0

Limiting= SPF changes the row key in bad ways. (Unless all senders are well-behaved = in ways they are not required to be.)


On Mar = 15, 2016, at 4:10 PM, Franck Martin <franck@peachymango.org> wrote:



=


From: "Tomki" <dmarcietf@tomki.com>
= To: "dmarc" <dmarc@ietf.org>
Sent: Tuesday, March 15, 2016 = 3:27:15 PM
Subject: [dmarc-ietf] SPFAuthResultType unbounded
<= div>
Does it make sense that SPFAuthResultType element counts=
 are allowed to be unbounded?
I would think that it should be a maximum of 2, and then only if the scope =
is indicated (helo/mfrom)

from http=
s://tools.ietf.org/html/rfc7489

   <xs:complexType name=3D"AuthResultType">
     <xs:sequence>
       <!-- There may be no DKIM signatures, or multiple DKIM
            signatures. -->
       <xs:element name=3D"dkim" type=3D"DKIMAuthResultTy=
pe"
         minOccurs=3D"0" maxOccurs=3D"unbounded"/>
       <!-- There will always be at least one SPF result. -->
       <xs:element name=3D"spf" type=3D"SPFAuthResultType=
" minOccurs=3D"1"
                   maxOccurs=3D"unbounded"/>
     </xs:sequence>
   </xs:complexType>

Makes sense, does it matter?
__________= _____________________________________
dmarc mailing list
dmarc@iet= f.org
https://www.ietf.org/mailman/listinfo/dmarc

______________________________________= _________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc


--001a114111a492e078052e2d7254-- From nobody Wed Mar 16 10:09:38 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0CA512D9E2 for ; Wed, 16 Mar 2016 10:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=peachymango.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6s5KJQvKsb2V for ; Wed, 16 Mar 2016 10:09:31 -0700 (PDT) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id 2083312D518 for ; Wed, 16 Mar 2016 10:09:31 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id AC8EC563DB9; Wed, 16 Mar 2016 12:09:30 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id A2DFD602D5; Wed, 16 Mar 2016 12:09:30 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NL3eoVJQ1GzM; Wed, 16 Mar 2016 12:09:30 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 73AE0602DF; Wed, 16 Mar 2016 12:09:30 -0500 (CDT) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-2.01.com 73AE0602DF DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1458148170; bh=ZpWhOSu61XVVW1mun0dry2MUG9A6+9LH2uG+Q90Fvow=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; b=ZScmhQ6+FcHzAPkFpw+JN6dUBWtG3YSnpzyH+aGsdv7C9Qq63v+q7PnJw3KA7A4ZM +2CXRkyowYCUXWWdbm+Tl3pnXE+J5yf3iwiFk5zmPsfetToGVtoyJOkT43VbtFELud lWGeJzMk4ciwhNBp+Bby09+AroFZ1w8BeAbfwcVs= Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 5CE7D602D9; Wed, 16 Mar 2016 12:09:30 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id eVvN1dtlm9KI; Wed, 16 Mar 2016 12:09:30 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-2.01.com (Postfix) with ESMTP id 08EA7602D5; Wed, 16 Mar 2016 12:09:30 -0500 (CDT) Date: Wed, 16 Mar 2016 12:09:29 -0500 (CDT) From: Franck Martin To: Elizabeth Zwicky Message-ID: <1390759948.32865.1458148169461.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <56E88C43.2050806@tomki.com> <2039296774.26888.1458083423836.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_32864_1129214241.1458148169460" X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF44 (Mac)/8.0.5_GA_5839) Thread-Topic: SPFAuthResultType unbounded Thread-Index: 2NbRtX41FtKxHr20StTCZGgkT9m1Hw== Archived-At: Cc: dmarc , dmarcietf@tomki.com Subject: Re: [dmarc-ietf] SPFAuthResultType unbounded X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 17:09:35 -0000 ------=_Part_32864_1129214241.1458148169460 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit ----- Original Message ----- > From: "Elizabeth Zwicky" > To: "Franck Martin" > Cc: "dmarc" , dmarcietf@tomki.com > Sent: Wednesday, March 16, 2016 7:27:04 AM > Subject: Re: [dmarc-ietf] SPFAuthResultType unbounded > Rows are defined by IP; if the same IP uses multiple MAILFROM and SPF is > bounded what is the reporter supposed to do? Duplicate rows? > Limiting SPF changes the row key in bad ways. (Unless all senders are > well-behaved in ways they are not required to be.) > Elizabeth Are you saying for the same (IP, RFC5322.From domain) tuple you have several RFC5321.Helo and RFC5321.MailFrom domains? It seems to me, if for the same tuple you have different DKIM d= with different results (pass,fail) you do create a row for each case. So same for SPF.... The record key is certainly multidimensional and not by IP alone. ------=_Part_32864_1129214241.1458148169460 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable




<= hr id=3D"zwchr">
= From: "Elizabeth Zwicky" <zwicky@otoh.org>
To: "Fran= ck Martin" <franck@peachymango.org>
Cc: "dmarc" <dmarc@i= etf.org>, dmarcietf@tomki.com
Sent: Wednesday, March 16, 2016 = 7:27:04 AM
Subject: Re: [dmarc-ietf] SPFAuthResultType unbounded<= br>


Rows are de= fined by IP; if the same IP uses multiple MAILFROM and SPF is bounded what = is the reporter supposed to do? Duplicate rows? 

Limiting SPF change= s the row key in bad ways. (Unless all senders are well-behaved in ways the= y are not required to be.)

Elizabeth

Are you saying for the same (IP, RFC5322.From domain) tuple you have = several RFC5321.Helo and RFC5321.MailFrom domains?

=
It seems to me, if for the same tuple you have different DKIM d=3D wit= h different results (pass,fail) you do create a row for each case. So same = for SPF....

The record key is certainly multid= imensional and not by IP alone.

------=_Part_32864_1129214241.1458148169460-- From nobody Wed Mar 16 10:38:49 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73F2612D748 for ; Wed, 16 Mar 2016 10:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=returnpath.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 JbCcIVeusHGq for ; Wed, 16 Mar 2016 10:38:44 -0700 (PDT) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94D5D12DA4F for ; Wed, 16 Mar 2016 10:38:18 -0700 (PDT) Received: by mail-lb0-x230.google.com with SMTP id x1so52539288lbj.3 for ; Wed, 16 Mar 2016 10:38:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=returnpath.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=lsSC6fomhemn5yZYn1Xi0s510kk82Uw4GlrpIksMnC0=; b=UOasbCFdpUMVTvZJSqLI8685S0elzelcGFP/OCuWIyC6DceLoalla9uar1jG2nzrdQ vh42ObCmgJMmdxV+mW9Wz6Arc2fdstNvlICcEbZjaxW9AdQxpgketWLJd8JHyuhkJMBG bTJPMYitVs01ikaMCRQCAzVXm19pOcVsIclzU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=lsSC6fomhemn5yZYn1Xi0s510kk82Uw4GlrpIksMnC0=; b=LWLY4Ls5lWQsW8KY/tWpi0YlgRuISRyBCDPmRJf4rZdSMnDFyykjMtCVhFPsmg8O3F 7VdSLJjrrAxacYPoti5s7CMoB/6fVgu+kgWFNRpln3+lWSrLDDx0/fVCqFnLn57bxSrc Nmwelfte5eHdd9XRJXqihj3qQMISmaA/oRY6kmmPRS5Ode1DikI/RH1TMiYwC0xbf8k9 HVsRjNthGh/sU3mB4LlHATN0qel3ciNMJ02flRxIWewd503L1smeOI/fu2c3mEzn9LCZ OXGAOfR7jseo/OUEBLWkO1VkE2OspIhUHfT8/SIUN+WatZnuIZ6HgYLU5bUcCQdUgL5T kZ6g== X-Gm-Message-State: AD7BkJKvSoe8QgK2ogdUEkuT++yk+FTMzlLiV/C0LcZ1Ey4Vjzv/WY0m9gBB/IP/7FvUmqimwYBYB+lFNxYcQToGKeWev34Uyil9I1+t/JmjfKxNV4klfuaBNkLTyp3Q+z9jsPCpPKbSuoWu7+vf96ZOjP1FNG13WPrKTCzboJFzsGqjUs/OPP2jvuzwnMZaBR+rpYyWQ48Fm/8p+vCdb6os/4x2iWKbrHQ8l1H7JoqNegTcBimOTkoWd6h9FacgPBp4+Mazd1B4R8U= MIME-Version: 1.0 X-Received: by 10.112.156.6 with SMTP id wa6mr1937928lbb.66.1458149895563; Wed, 16 Mar 2016 10:38:15 -0700 (PDT) Received: by 10.114.57.170 with HTTP; Wed, 16 Mar 2016 10:38:15 -0700 (PDT) In-Reply-To: <1390759948.32865.1458148169461.JavaMail.zimbra@peachymango.org> References: <56E88C43.2050806@tomki.com> <2039296774.26888.1458083423836.JavaMail.zimbra@peachymango.org> <1390759948.32865.1458148169461.JavaMail.zimbra@peachymango.org> Date: Wed, 16 Mar 2016 11:38:15 -0600 Message-ID: From: Les Barstow To: Franck Martin Content-Type: multipart/alternative; boundary=089e01161bf48e0bc1052e2dfa46 Archived-At: Cc: dmarc , Elizabeth Zwicky , dmarcietf@tomki.com Subject: Re: [dmarc-ietf] SPFAuthResultType unbounded X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 17:38:48 -0000 --089e01161bf48e0bc1052e2dfa46 Content-Type: text/plain; charset=UTF-8 To answer the first - we certainly receive reports from some providers containing multiple SPF results within the same row. It makes things "difficult"; without scope, there's no correct way to interpret the row. But if you report one and only one of each scope (helo and mfrom), then the normal SPF authentication rules apply - mfrom rules over helo when present. With DKIM, a row could conceivably be accurate while containing multiple DKIM results with different d= values if all of the messages were signed with the same multiple DKIM signing keys. -- Les Barstow On Wed, Mar 16, 2016 at 11:09 AM, Franck Martin wrote: > > > > > ------------------------------ > > *From: *"Elizabeth Zwicky" > *To: *"Franck Martin" > *Cc: *"dmarc" , dmarcietf@tomki.com > *Sent: *Wednesday, March 16, 2016 7:27:04 AM > *Subject: *Re: [dmarc-ietf] SPFAuthResultType unbounded > > > Rows are defined by IP; if the same IP uses multiple MAILFROM and SPF is > bounded what is the reporter supposed to do? Duplicate rows? > > Limiting SPF changes the row key in bad ways. (Unless all senders are > well-behaved in ways they are not required to be.) > > Elizabeth > > Are you saying for the same (IP, RFC5322.From domain) tuple you have > several RFC5321.Helo and RFC5321.MailFrom domains? > > It seems to me, if for the same tuple you have different DKIM d= with > different results (pass,fail) you do create a row for each case. So same > for SPF.... > > The record key is certainly multidimensional and not by IP alone. > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --089e01161bf48e0bc1052e2dfa46 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
To answer the first - we certainly receive reports fr= om some providers containing multiple SPF results within the same row. It m= akes things "difficult"; without scope, there's no correct wa= y to interpret the row. But if you report one and only one of each scope (h= elo and mfrom), then the normal SPF authentication rules apply - mfrom rule= s over helo when present.

With DKIM, a row could c= onceivably be accurate while containing multiple DKIM results with differen= t d=3D values if all of the messages were signed with the same multiple DKI= M signing keys.

--
Les Barstow
=

On Wed, Mar= 16, 2016 at 11:09 AM, Franck Martin <franck@peachymango.org><= /span> wrote:




From: "Elizabeth Zwicky" <zwicky@otoh.org>
To: "Franck Martin" <franck@peachymango.org>
Cc: "= dmarc" <dmarc@i= etf.org>, d= marcietf@tomki.com
Sent: Wednesday, March 16, 2016 7:27:04 AM=
Subject: Re: [dmarc-ietf] SPFAuthResultType unbounded


Rows are defined by IP; if the= same IP uses multiple MAILFROM and SPF is bounded what is the reporter sup= posed to do? Duplicate rows?=C2=A0

Limiting SPF ch= anges the row key in bad ways. (Unless all senders are well-behaved in ways= they are not required to be.)

Elizabeth
<= br>
Are you saying for the same (IP, RF= C5322.From domain) tuple you have several RFC5321.Helo and RFC5321.MailFrom= domains?

It seems to me, if for the same tupl= e you have different DKIM d=3D with different results (pass,fail) you do cr= eate a row for each case. So same for SPF....

= The record key is certainly multidimensional and not by IP alone.
=

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


--089e01161bf48e0bc1052e2dfa46-- From nobody Wed Mar 16 11:14:14 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A81512D65C for ; Wed, 16 Mar 2016 11:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 WUR8fzp09E4Q for ; Wed, 16 Mar 2016 11:14:07 -0700 (PDT) Received: from mailscan.turtlesys.net (mailscan.turtlesys.net [IPv6:2001:470:4a:7:241f:acff:fe66:5236]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF87112DA10 for ; Wed, 16 Mar 2016 11:14:07 -0700 (PDT) Received: from www01.turtlesys.net (www01.turtlesys.net [207.135.97.24]) by mailscan.turtlesys.net (Postfix) with ESMTPS id B20742244D88 for ; Wed, 16 Mar 2016 14:13:00 -0400 (EDT) Received: from 71-6-26-18.static-ip.telepacific.net ([71.6.26.18]:55688 helo=silverado.co.agari.com) by www01.turtlesys.net with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.86_1) (envelope-from ) id 1agFxA-0004dF-Ou; Wed, 16 Mar 2016 11:13:52 -0700 References: <56E88C43.2050806@tomki.com> <2039296774.26888.1458083423836.JavaMail.zimbra@peachymango.org> To: Les Barstow , Elizabeth Zwicky From: Tomki Message-ID: <56E9A25C.2080607@tomki.com> Date: Wed, 16 Mar 2016 11:13:48 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------030102070103030903090801" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - www01.turtlesys.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tomki.com X-Get-Message-Sender-Via: www01.turtlesys.net: authenticated_id: tki@tomki.com X-Authenticated-Sender: www01.turtlesys.net: tki@tomki.com X-tsmailscan01-MailScanner-Information: Please contact the ISP for more information X-tsmailscan01-MailScanner-ID: B20742244D88.ACD7C X-tsmailscan01-MailScanner: Found to be clean X-tsmailscan01-MailScanner-From: dmarcietf@tomki.com Archived-At: Cc: dmarc , Franck Martin Subject: Re: [dmarc-ietf] SPFAuthResultType unbounded X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dmarcietf@tomki.com 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, 16 Mar 2016 18:14:12 -0000 This is a multi-part message in MIME format. --------------030102070103030903090801 Content-Type: multipart/alternative; boundary="------------090009040207090903090402" --------------090009040207090903090402 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Les: right, I think you've seen the same problem I am describing. Elizabeth: this is a problem that I have not identified at more than one provider, and don't worry you're not it. For a concrete example, please see the attached XML record object. There are 1834 messages reported in this object by 'count', but 312 SPF items reported. I guess if these were all either pass or failure cases, and the counts lined up I could disambiguate properly, but as it stands I don't think it's comprehensible. -- Tomki On 3/16/16 10:00, Les Barstow wrote: > The question then is - how does a report receiver interpret the > multiple SPF results? A row has only a single auth message count; if > there are three SPF rows, then which SPF result goes with how many > messages? It's ambiguous (not to mention hard to render to an end user). > > If an IP has multiple auth result combinations, shouldn't it have one > row per combination so that the report receiver can get an accurate > idea of how many instances of each combination are being reported? > > -- > Les Barstow > > On Wed, Mar 16, 2016 at 8:27 AM, Elizabeth Zwicky > wrote: > > > Rows are defined by IP; if the same IP uses multiple MAILFROM and > SPF is bounded what is the reporter supposed to do? Duplicate rows? > > Limiting SPF changes the row key in bad ways. (Unless all senders > are well-behaved in ways they are not required to be.) > > Elizabeth > > Zwicky@otoh.org > > On Mar 15, 2016, at 4:10 PM, Franck Martin > wrote: > >> >> >> >> >> >> ------------------------------------------------------------------------ >> >> *From: *"Tomki" > > >> *To: *"dmarc" > >> *Sent: *Tuesday, March 15, 2016 3:27:15 PM >> *Subject: *[dmarc-ietf] SPFAuthResultType unbounded >> >> Does it make sense that SPFAuthResultType element counts are allowed to be unbounded? >> I would think that it should be a maximum of 2, and then only if the scope is indicated (helo/mfrom) >> >> fromhttps://tools.ietf.org/html/rfc7489 >> >> >> >> >> > minOccurs="0" maxOccurs="unbounded"/> >> >> > maxOccurs="unbounded"/> >> >> >> >> >> Makes sense, does it matter? >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --------------090009040207090903090402 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Les: right, I think you've seen the same problem I am describing.

Elizabeth: this is a problem that I have not identified at more than one provider, and don't worry you're not it.

For a concrete example, please see the attached XML record object.
There are 1834 messages reported in this object by 'count', but 312 SPF items reported.  I guess if these were all either pass or failure cases, and the counts lined up I could disambiguate properly, but as it stands I don't think it's comprehensible.

--
Tomki


On 3/16/16 10:00, Les Barstow wrote:
The question then is - how does a report receiver interpret the multiple SPF results? A row has only a single auth message count; if there are three SPF rows, then which SPF result goes with how many messages? It's ambiguous (not to mention hard to render to an end user).

If an IP has multiple auth result combinations, shouldn't it have one row per combination so that the report receiver can get an accurate idea of how many instances of each combination are being reported?

--
Les Barstow

On Wed, Mar 16, 2016 at 8:27 AM, Elizabeth Zwicky <zwicky@otoh.org> wrote:

Rows are defined by IP; if the same IP uses multiple MAILFROM and SPF is bounded what is the reporter supposed to do? Duplicate rows? 

Limiting SPF changes the row key in bad ways. (Unless all senders are well-behaved in ways they are not required to be.)

Elizabeth


On Mar 15, 2016, at 4:10 PM, Franck Martin <franck@peachymango.org> wrote:






From: "Tomki" <dmarcietf@tomki.com>
To: "dmarc" <dmarc@ietf.org>
Sent: Tuesday, March 15, 2016 3:27:15 PM
Subject: [dmarc-ietf] SPFAuthResultType unbounded

Does it make sense that SPFAuthResultType element counts are allowed to be unbounded?
I would think that it should be a maximum of 2, and then only if the scope is indicated (helo/mfrom)

from https://tools.ietf.org/html/rfc7489

   <xs:complexType name="AuthResultType">
     <xs:sequence>
       <!-- There may be no DKIM signatures, or multiple DKIM
            signatures. -->
       <xs:element name="dkim" type="DKIMAuthResultType"
         minOccurs="0" maxOccurs="unbounded"/>
       <!-- There will always be at least one SPF result. -->
       <xs:element name="spf" type="SPFAuthResultType" minOccurs="1"
                   maxOccurs="unbounded"/>
     </xs:sequence>
   </xs:complexType>

Makes sense, does it matter?
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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




--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. --------------090009040207090903090402-- --------------030102070103030903090801 Content-Type: text/plain; charset=UTF-8; name="toomuchSPF.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="toomuchSPF.txt" ICA8cmVjb3JkPgogICAgPHJvdz4KICAgICAgPHNvdXJjZV9pcD4xODQuMTY4 LjIwMC4xMzg8L3NvdXJjZV9pcD4KICAgICAgPGNvdW50PjE4MzQ8L2NvdW50 PgogICAgICA8cG9saWN5X2V2YWx1YXRlZD4KICAgICAgICA8ZGlzcG9zaXRp b24+bm9uZTwvZGlzcG9zaXRpb24+CiAgICAgICAgPGRraW0+ZmFpbDwvZGtp bT4KICAgICAgICA8c3BmPmZhaWw8L3NwZj4KICAgICAgPC9wb2xpY3lfZXZh bHVhdGVkPgogICAgPC9yb3c+CiAgICA8aWRlbnRpZmllcnM+CiAgICAgIDxo ZWFkZXJfZnJvbT50b21raS5jb208L2hlYWRlcl9mcm9tPgogICAgPC9pZGVu dGlmaWVycz4KICAgIDxhdXRoX3Jlc3VsdHM+CiAgICAgIDxzcGY+CiAgICAg ICAgPGRvbWFpbj5hYnZpbzMuY29tPC9kb21haW4+CiAgICAgICAgPHJlc3Vs dD5ub25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAgICA8c3BmPgogICAg ICAgIDxkb21haW4+YWRoZXNpdm9jb211bmljYWNpb24uY29tPC9kb21haW4+ CiAgICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgog ICAgICA8c3BmPgogICAgICAgIDxkb21haW4+YWtkbi5vcmc8L2RvbWFpbj4K ICAgICAgICA8cmVzdWx0Pm5vbmU8L3Jlc3VsdD4KICAgICAgPC9zcGY+CiAg ICAgIDxzcGY+CiAgICAgICAgPGRvbWFpbj5hbWVyaWNhbm9hc2lzLmJpejwv ZG9tYWluPgogICAgICAgIDxyZXN1bHQ+bm9uZTwvcmVzdWx0PgogICAgICA8 L3NwZj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9tYWluPmFyaXphZ2FkZC5j b208L2RvbWFpbj4KICAgICAgICA8cmVzdWx0Pm5vbmU8L3Jlc3VsdD4KICAg ICAgPC9zcGY+CiAgICAgIDxzcGY+CiAgICAgICAgPGRvbWFpbj5iaWdici5j b20uYnI8L2RvbWFpbj4KICAgICAgICA8cmVzdWx0Pm5vbmU8L3Jlc3VsdD4K ICAgICAgPC9zcGY+CiAgICAgIDxzcGY+CiAgICAgICAgPGRvbWFpbj5ibG9n bWtpaXdhdGNoZXMuY29tPC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5ub25l PC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAgIDxk b21haW4+Ym91bmNlLnNlY3VyZXNlcnZlci5uZXQ8L2RvbWFpbj4KICAgICAg ICA8cmVzdWx0PnBhc3M8L3Jlc3VsdD4KICAgICAgPC9zcGY+CiAgICAgIDxz cGY+CiAgICAgICAgPGRvbWFpbj5ib3VuY2VzLmdlbS5nb2RhZGR5LmNvbTwv ZG9tYWluPgogICAgICAgIDxyZXN1bHQ+bm9uZTwvcmVzdWx0PgogICAgICA8 L3NwZj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9tYWluPmNhbnlvbnZpZXdh aC5jb208L2RvbWFpbj4KICAgICAgICA8cmVzdWx0Pm5vbmU8L3Jlc3VsdD4K ICAgICAgPC9zcGY+CiAgICAgIDxzcGY+CiAgICAgICAgPGRvbWFpbj5jZXNi YS1xdWVyZXRhcm8uZWR1Lm14PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5w YXNzPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAg IDxkb21haW4+Y2lwcHN2b25saW5lLmNvbTwvZG9tYWluPgogICAgICAgIDxy ZXN1bHQ+bm9uZTwvcmVzdWx0PgogICAgICA8L3NwZj4KICAgICAgPHNwZj4K ICAgICAgICA8ZG9tYWluPmNtYWlsMjAuY29tPC9kb21haW4+CiAgICAgICAg PHJlc3VsdD5mYWlsPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAgICA8c3Bm PgogICAgICAgIDxkb21haW4+Y3Jvc3NjcmVhdGl2ZWNsb3VkLmNvbTwvZG9t YWluPgogICAgICAgIDxyZXN1bHQ+ZmFpbDwvcmVzdWx0PgogICAgICA8L3Nw Zj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9tYWluPmN1YmljdWxvLm5ldDwv ZG9tYWluPgogICAgICAgIDxyZXN1bHQ+bm9uZTwvcmVzdWx0PgogICAgICA8 L3NwZj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9tYWluPmRiMy5uZXQ8L2Rv bWFpbj4KICAgICAgICA8cmVzdWx0PmZhaWw8L3Jlc3VsdD4KICAgICAgPC9z cGY+CiAgICAgIDxzcGY+CiAgICAgICAgPGRvbWFpbj5kZWFuYW5kZHVubmxs Yy5jb208L2RvbWFpbj4KICAgICAgICA8cmVzdWx0Pm5vbmU8L3Jlc3VsdD4K ICAgICAgPC9zcGY+CiAgICAgIDxzcGY+CiAgICAgICAgPGRvbWFpbj5kaWVn ei5uZXQ8L2RvbWFpbj4KICAgICAgICA8cmVzdWx0PmZhaWw8L3Jlc3VsdD4K ICAgICAgPC9zcGY+CiAgICAgIDxzcGY+CiAgICAgICAgPGRvbWFpbj5kcmFn b25wcmltZS5uZXQ8L2RvbWFpbj4KICAgICAgICA8cmVzdWx0Pm5vbmU8L3Jl c3VsdD4KICAgICAgPC9zcGY+CiAgICAgIDxzcGY+CiAgICAgICAgPGRvbWFp bj5lbGlzdGFzLm5ldDwvZG9tYWluPgogICAgICAgIDxyZXN1bHQ+bm9uZTwv cmVzdWx0PgogICAgICA8L3NwZj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9t YWluPmV1Z2VuZWhvc3RlbHMuY29tPC9kb21haW4+CiAgICAgICAgPHJlc3Vs dD5ub25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAgICA8c3BmPgogICAg ICAgIDxkb21haW4+Zm9yZXBzeS5pdDwvZG9tYWluPgogICAgICAgIDxyZXN1 bHQ+dGVtcGVycm9yPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAgICA8c3Bm PgogICAgICAgIDxkb21haW4+Z2VhcmVkZm9yZnVuLmNvbTwvZG9tYWluPgog ICAgICAgIDxyZXN1bHQ+bm9uZTwvcmVzdWx0PgogICAgICA8L3NwZj4KICAg ICAgPHNwZj4KICAgICAgICA8ZG9tYWluPmdtYWlsLmNvbTwvZG9tYWluPgog ICAgICAgIDxyZXN1bHQ+ZmFpbDwvcmVzdWx0PgogICAgICA8L3NwZj4KICAg ICAgPHNwZj4KICAgICAgICA8ZG9tYWluPmdvb2dsZWdyb3Vwcy5jb208L2Rv bWFpbj4KICAgICAgICA8cmVzdWx0PmZhaWw8L3Jlc3VsdD4KICAgICAgPC9z cGY+CiAgICAgIDxzcGY+CiAgICAgICAgPGRvbWFpbj5ncnVwb2RvbmFuYS5j b208L2RvbWFpbj4KICAgICAgICA8cmVzdWx0Pm5vbmU8L3Jlc3VsdD4KICAg ICAgPC9zcGY+CiAgICAgIDxzcGY+CiAgICAgICAgPGRvbWFpbj5ncy5zb2dv aGFpci5jb20uYXU8L2RvbWFpbj4KICAgICAgICA8cmVzdWx0Pm5vbmU8L3Jl c3VsdD4KICAgICAgPC9zcGY+CiAgICAgIDxzcGY+CiAgICAgICAgPGRvbWFp bj5ncy13ZWVxdWFoaWNhbHVtbmkub3JnPC9kb21haW4+CiAgICAgICAgPHJl c3VsdD5ub25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAgICA8c3BmPgog ICAgICAgIDxkb21haW4+aWNwYm91bmNlLmNvbTwvZG9tYWluPgogICAgICAg IDxyZXN1bHQ+ZmFpbDwvcmVzdWx0PgogICAgICA8L3NwZj4KICAgICAgPHNw Zj4KICAgICAgICA8ZG9tYWluPmltcG9zc2libGVzb3VsLm5ldDwvZG9tYWlu PgogICAgICAgIDxyZXN1bHQ+bm9uZTwvcmVzdWx0PgogICAgICA8L3NwZj4K ICAgICAgPHNwZj4KICAgICAgICA8ZG9tYWluPmluLmNvbnN0YW50Y29udGFj dC5jb208L2RvbWFpbj4KICAgICAgICA8cmVzdWx0PmZhaWw8L3Jlc3VsdD4K ICAgICAgPC9zcGY+CiAgICAgIDxzcGY+CiAgICAgICAgPGRvbWFpbj5pbjAw Lm0xZS5uZXQ8L2RvbWFpbj4KICAgICAgICA8cmVzdWx0PmZhaWw8L3Jlc3Vs dD4KICAgICAgPC9zcGY+CiAgICAgIDxzcGY+CiAgICAgICAgPGRvbWFpbj5p bmZ1c2lvbm1haWwuY29tPC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5mYWls PC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAgIDxk b21haW4+aXRlamFwb24ub3JnPC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5w YXNzPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAg IDxkb21haW4+amFtZXMtZGljay5jb208L2RvbWFpbj4KICAgICAgICA8cmVz dWx0Pm5vbmU8L3Jlc3VsdD4KICAgICAgPC9zcGY+CiAgICAgIDxzcGY+CiAg ICAgICAgPGRvbWFpbj5qbmFjay5jb208L2RvbWFpbj4KICAgICAgICA8cmVz dWx0Pm5vbmU8L3Jlc3VsdD4KICAgICAgPC9zcGY+CiAgICAgIDxzcGY+CiAg ICAgICAgPGRvbWFpbj5rYW50dGkuaGVsc2lua2kuZmk8L2RvbWFpbj4KICAg ICAgICA8cmVzdWx0Pm5ldXRyYWw8L3Jlc3VsdD4KICAgICAgPC9zcGY+CiAg ICAgIDxzcGY+CiAgICAgICAgPGRvbWFpbj5rZXZpbmFuZHJpdGEuY29tPC9k b21haW4+CiAgICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAgICAgIDwv c3BmPgogICAgICA8c3BmPgogICAgICAgIDxkb21haW4+bGFmLWRlc2lnbi5j b208L2RvbWFpbj4KICAgICAgICA8cmVzdWx0PmZhaWw8L3Jlc3VsdD4KICAg ICAgPC9zcGY+CiAgICAgIDxzcGY+CiAgICAgICAgPGRvbWFpbj5sYXZuZXR3 b3Jrcy5jb208L2RvbWFpbj4KICAgICAgICA8cmVzdWx0Pm5vbmU8L3Jlc3Vs dD4KICAgICAgPC9zcGY+CiAgICAgIDxzcGY+CiAgICAgICAgPGRvbWFpbj5s aXN0cy5zb2NpYWxpbm5vdmF0aW9uLmNhPC9kb21haW4+CiAgICAgICAgPHJl c3VsdD5mYWlsPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAgICA8c3BmPgog ICAgICAgIDxkb21haW4+bG9wZXpvbmdheS5jb208L2RvbWFpbj4KICAgICAg ICA8cmVzdWx0Pm5vbmU8L3Jlc3VsdD4KICAgICAgPC9zcGY+CiAgICAgIDxz cGY+CiAgICAgICAgPGRvbWFpbj5tYWlsMTMuYXRsNzEubWNkbHYubmV0PC9k b21haW4+CiAgICAgICAgPHJlc3VsdD5uZXV0cmFsPC9yZXN1bHQ+CiAgICAg IDwvc3BmPgogICAgICA8c3BmPgogICAgICAgIDxkb21haW4+bWFpbDE0Ny5z dXcxNC5tY2Rsdi5uZXQ8L2RvbWFpbj4KICAgICAgICA8cmVzdWx0Pm5ldXRy YWw8L3Jlc3VsdD4KICAgICAgPC9zcGY+CiAgICAgIDxzcGY+CiAgICAgICAg PGRvbWFpbj5tYWlsMTg3LndkYzAyLm1jZGx2Lm5ldDwvZG9tYWluPgogICAg ICAgIDxyZXN1bHQ+bmV1dHJhbDwvcmVzdWx0PgogICAgICA8L3NwZj4KICAg ICAgPHNwZj4KICAgICAgICA8ZG9tYWluPm1haWwyMTEuYXRsODEucnNnc3Yu bmV0PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5uZXV0cmFsPC9yZXN1bHQ+ CiAgICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAgIDxkb21haW4+bWFp bDIxOC5hdGwxMjEubWNzdi5uZXQ8L2RvbWFpbj4KICAgICAgICA8cmVzdWx0 Pm5ldXRyYWw8L3Jlc3VsdD4KICAgICAgPC9zcGY+CiAgICAgIDxzcGY+CiAg ICAgICAgPGRvbWFpbj5tYWlsNTguYXRsNzEubWNkbHYubmV0PC9kb21haW4+ CiAgICAgICAgPHJlc3VsdD5uZXV0cmFsPC9yZXN1bHQ+CiAgICAgIDwvc3Bm PgogICAgICA8c3BmPgogICAgICAgIDxkb21haW4+bWFpbDY1LmF0bDExLnJz Z3N2Lm5ldDwvZG9tYWluPgogICAgICAgIDxyZXN1bHQ+bmV1dHJhbDwvcmVz dWx0PgogICAgICA8L3NwZj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9tYWlu Pm1haWw2OS5hdGw5MS5tY3N2Lm5ldDwvZG9tYWluPgogICAgICAgIDxyZXN1 bHQ+bmV1dHJhbDwvcmVzdWx0PgogICAgICA8L3NwZj4KICAgICAgPHNwZj4K ICAgICAgICA8ZG9tYWluPm1haWw4OS5zdXcxNy5tY3N2Lm5ldDwvZG9tYWlu PgogICAgICAgIDxyZXN1bHQ+bmV1dHJhbDwvcmVzdWx0PgogICAgICA8L3Nw Zj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9tYWluPm1pY2hlbGxlYmVhdG9u LmNvbTwvZG9tYWluPgogICAgICAgIDxyZXN1bHQ+bm9uZTwvcmVzdWx0Pgog ICAgICA8L3NwZj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9tYWluPm1sc2Vu ZDIuY29tPC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5mYWlsPC9yZXN1bHQ+ CiAgICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAgIDxkb21haW4+bW9u c3Rlci5jby5pbjwvZG9tYWluPgogICAgICAgIDxyZXN1bHQ+ZmFpbDwvcmVz dWx0PgogICAgICA8L3NwZj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9tYWlu Pm1vcmVsaWF0cmF2ZWwuY29tPC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5u b25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAg IDxkb21haW4+bXljb3VudHJ5c2lkZXZpbGxhZ2UuY2E8L2RvbWFpbj4KICAg ICAgICA8cmVzdWx0PnBhc3M8L3Jlc3VsdD4KICAgICAgPC9zcGY+CiAgICAg IDxzcGY+CiAgICAgICAgPGRvbWFpbj5vbW5pdmVyc2VtdXNpYy5jb208L2Rv bWFpbj4KICAgICAgICA8cmVzdWx0Pm5vbmU8L3Jlc3VsdD4KICAgICAgPC9z cGY+CiAgICAgIDxzcGY+CiAgICAgICAgPGRvbWFpbj5vdXRib3VuZC1iLm1h aWwuaW50ZXJjb20uaW88L2RvbWFpbj4KICAgICAgICA8cmVzdWx0PmZhaWw8 L3Jlc3VsdD4KICAgICAgPC9zcGY+CiAgICAgIDxzcGY+CiAgICAgICAgPGRv bWFpbj5wM3BsY3BubDAwMzYucHJvZC5waHgzLnNlY3VyZXNlcnZlci5uZXQ8 L2RvbWFpbj4KICAgICAgICA8cmVzdWx0Pm5vbmU8L3Jlc3VsdD4KICAgICAg PC9zcGY+CiAgICAgIDxzcGY+CiAgICAgICAgPGRvbWFpbj5wM3BsY3BubDAw NDEucHJvZC5waHgzLnNlY3VyZXNlcnZlci5uZXQ8L2RvbWFpbj4KICAgICAg ICA8cmVzdWx0Pm5vbmU8L3Jlc3VsdD4KICAgICAgPC9zcGY+CiAgICAgIDxz cGY+CiAgICAgICAgPGRvbWFpbj5wM3BsY3BubDAwNTYucHJvZC5waHgzLnNl Y3VyZXNlcnZlci5uZXQ8L2RvbWFpbj4KICAgICAgICA8cmVzdWx0Pm5vbmU8 L3Jlc3VsdD4KICAgICAgPC9zcGY+CiAgICAgIDxzcGY+CiAgICAgICAgPGRv bWFpbj5wM3BsY3BubDAwNzEucHJvZC5waHgzLnNlY3VyZXNlcnZlci5uZXQ8 L2RvbWFpbj4KICAgICAgICA8cmVzdWx0Pm5vbmU8L3Jlc3VsdD4KICAgICAg PC9zcGY+CiAgICAgIDxzcGY+CiAgICAgICAgPGRvbWFpbj5wM3BsY3BubDAw NzUucHJvZC5waHgzLnNlY3VyZXNlcnZlci5uZXQ8L2RvbWFpbj4KICAgICAg ICA8cmVzdWx0Pm5vbmU8L3Jlc3VsdD4KICAgICAgPC9zcGY+CiAgICAgIDxz cGY+CiAgICAgICAgPGRvbWFpbj5wM3BsY3BubDAwNzkucHJvZC5waHgzLnNl Y3VyZXNlcnZlci5uZXQ8L2RvbWFpbj4KICAgICAgICA8cmVzdWx0Pm5vbmU8 L3Jlc3VsdD4KICAgICAgPC9zcGY+CiAgICAgIDxzcGY+CiAgICAgICAgPGRv bWFpbj5wM3BsY3BubDAwOTEucHJvZC5waHgzLnNlY3VyZXNlcnZlci5uZXQ8 L2RvbWFpbj4KICAgICAgICA8cmVzdWx0Pm5vbmU8L3Jlc3VsdD4KICAgICAg PC9zcGY+CiAgICAgIDxzcGY+CiAgICAgICAgPGRvbWFpbj5wM3BsY3BubDAw OTMucHJvZC5waHgzLnNlY3VyZXNlcnZlci5uZXQ8L2RvbWFpbj4KICAgICAg ICA8cmVzdWx0Pm5vbmU8L3Jlc3VsdD4KICAgICAgPC9zcGY+CiAgICAgIDxz cGY+CiAgICAgICAgPGRvbWFpbj5wM3BsY3BubDAxMDIucHJvZC5waHgzLnNl Y3VyZXNlcnZlci5uZXQ8L2RvbWFpbj4KICAgICAgICA8cmVzdWx0Pm5vbmU8 L3Jlc3VsdD4KICAgICAgPC9zcGY+CiAgICAgIDxzcGY+CiAgICAgICAgPGRv bWFpbj5wM3BsY3BubDAxMjEucHJvZC5waHgzLnNlY3VyZXNlcnZlci5uZXQ8 L2RvbWFpbj4KICAgICAgICA8cmVzdWx0Pm5vbmU8L3Jlc3VsdD4KICAgICAg PC9zcGY+CiAgICAgIDxzcGY+CiAgICAgICAgPGRvbWFpbj5wM3BsY3BubDAx MjIucHJvZC5waHgzLnNlY3VyZXNlcnZlci5uZXQ8L2RvbWFpbj4KICAgICAg ICA8cmVzdWx0Pm5vbmU8L3Jlc3VsdD4KICAgICAgPC9zcGY+CiAgICAgIDxz cGY+CiAgICAgICAgPGRvbWFpbj5wM3BsY3BubDAxMjgucHJvZC5waHgzLnNl Y3VyZXNlcnZlci5uZXQ8L2RvbWFpbj4KICAgICAgICA8cmVzdWx0Pm5vbmU8 L3Jlc3VsdD4KICAgICAgPC9zcGY+CiAgICAgIDxzcGY+CiAgICAgICAgPGRv bWFpbj5wM3BsY3BubDAxMzMucHJvZC5waHgzLnNlY3VyZXNlcnZlci5uZXQ8 L2RvbWFpbj4KICAgICAgICA8cmVzdWx0Pm5vbmU8L3Jlc3VsdD4KICAgICAg PC9zcGY+CiAgICAgIDxzcGY+CiAgICAgICAgPGRvbWFpbj5wM3BsY3BubDAx MzQucHJvZC5waHgzLnNlY3VyZXNlcnZlci5uZXQ8L2RvbWFpbj4KICAgICAg ICA8cmVzdWx0Pm5vbmU8L3Jlc3VsdD4KICAgICAgPC9zcGY+CiAgICAgIDxz cGY+CiAgICAgICAgPGRvbWFpbj5wM3BsY3BubDAxMzUucHJvZC5waHgzLnNl Y3VyZXNlcnZlci5uZXQ8L2RvbWFpbj4KICAgICAgICA8cmVzdWx0Pm5vbmU8 L3Jlc3VsdD4KICAgICAgPC9zcGY+CiAgICAgIDxzcGY+CiAgICAgICAgPGRv bWFpbj5wM3BsY3BubDAxMzgucHJvZC5waHgzLnNlY3VyZXNlcnZlci5uZXQ8 L2RvbWFpbj4KICAgICAgICA8cmVzdWx0Pm5vbmU8L3Jlc3VsdD4KICAgICAg PC9zcGY+CiAgICAgIDxzcGY+CiAgICAgICAgPGRvbWFpbj5wM3BsY3BubDAx NDEucHJvZC5waHgzLnNlY3VyZXNlcnZlci5uZXQ8L2RvbWFpbj4KICAgICAg ICA8cmVzdWx0Pm5vbmU8L3Jlc3VsdD4KICAgICAgPC9zcGY+CiAgICAgIDxz cGY+CiAgICAgICAgPGRvbWFpbj5wM3BsY3BubDAxNTAucHJvZC5waHgzLnNl Y3VyZXNlcnZlci5uZXQ8L2RvbWFpbj4KICAgICAgICA8cmVzdWx0Pm5vbmU8 L3Jlc3VsdD4KICAgICAgPC9zcGY+CiAgICAgIDxzcGY+CiAgICAgICAgPGRv bWFpbj5wM3BsY3BubDAxNTIucHJvZC5waHgzLnNlY3VyZXNlcnZlci5uZXQ8 L2RvbWFpbj4KICAgICAgICA8cmVzdWx0Pm5vbmU8L3Jlc3VsdD4KICAgICAg PC9zcGY+CiAgICAgIDxzcGY+CiAgICAgICAgPGRvbWFpbj5wM3BsY3BubDAx NTMucHJvZC5waHgzLnNlY3VyZXNlcnZlci5uZXQ8L2RvbWFpbj4KICAgICAg ICA8cmVzdWx0Pm5vbmU8L3Jlc3VsdD4KICAgICAgPC9zcGY+CiAgICAgIDxz cGY+CiAgICAgICAgPGRvbWFpbj5wM3BsY3BubDAxNTQucHJvZC5waHgzLnNl Y3VyZXNlcnZlci5uZXQ8L2RvbWFpbj4KICAgICAgICA8cmVzdWx0Pm5vbmU8 L3Jlc3VsdD4KICAgICAgPC9zcGY+CiAgICAgIDxzcGY+CiAgICAgICAgPGRv bWFpbj5wM3BsY3BubDAxNTkucHJvZC5waHgzLnNlY3VyZXNlcnZlci5uZXQ8 L2RvbWFpbj4KICAgICAgICA8cmVzdWx0Pm5vbmU8L3Jlc3VsdD4KICAgICAg PC9zcGY+CiAgICAgIDxzcGY+CiAgICAgICAgPGRvbWFpbj5wM3BsY3BubDAx NjIucHJvZC5waHgzLnNlY3VyZXNlcnZlci5uZXQ8L2RvbWFpbj4KICAgICAg ICA8cmVzdWx0Pm5vbmU8L3Jlc3VsdD4KICAgICAgPC9zcGY+CiAgICAgIDxz cGY+CiAgICAgICAgPGRvbWFpbj5wM3BsY3BubDAxNjQucHJvZC5waHgzLnNl Y3VyZXNlcnZlci5uZXQ8L2RvbWFpbj4KICAgICAgICA8cmVzdWx0Pm5vbmU8 L3Jlc3VsdD4KICAgICAgPC9zcGY+CiAgICAgIDxzcGY+CiAgICAgICAgPGRv bWFpbj5wM3BsY3BubDAxNjcucHJvZC5waHgzLnNlY3VyZXNlcnZlci5uZXQ8 L2RvbWFpbj4KICAgICAgICA8cmVzdWx0Pm5vbmU8L3Jlc3VsdD4KICAgICAg PC9zcGY+CiAgICAgIDxzcGY+CiAgICAgICAgPGRvbWFpbj5wM3BsY3BubDAx NzAucHJvZC5waHgzLnNlY3VyZXNlcnZlci5uZXQ8L2RvbWFpbj4KICAgICAg ICA8cmVzdWx0Pm5vbmU8L3Jlc3VsdD4KICAgICAgPC9zcGY+CiAgICAgIDxz cGY+CiAgICAgICAgPGRvbWFpbj5wM3BsY3BubDAxNzMucHJvZC5waHgzLnNl Y3VyZXNlcnZlci5uZXQ8L2RvbWFpbj4KICAgICAgICA8cmVzdWx0Pm5vbmU8 L3Jlc3VsdD4KICAgICAgPC9zcGY+CiAgICAgIDxzcGY+CiAgICAgICAgPGRv bWFpbj5wM3BsY3BubDAxNzUucHJvZC5waHgzLnNlY3VyZXNlcnZlci5uZXQ8 L2RvbWFpbj4KICAgICAgICA8cmVzdWx0Pm5vbmU8L3Jlc3VsdD4KICAgICAg PC9zcGY+CiAgICAgIDxzcGY+CiAgICAgICAgPGRvbWFpbj5wM3BsY3BubDAx NzgucHJvZC5waHgzLnNlY3VyZXNlcnZlci5uZXQ8L2RvbWFpbj4KICAgICAg ICA8cmVzdWx0Pm5vbmU8L3Jlc3VsdD4KICAgICAgPC9zcGY+CiAgICAgIDxz cGY+CiAgICAgICAgPGRvbWFpbj5wM3BsY3BubDAxODMucHJvZC5waHgzLnNl Y3VyZXNlcnZlci5uZXQ8L2RvbWFpbj4KICAgICAgICA8cmVzdWx0Pm5vbmU8 L3Jlc3VsdD4KICAgICAgPC9zcGY+CiAgICAgIDxzcGY+CiAgICAgICAgPGRv bWFpbj5wM3BsY3BubDAxODgucHJvZC5waHgzLnNlY3VyZXNlcnZlci5uZXQ8 L2RvbWFpbj4KICAgICAgICA8cmVzdWx0Pm5vbmU8L3Jlc3VsdD4KICAgICAg PC9zcGY+CiAgICAgIDxzcGY+CiAgICAgICAgPGRvbWFpbj5wM3BsY3BubDAx ODkucHJvZC5waHgzLnNlY3VyZXNlcnZlci5uZXQ8L2RvbWFpbj4KICAgICAg ICA8cmVzdWx0Pm5vbmU8L3Jlc3VsdD4KICAgICAgPC9zcGY+CiAgICAgIDxz cGY+CiAgICAgICAgPGRvbWFpbj5wM3BsY3BubDAxOTQucHJvZC5waHgzLnNl Y3VyZXNlcnZlci5uZXQ8L2RvbWFpbj4KICAgICAgICA8cmVzdWx0Pm5vbmU8 L3Jlc3VsdD4KICAgICAgPC9zcGY+CiAgICAgIDxzcGY+CiAgICAgICAgPGRv bWFpbj5wM3BsY3BubDAxOTUucHJvZC5waHgzLnNlY3VyZXNlcnZlci5uZXQ8 L2RvbWFpbj4KICAgICAgICA8cmVzdWx0Pm5vbmU8L3Jlc3VsdD4KICAgICAg PC9zcGY+CiAgICAgIDxzcGY+CiAgICAgICAgPGRvbWFpbj5wM3BsY3BubDAy MDEucHJvZC5waHgzLnNlY3VyZXNlcnZlci5uZXQ8L2RvbWFpbj4KICAgICAg ICA8cmVzdWx0Pm5vbmU8L3Jlc3VsdD4KICAgICAgPC9zcGY+CiAgICAgIDxz cGY+CiAgICAgICAgPGRvbWFpbj5wM3BsY3BubDAyMDIucHJvZC5waHgzLnNl Y3VyZXNlcnZlci5uZXQ8L2RvbWFpbj4KICAgICAgICA8cmVzdWx0Pm5vbmU8 L3Jlc3VsdD4KICAgICAgPC9zcGY+CiAgICAgIDxzcGY+CiAgICAgICAgPGRv bWFpbj5wM3BsY3BubDAyMS5wcm9kLnBoeDMuc2VjdXJlc2VydmVyLm5ldDwv ZG9tYWluPgogICAgICAgIDxyZXN1bHQ+bm9uZTwvcmVzdWx0PgogICAgICA8 L3NwZj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9tYWluPnAzcGxjcG5sMDIx MS5wcm9kLnBoeDMuc2VjdXJlc2VydmVyLm5ldDwvZG9tYWluPgogICAgICAg IDxyZXN1bHQ+bm9uZTwvcmVzdWx0PgogICAgICA8L3NwZj4KICAgICAgPHNw Zj4KICAgICAgICA8ZG9tYWluPnAzcGxjcG5sMDIxNC5wcm9kLnBoeDMuc2Vj dXJlc2VydmVyLm5ldDwvZG9tYWluPgogICAgICAgIDxyZXN1bHQ+bm9uZTwv cmVzdWx0PgogICAgICA8L3NwZj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9t YWluPnAzcGxjcG5sMDIyLnByb2QucGh4My5zZWN1cmVzZXJ2ZXIubmV0PC9k b21haW4+CiAgICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAgICAgIDwv c3BmPgogICAgICA8c3BmPgogICAgICAgIDxkb21haW4+cDNwbGNwbmwwMjIy LnByb2QucGh4My5zZWN1cmVzZXJ2ZXIubmV0PC9kb21haW4+CiAgICAgICAg PHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAgICA8c3Bm PgogICAgICAgIDxkb21haW4+cDNwbGNwbmwwMjMwLnByb2QucGh4My5zZWN1 cmVzZXJ2ZXIubmV0PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5ub25lPC9y ZXN1bHQ+CiAgICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAgIDxkb21h aW4+cDNwbGNwbmwwMjMyLnByb2QucGh4My5zZWN1cmVzZXJ2ZXIubmV0PC9k b21haW4+CiAgICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAgICAgIDwv c3BmPgogICAgICA8c3BmPgogICAgICAgIDxkb21haW4+cDNwbGNwbmwwMjMz LnByb2QucGh4My5zZWN1cmVzZXJ2ZXIubmV0PC9kb21haW4+CiAgICAgICAg PHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAgICA8c3Bm PgogICAgICAgIDxkb21haW4+cDNwbGNwbmwwMjM3LnByb2QucGh4My5zZWN1 cmVzZXJ2ZXIubmV0PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5ub25lPC9y ZXN1bHQ+CiAgICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAgIDxkb21h aW4+cDNwbGNwbmwwMjQ2LnByb2QucGh4My5zZWN1cmVzZXJ2ZXIubmV0PC9k b21haW4+CiAgICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAgICAgIDwv c3BmPgogICAgICA8c3BmPgogICAgICAgIDxkb21haW4+cDNwbGNwbmwwMjQ4 LnByb2QucGh4My5zZWN1cmVzZXJ2ZXIubmV0PC9kb21haW4+CiAgICAgICAg PHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAgICA8c3Bm PgogICAgICAgIDxkb21haW4+cDNwbGNwbmwwMjUwLnByb2QucGh4My5zZWN1 cmVzZXJ2ZXIubmV0PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5ub25lPC9y ZXN1bHQ+CiAgICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAgIDxkb21h aW4+cDNwbGNwbmwwMjUxLnByb2QucGh4My5zZWN1cmVzZXJ2ZXIubmV0PC9k b21haW4+CiAgICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAgICAgIDwv c3BmPgogICAgICA8c3BmPgogICAgICAgIDxkb21haW4+cDNwbGNwbmwwMjUz LnByb2QucGh4My5zZWN1cmVzZXJ2ZXIubmV0PC9kb21haW4+CiAgICAgICAg PHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAgICA8c3Bm PgogICAgICAgIDxkb21haW4+cDNwbGNwbmwwMjYucHJvZC5waHgzLnNlY3Vy ZXNlcnZlci5uZXQ8L2RvbWFpbj4KICAgICAgICA8cmVzdWx0Pm5vbmU8L3Jl c3VsdD4KICAgICAgPC9zcGY+CiAgICAgIDxzcGY+CiAgICAgICAgPGRvbWFp bj5wM3BsY3BubDAyNjYucHJvZC5waHgzLnNlY3VyZXNlcnZlci5uZXQ8L2Rv bWFpbj4KICAgICAgICA8cmVzdWx0Pm5vbmU8L3Jlc3VsdD4KICAgICAgPC9z cGY+CiAgICAgIDxzcGY+CiAgICAgICAgPGRvbWFpbj5wM3BsY3BubDAyNjcu cHJvZC5waHgzLnNlY3VyZXNlcnZlci5uZXQ8L2RvbWFpbj4KICAgICAgICA8 cmVzdWx0Pm5vbmU8L3Jlc3VsdD4KICAgICAgPC9zcGY+CiAgICAgIDxzcGY+ CiAgICAgICAgPGRvbWFpbj5wM3BsY3BubDAyNy5wcm9kLnBoeDMuc2VjdXJl c2VydmVyLm5ldDwvZG9tYWluPgogICAgICAgIDxyZXN1bHQ+bm9uZTwvcmVz dWx0PgogICAgICA8L3NwZj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9tYWlu PnAzcGxjcG5sMDI3MS5wcm9kLnBoeDMuc2VjdXJlc2VydmVyLm5ldDwvZG9t YWluPgogICAgICAgIDxyZXN1bHQ+bm9uZTwvcmVzdWx0PgogICAgICA8L3Nw Zj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9tYWluPnAzcGxjcG5sMDI3Ni5w cm9kLnBoeDMuc2VjdXJlc2VydmVyLm5ldDwvZG9tYWluPgogICAgICAgIDxy ZXN1bHQ+bm9uZTwvcmVzdWx0PgogICAgICA8L3NwZj4KICAgICAgPHNwZj4K ICAgICAgICA8ZG9tYWluPnAzcGxjcG5sMDI4MS5wcm9kLnBoeDMuc2VjdXJl c2VydmVyLm5ldDwvZG9tYWluPgogICAgICAgIDxyZXN1bHQ+bm9uZTwvcmVz dWx0PgogICAgICA8L3NwZj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9tYWlu PnAzcGxjcG5sMDI4NC5wcm9kLnBoeDMuc2VjdXJlc2VydmVyLm5ldDwvZG9t YWluPgogICAgICAgIDxyZXN1bHQ+bm9uZTwvcmVzdWx0PgogICAgICA8L3Nw Zj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9tYWluPnAzcGxjcG5sMDI4OC5w cm9kLnBoeDMuc2VjdXJlc2VydmVyLm5ldDwvZG9tYWluPgogICAgICAgIDxy ZXN1bHQ+bm9uZTwvcmVzdWx0PgogICAgICA8L3NwZj4KICAgICAgPHNwZj4K ICAgICAgICA8ZG9tYWluPnAzcGxjcG5sMDI5LnByb2QucGh4My5zZWN1cmVz ZXJ2ZXIubmV0PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5ub25lPC9yZXN1 bHQ+CiAgICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAgIDxkb21haW4+ cDNwbGNwbmwwMjk4LnByb2QucGh4My5zZWN1cmVzZXJ2ZXIubmV0PC9kb21h aW4+CiAgICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAgICAgIDwvc3Bm PgogICAgICA8c3BmPgogICAgICAgIDxkb21haW4+cDNwbGNwbmwwMzAxLnBy b2QucGh4My5zZWN1cmVzZXJ2ZXIubmV0PC9kb21haW4+CiAgICAgICAgPHJl c3VsdD5ub25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAgICA8c3BmPgog ICAgICAgIDxkb21haW4+cDNwbGNwbmwwMzAyLnByb2QucGh4My5zZWN1cmVz ZXJ2ZXIubmV0PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5ub25lPC9yZXN1 bHQ+CiAgICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAgIDxkb21haW4+ cDNwbGNwbmwwMzEwLnByb2QucGh4My5zZWN1cmVzZXJ2ZXIubmV0PC9kb21h aW4+CiAgICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAgICAgIDwvc3Bm PgogICAgICA8c3BmPgogICAgICAgIDxkb21haW4+cDNwbGNwbmwwMzE4LnBy b2QucGh4My5zZWN1cmVzZXJ2ZXIubmV0PC9kb21haW4+CiAgICAgICAgPHJl c3VsdD5ub25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAgICA8c3BmPgog ICAgICAgIDxkb21haW4+cDNwbGNwbmwwMzIwLnByb2QucGh4My5zZWN1cmVz ZXJ2ZXIubmV0PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5ub25lPC9yZXN1 bHQ+CiAgICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAgIDxkb21haW4+ cDNwbGNwbmwwMzIzLnByb2QucGh4My5zZWN1cmVzZXJ2ZXIubmV0PC9kb21h aW4+CiAgICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAgICAgIDwvc3Bm PgogICAgICA8c3BmPgogICAgICAgIDxkb21haW4+cDNwbGNwbmwwMzI3LnBy b2QucGh4My5zZWN1cmVzZXJ2ZXIubmV0PC9kb21haW4+CiAgICAgICAgPHJl c3VsdD5ub25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAgICA8c3BmPgog ICAgICAgIDxkb21haW4+cDNwbGNwbmwwMzI4LnByb2QucGh4My5zZWN1cmVz ZXJ2ZXIubmV0PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5ub25lPC9yZXN1 bHQ+CiAgICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAgIDxkb21haW4+ cDNwbGNwbmwwMzMucHJvZC5waHgzLnNlY3VyZXNlcnZlci5uZXQ8L2RvbWFp bj4KICAgICAgICA8cmVzdWx0Pm5vbmU8L3Jlc3VsdD4KICAgICAgPC9zcGY+ CiAgICAgIDxzcGY+CiAgICAgICAgPGRvbWFpbj5wM3BsY3BubDAzMzQucHJv ZC5waHgzLnNlY3VyZXNlcnZlci5uZXQ8L2RvbWFpbj4KICAgICAgICA8cmVz dWx0Pm5vbmU8L3Jlc3VsdD4KICAgICAgPC9zcGY+CiAgICAgIDxzcGY+CiAg ICAgICAgPGRvbWFpbj5wM3BsY3BubDAzMzYucHJvZC5waHgzLnNlY3VyZXNl cnZlci5uZXQ8L2RvbWFpbj4KICAgICAgICA8cmVzdWx0Pm5vbmU8L3Jlc3Vs dD4KICAgICAgPC9zcGY+CiAgICAgIDxzcGY+CiAgICAgICAgPGRvbWFpbj5w M3BsY3BubDAzMzcucHJvZC5waHgzLnNlY3VyZXNlcnZlci5uZXQ8L2RvbWFp bj4KICAgICAgICA8cmVzdWx0Pm5vbmU8L3Jlc3VsdD4KICAgICAgPC9zcGY+ CiAgICAgIDxzcGY+CiAgICAgICAgPGRvbWFpbj5wM3BsY3BubDAzMzgucHJv ZC5waHgzLnNlY3VyZXNlcnZlci5uZXQ8L2RvbWFpbj4KICAgICAgICA8cmVz dWx0Pm5vbmU8L3Jlc3VsdD4KICAgICAgPC9zcGY+CiAgICAgIDxzcGY+CiAg ICAgICAgPGRvbWFpbj5wM3BsY3BubDAzNDcucHJvZC5waHgzLnNlY3VyZXNl cnZlci5uZXQ8L2RvbWFpbj4KICAgICAgICA8cmVzdWx0Pm5vbmU8L3Jlc3Vs dD4KICAgICAgPC9zcGY+CiAgICAgIDxzcGY+CiAgICAgICAgPGRvbWFpbj5w M3BsY3BubDAzNDgucHJvZC5waHgzLnNlY3VyZXNlcnZlci5uZXQ8L2RvbWFp bj4KICAgICAgICA8cmVzdWx0Pm5vbmU8L3Jlc3VsdD4KICAgICAgPC9zcGY+ CiAgICAgIDxzcGY+CiAgICAgICAgPGRvbWFpbj5wM3BsY3BubDAzNTAucHJv ZC5waHgzLnNlY3VyZXNlcnZlci5uZXQ8L2RvbWFpbj4KICAgICAgICA8cmVz dWx0Pm5vbmU8L3Jlc3VsdD4KICAgICAgPC9zcGY+CiAgICAgIDxzcGY+CiAg ICAgICAgPGRvbWFpbj5wM3BsY3BubDAzNTkucHJvZC5waHgzLnNlY3VyZXNl cnZlci5uZXQ8L2RvbWFpbj4KICAgICAgICA8cmVzdWx0Pm5vbmU8L3Jlc3Vs dD4KICAgICAgPC9zcGY+CiAgICAgIDxzcGY+CiAgICAgICAgPGRvbWFpbj5w M3BsY3BubDAzNjAucHJvZC5waHgzLnNlY3VyZXNlcnZlci5uZXQ8L2RvbWFp bj4KICAgICAgICA8cmVzdWx0Pm5vbmU8L3Jlc3VsdD4KICAgICAgPC9zcGY+ CiAgICAgIDxzcGY+CiAgICAgICAgPGRvbWFpbj5wM3BsY3BubDAzNjUucHJv ZC5waHgzLnNlY3VyZXNlcnZlci5uZXQ8L2RvbWFpbj4KICAgICAgICA8cmVz dWx0Pm5vbmU8L3Jlc3VsdD4KICAgICAgPC9zcGY+CiAgICAgIDxzcGY+CiAg ICAgICAgPGRvbWFpbj5wM3BsY3BubDAzNzEucHJvZC5waHgzLnNlY3VyZXNl cnZlci5uZXQ8L2RvbWFpbj4KICAgICAgICA8cmVzdWx0Pm5vbmU8L3Jlc3Vs dD4KICAgICAgPC9zcGY+CiAgICAgIDxzcGY+CiAgICAgICAgPGRvbWFpbj5w M3BsY3BubDAzNzUucHJvZC5waHgzLnNlY3VyZXNlcnZlci5uZXQ8L2RvbWFp bj4KICAgICAgICA8cmVzdWx0Pm5vbmU8L3Jlc3VsdD4KICAgICAgPC9zcGY+ CiAgICAgIDxzcGY+CiAgICAgICAgPGRvbWFpbj5wM3BsY3BubDAzNzYucHJv ZC5waHgzLnNlY3VyZXNlcnZlci5uZXQ8L2RvbWFpbj4KICAgICAgICA8cmVz dWx0Pm5vbmU8L3Jlc3VsdD4KICAgICAgPC9zcGY+CiAgICAgIDxzcGY+CiAg ICAgICAgPGRvbWFpbj5wM3BsY3BubDAzODAucHJvZC5waHgzLnNlY3VyZXNl cnZlci5uZXQ8L2RvbWFpbj4KICAgICAgICA8cmVzdWx0Pm5vbmU8L3Jlc3Vs dD4KICAgICAgPC9zcGY+CiAgICAgIDxzcGY+CiAgICAgICAgPGRvbWFpbj5w M3BsY3BubDAzODYucHJvZC5waHgzLnNlY3VyZXNlcnZlci5uZXQ8L2RvbWFp bj4KICAgICAgICA8cmVzdWx0Pm5vbmU8L3Jlc3VsdD4KICAgICAgPC9zcGY+ CiAgICAgIDxzcGY+CiAgICAgICAgPGRvbWFpbj5wM3BsY3BubDAzODgucHJv ZC5waHgzLnNlY3VyZXNlcnZlci5uZXQ8L2RvbWFpbj4KICAgICAgICA8cmVz dWx0Pm5vbmU8L3Jlc3VsdD4KICAgICAgPC9zcGY+CiAgICAgIDxzcGY+CiAg ICAgICAgPGRvbWFpbj5wM3BsY3BubDAzOTEucHJvZC5waHgzLnNlY3VyZXNl cnZlci5uZXQ8L2RvbWFpbj4KICAgICAgICA8cmVzdWx0Pm5vbmU8L3Jlc3Vs dD4KICAgICAgPC9zcGY+CiAgICAgIDxzcGY+CiAgICAgICAgPGRvbWFpbj5w M3BsY3BubDAzOTIucHJvZC5waHgzLnNlY3VyZXNlcnZlci5uZXQ8L2RvbWFp bj4KICAgICAgICA8cmVzdWx0Pm5vbmU8L3Jlc3VsdD4KICAgICAgPC9zcGY+ CiAgICAgIDxzcGY+CiAgICAgICAgPGRvbWFpbj5wM3BsY3BubDAzOTQucHJv ZC5waHgzLnNlY3VyZXNlcnZlci5uZXQ8L2RvbWFpbj4KICAgICAgICA8cmVz dWx0Pm5vbmU8L3Jlc3VsdD4KICAgICAgPC9zcGY+CiAgICAgIDxzcGY+CiAg ICAgICAgPGRvbWFpbj5wM3BsY3BubDAzOTUucHJvZC5waHgzLnNlY3VyZXNl cnZlci5uZXQ8L2RvbWFpbj4KICAgICAgICA8cmVzdWx0Pm5vbmU8L3Jlc3Vs dD4KICAgICAgPC9zcGY+CiAgICAgIDxzcGY+CiAgICAgICAgPGRvbWFpbj5w M3BsY3BubDAzOTUucHJvZC5waHgzLnNlY3VyZXNlcnZlci5uZXQ8L2RvbWFp bj4KICAgICAgICA8cmVzdWx0PnRlbXBlcnJvcjwvcmVzdWx0PgogICAgICA8 L3NwZj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9tYWluPnAzcGxjcG5sMDQw MC5wcm9kLnBoeDMuc2VjdXJlc2VydmVyLm5ldDwvZG9tYWluPgogICAgICAg IDxyZXN1bHQ+bm9uZTwvcmVzdWx0PgogICAgICA8L3NwZj4KICAgICAgPHNw Zj4KICAgICAgICA8ZG9tYWluPnAzcGxjcG5sMDQwMi5wcm9kLnBoeDMuc2Vj dXJlc2VydmVyLm5ldDwvZG9tYWluPgogICAgICAgIDxyZXN1bHQ+bm9uZTwv cmVzdWx0PgogICAgICA8L3NwZj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9t YWluPnAzcGxjcG5sMDQwMy5wcm9kLnBoeDMuc2VjdXJlc2VydmVyLm5ldDwv ZG9tYWluPgogICAgICAgIDxyZXN1bHQ+bm9uZTwvcmVzdWx0PgogICAgICA8 L3NwZj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9tYWluPnAzcGxjcG5sMDQx Mi5wcm9kLnBoeDMuc2VjdXJlc2VydmVyLm5ldDwvZG9tYWluPgogICAgICAg IDxyZXN1bHQ+bm9uZTwvcmVzdWx0PgogICAgICA8L3NwZj4KICAgICAgPHNw Zj4KICAgICAgICA8ZG9tYWluPnAzcGxjcG5sMDQxMy5wcm9kLnBoeDMuc2Vj dXJlc2VydmVyLm5ldDwvZG9tYWluPgogICAgICAgIDxyZXN1bHQ+bm9uZTwv cmVzdWx0PgogICAgICA8L3NwZj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9t YWluPnAzcGxjcG5sMDQxNC5wcm9kLnBoeDMuc2VjdXJlc2VydmVyLm5ldDwv ZG9tYWluPgogICAgICAgIDxyZXN1bHQ+bm9uZTwvcmVzdWx0PgogICAgICA8 L3NwZj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9tYWluPnAzcGxjcG5sMDQy Ny5wcm9kLnBoeDMuc2VjdXJlc2VydmVyLm5ldDwvZG9tYWluPgogICAgICAg IDxyZXN1bHQ+bm9uZTwvcmVzdWx0PgogICAgICA8L3NwZj4KICAgICAgPHNw Zj4KICAgICAgICA8ZG9tYWluPnAzcGxjcG5sMDQzNS5wcm9kLnBoeDMuc2Vj dXJlc2VydmVyLm5ldDwvZG9tYWluPgogICAgICAgIDxyZXN1bHQ+bm9uZTwv cmVzdWx0PgogICAgICA8L3NwZj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9t YWluPnAzcGxjcG5sMDQ0My5wcm9kLnBoeDMuc2VjdXJlc2VydmVyLm5ldDwv ZG9tYWluPgogICAgICAgIDxyZXN1bHQ+bm9uZTwvcmVzdWx0PgogICAgICA8 L3NwZj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9tYWluPnAzcGxjcG5sMDQ0 NS5wcm9kLnBoeDMuc2VjdXJlc2VydmVyLm5ldDwvZG9tYWluPgogICAgICAg IDxyZXN1bHQ+bm9uZTwvcmVzdWx0PgogICAgICA8L3NwZj4KICAgICAgPHNw Zj4KICAgICAgICA8ZG9tYWluPnAzcGxjcG5sMDQ1MC5wcm9kLnBoeDMuc2Vj dXJlc2VydmVyLm5ldDwvZG9tYWluPgogICAgICAgIDxyZXN1bHQ+bm9uZTwv cmVzdWx0PgogICAgICA8L3NwZj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9t YWluPnAzcGxjcG5sMDQ1MS5wcm9kLnBoeDMuc2VjdXJlc2VydmVyLm5ldDwv ZG9tYWluPgogICAgICAgIDxyZXN1bHQ+bm9uZTwvcmVzdWx0PgogICAgICA8 L3NwZj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9tYWluPnAzcGxjcG5sMDQ1 NC5wcm9kLnBoeDMuc2VjdXJlc2VydmVyLm5ldDwvZG9tYWluPgogICAgICAg IDxyZXN1bHQ+bm9uZTwvcmVzdWx0PgogICAgICA8L3NwZj4KICAgICAgPHNw Zj4KICAgICAgICA8ZG9tYWluPnAzcGxjcG5sMDQ1NS5wcm9kLnBoeDMuc2Vj dXJlc2VydmVyLm5ldDwvZG9tYWluPgogICAgICAgIDxyZXN1bHQ+bm9uZTwv cmVzdWx0PgogICAgICA8L3NwZj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9t YWluPnAzcGxjcG5sMDQ1Ni5wcm9kLnBoeDMuc2VjdXJlc2VydmVyLm5ldDwv ZG9tYWluPgogICAgICAgIDxyZXN1bHQ+bm9uZTwvcmVzdWx0PgogICAgICA8 L3NwZj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9tYWluPnAzcGxjcG5sMDQ1 OS5wcm9kLnBoeDMuc2VjdXJlc2VydmVyLm5ldDwvZG9tYWluPgogICAgICAg IDxyZXN1bHQ+bm9uZTwvcmVzdWx0PgogICAgICA8L3NwZj4KICAgICAgPHNw Zj4KICAgICAgICA8ZG9tYWluPnAzcGxjcG5sMDQ2NC5wcm9kLnBoeDMuc2Vj dXJlc2VydmVyLm5ldDwvZG9tYWluPgogICAgICAgIDxyZXN1bHQ+bm9uZTwv cmVzdWx0PgogICAgICA8L3NwZj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9t YWluPnAzcGxjcG5sMDQ2Ni5wcm9kLnBoeDMuc2VjdXJlc2VydmVyLm5ldDwv ZG9tYWluPgogICAgICAgIDxyZXN1bHQ+bm9uZTwvcmVzdWx0PgogICAgICA8 L3NwZj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9tYWluPnAzcGxjcG5sMDQ2 OS5wcm9kLnBoeDMuc2VjdXJlc2VydmVyLm5ldDwvZG9tYWluPgogICAgICAg IDxyZXN1bHQ+bm9uZTwvcmVzdWx0PgogICAgICA8L3NwZj4KICAgICAgPHNw Zj4KICAgICAgICA8ZG9tYWluPnAzcGxjcG5sMDQ3MC5wcm9kLnBoeDMuc2Vj dXJlc2VydmVyLm5ldDwvZG9tYWluPgogICAgICAgIDxyZXN1bHQ+bm9uZTwv cmVzdWx0PgogICAgICA8L3NwZj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9t YWluPnAzcGxjcG5sMDQ3MS5wcm9kLnBoeDMuc2VjdXJlc2VydmVyLm5ldDwv ZG9tYWluPgogICAgICAgIDxyZXN1bHQ+bm9uZTwvcmVzdWx0PgogICAgICA8 L3NwZj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9tYWluPnAzcGxjcG5sMDQ3 NC5wcm9kLnBoeDMuc2VjdXJlc2VydmVyLm5ldDwvZG9tYWluPgogICAgICAg IDxyZXN1bHQ+bm9uZTwvcmVzdWx0PgogICAgICA8L3NwZj4KICAgICAgPHNw Zj4KICAgICAgICA8ZG9tYWluPnAzcGxjcG5sMDQ3Ni5wcm9kLnBoeDMuc2Vj dXJlc2VydmVyLm5ldDwvZG9tYWluPgogICAgICAgIDxyZXN1bHQ+bm9uZTwv cmVzdWx0PgogICAgICA8L3NwZj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9t YWluPnAzcGxjcG5sMDQ4My5wcm9kLnBoeDMuc2VjdXJlc2VydmVyLm5ldDwv ZG9tYWluPgogICAgICAgIDxyZXN1bHQ+bm9uZTwvcmVzdWx0PgogICAgICA8 L3NwZj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9tYWluPnAzcGxjcG5sMDQ4 Ni5wcm9kLnBoeDMuc2VjdXJlc2VydmVyLm5ldDwvZG9tYWluPgogICAgICAg IDxyZXN1bHQ+bm9uZTwvcmVzdWx0PgogICAgICA8L3NwZj4KICAgICAgPHNw Zj4KICAgICAgICA8ZG9tYWluPnAzcGxjcG5sMDQ4OC5wcm9kLnBoeDMuc2Vj dXJlc2VydmVyLm5ldDwvZG9tYWluPgogICAgICAgIDxyZXN1bHQ+bm9uZTwv cmVzdWx0PgogICAgICA8L3NwZj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9t YWluPnAzcGxjcG5sMDQ5MS5wcm9kLnBoeDMuc2VjdXJlc2VydmVyLm5ldDwv ZG9tYWluPgogICAgICAgIDxyZXN1bHQ+bm9uZTwvcmVzdWx0PgogICAgICA8 L3NwZj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9tYWluPnAzcGxjcG5sMDQ5 NC5wcm9kLnBoeDMuc2VjdXJlc2VydmVyLm5ldDwvZG9tYWluPgogICAgICAg IDxyZXN1bHQ+bm9uZTwvcmVzdWx0PgogICAgICA8L3NwZj4KICAgICAgPHNw Zj4KICAgICAgICA8ZG9tYWluPnAzcGxjcG5sMDQ5Ni5wcm9kLnBoeDMuc2Vj dXJlc2VydmVyLm5ldDwvZG9tYWluPgogICAgICAgIDxyZXN1bHQ+bm9uZTwv cmVzdWx0PgogICAgICA8L3NwZj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9t YWluPnAzcGxjcG5sMDQ5Ny5wcm9kLnBoeDMuc2VjdXJlc2VydmVyLm5ldDwv ZG9tYWluPgogICAgICAgIDxyZXN1bHQ+bm9uZTwvcmVzdWx0PgogICAgICA8 L3NwZj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9tYWluPnAzcGxjcG5sMDUw MC5wcm9kLnBoeDMuc2VjdXJlc2VydmVyLm5ldDwvZG9tYWluPgogICAgICAg IDxyZXN1bHQ+bm9uZTwvcmVzdWx0PgogICAgICA8L3NwZj4KICAgICAgPHNw Zj4KICAgICAgICA8ZG9tYWluPnAzcGxjcG5sMDUwMS5wcm9kLnBoeDMuc2Vj dXJlc2VydmVyLm5ldDwvZG9tYWluPgogICAgICAgIDxyZXN1bHQ+bm9uZTwv cmVzdWx0PgogICAgICA8L3NwZj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9t YWluPnAzcGxjcG5sMDUxMC5wcm9kLnBoeDMuc2VjdXJlc2VydmVyLm5ldDwv ZG9tYWluPgogICAgICAgIDxyZXN1bHQ+bm9uZTwvcmVzdWx0PgogICAgICA8 L3NwZj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9tYWluPnAzcGxjcG5sMDUx MS5wcm9kLnBoeDMuc2VjdXJlc2VydmVyLm5ldDwvZG9tYWluPgogICAgICAg IDxyZXN1bHQ+bm9uZTwvcmVzdWx0PgogICAgICA8L3NwZj4KICAgICAgPHNw Zj4KICAgICAgICA8ZG9tYWluPnAzcGxjcG5sMDUxMi5wcm9kLnBoeDMuc2Vj dXJlc2VydmVyLm5ldDwvZG9tYWluPgogICAgICAgIDxyZXN1bHQ+bm9uZTwv cmVzdWx0PgogICAgICA8L3NwZj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9t YWluPnAzcGxjcG5sMDUxNC5wcm9kLnBoeDMuc2VjdXJlc2VydmVyLm5ldDwv ZG9tYWluPgogICAgICAgIDxyZXN1bHQ+bm9uZTwvcmVzdWx0PgogICAgICA8 L3NwZj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9tYWluPnAzcGxjcG5sMDUx Ni5wcm9kLnBoeDMuc2VjdXJlc2VydmVyLm5ldDwvZG9tYWluPgogICAgICAg IDxyZXN1bHQ+bm9uZTwvcmVzdWx0PgogICAgICA8L3NwZj4KICAgICAgPHNw Zj4KICAgICAgICA8ZG9tYWluPnAzcGxjcG5sMDUyMC5wcm9kLnBoeDMuc2Vj dXJlc2VydmVyLm5ldDwvZG9tYWluPgogICAgICAgIDxyZXN1bHQ+bm9uZTwv cmVzdWx0PgogICAgICA8L3NwZj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9t YWluPnAzcGxjcG5sMDUyMC5wcm9kLnBoeDMuc2VjdXJlc2VydmVyLm5ldDwv ZG9tYWluPgogICAgICAgIDxyZXN1bHQ+dGVtcGVycm9yPC9yZXN1bHQ+CiAg ICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAgIDxkb21haW4+cDNwbGNw bmwwNTI0LnByb2QucGh4My5zZWN1cmVzZXJ2ZXIubmV0PC9kb21haW4+CiAg ICAgICAgPHJlc3VsdD50ZW1wZXJyb3I8L3Jlc3VsdD4KICAgICAgPC9zcGY+ CiAgICAgIDxzcGY+CiAgICAgICAgPGRvbWFpbj5wM3BsY3BubDA1MjcucHJv ZC5waHgzLnNlY3VyZXNlcnZlci5uZXQ8L2RvbWFpbj4KICAgICAgICA8cmVz dWx0Pm5vbmU8L3Jlc3VsdD4KICAgICAgPC9zcGY+CiAgICAgIDxzcGY+CiAg ICAgICAgPGRvbWFpbj5wM3BsY3BubDA1MjkucHJvZC5waHgzLnNlY3VyZXNl cnZlci5uZXQ8L2RvbWFpbj4KICAgICAgICA8cmVzdWx0Pm5vbmU8L3Jlc3Vs dD4KICAgICAgPC9zcGY+CiAgICAgIDxzcGY+CiAgICAgICAgPGRvbWFpbj5w M3BsY3BubDA1MzAucHJvZC5waHgzLnNlY3VyZXNlcnZlci5uZXQ8L2RvbWFp bj4KICAgICAgICA8cmVzdWx0Pm5vbmU8L3Jlc3VsdD4KICAgICAgPC9zcGY+ CiAgICAgIDxzcGY+CiAgICAgICAgPGRvbWFpbj5wM3BsY3BubDA1MzEucHJv ZC5waHgzLnNlY3VyZXNlcnZlci5uZXQ8L2RvbWFpbj4KICAgICAgICA8cmVz dWx0Pm5vbmU8L3Jlc3VsdD4KICAgICAgPC9zcGY+CiAgICAgIDxzcGY+CiAg ICAgICAgPGRvbWFpbj5wM3BsY3BubDA1MzIucHJvZC5waHgzLnNlY3VyZXNl cnZlci5uZXQ8L2RvbWFpbj4KICAgICAgICA8cmVzdWx0Pm5vbmU8L3Jlc3Vs dD4KICAgICAgPC9zcGY+CiAgICAgIDxzcGY+CiAgICAgICAgPGRvbWFpbj5w M3BsY3BubDA1MzMucHJvZC5waHgzLnNlY3VyZXNlcnZlci5uZXQ8L2RvbWFp bj4KICAgICAgICA8cmVzdWx0Pm5vbmU8L3Jlc3VsdD4KICAgICAgPC9zcGY+ CiAgICAgIDxzcGY+CiAgICAgICAgPGRvbWFpbj5wM3BsY3BubDA1MzQucHJv ZC5waHgzLnNlY3VyZXNlcnZlci5uZXQ8L2RvbWFpbj4KICAgICAgICA8cmVz dWx0Pm5vbmU8L3Jlc3VsdD4KICAgICAgPC9zcGY+CiAgICAgIDxzcGY+CiAg ICAgICAgPGRvbWFpbj5wM3BsY3BubDA1MzUucHJvZC5waHgzLnNlY3VyZXNl cnZlci5uZXQ8L2RvbWFpbj4KICAgICAgICA8cmVzdWx0Pm5vbmU8L3Jlc3Vs dD4KICAgICAgPC9zcGY+CiAgICAgIDxzcGY+CiAgICAgICAgPGRvbWFpbj5w M3BsY3BubDA1MzUucHJvZC5waHgzLnNlY3VyZXNlcnZlci5uZXQ8L2RvbWFp bj4KICAgICAgICA8cmVzdWx0PnRlbXBlcnJvcjwvcmVzdWx0PgogICAgICA8 L3NwZj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9tYWluPnAzcGxjcG5sMDUz Ni5wcm9kLnBoeDMuc2VjdXJlc2VydmVyLm5ldDwvZG9tYWluPgogICAgICAg IDxyZXN1bHQ+bm9uZTwvcmVzdWx0PgogICAgICA8L3NwZj4KICAgICAgPHNw Zj4KICAgICAgICA8ZG9tYWluPnAzcGxjcG5sMDU0MS5wcm9kLnBoeDMuc2Vj dXJlc2VydmVyLm5ldDwvZG9tYWluPgogICAgICAgIDxyZXN1bHQ+bm9uZTwv cmVzdWx0PgogICAgICA8L3NwZj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9t YWluPnAzcGxjcG5sMDU0My5wcm9kLnBoeDMuc2VjdXJlc2VydmVyLm5ldDwv ZG9tYWluPgogICAgICAgIDxyZXN1bHQ+bm9uZTwvcmVzdWx0PgogICAgICA8 L3NwZj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9tYWluPnAzcGxjcG5sMDU0 NS5wcm9kLnBoeDMuc2VjdXJlc2VydmVyLm5ldDwvZG9tYWluPgogICAgICAg IDxyZXN1bHQ+bm9uZTwvcmVzdWx0PgogICAgICA8L3NwZj4KICAgICAgPHNw Zj4KICAgICAgICA8ZG9tYWluPnAzcGxjcG5sMDU0OC5wcm9kLnBoeDMuc2Vj dXJlc2VydmVyLm5ldDwvZG9tYWluPgogICAgICAgIDxyZXN1bHQ+bm9uZTwv cmVzdWx0PgogICAgICA8L3NwZj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9t YWluPnAzcGxjcG5sMDU2NC5wcm9kLnBoeDMuc2VjdXJlc2VydmVyLm5ldDwv ZG9tYWluPgogICAgICAgIDxyZXN1bHQ+bm9uZTwvcmVzdWx0PgogICAgICA8 L3NwZj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9tYWluPnAzcGxjcG5sMDU3 MC5wcm9kLnBoeDMuc2VjdXJlc2VydmVyLm5ldDwvZG9tYWluPgogICAgICAg IDxyZXN1bHQ+bm9uZTwvcmVzdWx0PgogICAgICA8L3NwZj4KICAgICAgPHNw Zj4KICAgICAgICA8ZG9tYWluPnAzcGxjcG5sMDU3Mi5wcm9kLnBoeDMuc2Vj dXJlc2VydmVyLm5ldDwvZG9tYWluPgogICAgICAgIDxyZXN1bHQ+bm9uZTwv cmVzdWx0PgogICAgICA8L3NwZj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9t YWluPnAzcGxjcG5sMDU4MC5wcm9kLnBoeDMuc2VjdXJlc2VydmVyLm5ldDwv ZG9tYWluPgogICAgICAgIDxyZXN1bHQ+bm9uZTwvcmVzdWx0PgogICAgICA8 L3NwZj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9tYWluPnAzcGxjcG5sMDU4 Ny5wcm9kLnBoeDMuc2VjdXJlc2VydmVyLm5ldDwvZG9tYWluPgogICAgICAg IDxyZXN1bHQ+bm9uZTwvcmVzdWx0PgogICAgICA8L3NwZj4KICAgICAgPHNw Zj4KICAgICAgICA8ZG9tYWluPnAzcGxjcG5sMDU5NC5wcm9kLnBoeDMuc2Vj dXJlc2VydmVyLm5ldDwvZG9tYWluPgogICAgICAgIDxyZXN1bHQ+bm9uZTwv cmVzdWx0PgogICAgICA8L3NwZj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9t YWluPnAzcGxjcG5sMDYwMS5wcm9kLnBoeDMuc2VjdXJlc2VydmVyLm5ldDwv ZG9tYWluPgogICAgICAgIDxyZXN1bHQ+bm9uZTwvcmVzdWx0PgogICAgICA8 L3NwZj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9tYWluPnAzcGxjcG5sMDYw Mi5wcm9kLnBoeDMuc2VjdXJlc2VydmVyLm5ldDwvZG9tYWluPgogICAgICAg IDxyZXN1bHQ+bm9uZTwvcmVzdWx0PgogICAgICA8L3NwZj4KICAgICAgPHNw Zj4KICAgICAgICA8ZG9tYWluPnAzcGxjcG5sMDYwMy5wcm9kLnBoeDMuc2Vj dXJlc2VydmVyLm5ldDwvZG9tYWluPgogICAgICAgIDxyZXN1bHQ+bm9uZTwv cmVzdWx0PgogICAgICA8L3NwZj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9t YWluPnAzcGxjcG5sMDYwNi5wcm9kLnBoeDMuc2VjdXJlc2VydmVyLm5ldDwv ZG9tYWluPgogICAgICAgIDxyZXN1bHQ+bm9uZTwvcmVzdWx0PgogICAgICA8 L3NwZj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9tYWluPnAzcGxjcG5sMDYx MC5wcm9kLnBoeDMuc2VjdXJlc2VydmVyLm5ldDwvZG9tYWluPgogICAgICAg IDxyZXN1bHQ+bm9uZTwvcmVzdWx0PgogICAgICA8L3NwZj4KICAgICAgPHNw Zj4KICAgICAgICA8ZG9tYWluPnAzcGxjcG5sMDYxMS5wcm9kLnBoeDMuc2Vj dXJlc2VydmVyLm5ldDwvZG9tYWluPgogICAgICAgIDxyZXN1bHQ+bm9uZTwv cmVzdWx0PgogICAgICA8L3NwZj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9t YWluPnAzcGxjcG5sMDYxNS5wcm9kLnBoeDMuc2VjdXJlc2VydmVyLm5ldDwv ZG9tYWluPgogICAgICAgIDxyZXN1bHQ+bm9uZTwvcmVzdWx0PgogICAgICA8 L3NwZj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9tYWluPnAzcGxjcG5sMDYx Ni5wcm9kLnBoeDMuc2VjdXJlc2VydmVyLm5ldDwvZG9tYWluPgogICAgICAg IDxyZXN1bHQ+bm9uZTwvcmVzdWx0PgogICAgICA8L3NwZj4KICAgICAgPHNw Zj4KICAgICAgICA8ZG9tYWluPnAzcGxjcG5sMDYyNC5wcm9kLnBoeDMuc2Vj dXJlc2VydmVyLm5ldDwvZG9tYWluPgogICAgICAgIDxyZXN1bHQ+bm9uZTwv cmVzdWx0PgogICAgICA8L3NwZj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9t YWluPnAzcGxjcG5sMDY0Ni5wcm9kLnBoeDMuc2VjdXJlc2VydmVyLm5ldDwv ZG9tYWluPgogICAgICAgIDxyZXN1bHQ+bm9uZTwvcmVzdWx0PgogICAgICA8 L3NwZj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9tYWluPnAzcGxjcG5sMDY0 Ni5wcm9kLnBoeDMuc2VjdXJlc2VydmVyLm5ldDwvZG9tYWluPgogICAgICAg IDxyZXN1bHQ+dGVtcGVycm9yPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAg ICA8c3BmPgogICAgICAgIDxkb21haW4+cDNwbGNwbmwwNjYxLnByb2QucGh4 My5zZWN1cmVzZXJ2ZXIubmV0PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5u b25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAg IDxkb21haW4+cDNwbGNwbmwwNjY0LnByb2QucGh4My5zZWN1cmVzZXJ2ZXIu bmV0PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAg ICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAgIDxkb21haW4+cDNwbGNw bmwwNjY1LnByb2QucGh4My5zZWN1cmVzZXJ2ZXIubmV0PC9kb21haW4+CiAg ICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAg ICA8c3BmPgogICAgICAgIDxkb21haW4+cDNwbGNwbmwwNjY3LnByb2QucGh4 My5zZWN1cmVzZXJ2ZXIubmV0PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5u b25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAg IDxkb21haW4+cDNwbGNwbmwwNjcyLnByb2QucGh4My5zZWN1cmVzZXJ2ZXIu bmV0PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAg ICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAgIDxkb21haW4+cDNwbGNw bmwwNjgxLnByb2QucGh4My5zZWN1cmVzZXJ2ZXIubmV0PC9kb21haW4+CiAg ICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAg ICA8c3BmPgogICAgICAgIDxkb21haW4+cDNwbGNwbmwwNjgzLnByb2QucGh4 My5zZWN1cmVzZXJ2ZXIubmV0PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5u b25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAg IDxkb21haW4+cDNwbGNwbmwwNjg0LnByb2QucGh4My5zZWN1cmVzZXJ2ZXIu bmV0PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAg ICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAgIDxkb21haW4+cDNwbGNw bmwwNjkyLnByb2QucGh4My5zZWN1cmVzZXJ2ZXIubmV0PC9kb21haW4+CiAg ICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAg ICA8c3BmPgogICAgICAgIDxkb21haW4+cDNwbGNwbmwwNjk0LnByb2QucGh4 My5zZWN1cmVzZXJ2ZXIubmV0PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5u b25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAg IDxkb21haW4+cDNwbGNwbmwwNzA1LnByb2QucGh4My5zZWN1cmVzZXJ2ZXIu bmV0PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAg ICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAgIDxkb21haW4+cDNwbGNw bmwwNzEzLnByb2QucGh4My5zZWN1cmVzZXJ2ZXIubmV0PC9kb21haW4+CiAg ICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAg ICA8c3BmPgogICAgICAgIDxkb21haW4+cDNwbGNwbmwwNzE1LnByb2QucGh4 My5zZWN1cmVzZXJ2ZXIubmV0PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5u b25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAg IDxkb21haW4+cDNwbGNwbmwwNzIwLnByb2QucGh4My5zZWN1cmVzZXJ2ZXIu bmV0PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAg ICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAgIDxkb21haW4+cDNwbGNw bmwwNzIxLnByb2QucGh4My5zZWN1cmVzZXJ2ZXIubmV0PC9kb21haW4+CiAg ICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAg ICA8c3BmPgogICAgICAgIDxkb21haW4+cDNwbGNwbmwwNzI3LnByb2QucGh4 My5zZWN1cmVzZXJ2ZXIubmV0PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5u b25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAg IDxkb21haW4+cDNwbGNwbmwwNzI5LnByb2QucGh4My5zZWN1cmVzZXJ2ZXIu bmV0PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAg ICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAgIDxkb21haW4+cDNwbGNw bmwwNzM0LnByb2QucGh4My5zZWN1cmVzZXJ2ZXIubmV0PC9kb21haW4+CiAg ICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAg ICA8c3BmPgogICAgICAgIDxkb21haW4+cDNwbGNwbmwwNzM1LnByb2QucGh4 My5zZWN1cmVzZXJ2ZXIubmV0PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5u b25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAg IDxkb21haW4+cDNwbGNwbmwwNzQ4LnByb2QucGh4My5zZWN1cmVzZXJ2ZXIu bmV0PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAg ICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAgIDxkb21haW4+cDNwbGNw bmwwNzUxLnByb2QucGh4My5zZWN1cmVzZXJ2ZXIubmV0PC9kb21haW4+CiAg ICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAg ICA8c3BmPgogICAgICAgIDxkb21haW4+cDNwbGNwbmwwNzU1LnByb2QucGh4 My5zZWN1cmVzZXJ2ZXIubmV0PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5u b25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAg IDxkb21haW4+cDNwbGNwbmwwNzU2LnByb2QucGh4My5zZWN1cmVzZXJ2ZXIu bmV0PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAg ICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAgIDxkb21haW4+cDNwbGNw bmwwNzU3LnByb2QucGh4My5zZWN1cmVzZXJ2ZXIubmV0PC9kb21haW4+CiAg ICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAg ICA8c3BmPgogICAgICAgIDxkb21haW4+cDNwbGNwbmwwNzU5LnByb2QucGh4 My5zZWN1cmVzZXJ2ZXIubmV0PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5u b25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAg IDxkb21haW4+cDNwbGNwbmwwNzYyLnByb2QucGh4My5zZWN1cmVzZXJ2ZXIu bmV0PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAg ICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAgIDxkb21haW4+cDNwbGNw bmwwNzY0LnByb2QucGh4My5zZWN1cmVzZXJ2ZXIubmV0PC9kb21haW4+CiAg ICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAg ICA8c3BmPgogICAgICAgIDxkb21haW4+cDNwbGNwbmwwNzY1LnByb2QucGh4 My5zZWN1cmVzZXJ2ZXIubmV0PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5u b25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAg IDxkb21haW4+cDNwbGNwbmwwNzY2LnByb2QucGh4My5zZWN1cmVzZXJ2ZXIu bmV0PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAg ICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAgIDxkb21haW4+cDNwbGNw bmwwNzY3LnByb2QucGh4My5zZWN1cmVzZXJ2ZXIubmV0PC9kb21haW4+CiAg ICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAg ICA8c3BmPgogICAgICAgIDxkb21haW4+cDNwbGNwbmwwNzY5LnByb2QucGh4 My5zZWN1cmVzZXJ2ZXIubmV0PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5u b25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAg IDxkb21haW4+cDNwbGNwbmwwNzczLnByb2QucGh4My5zZWN1cmVzZXJ2ZXIu bmV0PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAg ICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAgIDxkb21haW4+cDNwbGNw bmwwNzkzLnByb2QucGh4My5zZWN1cmVzZXJ2ZXIubmV0PC9kb21haW4+CiAg ICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAg ICA8c3BmPgogICAgICAgIDxkb21haW4+cDNwbGNwbmwwNzk4LnByb2QucGh4 My5zZWN1cmVzZXJ2ZXIubmV0PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5u b25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAg IDxkb21haW4+cDNwbGNwbmwwNzk5LnByb2QucGh4My5zZWN1cmVzZXJ2ZXIu bmV0PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAg ICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAgIDxkb21haW4+cDNwbGNw bmwwODAxLnByb2QucGh4My5zZWN1cmVzZXJ2ZXIubmV0PC9kb21haW4+CiAg ICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAg ICA8c3BmPgogICAgICAgIDxkb21haW4+cDNwbGNwbmwwODAyLnByb2QucGh4 My5zZWN1cmVzZXJ2ZXIubmV0PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5u b25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAg IDxkb21haW4+cDNwbGNwbmwwODA1LnByb2QucGh4My5zZWN1cmVzZXJ2ZXIu bmV0PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAg ICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAgIDxkb21haW4+cDNwbGNw bmwwODA5LnByb2QucGh4My5zZWN1cmVzZXJ2ZXIubmV0PC9kb21haW4+CiAg ICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAg ICA8c3BmPgogICAgICAgIDxkb21haW4+cDNwbGNwbmwwODI1LnByb2QucGh4 My5zZWN1cmVzZXJ2ZXIubmV0PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5u b25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAg IDxkb21haW4+cDNwbGNwbmwwODI2LnByb2QucGh4My5zZWN1cmVzZXJ2ZXIu bmV0PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAg ICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAgIDxkb21haW4+cDNwbGNw bmwwODI5LnByb2QucGh4My5zZWN1cmVzZXJ2ZXIubmV0PC9kb21haW4+CiAg ICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAg ICA8c3BmPgogICAgICAgIDxkb21haW4+cDNwbGNwbmwwODMxLnByb2QucGh4 My5zZWN1cmVzZXJ2ZXIubmV0PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5u b25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAg IDxkb21haW4+cDNwbGNwbmwwODM4LnByb2QucGh4My5zZWN1cmVzZXJ2ZXIu bmV0PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAg ICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAgIDxkb21haW4+cDNwbGNw bmwwODUzLnByb2QucGh4My5zZWN1cmVzZXJ2ZXIubmV0PC9kb21haW4+CiAg ICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAg ICA8c3BmPgogICAgICAgIDxkb21haW4+cDNwbGNwbmwwODU3LnByb2QucGh4 My5zZWN1cmVzZXJ2ZXIubmV0PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5u b25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAg IDxkb21haW4+cDNwbGNwbmwwODYxLnByb2QucGh4My5zZWN1cmVzZXJ2ZXIu bmV0PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAg ICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAgIDxkb21haW4+cDNwbGNw bmwwODYyLnByb2QucGh4My5zZWN1cmVzZXJ2ZXIubmV0PC9kb21haW4+CiAg ICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAg ICA8c3BmPgogICAgICAgIDxkb21haW4+cDNwbGNwbmwwODcxLnByb2QucGh4 My5zZWN1cmVzZXJ2ZXIubmV0PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5u b25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAg IDxkb21haW4+cDNwbGNwbmwwODc1LnByb2QucGh4My5zZWN1cmVzZXJ2ZXIu bmV0PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAg ICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAgIDxkb21haW4+cDNwbGNw bmwwODkwLnByb2QucGh4My5zZWN1cmVzZXJ2ZXIubmV0PC9kb21haW4+CiAg ICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAg ICA8c3BmPgogICAgICAgIDxkb21haW4+cDNwbGNwbmwwODkzLnByb2QucGh4 My5zZWN1cmVzZXJ2ZXIubmV0PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5u b25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAg IDxkb21haW4+cDNwbGNwbmwwODk2LnByb2QucGh4My5zZWN1cmVzZXJ2ZXIu bmV0PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAg ICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAgIDxkb21haW4+cDNwbGNw bmwwODk3LnByb2QucGh4My5zZWN1cmVzZXJ2ZXIubmV0PC9kb21haW4+CiAg ICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAg ICA8c3BmPgogICAgICAgIDxkb21haW4+cDNwbGNwbmwwOTA2LnByb2QucGh4 My5zZWN1cmVzZXJ2ZXIubmV0PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5u b25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAg IDxkb21haW4+cDNwbGNwbmwwOTEwLnByb2QucGh4My5zZWN1cmVzZXJ2ZXIu bmV0PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAg ICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAgIDxkb21haW4+cDNwbGNw bmwwOTE0LnByb2QucGh4My5zZWN1cmVzZXJ2ZXIubmV0PC9kb21haW4+CiAg ICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAg ICA8c3BmPgogICAgICAgIDxkb21haW4+cDNwbGNwbmwwOTMwLnByb2QucGh4 My5zZWN1cmVzZXJ2ZXIubmV0PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5u b25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAg IDxkb21haW4+cDNwbGNwbmwwOTM2LnByb2QucGh4My5zZWN1cmVzZXJ2ZXIu bmV0PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAg ICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAgIDxkb21haW4+cDNwbGNw bmwwOTQ0LnByb2QucGh4My5zZWN1cmVzZXJ2ZXIubmV0PC9kb21haW4+CiAg ICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAg ICA8c3BmPgogICAgICAgIDxkb21haW4+cDNwbGNwbmwwOTQ2LnByb2QucGh4 My5zZWN1cmVzZXJ2ZXIubmV0PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5u b25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAg IDxkb21haW4+cDNwbGNwbmwwOTQ5LnByb2QucGh4My5zZWN1cmVzZXJ2ZXIu bmV0PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAg ICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAgIDxkb21haW4+cDNwbGNw bmwwOTUxLnByb2QucGh4My5zZWN1cmVzZXJ2ZXIubmV0PC9kb21haW4+CiAg ICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAg ICA8c3BmPgogICAgICAgIDxkb21haW4+cDNwbGNwbmwwOTU1LnByb2QucGh4 My5zZWN1cmVzZXJ2ZXIubmV0PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5u b25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAg IDxkb21haW4+cDNwbGNwbmwwOTY1LnByb2QucGh4My5zZWN1cmVzZXJ2ZXIu bmV0PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAg ICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAgIDxkb21haW4+cDNwbGNw bmwwOTcxLnByb2QucGh4My5zZWN1cmVzZXJ2ZXIubmV0PC9kb21haW4+CiAg ICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAg ICA8c3BmPgogICAgICAgIDxkb21haW4+cDNwbGNwbmwwOTczLnByb2QucGh4 My5zZWN1cmVzZXJ2ZXIubmV0PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5u b25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAg IDxkb21haW4+cDNwbGNwbmwwOTc4LnByb2QucGh4My5zZWN1cmVzZXJ2ZXIu bmV0PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAg ICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAgIDxkb21haW4+cDNwbGNw bmwwOTg1LnByb2QucGh4My5zZWN1cmVzZXJ2ZXIubmV0PC9kb21haW4+CiAg ICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAg ICA8c3BmPgogICAgICAgIDxkb21haW4+cDNwbGNwbmwwOTg3LnByb2QucGh4 My5zZWN1cmVzZXJ2ZXIubmV0PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5u b25lPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAg IDxkb21haW4+cDNwbGNwbmwwOTkyLnByb2QucGh4My5zZWN1cmVzZXJ2ZXIu bmV0PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAg ICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAgIDxkb21haW4+cGFpZDJz YXZlLmNvbTwvZG9tYWluPgogICAgICAgIDxyZXN1bHQ+ZmFpbDwvcmVzdWx0 PgogICAgICA8L3NwZj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9tYWluPnBh bGFicmFzLmpwPC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5ub25lPC9yZXN1 bHQ+CiAgICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAgIDxkb21haW4+ cG93ZXJxdGVjaC5jb208L2RvbWFpbj4KICAgICAgICA8cmVzdWx0Pm5vbmU8 L3Jlc3VsdD4KICAgICAgPC9zcGY+CiAgICAgIDxzcGY+CiAgICAgICAgPGRv bWFpbj5yYXNrYi5vcmc8L2RvbWFpbj4KICAgICAgICA8cmVzdWx0Pm5vbmU8 L3Jlc3VsdD4KICAgICAgPC9zcGY+CiAgICAgIDxzcGY+CiAgICAgICAgPGRv bWFpbj5yZWFsdG9yLmNhPC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5mYWls PC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAgIDxk b21haW4+cmVzdGVkbGVncy5jb208L2RvbWFpbj4KICAgICAgICA8cmVzdWx0 Pm5vbmU8L3Jlc3VsdD4KICAgICAgPC9zcGY+CiAgICAgIDxzcGY+CiAgICAg ICAgPGRvbWFpbj5yb3NzZ2xlZGhpbGwuY29tPC9kb21haW4+CiAgICAgICAg PHJlc3VsdD5mYWlsPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAgICA8c3Bm PgogICAgICAgIDxkb21haW4+c2VhdHRsZWFvLm9yZzwvZG9tYWluPgogICAg ICAgIDxyZXN1bHQ+bm9uZTwvcmVzdWx0PgogICAgICA8L3NwZj4KICAgICAg PHNwZj4KICAgICAgICA8ZG9tYWluPnNlci1oYWNlci10ZW5lci5jb20ubXg8 L2RvbWFpbj4KICAgICAgICA8cmVzdWx0Pm5vbmU8L3Jlc3VsdD4KICAgICAg PC9zcGY+CiAgICAgIDxzcGY+CiAgICAgICAgPGRvbWFpbj5zaG90Z3VuaG9u ZXkuY29tPC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+ CiAgICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAgIDxkb21haW4+c21v cnRvLmNvbTwvZG9tYWluPgogICAgICAgIDxyZXN1bHQ+bm9uZTwvcmVzdWx0 PgogICAgICA8L3NwZj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9tYWluPnNt dHAueW1scDE4Lm5ldDwvZG9tYWluPgogICAgICAgIDxyZXN1bHQ+ZmFpbDwv cmVzdWx0PgogICAgICA8L3NwZj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9t YWluPnNtdHA0LnltbHBzcnYubmV0PC9kb21haW4+CiAgICAgICAgPHJlc3Vs dD5mYWlsPC9yZXN1bHQ+CiAgICAgIDwvc3BmPgogICAgICA8c3BmPgogICAg ICAgIDxkb21haW4+c3VidXJiYW5tYXJrZXRpbmdncm91cC5jb208L2RvbWFp bj4KICAgICAgICA8cmVzdWx0Pm5vbmU8L3Jlc3VsdD4KICAgICAgPC9zcGY+ CiAgICAgIDxzcGY+CiAgICAgICAgPGRvbWFpbj50cmljbHViLmNvLm56PC9k b21haW4+CiAgICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAgICAgIDwv c3BmPgogICAgICA8c3BmPgogICAgICAgIDxkb21haW4+d3d3LmNhZXUub3Jn PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAgICAg IDwvc3BmPgogICAgICA8c3BmPgogICAgICAgIDxkb21haW4+eWFob28uY29t PC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5uZXV0cmFsPC9yZXN1bHQ+CiAg ICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAgIDxkb21haW4+eWFob28u b3JnPC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+CiAg ICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAgIDxkb21haW4+eW9nYWRv cmsuY29tPC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5ub25lPC9yZXN1bHQ+ CiAgICAgIDwvc3BmPgogICAgICA8c3BmPgogICAgICAgIDxkb21haW4+emVv dGhlb3J5LmNvbTwvZG9tYWluPgogICAgICAgIDxyZXN1bHQ+bm9uZTwvcmVz dWx0PgogICAgICA8L3NwZj4KICAgICAgPHNwZj4KICAgICAgICA8ZG9tYWlu Pnp3dGIuY29tPC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5ub25lPC9yZXN1 bHQ+CiAgICAgIDwvc3BmPgogICAgICA8ZGtpbT4KICAgICAgICA8ZG9tYWlu PnRvbWtpLmNvbTwvZG9tYWluPgogICAgICAgIDxyZXN1bHQ+bm9uZTwvcmVz dWx0PgogICAgICA8L2RraW0+CiAgICAgIDxka2ltPgogICAgICAgIDxkb21h aW4+dG9ta2kuY29tPC9kb21haW4+CiAgICAgICAgPHJlc3VsdD5mYWlsPC9y ZXN1bHQ+CiAgICAgIDwvZGtpbT4KICAgIDwvYXV0aF9yZXN1bHRzPgogIDwv cmVjb3JkPgoK --------------030102070103030903090801-- From nobody Thu Mar 17 01:50:15 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D64812D7DD for ; Thu, 17 Mar 2016 01:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RP_MATCHES_RCVD=-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 y945e09-iJVX for ; Thu, 17 Mar 2016 01:50:11 -0700 (PDT) Received: from turnbull.sk.tsukuba.ac.jp (turnbull.sk.tsukuba.ac.jp [130.158.96.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8E1812D57C for ; Thu, 17 Mar 2016 01:50:10 -0700 (PDT) Received: from steve by turnbull.sk.tsukuba.ac.jp with local (Exim 4.86) (envelope-from ) id 1agTd9-0003Yl-Io; Thu, 17 Mar 2016 17:50:07 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22250.28607.548315.734422@turnbull.sk.tsukuba.ac.jp> Date: Thu, 17 Mar 2016 17:50:07 +0900 From: "Stephen J. Turnbull" To: Terry Zink In-Reply-To: References: <20160314043043.31115.73657.idtracker@ietfa.amsl.com> <58630132-33D2-491B-9EC0-A98328F2BCD4@lepidum.co.jp> <84979E86-150D-487C-962C-72E945293ACE@wordtothewise.com> X-Mailer: VM 8.2.0b under 21.5 (beta34) "kale" dcd7dca8d70b XEmacs Lucid (x86_64-apple-darwin15.2.0) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: steve@turnbull.sk.tsukuba.ac.jp X-SA-Exim-Scanned: No (on turnbull.sk.tsukuba.ac.jp); SAEximRunCond expanded to false Archived-At: Cc: dmarc Subject: Re: [dmarc-ietf] I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 08:50:13 -0000 Terry Zink writes: > +1 to virtual DMARC, -1 to the arguments against it. How quickly we forget! > Figuring out implicit/virtual DMARC Semantically, it's only partly "implicit" and hardly virtual at all. A more accurate description is "mandatory/punitive". > for everyone else is a much bigger body of water to boil, Sure it's big, but Yahoo! and AOL are big too, and they already boiled the pot right down to the residual salt in April 2014. This I-D just mandates the same disaster again. > There's more tools in our toolbox than just junking. But a mandatory implicit p=reject means all those tools become non- conforming if this I-D is standardized. That's a bad thing. You can already "opt in" to using From alignment in your site's filtering and reputational systems. *You* don't need more than that. So the only value in this I-D is punishing non-participants in DMARC. "Mailing Lists object strenuously." On the other hand, the cool freemail services were *already* treating "p=reject" as advisory *before* April 2014 (at least according to some Google posters). AFAICS, this would *force* much of the world to do the same thing, despite the earlier experience. Google's behavior is justifiable in view of the "unexpected" use of p=reject by AOL and Yahoo! to combat spam based on leaked personal information, but now we know better. Embedding mandatory implicit p=reject in a new RFC is just saying "non-conformance is conformance". I certainly don't plan to *ever* administer a site that doesn't implement exceptions for AOL and Yahoo!'s p=reject policies, and I'll happily extend those exceptions to any p=reject sites that are sources of non-transactional mail flows to my users. I cannot see that as a good thing, but without an eventual mandatory p=reject, the whole I-D is pointless. A big fat -1. Steve From nobody Thu Mar 17 09:52:43 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A17712D7CF for ; Thu, 17 Mar 2016 09:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TCkgbEY4lmFj for ; Thu, 17 Mar 2016 09:52:40 -0700 (PDT) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EBE412D680 for ; Thu, 17 Mar 2016 09:52:40 -0700 (PDT) Received: by mail-ig0-x22e.google.com with SMTP id ig19so1468691igb.1 for ; Thu, 17 Mar 2016 09:52:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:date:message-id:subject:from:to:cc; bh=tD62bxAOyktib5ovDAEHpMAw9/winuqe4D9LAZI+2ws=; b=TGjZQaDzXMGdDaV0GvAUkfqdAcAy1bSFK7MGl7Q2RMSwsQ2geQh9Htvhf9PNsf7U9D 7foFgDxZnaN2wSGmrOMYnLGC9tvCw2m6XFjSMqpG/H1XNzgB10LIWqZ1l+2VlgRDW2ca jufJlSAJuQPTGIgW5dTRegwoPzWRu+f9TNzzE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to:cc; bh=tD62bxAOyktib5ovDAEHpMAw9/winuqe4D9LAZI+2ws=; b=ZKZ0uot1O03ba7MDlwGgJHEmZMoapLBbch9IRIxn8zsD/x54s1bPAn8xrn8jNheU16 yqqPEgGbdhjMxGeTOqoxbZUN60K6LIBQFmJSEn4pO9nqcMIg+89VHbjGi61ms7Ksh17F pvGpfRjj6tZJJeSvHDjX++mT/0HVkJzZZzgtRVo8xvC1/Fu6F/DhxxSd2wPSTaETHDNh Bs/VM2Pz6y85GwqL/VE2NOof7klvSxVBv9t+Q7Nv5S7uXQwX1pEWJ1MI93LjQATb7nAM 0jM2QLM5byUuvAuFHxpxyD4H7xnzaL1jNMgNNmS9b4DHmr7uQcDOWWbI0CF3P6K3fODI nI7w== X-Gm-Message-State: AD7BkJI/QkDvv5NT0Ek/NDw6FHyK4d8MOyyyUQtSvCTmZ9crDEhu1bbIRHNnVtM5g6O+klJznF5r5nEsoW5abQ== MIME-Version: 1.0 X-Received: by 10.50.72.82 with SMTP id b18mr6868401igv.79.1458233559387; Thu, 17 Mar 2016 09:52:39 -0700 (PDT) Sender: kurta@drkurt.com Received: by 10.107.201.16 with HTTP; Thu, 17 Mar 2016 09:52:39 -0700 (PDT) Date: Thu, 17 Mar 2016 09:52:39 -0700 X-Google-Sender-Auth: TsttFv56GJfqluue3IuiJxK_abs Message-ID: From: "Kurt Andersen (b)" To: Terry Zink Content-Type: multipart/alternative; boundary=047d7bdc9e764eb49e052e4175e4 Archived-At: Cc: dmarc Subject: Re: [dmarc-ietf] I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 16:52:42 -0000 --047d7bdc9e764eb49e052e4175e4 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 15, 2016 at 1:04 PM, Terry Zink wrote: > Office 365 already supports something like this for our customers to cut > down on Business Email Compromise. Maybe 5% of our customers have DMARC > records, yet we treat all inbound email destined to them as having > p=quarantine and then we figure out roughly who is allowed to send email as > them even when (especially when) they don't authenticate. I talk about this > here: http://aka.ms/AntispoofingInOffice365. Having special policies to prevent self-spoofing is, IMO, entirely different from using domain authentication mechanisms to protect mail streams from non-self entities. For instance, I've always wondered why people (try to) use public SPF records as a mechanism to figure out which mail servers they, themselves, send mail from. Anti-self-spoofing mechanisms to protect against BEC are important for hosted email solutions like Office365, but I still question whether general domain authentication mechanisms like SPF, DKIM, DMARC are the right tools to use for such purpose. I also don't see that as a justification for something like this I-D. --Kurt Andersen --047d7bdc9e764eb49e052e4175e4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Mar 15, 2016 at 1:04 PM, Terry Zink <tzink@exchange.microso= ft.com> wrote:
Office 365 a= lready supports something like this for our customers to cut down on Busine= ss Email Compromise. Maybe 5% of our customers have DMARC records, yet we t= reat all inbound email destined to them as having p=3Dquarantine and then w= e figure out roughly who is allowed to send email as them even when (especi= ally when) they don't authenticate. I talk about this here: http://aka.ms/AntispoofingInOffice365.

Having special policies to prevent self-spoofing is= , IMO, entirely different from using domain authentication mechanisms to pr= otect mail streams from non-self entities. For instance, I've always wo= ndered why people (try to) use public SPF records as a mechanism to figure = out which mail servers they, themselves, send mail from.

Anti-self-spoofing mecha= nisms to protect against BEC are important for hosted email solutions like = Office365, but I still question whether general domain authentication mecha= nisms like SPF, DKIM, DMARC are the right tools to use for such purpose.

I also d= on't see that as a justification for something like this I-D.

--Kurt Andersen=
--047d7bdc9e764eb49e052e4175e4-- From nobody Thu Mar 17 09:59:34 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 166BA12D626 for ; Thu, 17 Mar 2016 09:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=peachymango.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywbQEAYAZ086 for ; Thu, 17 Mar 2016 09:59:30 -0700 (PDT) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id D19F012D6BA for ; Thu, 17 Mar 2016 09:58:54 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 99554563E0C; Thu, 17 Mar 2016 11:58:53 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 87C51A0289; Thu, 17 Mar 2016 11:58:53 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6Ruh83TS_m0; Thu, 17 Mar 2016 11:58:53 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 49B2CA0355; Thu, 17 Mar 2016 11:58:53 -0500 (CDT) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-1.01.com 49B2CA0355 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1458233933; bh=k/pbt3jxm+Oc166LZ7u9nj2o4lA0/bhS1/BpJBy44yo=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; b=FlT/yvGi69Ga2orS/aohs5yt5lft0Afx0DlJMbz8/ZFYgZQVu3mgLSnpSTwoVfOma Gn8Ytp1ssHQomKeFtbMfS7d82dLxtb4AuTGx7GOK/WRwxUNOM+a09nAFtDwE8PDGXo +eGcK51vQI3b2SS+72OKhbH0N/uof76TmFxMnMhE= Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 17BC1A0342; Thu, 17 Mar 2016 11:58:53 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id w6ufp6nwHFBN; Thu, 17 Mar 2016 11:58:53 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-1.01.com (Postfix) with ESMTP id 64675A0289; Thu, 17 Mar 2016 11:58:52 -0500 (CDT) Date: Thu, 17 Mar 2016 11:58:51 -0500 (CDT) From: Franck Martin To: "Kurt Andersen (b)" Message-ID: <1091919919.43972.1458233931938.JavaMail.zimbra@peachymango.org> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_43971_82478662.1458233931937" X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF44 (Mac)/8.0.5_GA_5839) Thread-Topic: I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt Thread-Index: kNuNIx6ybqJjyJ1y8xftn/V56BtqqQ== Archived-At: Cc: dmarc , Terry Zink Subject: Re: [dmarc-ietf] I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 16:59:33 -0000 ------=_Part_43971_82478662.1458233931937 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit ----- Original Message ----- > From: "Kurt Andersen (b)" > To: "Terry Zink" > Cc: "dmarc" > Sent: Thursday, March 17, 2016 9:52:39 AM > Subject: Re: [dmarc-ietf] I-D Action: > draft-akagiri-dmarc-virtual-verification-00.txt > On Tue, Mar 15, 2016 at 1:04 PM, Terry Zink < tzink@exchange.microsoft.com > > wrote: > > Office 365 already supports something like this for our customers to cut > > down > > on Business Email Compromise. Maybe 5% of our customers have DMARC records, > > yet we treat all inbound email destined to them as having p=quarantine and > > then we figure out roughly who is allowed to send email as them even when > > (especially when) they don't authenticate. I talk about this here: > > http://aka.ms/AntispoofingInOffice365 . > > Having special policies to prevent self-spoofing is, IMO, entirely different > from using domain authentication mechanisms to protect mail streams from > non-self entities. For instance, I've always wondered why people (try to) > use public SPF records as a mechanism to figure out which mail servers they, > themselves, send mail from. > Anti-self-spoofing mechanisms to protect against BEC are important for hosted > email solutions like Office365, but I still question whether general domain > authentication mechanisms like SPF, DKIM, DMARC are the right tools to use > for such purpose. > I also don't see that as a justification for something like this I-D. Yes, it should not be normative, documented is fine. I prefer documented than part of the secret sauce... I'm more concerned that the implementation at Microsoft does not reject the message when p=reject but move the email to the spam folder (with all payloads disabled, etc...) treating p=nil (no policy) may seem for someone outside about the same than for p=none|quarantine|reject. ------=_Part_43971_82478662.1458233931937 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
From: "Kurt Andersen (b)" <kboth@drkurt= .com>
To: "Terry Zink" <tzink@exchange.microsoft.com>Cc: "dmarc" <dmarc@ietf.org>
Sent: Thursday, March = 17, 2016 9:52:39 AM
Subject: Re: [dmarc-ietf] I-D Action: draft-a= kagiri-dmarc-virtual-verification-00.txt

On Tue, Mar 15, 2016= at 1:04 PM, Terry Zink <tzink@exchange.microsoft.com> wrote:
Office 365 already supports = something like this for our customers to cut down on Business Email Comprom= ise. Maybe 5% of our customers have DMARC records, yet we treat all inbound= email destined to them as having p=3Dquarantine and then we figure out rou= ghly who is allowed to send email as them even when (especially when) they = don't authenticate. I talk about this here: http://aka.ms/Antis= poofingInOffice365.

Having special policies to prevent self-spoofing is, IMO, entirely diff= erent from using domain authentication mechanisms to protect mail streams f= rom non-self entities. For instance, I've always wondered why people (try t= o) use public SPF records as a mechanism to figure out which mail servers t= hey, themselves, send mail from.

=
Anti-self-spoofing mechanisms to protect against= BEC are important for hosted email solutions like Office365, but I still q= uestion whether general domain authentication mechanisms like SPF, DKIM, DM= ARC are the right tools to use for such purpose.

I also don't see that as a justi= fication for something like this I-D.

<= /div>

Yes, it should not be normative, documente= d is fine. I prefer documented than part of the secret sauce...

I'm more concerned that the implementation at Microsoft d= oes not reject the message when p=3Dreject but move the email to the spam f= older (with all payloads disabled, etc...) treating p=3Dnil (no policy) may= seem for someone outside about the same than for p=3Dnone|quarantine|rejec= t.

------=_Part_43971_82478662.1458233931937-- From nobody Thu Mar 17 11:04:42 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EBEE12DA1A for ; Thu, 17 Mar 2016 11:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.303 X-Spam-Level: X-Spam-Status: No, score=-4.303 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 erag3IiLT9tW for ; Thu, 17 Mar 2016 11:04:35 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A97B912D9CD for ; Thu, 17 Mar 2016 11:04:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1458237873; bh=SF7RKRS9NEm1QNQTi0i9/ocxnvucenv28G0oIfT7NKE=; l=1423; h=To:References:From:Date:In-Reply-To; b=B2OlYYVwpDwsuyJWRYVFybnVFLKq9/wyqY9r709Mil6AJeyMj7yucxTvwLC1xHUUy a3Vw5Dk8+A4anVgFBde/9boTvap9Whcs8olPDDoro7KRL4hezEF7bE8S9XcwmWIvXI QuzbLkP0DBkB/F6eAWW1ae593gq+ao2pr5lPZgNI= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.88] (pcale.tana [172.25.197.88]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Thu, 17 Mar 2016 19:04:32 +0100 id 00000000005DC033.0000000056EAF1B0.00001806 To: dmarc@ietf.org References: <56E88C43.2050806@tomki.com> <2039296774.26888.1458083423836.JavaMail.zimbra@peachymango.org> <56E9A25C.2080607@tomki.com> From: Alessandro Vesely Message-ID: <56EAF1B0.2050400@tana.it> Date: Thu, 17 Mar 2016 19:04:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.6.0 MIME-Version: 1.0 In-Reply-To: <56E9A25C.2080607@tomki.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] SPFAuthResultType unbounded X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 18:04:40 -0000 On Wed 16/Mar/2016 19:13:48 +0100 Tomki wrote: > > For a concrete example, please see the attached XML record object. > There are 1834 messages reported in this object by 'count', but 312 SPF items > reported. I guess if these were all either pass or failure cases, and the > counts lined up I could disambiguate properly, but as it stands I don't think > it's comprehensible. It looks a bug to me. It contains results for 312 domains and 2 results for tomki.com. The domains seem to be a mixture of "helo" and "mfrom" (e.g. bounce.secureserver.net must have been "mfrom", since it passed; the hundreds of domains like "p3plcpnl[0-9]+.prod.phx3.secureserver.net" must have been "helo", unless there is some sort of helo-attack underway). I agree with Les that rows ought to be split by result type. The report doesn't disclose how 1834 messages are distributed over 312 domains. IMHO, *reporting the bug is better than tightening the specs*. BTW, isn't there any monitoring service which sends a few email from a couple of domains and verifies the aggregate feedback? A semantic check would have to send various messages with varying authentication methods from a few domains with varying dmarc policies, and then verify that the reports from the target domain are consistent with what was sent. I checked out dmarcian and dmarcanalyzer, but neither seems to do that. Ale From nobody Thu Mar 17 15:23:26 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B08D12DD4E for ; Thu, 17 Mar 2016 15:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=exchange.microsoft.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 A3tQX8edVRx5 for ; Thu, 17 Mar 2016 15:23:22 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0111.outbound.protection.outlook.com [207.46.100.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C058C12DD45 for ; Thu, 17 Mar 2016 15:23:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=exchange.microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=JFrYRqOyMONqfaoa6DaYaGbqtEJXM/NygX6bqac0gYM=; b=KMH4F9xXw0DdjLJ/IppyDsmY39/EmNRZxew+EfureILV7noJzXJrIEtu2ZWQWnIMp7ePP27+6JMOq3YWG0gQ8JGP3XnPNa+Tke+FpWfXSJCcuEcslVayHPNlcoG7qm1FVfobDs8ph+Hc2NYArtjZbQgPWK7wiqxvmb5BEOQtjDI= Received: from BY1PR00MB0005.namprd00.prod.outlook.com (10.160.107.18) by BY1PR00MB0005.namprd00.prod.outlook.com (10.160.107.18) with Microsoft SMTP Server (TLS) id 15.1.453.2; Thu, 17 Mar 2016 22:23:21 +0000 Received: from BY1PR00MB0005.namprd00.prod.outlook.com ([10.160.107.18]) by BY1PR00MB0005.namprd00.prod.outlook.com ([10.160.107.18]) with mapi id 15.01.0453.002; Thu, 17 Mar 2016 22:23:21 +0000 From: Terry Zink To: dmarc Thread-Topic: [dmarc-ietf] I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt Thread-Index: kAHRgG1qOv7CJWcfnEWf13ajirEjOp9eNl3Q Date: Thu, 17 Mar 2016 22:23:20 +0000 Message-ID: References: <1091919919.43972.1458233931938.JavaMail.zimbra@peachymango.org> In-Reply-To: <1091919919.43972.1458233931938.JavaMail.zimbra@peachymango.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=exchange.microsoft.com; x-originating-ip: [2001:4898:80e8:6::276] x-ms-office365-filtering-correlation-id: 26b55aba-8c02-45a2-9232-08d34eb2bf5d x-microsoft-exchange-diagnostics: 1; BY1PR00MB0005; 5:wM84Nopq6A56Gr0dpo2DIrryEGJ8FzuoPjoDHNBskx9CKjEPxffGLpMcgoOXwoGEGIBYV22hDxeO/7272pFWUogtHDA52XtffujnqZM2JdjPEz4YJzJhvMjXNmH4aBiyZtuGJBtFNN5aVCkVOP8+qw==; 24:FW7yYMm8Cq3iLxkAyYB5JVSy7yZR2tvBkeLI0IgTlo6Jfm7w66d+yXHtLa6+pMKbOZUYO2pO3OkuGUfQGQfyzsQXMisWebioz7WpKooNUAM= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR00MB0005; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BY1PR00MB0005; BCL:0; PCL:0; RULEID:; SRVR:BY1PR00MB0005; x-forefront-prvs: 0884AAA693 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(19300405004)(1740400002)(122556002)(5002640100001)(54356999)(2420400007)(15650500001)(99286002)(5004730100002)(189998001)(81166005)(50986999)(450100001)(107886002)(558084003)(15975445007)(77096005)(19580395003)(2900100001)(2950100001)(110136002)(6116002)(87936001)(10710500007)(790700001)(586003)(5003600100002)(1220700001)(1096002)(102836003)(19609705001)(86362001)(76176999)(2906002)(76576001)(16236675004)(8990500004)(33656002)(74316001)(10290500002)(5005710100001)(10400500002)(3280700002)(92566002)(11100500001)(230783001)(3660700001)(5008740100001)(19625215002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR00MB0005; H:BY1PR00MB0005.namprd00.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY1PR00MB0005B8B88863606A4411C387968B0BY1PR00MB0005namp_" MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2016 22:23:20.9847 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR00MB0005 Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 22:23:25 -0000 --_000_BY1PR00MB0005B8B88863606A4411C387968B0BY1PR00MB0005namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBJJ20gbW9yZSBjb25jZXJuZWQgdGhhdCB0aGUgaW1wbGVtZW50YXRpb24gYXQgTWljcm9zb2Z0 IGRvZXMgbm90DQo+IHJlamVjdCB0aGUgbWVzc2FnZSB3aGVuIHA9cmVqZWN0IGJ1dCBtb3ZlIHRo ZSBlbWFpbCB0byB0aGUgc3BhbQ0KPiBmb2xkZXIgKHdpdGggYWxsIHBheWxvYWRzIGRpc2FibGVk LCBldGMuLi4pDQoNCkl04oCZcyBkb25lIHRoaXMgd2F5IGJlY2F1c2UgaXQgd29ya3MgYmV0dGVy IGZvciBvdXIgb3ZlcmFsbCB1c2VyIGJhc2UgdGhhbiBmbGF0LW91dCByZWplY3RpbmcgdGhlIG1l c3NhZ2UgaW4gU01UUC4NCg0K --_000_BY1PR00MB0005B8B88863606A4411C387968B0BY1PR00MB0005namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVC My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S RUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBj b250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEt LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2Ft YnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9 DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2 Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0K YTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5N c29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVy cGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBs aS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJp b3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4t Ym90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJp ZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibGFjazt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6 MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZndDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+SSdtIG1vcmUgY29uY2VybmVkIHRoYXQgdGhlIGltcGxlbWVudGF0aW9uIGF0IE1p Y3Jvc29mdCBkb2VzIG5vdA0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPiZndDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+cmVq ZWN0IHRoZSBtZXNzYWdlIHdoZW4gcD1yZWplY3QgYnV0IG1vdmUgdGhlIGVtYWlsIHRvIHRoZSBz cGFtDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxicj4NCiZndDsgPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj5mb2xkZXIgKHdpdGggYWxsIHBheWxvYWRzIGRpc2FibGVkLCBldGMu Li4pDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5JdOKAmXMgZG9uZSB0aGlz IHdheSBiZWNhdXNlIGl0IHdvcmtzIGJldHRlciBmb3Igb3VyIG92ZXJhbGwgdXNlciBiYXNlIHRo YW4gZmxhdC1vdXQgcmVqZWN0aW5nIHRoZSBtZXNzYWdlIGluIFNNVFAuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_BY1PR00MB0005B8B88863606A4411C387968B0BY1PR00MB0005namp_-- From nobody Thu Mar 17 16:21:37 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E682512DDAB for ; Thu, 17 Mar 2016 16:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=agari.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhXK111ElgUl for ; Thu, 17 Mar 2016 16:21:31 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2BE912DDA0 for ; Thu, 17 Mar 2016 16:21:31 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id m184so118337468iof.1 for ; Thu, 17 Mar 2016 16:21:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=agari.com; s=s1024; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=J8JVtM3JyWj4CwTo2CGcndPN6H70ftJL7pH+tTLeL8c=; b=VCJZMTYLJNcaX4G+NobPOd/HUppy+C9pC6zX1KmOEvLrKcDOOUbOtrSMpKFCTb5qDV vosnirM271YULSnrKR9LXsYz7HHYUfhNX/70QlKOHEScl7ifb4VVeLuNrDgKDHPkbpQB hmsXFYi4B7ltSrwWCLvmN9nbekoU5zW8eWk00= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=J8JVtM3JyWj4CwTo2CGcndPN6H70ftJL7pH+tTLeL8c=; b=X6AgEUV5UfsjaITNWc7udhJT89G5t/WmXUn0/4bp3ncgGEJA6R7fc8gkB2mF3kVSzH Cq5E1HMVrjGaEIGjagB3XIuH72ZqCbuyGWlO0ODeSme9jZH9sNx30wlcz1QV8Dj7GxcE BOykikHvksU0p8yDUmdRozXm1Lfu+vOCSWN3Qo9BMSnWw208OIQe7qNsLlGQ3MjDoSPc DyqifNqUG6mSZofg+kyEn+6UbMRbP8OE23Z8ew9bEDjdlWdRXq5hJq22ntcgitcSg+sX Yaf6LpdeIAKSdM05acuHACdh26BFtx/5qpoMLJMuqaiT+9G4RgalsfjeqWFQEczfZ3lF nc3A== X-Gm-Message-State: AD7BkJL+6pD15pY3CNRik26fspjviPnqPU9Exo2nQeU07AJMZ50Jz5CFzjPCvz0JHGWiNZjMo2DyCRorafYtBwW5 X-Received: by 10.107.165.140 with SMTP id o134mr14608209ioe.62.1458256891008; Thu, 17 Mar 2016 16:21:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.222.165 with HTTP; Thu, 17 Mar 2016 16:21:11 -0700 (PDT) In-Reply-To: <56EAF1B0.2050400@tana.it> References: <56E88C43.2050806@tomki.com> <2039296774.26888.1458083423836.JavaMail.zimbra@peachymango.org> <56E9A25C.2080607@tomki.com> <56EAF1B0.2050400@tana.it> From: Tomki Camp Date: Thu, 17 Mar 2016 16:21:11 -0700 Message-ID: To: Alessandro Vesely Content-Type: multipart/alternative; boundary=001a1141fb90fb1064052e46e31d Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] SPFAuthResultType unbounded X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 23:21:36 -0000 --001a1141fb90fb1064052e46e31d Content-Type: text/plain; charset=UTF-8 The bug was reported some time ago, and the spec was referenced as allowing the questionable data+format. I am of the opinion that tightening the spec is necessary in this case, both to prevent future implementations from making the same misinterpretation, and as reference for fixing the current problem. --Tomki On Thu, Mar 17, 2016 at 11:04 AM, Alessandro Vesely wrote: > On Wed 16/Mar/2016 19:13:48 +0100 Tomki wrote: > > > > For a concrete example, please see the attached XML record object. > > There are 1834 messages reported in this object by 'count', but 312 SPF > items > > reported. I guess if these were all either pass or failure cases, and > the > > counts lined up I could disambiguate properly, but as it stands I don't > think > > it's comprehensible. > > It looks a bug to me. It contains results for 312 domains and 2 > > results for tomki.com. The domains seem to be a mixture of "helo" > and > "mfrom" (e.g. bounce.secureserver.net must have been "mfrom", since it > passed; > the hundreds of domains like "p3plcpnl[0-9]+.prod.phx3.secureserver.net" > must > have been "helo", unless there is some sort of helo-attack underway). > > I agree with Les that rows ought to be split by result type. The report > doesn't disclose how 1834 messages are distributed over 312 domains. > > IMHO, *reporting the bug is better than tightening the specs*. > > BTW, isn't there any monitoring service which sends a few email from a > couple > of domains and verifies the aggregate feedback? A semantic check would > have to > send various messages with varying authentication methods from a few > domains > with varying dmarc policies, and then verify that the reports from the > target > domain are consistent with what was sent. I checked out dmarcian and > dmarcanalyzer, but neither seems to do that. > > Ale > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --001a1141fb90fb1064052e46e31d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The bug was reported some time ago, and the= spec was referenced as allowing the questionable data+format.
I a= m of the opinion that tightening the spec is necessary in this case, both t= o prevent future implementations from making the same misinterpretation, an= d as reference for fixing the current problem.


--Tom= ki


O= n Thu, Mar 17, 2016 at 11:04 AM, Alessandro Vesely <vesely@tana.it> wrote:
On Wed 16/Ma= r/2016 19:13:48 +0100 Tomki wrote:
>
> For a concrete example, please see the attached XML record object.
> There are 1834 messages reported in this object by 'count', bu= t 312 SPF items
> reported.=C2=A0 I guess if these were all either pass or failure cases= , and the
> counts lined up I could disambiguate properly, but as it stands I don&= #39;t think
> it's comprehensible.

It looks a bug to me.=C2=A0 It contains results for 312 <spf> = domains and 2 <dkim>
results for tomki.com.=C2=A0 The <spf> domains seem to be a mixture of &qu= ot;helo" and
"mfrom" (e.g. bounce.secureserver.net must have been &qu= ot;mfrom", since it passed;
the hundreds of domains like "p3plcpnl[0-9]+.prod.phx3.secures= erver.net" must
have been "helo", unless there is some sort of helo-attack underw= ay).

I agree with Les that rows ought to be split by result type.=C2=A0 The repo= rt
doesn't disclose how 1834 messages are distributed over 312 domains.
IMHO, *reporting the bug is better than tightening the specs*.

BTW, isn't there any monitoring service which sends a few email from a = couple
of domains and verifies the aggregate feedback?=C2=A0 A semantic check woul= d have to
send various messages with varying authentication methods from a few domain= s
with varying dmarc policies, and then verify that the reports from the targ= et
domain are consistent with what was sent.=C2=A0 I checked out dmarcian and<= br> dmarcanalyzer, but neither seems to do that.

Ale

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

--001a1141fb90fb1064052e46e31d-- From nobody Thu Mar 17 20:17:45 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14F2512DF10 for ; Thu, 17 Mar 2016 20:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMPuliqIWZjm for ; Thu, 17 Mar 2016 20:17:42 -0700 (PDT) Received: from lepidum.jp (lepidum.jp [60.32.83.213]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8B6312DF0D for ; Thu, 17 Mar 2016 20:17:42 -0700 (PDT) Received: from okadakoujinombp.local.lepidum.net (lepidum.net [60.32.83.208]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: okd@lepidum.co.jp) by mail06.server.lepidum.net (Postfix) with ESMTPSA id 038CB2F806A92; Fri, 18 Mar 2016 12:17:40 +0900 (JST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Kouji Okada In-Reply-To: Date: Fri, 18 Mar 2016 12:17:40 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <233B51DD-C6BB-464F-8206-D3D0CDD032DE@lepidum.co.jp> References: <1091919919.43972.1458233931938.JavaMail.zimbra@peachymango.org> To: dmarc X-Mailer: Apple Mail (2.3112) X-Clamav-Info: Checked(Clean) X-LepidumMailFilterAgent-by: mailfromd (5.1) X-LepidumMailFilterAgent-Info: Original (mailfrom:Inbound) Archived-At: Cc: Kouji Okada Subject: Re: [dmarc-ietf] I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2016 03:17:45 -0000 Thank you very much for your comments. Here I summarize and answer to the comments. First of all, I understand there are 3 topics we are discussing on the = ML so far. 1. Virtual verification for "p=3Dnone" (step 1 on Roadmap) 2. Virtual verification for "p=3Dquarantine and reject" (step 2, 3 on = Roadmap) 3. Needs for documentation ---------------------------------------------------------- 1. Virtual verification for "p=3Dnone" (step 1 on Roadmap) ---------------------------------------------------------- [Points] - Discussion about step 1 on Roadmap - We can use PASS without DMARC record - If there are no DMARC records for a domain, we can use PASS status. - Except for =E2=80=9CPASS=E2=80=9D, we don't need to any changes to = DMARC. - In case of no DMARC record, the Authentication-results code should = be "none". (RFC7489 11.2) [Comments and Answers] - C.1-1 We should not verify the domains not ready for DMARC. =E2=80=9Cp=3Dnone=E2=80=9D has no effect. A.1-1 Even in the case of =E2=80=9Cp=3Dnone=E2=80=9D, we can use the = authentication-result of =E2=80=9CPASS=E2=80=9D. For example, visual notifications to display the reliabilities of = received mails, or white lists. Senders not ready for DMARC are not ready for 1. receiving reports 2. negative verification results for the mails they send =E2=80=BB = except none I think they are ready to be verified as =E2=80=9CPASS=E2=80=9D. Additionally, if DMARC must be opt-in, why does RFC 7489 define the = authentication-results code in case of no DMARC record? (See 11.2 of RFC = 7489) About SPF best guess, virtual DMARC verification does not =E2=80=9Cguess=E2= =80=9D anything while SPF Best Guess guesses originated IP addresses. = --------------------------------------------------------------------------= --- 2. Virtual verification for "p=3Dquarantine and reject" (step 2, 3 on = Roadmap) = --------------------------------------------------------------------------= --- [points] - problem of step 2 and 3(p=3Dquarantine or p=3Dreject) - default rua and ruf in step 2 and 3 [Comments and Answers] - C.2-2 In the deployment steps of 2 and 3, they cause massive loss of = legitimate mails without reports. A.2-2 This is our 00 draft and we wrote about what we aim at for the future. I understand the deployment scenario needs to be discussed more in the = DMARC communities, and we are ready to delete the deployment steps 2 and 3 from the = document for now. Those steps might need more 10 years. However I think we should look ahead of the deployment after 5 or 10 = years. I understand that the ultimate goal of DMARC is to defend mail users from malicious activities such as phishing or spoofing. Concerned with SPF, most of the operators still do not publish the SPF = records with =E2=80=9C-all=E2=80=9D. When deployment steps 2 or 3 are applied, the operators who need the feedbacks just have to publish the DMARC = records with =E2=80=9Cruf=E2=80=9D and =E2=80=9Crua=E2=80=9D. We could define the default value for those parameters (ruf, rua). Because security technologies always have difficulties in their = deployments, I think we should make plans for the future deployment. --------------------------- 3. Needs for documentation (and editorial issues) --------------------------- [Points] - Do we need standard document? [Comments and Answers] C.3-1 It=E2=80=99s an internal processing issue and should not be = standardized. A.3-1 I think we need some informational document about the procedure to add =E2=80=9CDMARC=3Dpass=E2=80=9C in the = Authentication-Results without explicitly published DMARC records. The document may help operators who are trying to introduce DMARC = capability to their MTAs as a current practice. - C.3-2 In the last paragraph of Section 3, something may be missed. A.3-2 I should have written this in the beginning of the paragraph. This was somehow lost in the editing. =E2=80=9CWhen a DKIM verification passes utilizing the author domain = signatures,=E2=80=9D With this description, does the paragraph make sense? - C.3-3 Name. A.3-3 What would you think is suitable for the name of this verification? Any suggestions are welcome. From nobody Thu Mar 17 21:21:37 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9932D12D7F6 for ; Thu, 17 Mar 2016 21:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kitterman.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 d0rWn0Gm8ABW for ; Thu, 17 Mar 2016 21:21:33 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 558A212D76B for ; Thu, 17 Mar 2016 21:21:33 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 41A6DC4029A for ; Thu, 17 Mar 2016 23:21:32 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1458274892; bh=qog5DsZvJY1Eufy2mpMjDCQiQ+Eac1DmLTH6Z4znpGc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=wv24B6IuISOFt+eeWQngSbb1SBK6YIGRUQE5Iw+e8opBz7Aw+OqzoHAlH/M1oaaXa TR+t+nFduf1PPFNyw7FQSkruRpyxsB/IhjDQX0POWMjH0ForkaVz9mJzQ4kXs9UGOy a4Ui8o5cS0VymU5t35x9hFq0bt7jjrNyEWk9SKCg= From: Scott Kitterman To: dmarc Date: Fri, 18 Mar 2016 00:21:31 -0400 Message-ID: <3466577.32ZH9WUC9A@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-83-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <233B51DD-C6BB-464F-8206-D3D0CDD032DE@lepidum.co.jp> References: <233B51DD-C6BB-464F-8206-D3D0CDD032DE@lepidum.co.jp> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2016 04:21:35 -0000 On Friday, March 18, 2016 12:17:40 PM Kouji Okada wrote: > Thank you very much for your comments. > Here I summarize and answer to the comments. >=20 > First of all, I understand there are 3 topics we are discussing on th= e ML so > far. >=20 > 1. Virtual verification for "p=3Dnone" (step 1 on Roadmap) > 2. Virtual verification for "p=3Dquarantine and reject" (step 2, 3 on= Roadmap) > 3. Needs for documentation >=20 >=20 > ---------------------------------------------------------- > 1. Virtual verification for "p=3Dnone" (step 1 on Roadmap) > ---------------------------------------------------------- > [Points] > - Discussion about step 1 on Roadmap > - We can use PASS without DMARC record > - If there are no DMARC records for a domain, we can use PASS statu= s. > - Except for =E2=80=9CPASS=E2=80=9D, we don't need to any changes to = DMARC. > - In case of no DMARC record, the Authentication-results code shoul= d be > "none". (RFC7489 11.2) >=20 > [Comments and Answers] >=20 > - > C.1-1 We should not verify the domains not ready for DMARC. > =E2=80=9Cp=3Dnone=E2=80=9D has no effect. >=20 > A.1-1 > Even in the case of =E2=80=9Cp=3Dnone=E2=80=9D, we can use the authen= tication-result of > =E2=80=9CPASS=E2=80=9D. For example, visual notifications to display = the reliabilities of > received mails, or white lists. >=20 > Senders not ready for DMARC are not ready for > 1. receiving reports > 2. negative verification results for the mails they send =E2=80=BB e= xcept none >=20 > I think they are ready to be verified as =E2=80=9CPASS=E2=80=9D. >=20 > Additionally, if DMARC must be opt-in, why does RFC 7489 define the > authentication-results code in case of no DMARC record? (See 11.2 of = RFC > 7489) Because that is how non-participant results are recorded. > About SPF best guess, virtual DMARC verification does not =E2=80=9Cgu= ess=E2=80=9D anything > while SPF Best Guess guesses originated IP addresses. You are guessing that things like identifier alignment that are require= d to get=20 a DMARC like pass are consistently available for a domain that has not = opted=20 into DMARC. =20 >=20 > ---------------------------------------------------------------------= ------- > - 2. Virtual verification for "p=3Dquarantine and reject" (step 2, 3 = on > Roadmap) > ---------------------------------------------------------------------= ------ > -- [points] > - problem of step 2 and 3(p=3Dquarantine or p=3Dreject) > - default rua and ruf in step 2 and 3 >=20 > [Comments and Answers] >=20 > - > C.2-2 In the deployment steps of 2 and 3, they cause massive loss of > legitimate mails without reports. >=20 > A.2-2 > This is our 00 draft and we wrote about what we aim at for the future= . > I understand the deployment scenario needs to be discussed more in th= e DMARC > communities, and we are ready to delete the deployment steps 2 and 3 = from > the document for now. Those steps might need more 10 years. >=20 > However I think we should look ahead of the deployment after 5 or 10 = years. > I understand that the ultimate goal of DMARC is to defend mail users > from malicious activities such as phishing or spoofing. > Concerned with SPF, most of the operators still do not publish the SP= F > records with =E2=80=9C-all=E2=80=9D. When deployment steps 2 or 3 are= applied, > the operators who need the feedbacks just have to publish the DMARC r= ecords > with =E2=80=9Cruf=E2=80=9D and =E2=80=9Crua=E2=80=9D. We could define= the default value for those > parameters (ruf, rua). The mail flows associated with feedback reporting can be non-trivial. = It would=20 not be appropriate to start providing feedback that is not requested. = A=20 default report address would not be appropriate. If DMARC turns out to be a good idea in the long run, people will adopt= it, I=20 don't think your steps 2 and 3 will be needed. If in 5 - 10 years it t= urns=20 out to be needed, then write another draft then. There's no need to wo= rry=20 about it now. The future is not that predictable. > Because security technologies always have difficulties in their deplo= yments, > I think we should make plans for the future deployment. >=20 >=20 >=20 > --------------------------- > 3. Needs for documentation (and editorial issues) > --------------------------- > [Points] > - Do we need standard document? >=20 > [Comments and Answers] > C.3-1 It=E2=80=99s an internal processing issue and should not be sta= ndardized. >=20 > A.3-1 > I think we need some informational document > about the procedure to add =E2=80=9CDMARC=3Dpass=E2=80=9C in the Auth= entication-Results > without explicitly published DMARC records. > The document may help operators who are trying to introduce DMARC cap= ability > to their MTAs as a current practice. What you are proposing is not DMARC since the correct DMARC result for = these=20 domains is none. What might be appropriate to standardize, is a name f= or this=20 kind of check so that it can be distinguished between actual DMARC and = the=20 results associated with your proposal, although I don't particularly se= e the=20 advantage to do so over just including the appropriate SPF or DKIM resu= lts. > - > C.3-2 In the last paragraph of Section 3, something may be missed. >=20 > A.3-2 > I should have written this in the beginning of the paragraph. > This was somehow lost in the editing. >=20 > =E2=80=9CWhen a DKIM verification passes utilizing the author domain = signatures,=E2=80=9D >=20 > With this description, does the paragraph make sense? >=20 > - > C.3-3 Name. >=20 > A.3-3 > What would you think is suitable for the name of this verification? > Any suggestions are welcome. I don't have any good ideas about a name, but I do think it's important= that=20 it be something other than DMARC since it's not done in accordance with= the=20 DMARC processing. Scott K From nobody Fri Mar 18 00:32:12 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F79312D642 for ; Fri, 18 Mar 2016 00:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RP_MATCHES_RCVD=-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 4r10B3Fe4aNX for ; Fri, 18 Mar 2016 00:32:09 -0700 (PDT) Received: from turnbull.sk.tsukuba.ac.jp (turnbull.sk.tsukuba.ac.jp [130.158.96.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4F2812D94B for ; Fri, 18 Mar 2016 00:32:08 -0700 (PDT) Received: from steve by turnbull.sk.tsukuba.ac.jp with local (Exim 4.86) (envelope-from ) id 1agotD-0006d6-5k for dmarc@ietf.org; Fri, 18 Mar 2016 16:32:07 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <22251.44791.131009.222848@turnbull.sk.tsukuba.ac.jp> Date: Fri, 18 Mar 2016 16:32:07 +0900 From: "Stephen J. Turnbull" To: DMARC discussion In-Reply-To: References: <1091919919.43972.1458233931938.JavaMail.zimbra@peachymango.org> X-Mailer: VM 8.2.0b under 21.5 (beta34) "kale" dcd7dca8d70b XEmacs Lucid (x86_64-apple-darwin15.2.0) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: steve@turnbull.sk.tsukuba.ac.jp X-SA-Exim-Scanned: No (on turnbull.sk.tsukuba.ac.jp); SAEximRunCond expanded to false Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2016 07:32:11 -0000 Terry Zink writes: > Franck Martin writes: > > I'm more concerned that the implementation at Microsoft does not > > reject the message when p=3Dreject but move the email to the spam > > folder (with all payloads disabled, etc...) >=20 > It=E2=80=99s done this way because it works better for our overall u= ser > base than flat-out rejecting the message in SMTP. This has been obvious to mailing lists from the very beginning. I understand the rationale for reject in the case of transactional mail flows, but for that, the p values should have been "unauthorized" [please reject], "suspicious" [do not deliver normally], and "none" [no inference or action needed], with the bracketed text being glossed in the text. And there should have been language in the RFC making clear that originating systems are really refusing to authorize mail flows that fail From alignment, including prospectively (eg, mailing lists whose processing invalidates DKIM signatures should reject). @Franck: I'm sorry, I understand why your use case wants "reject" to mean reject, but it wasn't in the cards given use cases like Yahoo!/ AOL. Receivers simply were not going to throw away large quantities of "good" mail their users actually requested, and Mediators weren't going to stop providing their value-added processing or violate RFCs for you. I don't recall you pushing hard for a clear "use only for transaction flows" clause in the RFC, nobody really did. Without that, such mechanisms always find other uses, which make a hard-line policy untenable for other communities. Please accept that, and think instead about the next step. For example, GNU Mailman is currently working[1] on implementing Authenticated Received Chain, an I-D with some promise for alleviating the pain of mailing lists receiving posts from p=3Dreject sites. Footnotes:=20 [1] Yes, we recognize that this kind of processing is much better done in the MTA. However, many mom-and-pop lists don't have control over their MTA, but do have control over Mailman. From nobody Fri Mar 18 00:35:12 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5028C12D642 for ; Fri, 18 Mar 2016 00:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RP_MATCHES_RCVD=-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 txGXn4Z7xwVd for ; Fri, 18 Mar 2016 00:35:08 -0700 (PDT) Received: from turnbull.sk.tsukuba.ac.jp (turnbull.sk.tsukuba.ac.jp [130.158.96.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B847412D5D7 for ; Fri, 18 Mar 2016 00:35:08 -0700 (PDT) Received: from steve by turnbull.sk.tsukuba.ac.jp with local (Exim 4.86) (envelope-from ) id 1agow7-0006ei-J8; Fri, 18 Mar 2016 16:35:07 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <22251.44971.534487.599194@turnbull.sk.tsukuba.ac.jp> Date: Fri, 18 Mar 2016 16:35:07 +0900 From: "Stephen J. Turnbull" To: Kouji Okada In-Reply-To: <233B51DD-C6BB-464F-8206-D3D0CDD032DE@lepidum.co.jp> References: <1091919919.43972.1458233931938.JavaMail.zimbra@peachymango.org> <233B51DD-C6BB-464F-8206-D3D0CDD032DE@lepidum.co.jp> X-Mailer: VM 8.2.0b under 21.5 (beta34) "kale" dcd7dca8d70b XEmacs Lucid (x86_64-apple-darwin15.2.0) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: steve@turnbull.sk.tsukuba.ac.jp X-SA-Exim-Scanned: No (on turnbull.sk.tsukuba.ac.jp); SAEximRunCond expanded to false Archived-At: Cc: dmarc Subject: Re: [dmarc-ietf] I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2016 07:35:11 -0000 Kouji Okada writes: > [Comments and Answers] >=20 > - C.2-2 In the deployment steps of 2 and 3, they cause massive loss > of legitimate mails without reports. >=20 > A.2-2 > This is our 00 draft and we wrote about what we aim at for the futur= e. But you seem to ignore what has happened in the past. To many receivers (including some of the largest freemail providers as well some enterprise providers) "p=3Dreject" already means "be careful", not= "reject".[1] For at least one 800-lb gorilla in the field, since *before* April 2014. If you try to make quarantine or reject mandatory for non-participants, many sites will simply ignore your protocol, and many others will weaken it as is already done for explicit policies. Why do you think they would do otherwise? > I understand that the ultimate goal of DMARC is to defend mail > users from malicious activities such as phishing or spoofing. It is. That doesn't mean it's possible to do so perfectly, and we've had ample demonstration that the DMARC p=3Dreject protocol is imperfect= . (That doesn't mean it is inherently flawed; it just means that it is insufficient for perfect protection.) Earlier in this thread, Franck Martin (who represents the original DMARC use case of "transactional" mail flows such as banks) wrote "I'm worried that a large mail provider doesn't reject when the apparent originator says reject", and Terry Zink (who represents a general provider of mail services, whose users receive indirect flows putatively from p=3Dreject sites) replied "that would harm our users, so we do something different to keep them safe." Most sites that don't publish DMARC records just plain don't need them, and would publish "none" anyway if forced to. Receivers won't wait for them to catch up, so Franck will be displeased by the proliferation of sites that disregard reject in favor of alternative disposition, and Terry will continue to provide users with exactly those alternatives. This is already an unpleasant situation, your proposal can't make it better (unless you can get rid of "p=3Dnone", too!), and arguably will make it worse. > [Comments and Answers] > C.3-1 It=E2=80=99s an internal processing issue and should not be st= andardized. >=20 > A.3-1 > I think we need some informational document > about the procedure to add =E2=80=9CDMARC=3Dpass=E2=80=9C in the Aut= hentication-Results > without explicitly published DMARC records. > The document may help operators who are trying to introduce DMARC > capability to their MTAs as a current practice. If there is no published DMARC record, you're just guessing. A DMARC record might be published at any level of para.subsub.sub.domain.tld. I don't see how you can say that mbox@sub.domain.tld would necessarily exhibit DMARC From alignment or not, because "Administrative Domain" is poorly defined. In DMARC practice it's an heuristic for guessing where to query for a DMARC record. This cannot be deduced from the DKIM signature. On the other hand, some efforts are being made to come up with an effective protocol for determining the responsible administrative domain. What if they succeed, and disagree with your procedure? That would be a mess, and hardly helpful. Nevertheless, for a receiver with good records of historical mail flows, appropriate analytical capability, and mail admins who know what they're doing, "implicit From alignment" might be a useful variable for their filtering and reputation systems. Similarly, it might be a useful factor for spam filtering applications and services to consider. Nobody denies that. The problem is that your I-D trying to impose behavior on receivers that is not beneficial to their users: they will Just Say No. Footnotes:=20 [1] Of course "be careful" is parametrized by domain: for these receivers, for mail from bankofamerica.com "be careful" means "reject", while for mail from stanford.edu it means "quarantine" (at worst). From nobody Fri Mar 18 07:17:09 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49E3F12D54E for ; Fri, 18 Mar 2016 07:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7L9-4uDbh6o for ; Fri, 18 Mar 2016 07:17:05 -0700 (PDT) Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.41]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 896C312D593 for ; Fri, 18 Mar 2016 07:17:05 -0700 (PDT) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES531.agna.amgreetings.com ([::1]) with mapi id 14.03.0266.001; Fri, 18 Mar 2016 10:17:04 -0400 From: "MH Michael Hammer (5304)" To: "Stephen J. Turnbull" , DMARC discussion Thread-Topic: [!!Mass Mail]Re: [dmarc-ietf] I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt Thread-Index: AdGBINePDZQKvwyjT12ALyM/9Bg7+A== Date: Fri, 18 Mar 2016 14:17:03 +0000 Message-ID: References: <1091919919.43972.1458233931938.JavaMail.zimbra@peachymango.org> <22251.44791.131009.222848@turnbull.sk.tsukuba.ac.jp> In-Reply-To: <22251.44791.131009.222848@turnbull.sk.tsukuba.ac.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.144.15.220] x-kse-attachmentfiltering-interceptor-info: protection disabled x-kse-serverinfo: USCLES531.agna.amgreetings.com, 9 x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean, bases: 3/18/2016 8:50:00 AM x-kse-dlp-scaninfo: Skipped Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [dmarc-ietf] [!!Mass Mail]Re: I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2016 14:17:08 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogZG1hcmMgW21haWx0bzpk bWFyYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU3RlcGhlbiBKLg0KPiBUdXJuYnVs bA0KPiBTZW50OiBGcmlkYXksIE1hcmNoIDE4LCAyMDE2IDM6MzIgQU0NCj4gVG86IERNQVJDIGRp c2N1c3Npb24NCj4gU3ViamVjdDogWyEhTWFzcyBNYWlsXVJlOiBbZG1hcmMtaWV0Zl0gSS1EIEFj dGlvbjogZHJhZnQtYWthZ2lyaS1kbWFyYy12aXJ0dWFsLQ0KPiB2ZXJpZmljYXRpb24tMDAudHh0 DQo+IA0KPiBUZXJyeSBaaW5rIHdyaXRlczoNCj4gID4gRnJhbmNrIE1hcnRpbiB3cml0ZXM6DQo+ IA0KPiAgPiA+IEknbSBtb3JlIGNvbmNlcm5lZCB0aGF0IHRoZSBpbXBsZW1lbnRhdGlvbiBhdCBN aWNyb3NvZnQgZG9lcyBub3QgID4gPg0KPiByZWplY3QgdGhlIG1lc3NhZ2Ugd2hlbiBwPXJlamVj dCBidXQgbW92ZSB0aGUgZW1haWwgdG8gdGhlIHNwYW0gID4gPg0KPiBmb2xkZXIgKHdpdGggYWxs IHBheWxvYWRzIGRpc2FibGVkLCBldGMuLi4pICA+ICA+IEl04oCZcyBkb25lIHRoaXMgd2F5IGJl Y2F1c2UgaXQNCj4gd29ya3MgYmV0dGVyIGZvciBvdXIgb3ZlcmFsbCB1c2VyICA+IGJhc2UgdGhh biBmbGF0LW91dCByZWplY3RpbmcgdGhlIG1lc3NhZ2UNCj4gaW4gU01UUC4NCj4gDQo+IFRoaXMg aGFzIGJlZW4gb2J2aW91cyB0byBtYWlsaW5nIGxpc3RzIGZyb20gdGhlIHZlcnkgYmVnaW5uaW5n LiAgSSB1bmRlcnN0YW5kDQo+IHRoZSByYXRpb25hbGUgZm9yIHJlamVjdCBpbiB0aGUgY2FzZSBv ZiB0cmFuc2FjdGlvbmFsIG1haWwgZmxvd3MsIGJ1dCBmb3IgdGhhdCwNCj4gdGhlIHAgdmFsdWVz IHNob3VsZCBoYXZlIGJlZW4gInVuYXV0aG9yaXplZCINCj4gW3BsZWFzZSByZWplY3RdLCAic3Vz cGljaW91cyIgW2RvIG5vdCBkZWxpdmVyIG5vcm1hbGx5XSwgYW5kICJub25lIg0KPiBbbm8gaW5m ZXJlbmNlIG9yIGFjdGlvbiBuZWVkZWRdLCB3aXRoIHRoZSBicmFja2V0ZWQgdGV4dCBiZWluZyBn bG9zc2VkIGluIHRoZQ0KPiB0ZXh0LiAgQW5kIHRoZXJlIHNob3VsZCBoYXZlIGJlZW4gbGFuZ3Vh Z2UgaW4gdGhlIFJGQyBtYWtpbmcgY2xlYXIgdGhhdA0KPiBvcmlnaW5hdGluZyBzeXN0ZW1zIGFy ZSByZWFsbHkgcmVmdXNpbmcgdG8gYXV0aG9yaXplIG1haWwgZmxvd3MgdGhhdCBmYWlsIEZyb20N Cj4gYWxpZ25tZW50LCBpbmNsdWRpbmcgcHJvc3BlY3RpdmVseSAoZWcsIG1haWxpbmcgbGlzdHMg d2hvc2UgcHJvY2Vzc2luZw0KPiBpbnZhbGlkYXRlcyBES0lNIHNpZ25hdHVyZXMgc2hvdWxkIHJl amVjdCkuDQo+IA0KPiBARnJhbmNrOiBJJ20gc29ycnksIEkgdW5kZXJzdGFuZCB3aHkgeW91ciB1 c2UgY2FzZSB3YW50cyAicmVqZWN0IiB0byBtZWFuDQo+IHJlamVjdCwgYnV0IGl0IHdhc24ndCBp biB0aGUgY2FyZHMgZ2l2ZW4gdXNlIGNhc2VzIGxpa2UgWWFob28hLyBBT0wuICBSZWNlaXZlcnMN Cj4gc2ltcGx5IHdlcmUgbm90IGdvaW5nIHRvIHRocm93IGF3YXkgbGFyZ2UgcXVhbnRpdGllcyBv ZiAiZ29vZCIgbWFpbCB0aGVpcg0KPiB1c2VycyBhY3R1YWxseSByZXF1ZXN0ZWQsIGFuZCBNZWRp YXRvcnMgd2VyZW4ndCBnb2luZyB0byBzdG9wIHByb3ZpZGluZyB0aGVpcg0KPiB2YWx1ZS1hZGRl ZCBwcm9jZXNzaW5nIG9yIHZpb2xhdGUgUkZDcyBmb3IgeW91LiAgSSBkb24ndCByZWNhbGwgeW91 IHB1c2hpbmcNCj4gaGFyZCBmb3IgYSBjbGVhciAidXNlIG9ubHkgZm9yIHRyYW5zYWN0aW9uIGZs b3dzIiBjbGF1c2UgaW4gdGhlIFJGQywgbm9ib2R5DQo+IHJlYWxseSBkaWQuICANCg0KTXkgdXNl IGNhc2UgYXJlIHByaW1hcmlseSB0cmFuc2FjdGlvbmFsIGVtYWlscyBidXQgdGhhdCBkb2Vzbid0 IG1lYW4gSSBvYmplY3QgdG8gbWFpbGJveCBwcm92aWRlcnMgaW1wbGVtZW50aW5nIHA9cmVqZWN0 IG9uIHRoZWlyIG91dGJvdW5kIG1haWwgZmxvd3MuIEl0IHJlYWxseSBjb21lcyBkb3duIHRvIGRl Y2lzaW9ucyBvbiB0aGVpciBwYXJ0LiBCeSB0aGUgc2FtZSB0b2tlbiwgd2hhdCBtYWlsYm94IHBy b3ZpZGVycy92YWxpZGF0b3JzIGRvIG9uIHRoZSBpbmJvdW5kIHNpZGUgZmFsbHMgdW5kZXIgbG9j YWwgcG9saWN5LiBIb3BlZnVsbHkgQVJDIHdpbGwgbWl0aWdhdGUgdGhlIGlzc3VlIGZvciBpbnRl cm1lZGlhcmllcyBzdWNoIGFzIG1haWxpbmcgbGlzdHMgKFN0YXkgdHVuZWQpLg0KDQo+V2l0aG91 dCB0aGF0LCBzdWNoIG1lY2hhbmlzbXMgYWx3YXlzIGZpbmQgb3RoZXIgdXNlcywgd2hpY2gNCj4g bWFrZSBhIGhhcmQtbGluZSBwb2xpY3kgdW50ZW5hYmxlIGZvciBvdGhlciBjb21tdW5pdGllcy4g IFBsZWFzZSBhY2NlcHQNCj4gdGhhdCwgYW5kIHRoaW5rIGluc3RlYWQgYWJvdXQgdGhlIG5leHQg c3RlcC4NCj4gDQoNCkkgd291bGQgc3VnZ2VzdCB0aGF0IHRoaXMgKG92ZXJhbGwpIGJlIHRha2Vu IGFzIGEgbGVhcm5pbmcgZXhwZXJpZW5jZSAgYnkgYWxsIG9mIHRoZSB2YXJpb3VzIGNvbnN0aXR1 ZW5jaWVzLiBDb2xsZWN0aXZlbHkgd2UgbmVlZCB0byBmaW5kIGJldHRlciB3YXlzIHRvIGV2b2x2 ZSAoZm9yIHNvbWUgZGVmaW5pdGlvbiBvZiBldm9sdmUpIGFuZCBkZWFsIHdpdGggKEFidXNlKSBw cm9ibGVtcy4gU3BlYWtpbmcgYXMgc29tZW9uZSB3aG8gaXMgcGFydCBvZiB0aGUgZG1hcmMub3Jn IHRlYW0sIEkgc3VyZSBsZWFybmVkIGEgbG90Lg0KDQpIYXZpbmcgc2FpZCBhbGwgdGhlIGFib3Zl LCBJIGFtIGZpcm1seSBhZ2FpbnN0IGRyYWZ0LWFrYWdpcmktZG1hcmMtdmlydHVhbC12ZXJpZmlj YXRpb24tMDAudHh0IGFzIGZyb20gdGhlIHN0YXJ0LCBETUFSQyB3YXMgaW50ZW5kZWQgdG8gYmUg b3B0LWluLiBZZXMgdGhlcmUgd2FzICJjb2xsYXRlcmFsIGRhbWFnZSIgZnJvbSBzb21lIGltcGxl bWVudGF0aW9ucyBidXQgdGhhdCBpcyBkaWZmZXJlbnQgdGhhbiB0cnlpbmcgdG8gZm9yY2UgYWxs IHNlbmRlcnMgdG8gaW1wbGVtZW50LiBJZiBvcmdhbml6YXRpb25zIHdpc2ggdG8gaW1wbGVtZW50 IHRoaXMgYXBwcm9hY2ggYXMgbG9jYWwgcG9saWN5LCB0aGF0IGlzIHRoZWlyIHByZXJvZ2F0aXZl LiBJdCBzaG91bGQgbm90IGJlIGVuZG9yc2VkICBieSBJRVRGLg0KDQpNaWtlDQo= From nobody Fri Mar 18 11:42:20 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8282F12D874 for ; Fri, 18 Mar 2016 11:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=peachymango.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bIhg8LeVpU8a for ; Fri, 18 Mar 2016 11:42:17 -0700 (PDT) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id 5AFBF12D540 for ; Fri, 18 Mar 2016 11:42:17 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id C7116563C8D; Fri, 18 Mar 2016 13:42:14 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id B4F39A0478; Fri, 18 Mar 2016 13:42:14 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85_PrdAcM3yg; Fri, 18 Mar 2016 13:42:14 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 74C43A0481; Fri, 18 Mar 2016 13:42:14 -0500 (CDT) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-1.01.com 74C43A0481 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1458326534; bh=6o5YpO4rcN7w7asCxpdkbdfWrrk0CD49O7dx2JxkyEA=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; b=LA4jB8VE4uEt3pCElFGZSGaG3LREbIyREKfXX7I9sDDZSAIEA1BPmG6CGMKyg5taG 4PMQaFX3biN758f9UX+WRVIJfwiPYtFSInx5mK69cQN1TB1RZ6Lzef2EOQGRdSxT4k ds5Tak4o2oWP1kpeXn3+uR+xD8aVX+sQzf+XtrW4= Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 55BE6A047B; Fri, 18 Mar 2016 13:42:14 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id xR_O3VUdcu4X; Fri, 18 Mar 2016 13:42:14 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-1.01.com (Postfix) with ESMTP id 1F5CFA0478; Fri, 18 Mar 2016 13:42:14 -0500 (CDT) Date: Fri, 18 Mar 2016 13:42:13 -0500 (CDT) From: Franck Martin To: Tomki Camp Message-ID: <833608930.69124.1458326533906.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <56E88C43.2050806@tomki.com> <2039296774.26888.1458083423836.JavaMail.zimbra@peachymango.org> <56E9A25C.2080607@tomki.com> <56EAF1B0.2050400@tana.it> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_69123_5416072.1458326533905" X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF44 (Mac)/8.0.5_GA_5839) Thread-Topic: SPFAuthResultType unbounded Thread-Index: P59Yhx3e1ElbnSXFyZsji1IOJVdTlA== Archived-At: Cc: dmarc@ietf.org, Alessandro Vesely Subject: Re: [dmarc-ietf] SPFAuthResultType unbounded X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2016 18:42:19 -0000 ------=_Part_69123_5416072.1458326533905 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit ----- Original Message ----- > From: "Tomki Camp" > To: "Alessandro Vesely" > Cc: dmarc@ietf.org > Sent: Thursday, March 17, 2016 4:21:11 PM > Subject: Re: [dmarc-ietf] SPFAuthResultType unbounded > The bug was reported some time ago, and the spec was referenced as allowing > the questionable data+format. > I am of the opinion that tightening the spec is necessary in this case, both > to prevent future implementations from making the same misinterpretation, > and as reference for fixing the current problem. I think you can submit an errata. https://www.rfc-editor.org/errata.php ------=_Part_69123_5416072.1458326533905 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable



=
From: "Tomki Camp" <tcamp@agari.com>
To: = "Alessandro Vesely" <vesely@tana.it>
Cc: dmarc@ietf.org
= Sent: Thursday, March 17, 2016 4:21:11 PM
Subject: Re: [dm= arc-ietf] SPFAuthResultType unbounded

The bug was reported some time ago, and the spec was reference= d as allowing the questionable data+format.
I am of the opinion th= at tightening the spec is necessary in this case, both to prevent future im= plementations from making the same misinterpretation, and as reference for = fixing the current problem.


I think you can submit an errata.

<= /div>
https://www.rfc-editor.org/errata.php
------=_Part_69123_5416072.1458326533905-- From nobody Fri Mar 18 14:01:50 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4EA12D618 for ; Fri, 18 Mar 2016 14:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=agari.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZUJ70Ie_7Dc for ; Fri, 18 Mar 2016 14:01:47 -0700 (PDT) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37E7412D507 for ; Fri, 18 Mar 2016 14:01:47 -0700 (PDT) Received: by mail-ig0-x22f.google.com with SMTP id ig19so47998514igb.0 for ; Fri, 18 Mar 2016 14:01:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=agari.com; s=s1024; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5B/1plhJfosSWLB8OFUOIHA9wSsEVVodJeg6XJMU1wo=; b=sQM0OXnhsoVd3f57HawGUhO7axFfMogM/2+QBQDQBJtVuMwgXPkPx29r8B+OOUIudw vbncCTdELBJSpeK2P0nA+3iAXkLeYrNQMihl/dgH/DmpwAlkd0A9j+SY9v2xPQXYY74o XxEouupip4EGTWtw3lTkWJN+HASIYd9MrPhnk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5B/1plhJfosSWLB8OFUOIHA9wSsEVVodJeg6XJMU1wo=; b=iuF7ghDbTXVNB8RPD06AhBDqDv70lsaqmRoYgCdY655VmOmEurDjjGkxli9402bfkG WXcLB/hjO8+uD7ZaeYd0OhuQjEtGpIqGWR0LrTKGM9UAbp3V+KDGZz++gZt/OE7Qeo/u N69hpO2XbfyALOOB76v0sR8DfQEcZzIXtKXK7w7X2AP8SZQSTnq4UJTu1xhCpmAtyi7H PuWkZddfVDUg3cbBXUr9QTn6o5uUNPdpwOcI7Gmmpvtju58dwKD8zqq7IZ27n9um3KQq Eh0ywUsARbBhYCabMBdZhONTtC0P/YAzntaKtaNYYAN2ll+5TEyuxcyUUj5YsrcVKHso xwlg== X-Gm-Message-State: AD7BkJI2NRM+JKZ3ZtSw0k1SidvU0C/U23mxyMzZjogtbTRjyM/AM+cxMjeAPAsElUbANFkKG7tJOMgfJhu7c16V X-Received: by 10.50.61.234 with SMTP id t10mr1608905igr.20.1458334906381; Fri, 18 Mar 2016 14:01:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.222.165 with HTTP; Fri, 18 Mar 2016 14:01:26 -0700 (PDT) In-Reply-To: <833608930.69124.1458326533906.JavaMail.zimbra@peachymango.org> References: <56E88C43.2050806@tomki.com> <2039296774.26888.1458083423836.JavaMail.zimbra@peachymango.org> <56E9A25C.2080607@tomki.com> <56EAF1B0.2050400@tana.it> <833608930.69124.1458326533906.JavaMail.zimbra@peachymango.org> From: Tomki Camp Date: Fri, 18 Mar 2016 14:01:26 -0700 Message-ID: To: Franck Martin Content-Type: multipart/alternative; boundary=047d7bdc07e20f1673052e590e1a Archived-At: Cc: "dmarc@ietf.org" , Alessandro Vesely Subject: Re: [dmarc-ietf] SPFAuthResultType unbounded X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2016 21:01:49 -0000 --047d7bdc07e20f1673052e590e1a Content-Type: text/plain; charset=UTF-8 Ok, I can do that. I'd like a further suggestion on how to specify more detail for this change: - + Because if there are more than just 1, both of the possible SPFAuthResultType entries need to indicate the scope, and they must be different. (i.e. one must be mfrom, the other must be helo) On Fri, Mar 18, 2016 at 11:42 AM, Franck Martin wrote: > > > > > ------------------------------ > > *From: *"Tomki Camp" > *To: *"Alessandro Vesely" > *Cc: *dmarc@ietf.org > *Sent: *Thursday, March 17, 2016 4:21:11 PM > *Subject: *Re: [dmarc-ietf] SPFAuthResultType unbounded > > The bug was reported some time ago, and the spec was referenced as > allowing the questionable data+format. > I am of the opinion that tightening the spec is necessary in this case, > both to prevent future implementations from making the same > misinterpretation, and as reference for fixing the current problem. > > > I think you can submit an errata. > > https://www.rfc-editor.org/errata.php > --047d7bdc07e20f1673052e590e1a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ok, I can do that.
I'd like a furth= er suggestion on how to specify more detail for this change:

-=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <xs:element name=3D"spf" type= =3D"SPFAuthResultType" minOccurs=3D"1"
-=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 maxOccurs=3D"unbounded"/>
+=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 <xs:element name=3D"spf" type=3D&q= uot;SPFAuthResultType" minOccurs=3D"1"
+=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 maxOccurs=3D"2"/>

Because if t= here are more than just 1, both of the possible SPFAuthResultType entries n= eed to indicate the scope, and they must be different. (i.e. one must be mf= rom, the other must be helo)




On Fri, Mar 18, 2016 at 11:42 A= M, Franck Martin <franck@peachymango.org> wrote:




From: "Tomki Camp" <tcamp@agari.com>
To: "= Alessandro Vesely" <vesely@tana.it>
Cc: dmarc@ietf.org
Sent: Thursday, March 17, 2= 016 4:21:11 PM
Subject: Re: [dmarc-ietf] SPFAuth= ResultType unbounded

The bug was reported some time ago, and the spec was re= ferenced as allowing the questionable data+format.
I am of the opi= nion that tightening the spec is necessary in this case, both to prevent fu= ture implementations from making the same misinterpretation, and as referen= ce for fixing the current problem.


I think you can submit an errata.


--047d7bdc07e20f1673052e590e1a-- From nobody Fri Mar 18 16:00:23 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C34A12D7ED for ; Fri, 18 Mar 2016 16:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=peachymango.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vmEOTRCqHZv2 for ; Fri, 18 Mar 2016 16:00:20 -0700 (PDT) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id B50B612D667 for ; Fri, 18 Mar 2016 16:00:20 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 0C290563E10; Fri, 18 Mar 2016 18:00:20 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 049C1A0493; Fri, 18 Mar 2016 18:00:20 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3dNW6HfQSotz; Fri, 18 Mar 2016 18:00:19 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id C480CA049C; Fri, 18 Mar 2016 18:00:19 -0500 (CDT) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-1.01.com C480CA049C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1458342019; bh=HUNMFrMJNAiVquE8SdKCgsHUjPXk6BX4MexmAc0j7dU=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; b=VbdIOEV+CyKXd+3WX0lVHk94eAX2lhpQSVRA3EgZjT/uBoTlIcjLK/92Fg3wgqmOn KdITfZXkb/G84l4/By0567PbW9LSedS9TjCNM9FFqlkd4MA7vyjmaORjijv8S3jzN7 pby50dfLXjwnQvF08eNSRDIVWkW3KMmLSqlqWGJE= Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id A4C0DA0499; Fri, 18 Mar 2016 18:00:19 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 3ht0xg5G8R-b; Fri, 18 Mar 2016 18:00:19 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-1.01.com (Postfix) with ESMTP id 30B06A0493; Fri, 18 Mar 2016 18:00:19 -0500 (CDT) Date: Fri, 18 Mar 2016 18:00:18 -0500 (CDT) From: Franck Martin To: Tomki Camp Message-ID: <461348453.71272.1458342018789.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <56E88C43.2050806@tomki.com> <56E9A25C.2080607@tomki.com> <56EAF1B0.2050400@tana.it> <833608930.69124.1458326533906.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_71271_1318518778.1458342018788" X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF44 (Mac)/8.0.5_GA_5839) Thread-Topic: SPFAuthResultType unbounded Thread-Index: 0khm6OfUXx9FjvTDfm1F0hqW6XXYAQ== Archived-At: Cc: dmarc@ietf.org, Alessandro Vesely Subject: Re: [dmarc-ietf] SPFAuthResultType unbounded X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2016 23:00:22 -0000 ------=_Part_71271_1318518778.1458342018788 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit ----- Original Message ----- > From: "Tomki Camp" > To: "Franck Martin" > Cc: dmarc@ietf.org, "Alessandro Vesely" > Sent: Friday, March 18, 2016 2:01:26 PM > Subject: Re: [dmarc-ietf] SPFAuthResultType unbounded > Ok, I can do that. > I'd like a further suggestion on how to specify more detail for this change: > - - maxOccurs="unbounded"/> > + + maxOccurs="2"/> > Because if there are more than just 1, both of the possible SPFAuthResultType > entries need to indicate the scope, and they must be different. (i.e. one > must be mfrom, the other must be helo) If not mistaken, in the spec, we say DMARC uses only the mform evaluation (rfc5321.mailfrom or rfc5321.helo if the first one is empty). ------=_Part_71271_1318518778.1458342018788 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
From: "Tomki Camp" <tcamp@agari.com>=
To: "Franck Martin" <franck@peachymango.org>
Cc: dmarc@ietf.org, "Alessandro Vesely" <vesely@tana.it>
Sent: Friday, March 18, 2016 2:01:26 PM
Subject: Re: [dmarc-ietf] SPFA= uthResultType unbounded

Ok, I = can do that.
I'd like a further suggestion on how to specify more = detail for this change:

-     &n= bsp; <xs:element name=3D"spf" type=3D"SPFAuthResultType" minOccurs=3D"1"=
-           &nbs= p;       maxOccurs=3D"unbounded"/>
+&nb= sp;      <xs:element name=3D"spf" type=3D"SPFAu= thResultType" minOccurs=3D"1"
+       = ;            maxOccu= rs=3D"2"/>

Because if there are more than just 1= , both of the possible SPFAuthResultType entries need to indicate the scope= , and they must be different. (i.e. one must be mfrom, the other must be he= lo)

If not mistaken, in the spec, we = say DMARC uses only the mform evaluation (rfc5321.mailfrom or rfc5321.helo = if the first one is empty).

------=_Part_71271_1318518778.1458342018788-- From nobody Sat Mar 19 03:55:50 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B715E12D6D6 for ; Sat, 19 Mar 2016 03:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.303 X-Spam-Level: X-Spam-Status: No, score=-4.303 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 uXQmDqLKV2q3 for ; Sat, 19 Mar 2016 03:55:47 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6BA612D4FF for ; Sat, 19 Mar 2016 03:55:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1458384943; bh=alk+v/wyJuUCV6+Q0ck0jEfr69e/Z9fSWmS1F6jkM0w=; l=1375; h=To:References:Cc:From:Date:In-Reply-To; b=sHpTWqW3bBTferlyn65aojYiCnhaNsKTQrgk5LLt8kk1tzFIiq4mHCFFbj9Lf2Bq/ y3ap5z0DtoDO7L+U32lMvi77ky6/vOw/W96MHXeox/H10jWhQIYpJEVRbEhHCngEgE IHxBlf6eoHEnTTe4L2n35Fn6wKTaMIEmjNT4HrHw= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.88] (pcale.tana [172.25.197.88]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Sat, 19 Mar 2016 11:55:43 +0100 id 00000000005DC044.0000000056ED302F.00002D17 To: Franck Martin , Tomki Camp References: <56E88C43.2050806@tomki.com> <56E9A25C.2080607@tomki.com> <56EAF1B0.2050400@tana.it> <833608930.69124.1458326533906.JavaMail.zimbra@peachymango.org> <461348453.71272.1458342018789.JavaMail.zimbra@peachymango.org> From: Alessandro Vesely Message-ID: <56ED302E.5090401@tana.it> Date: Sat, 19 Mar 2016 11:55:42 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.6.0 MIME-Version: 1.0 In-Reply-To: <461348453.71272.1458342018789.JavaMail.zimbra@peachymango.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] SPFAuthResultType unbounded X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Mar 2016 10:55:48 -0000 On Sat 19/Mar/2016 00:00:18 +0100 Franck Martin wrote: > ----- Original Message ----- > >> From: "Tomki Camp" >> To: "Franck Martin" >> Cc: dmarc@ietf.org, "Alessandro Vesely" >> Sent: Friday, March 18, 2016 2:01:26 PM >> Subject: Re: [dmarc-ietf] SPFAuthResultType unbounded > >> Ok, I can do that. >> I'd like a further suggestion on how to specify more detail for this change: > >> - > - maxOccurs="unbounded"/> >> + > + maxOccurs="2"/> Why not maxOccurs="1", after Franck's note below? Since most feedback producers supply one SPF result, I'd rather seek homogeneity than introduce further intricacies. >> Because if there are more than just 1, both of the possible SPFAuthResultType >> entries need to indicate the scope, and they must be different. (i.e. one >> must be mfrom, the other must be helo) > > If not mistaken, in the spec, we say DMARC uses only the mform evaluation > (rfc5321.mailfrom or rfc5321.helo if the first one is empty). Exactly, see https://tools.ietf.org/html/rfc7489#section-4.1 The possibility to use helo if mfrom is void is described in the second paragraph of http://tools.ietf.org/html/rfc7208#section-2.4 Ale -- From nobody Sat Mar 19 12:51:44 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0658B12D62E for ; Sat, 19 Mar 2016 12:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PpnrOueG8RKg for ; Sat, 19 Mar 2016 12:51:39 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 675A112D570 for ; Sat, 19 Mar 2016 12:51:39 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id k1so177904512vkb.0 for ; Sat, 19 Mar 2016 12:51:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=nUxk/HZMmPfeUeIy4LDIxjcas28DDElRa9NVTSq8YOQ=; b=Mxl4gla412+facT7u3e9IRW8H5mIyZopS/Z7IZNKVABifw0mzKnMA+p8TO488DY3dD NkPkagSxxlyupyAp3Oh8qQnr4ZumGdHQ0x+oRF8+GTXt904cohK2NtkbXtOFj/8CpVBj bJmFTWCaklZ+l3f25j9JftjBI+8yfwg60RaF5ebCsqW0qrlxqfRk4X+DkG9cRpovN7Sh BJV+mxbXv0ffJgCjREOsIvTYJZ92beytDmf6mmWCbz7uNgV3tTYZ7k67XgtaFvd7qDO8 D3gMBXsOjlVSd56Z1UFie9tcdz0EEGTcY1qCWWEBmRick6p3aGuJPyLYRPZ04Gnnd2EF jZuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=nUxk/HZMmPfeUeIy4LDIxjcas28DDElRa9NVTSq8YOQ=; b=GwdWKwjqsrVGBhoM5NXpusKounXTfEyncrLQllg0nud/RhgcZ/F2GzeUdi/4lMQiPo ti/t96hd+tRHVzV1P5d67TIYi7xODce76KyYaQdRDPblEGI9cKgbMpzGuoVm44RZVDtz moWetd0cWoccYhJHO0YFR0LvU1mCJwx9H1kDGPQ53IugjDf8e8GSatRvDFuGdY9c25C7 MryX4pnb9Mk3/SvhPm53fSkRTJVtsax4b+whLQUk1ksBaYAaY/JlbcZKlAI/oYTLbQfu zMDr9wU9b0SaV/Q1mAmsfgS+YNBkXT7hYylVJxkG1QEKamW4/imkkxFKYUQ6d8WvdXji wJfQ== X-Gm-Message-State: AD7BkJJw0warUuL8mVQG74TCi0eiXB5Z/2JUjioVOMnjDcuMxlB5nBNokDNaVpKHLUJHhIYB5QwMi67asfa+BA== MIME-Version: 1.0 X-Received: by 10.31.8.205 with SMTP id 196mr24991875vki.144.1458417098558; Sat, 19 Mar 2016 12:51:38 -0700 (PDT) Received: by 10.103.43.5 with HTTP; Sat, 19 Mar 2016 12:51:38 -0700 (PDT) In-Reply-To: <1091919919.43972.1458233931938.JavaMail.zimbra@peachymango.org> References: <1091919919.43972.1458233931938.JavaMail.zimbra@peachymango.org> Date: Sat, 19 Mar 2016 12:51:38 -0700 Message-ID: From: "Murray S. Kucherawy" To: Franck Martin Content-Type: multipart/alternative; boundary=001a1144f9121812b7052e6c31ab Archived-At: Cc: dmarc , "Kurt Andersen \(b\)" , Terry Zink Subject: Re: [dmarc-ietf] I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Mar 2016 19:51:41 -0000 --001a1144f9121812b7052e6c31ab Content-Type: text/plain; charset=UTF-8 On Thu, Mar 17, 2016 at 9:58 AM, Franck Martin wrote: > ------------------------------ > > Yes, it should not be normative, documented is fine. I prefer documented > than part of the secret sauce... > Is it important that it be documented in the RFC series? Best Guess SPF isn't documented in an RFC as far as I can recall, but you can find it described on plenty of web pages that turn up in a web search. -MSK --001a1144f9121812b7052e6c31ab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 17, 2016 at 9:58 AM, Franck Martin <fr= anck@peachymango.org> wrote:
Yes, it should not be normative, documented is fine. I prefer docume= nted than part of the secret sauce...

Is it important that it be documented in the RFC series?= =C2=A0 Best Guess SPF isn't documented in an RFC as far as I can recall= , but you can find it described on plenty of web pages that turn up in a we= b search.

-MSK
--001a1144f9121812b7052e6c31ab-- From nobody Sat Mar 19 18:36:56 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A568D12D68D for ; Sat, 19 Mar 2016 18:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=peachymango.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W83zO5m-a4hN for ; Sat, 19 Mar 2016 18:36:53 -0700 (PDT) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id C563212D672 for ; Sat, 19 Mar 2016 18:36:53 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 4AE71563D00; Sat, 19 Mar 2016 20:36:53 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 3C750A0478; Sat, 19 Mar 2016 20:36:53 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UNMSWoSZML41; Sat, 19 Mar 2016 20:36:53 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id A8CC2A03FD; Sat, 19 Mar 2016 20:36:52 -0500 (CDT) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-1.01.com A8CC2A03FD DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1458437812; bh=1aXmoUtvaZlI/cbBZZc4+CGtqzm0CifdLy1TFTbZuGg=; h=Content-Type:From:Mime-Version:Subject:Message-Id:Date:To; b=mmvla+EO8NyKTwFhqU11bSTmjRZTf1rYuD3BQMUJydIHo/q3vC0igxU+9EuIG7caA n4JOrABkOFYNNUnzBY6+3ZPlaIl0qGH+l2sn/cGrpNyYtjRgjw51JKCSmUL+pjQDXB lL0ih++QCqshbIPdaevYlcRsWhol6B63tZIalyXU= Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 76BFFA0478; Sat, 19 Mar 2016 20:36:52 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id bmdTkMamxU-U; Sat, 19 Mar 2016 20:36:52 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-1.01.com (Postfix) with ESMTP id 3F96CA03FD; Sat, 19 Mar 2016 20:36:52 -0500 (CDT) Content-Type: multipart/alternative; boundary=Apple-Mail-DA429E00-39DA-45F9-A508-3055132B9E76 From: Franck Martin Mime-Version: 1.0 Message-Id: Date: Sat, 19 Mar 2016 20:36:51 -0500 (CDT) References: <1091919919.43972.1458233931938.JavaMail.zimbra@peachymango.org> To: "Murray S. Kucherawy" In-Reply-To: X-Mailer: Zimbra 8.0.5_GA_5839 (MobileSync - Apple-iPhone8C1/1304.15) Thread-Topic: I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt Thread-Index: eT692LumehEtNxXc2Ze5YxVFWgDZBQ== Archived-At: Cc: dmarc , "Kurt Andersen \(b\)" , Terry Zink Subject: Re: [dmarc-ietf] I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2016 01:36:55 -0000 --Apple-Mail-DA429E00-39DA-45F9-A508-3055132B9E76 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 DQoNClRvdXRlIGNvbm5haXNzYW5jZSBlc3QgdW5lIHLDqXBvbnNlIMOgIHVuZSBxdWVzdGlvbi4N Cg0KPiBPbiBNYXIgMTksIDIwMTYsIGF0IDEyOjUxLCBNdXJyYXkgUy4gS3VjaGVyYXd5IDxzdXBl cnVzZXJAZ21haWwuY29tPiB3cm90ZToNCj4gDQo+PiBPbiBUaHUsIE1hciAxNywgMjAxNiBhdCA5 OjU4IEFNLCBGcmFuY2sgTWFydGluIDxmcmFuY2tAcGVhY2h5bWFuZ28ub3JnPiB3cm90ZToNCj4+ IA0KPj4gWWVzLCBpdCBzaG91bGQgbm90IGJlIG5vcm1hdGl2ZSwgZG9jdW1lbnRlZCBpcyBmaW5l LiBJIHByZWZlciBkb2N1bWVudGVkIHRoYW4gcGFydCBvZiB0aGUgc2VjcmV0IHNhdWNlLi4uDQo+ IA0KPiBJcyBpdCBpbXBvcnRhbnQgdGhhdCBpdCBiZSBkb2N1bWVudGVkIGluIHRoZSBSRkMgc2Vy aWVzPyAgQmVzdCBHdWVzcyBTUEYgaXNuJ3QgZG9jdW1lbnRlZCBpbiBhbiBSRkMgYXMgZmFyIGFz IEkgY2FuIHJlY2FsbCwgYnV0IHlvdSBjYW4gZmluZCBpdCBkZXNjcmliZWQgb24gcGxlbnR5IG9m IHdlYiBwYWdlcyB0aGF0IHR1cm4gdXAgaW4gYSB3ZWIgc2VhcmNoLg0KPiANClRydWUgYW5kIHRo ZSBkZXN0cnVjdGlvbiBvZiBlYXJ0aCB3YXMgY2xlYXJseSBhZHZlcnRpc2VkIGluIHRoZSBiYXNl bWVudCBwYXNzIHRoZSAnYmV3YXJlIG9mIHRoZSB0aWdlcicgc2lnbiA7KQ0KDQpJdCBhbGwgZGVw ZW5kcyBpZiBSRkMgZG9jdW1lbnRzIGFsbCB0aGUgYml0cyBvciBvbmx5IHRoZSBpbXBvcnRhbnQg b25lcy4gSSBkb24ndCBjYXJlIGVpdGhlciB3YXkuDQoNClBlb3BsZSBoYXZlIGJlZW4gdXNpbmcg RE1BUkMgYXV0aGVudGljYXRpb24gYXMgYSBsb3cgc2VjdXJpdHkgYXV0aG9yaXphdGlvbiBtZWNo YW5pc20uIElzIGl0IHdvcnRoIGRvY3VtZW50aW5nPyBJIGRvbid0IGtub3csIHRoYXQgbWF5IGJl IGxvdCBvZiBlZmZvcnQu --Apple-Mail-DA429E00-39DA-45F9-A508-3055132B9E76 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXY+PGJyPjxi cj5Ub3V0ZSBjb25uYWlzc2FuY2UgZXN0IHVuZSByw6lwb25zZSDDoCB1bmUgcXVlc3Rpb24uPC9k aXY+PGRpdj48YnI+T24gTWFyIDE5LCAyMDE2LCBhdCAxMjo1MSwgTXVycmF5IFMuIEt1Y2hlcmF3 eSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN1cGVydXNlckBnbWFpbC5jb20iPnN1cGVydXNlckBnbWFp bC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+PGJyPjwvZGl2PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi PjxkaXY+PGRpdiBkaXI9Imx0ciI+T24gVGh1LCBNYXIgMTcsIDIwMTYgYXQgOTo1OCBBTSwgRnJh bmNrIE1hcnRpbiA8c3BhbiBkaXI9Imx0ciI+Jmx0OzxhIGhyZWY9Im1haWx0bzpmcmFuY2tAcGVh Y2h5bWFuZ28ub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZnJhbmNrQHBlYWNoeW1hbmdvLm9yZzwvYT4m Z3Q7PC9zcGFuPiB3cm90ZTo8YnI+PGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxkaXYgY2xhc3M9 ImdtYWlsX3F1b3RlIj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJn aW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4 Ij48ZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlm O2ZvbnQtc2l6ZToxMnB0O2NvbG9yOiMwMDAwMDAiPjxocj48YnI+PGRpdj5ZZXMsIGl0IHNob3Vs ZCBub3QgYmUgbm9ybWF0aXZlLCBkb2N1bWVudGVkIGlzIGZpbmUuIEkgcHJlZmVyIGRvY3VtZW50 ZWQgdGhhbiBwYXJ0IG9mIHRoZSBzZWNyZXQgc2F1Y2UuLi48YnI+PC9kaXY+PC9kaXY+PC9kaXY+ PC9ibG9ja3F1b3RlPjxkaXY+PGJyPjwvZGl2PjxkaXY+SXMgaXQgaW1wb3J0YW50IHRoYXQgaXQg YmUgZG9jdW1lbnRlZCBpbiB0aGUgUkZDIHNlcmllcz8mbmJzcDsgQmVzdCBHdWVzcyBTUEYgaXNu J3QgZG9jdW1lbnRlZCBpbiBhbiBSRkMgYXMgZmFyIGFzIEkgY2FuIHJlY2FsbCwgYnV0IHlvdSBj YW4gZmluZCBpdCBkZXNjcmliZWQgb24gcGxlbnR5IG9mIHdlYiBwYWdlcyB0aGF0IHR1cm4gdXAg aW4gYSB3ZWIgc2VhcmNoLjxicj48YnI+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+DQo8L2Rpdj48 L2Jsb2NrcXVvdGU+VHJ1ZSBhbmQgdGhlIGRlc3RydWN0aW9uIG9mIGVhcnRoIHdhcyBjbGVhcmx5 IGFkdmVydGlzZWQgaW4gdGhlIGJhc2VtZW50IHBhc3MgdGhlICdiZXdhcmUgb2YgdGhlIHRpZ2Vy JyBzaWduIDspPGRpdj48YnI+PC9kaXY+PGRpdj5JdCBhbGwgZGVwZW5kcyBpZiBSRkMgZG9jdW1l bnRzIGFsbCB0aGUgYml0cyBvciBvbmx5IHRoZSBpbXBvcnRhbnQgb25lcy4gSSBkb24ndCBjYXJl IGVpdGhlciB3YXkuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5QZW9wbGUgaGF2ZSBiZWVuIHVz aW5nIERNQVJDIGF1dGhlbnRpY2F0aW9uIGFzIGEgbG93IHNlY3VyaXR5IGF1dGhvcml6YXRpb24g bWVjaGFuaXNtLiBJcyBpdCB3b3J0aCBkb2N1bWVudGluZz8gSSBkb24ndCBrbm93LCB0aGF0IG1h eSBiZSBsb3Qgb2YgZWZmb3J0LjwvZGl2PjwvYm9keT48L2h0bWw+ --Apple-Mail-DA429E00-39DA-45F9-A508-3055132B9E76-- From nobody Tue Mar 22 13:41:43 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 540A912D9A9 for ; Tue, 22 Mar 2016 13:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=crash.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8_QjG1OvhdnF for ; Tue, 22 Mar 2016 13:41:42 -0700 (PDT) Received: from segv.crash.com (segv.crash.com [IPv6:2001:470:1:1e9::4415]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2917712D9A7 for ; Tue, 22 Mar 2016 13:41:42 -0700 (PDT) Received: from abort.crash.com (70-36-157-26.dsl.static.fusionbroadband.com [70.36.157.26]) (authenticated bits=0) by segv.crash.com (8.14.5/8.14.5/cci-colo-1.6) with ESMTP id u2MKfUWU088498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 22 Mar 2016 13:41:36 -0700 (PDT) (envelope-from smj@crash.com) X-DKIM: OpenDKIM Filter v2.4.3 segv.crash.com u2MKfUWU088498 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=201506-2k; t=1458679296; bh=afe/rQKLyDClPrYA8y7+2UKO5DiXyrOj+nwO9HG27G8=; h=To:From:Subject:Message-ID:Date:MIME-Version:Content-Type: Content-Transfer-Encoding; b=bXaivBS0nGn6nLC1EuFSu0EtgC7VEmWI4Qba5p7sG3AAiha8Ww+Qt2y7akkxOKIFX 25+wbfI69z2D4u60H5FVMCe4aYEwL2wl/Ys8JZIq+Fi0pn//jESvYfzzd745mWfFju RT4aN/QGjRmKMyQ37ooIxZ1Zxj0qKbEhVksoE/Q/sGh510jcIpYTFhO4nXmTwVqlJV vVPuBSS4ZIK61cDjxUSZTly3EuOQeXlFT6iFoPXnyt64HQ43hFsCfugp9q/0UnkDZc qfQ8h4oGDCgRjQscqaPcV/cFb47fUkACyr5Yruyz5U1iO8rmbKMhIf1BfdI1DDBu5H hwyhoa2SBiAcw== X-Authentication-Warning: segv.crash.com: Host 70-36-157-26.dsl.static.fusionbroadband.com [70.36.157.26] claimed to be abort.crash.com To: dmarc@ietf.org From: Steven M Jones X-Enigmail-Draft-Status: N1110 Organization: Crash Computing Message-ID: <56F1ADFC.6090202@crash.com> Date: Tue, 22 Mar 2016 13:41:32 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (segv.crash.com [72.52.75.15]); Tue, 22 Mar 2016 13:41:36 -0700 (PDT) Archived-At: Subject: [dmarc-ietf] Semi-OT: Next ARC Interop Testing: April 1st X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 20:41:43 -0000 We'll be holding another interoperability & testing session for ARC on Friday, April 1st. This will be a "virtual" session coordinated via online conference, from 10AM Pacific / 1PM Eastern through 1PM Pacific / 4PM Eastern. This is intended for ARC implementers who have code to test, doesn't have to be a complete or finished product. And if you're actively working on a product/service/library that isn't yet ready, you can observe if that's of interest. If you'd like to participate please contact me off-list and I'll add you to the interop mailing list. There will be another virtual interop session held on Friday, May 13th. So if you're just starting your implementation, that may serve as a useful deadline or integration/testing opportunity. Let me know, --Steve. -- Steven M Jones DMARC.org