From nobody Wed Jul 5 08:26:13 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DDE113191D for ; Wed, 5 Jul 2017 08:26:11 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eudaemon.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UekYQ1GbCGt1 for ; Wed, 5 Jul 2017 08:26:08 -0700 (PDT) Received: from mail-yb0-x231.google.com (mail-yb0-x231.google.com [IPv6:2607:f8b0:4002:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B60E6129462 for ; Wed, 5 Jul 2017 08:26:08 -0700 (PDT) Received: by mail-yb0-x231.google.com with SMTP id 84so73315565ybe.0 for ; Wed, 05 Jul 2017 08:26:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eudaemon.net; s=dkey; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=oUd0ScD+ctejmk5iAKQ8Ro5tx4IRVc3gwd0frR99xiY=; b=gUvDlOjRkW7p4w1C4D504mCo/D+k65H0DhEq6HR9zMuIO595DPGMOwMgdWiZjTu31o R2LMRdP6N5wTNPzrUpZMFkT9+UT2waBiRwtmkk9d2D4bZ34QKL93qBT0gAf+dCMjj8BU Qdyj1HBayFUQW5ivrX0/OUsP8kwhv6TzB5YZw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=oUd0ScD+ctejmk5iAKQ8Ro5tx4IRVc3gwd0frR99xiY=; b=Y487G6H2u6MYDmOIsoC8Di8Nc87YCaFu0fm7gj6JZjun3Je97mQ594IJB6HFJVYYgR FLeGYF8MVUDebV6+3VzIhFl2NadxN+GCHu/bpTiAhvgNY2np8yOp1y8CSRDRFv2CthID WflF3wWc+hbSVpYIbgPSxOIQmXJBR+Ia2+ZVinhANunwJ+kDTL5BuIB1takcPB1zXCyh b0xlk7ygvctz+HsHHdpkF1wxa9MWZpXxYZRQOiw1oOuPDjAmun2xxxNNc/LsuTnpk3VB 1vcEC9SuxxePKn2Cr61eE1QHMCtDfYLD1hEBTdIefwc9Q62CvhV6TtByTsSjqQYYkJsX 9UkA== X-Gm-Message-State: AKS2vOw8Q7m/KGIILYGB5T5z28gEh8a37CFvOwdOf3P1LIYczpap87iG 7G60dSqA0hmZmBpuyAaOiA== X-Received: by 10.37.164.199 with SMTP id g65mr34819842ybi.160.1499268367476; Wed, 05 Jul 2017 08:26:07 -0700 (PDT) Received: from [192.168.0.18] (208-104-133-98.brvd.dsl.dyn.comporium.net. [208.104.133.98]) by smtp.gmail.com with ESMTPSA id f136sm9658329ywb.18.2017.07.05.08.26.06 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 05 Jul 2017 08:26:06 -0700 (PDT) From: Tim Draegen Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <4B696E89-C724-4783-B0A9-05670B8CCFC9@eudaemon.net> Date: Wed, 5 Jul 2017 11:26:05 -0400 To: dmarc Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [dmarc-ietf] Usage Guide interview (ISP) with Vladimir Dubrovin @ Mail.Ru X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 15:26:12 -0000 [This email is part of the series described here: = https://www.ietf.org/mail-archive/web/dmarc/current/msg03671.html] =20 Background: Mail.Ru is an early adopter of DMARC -- implementing the = technical specification as part of the pre-public pilot group. As the = largest provider of email in Russia, Mail.Ru sees a lot of spoofed email = and maintains a strong desire to improve the state of email. =46rom = Mail.Ru=E2=80=99s perspective, .COM email is almost all spam=E2=80=A6 = outside of RU, email from .RU is typically spam. DMARC has been very = useful in identifying real email to help with this problem. While DMARC = is mostly positioned as a protection against phishing, in case of = Mail.Ru primary reason to implement DMARC was protection against = spam/secondary spam and improve deliverability, because regional domains = like .ru are often blacklisted outside of Russia due to high spam/ham = values. Fraud is also an issue. To cut down on fraud, Mail.Ru works with = business and government organizations to implement DMARC. For example, = Russian Federa Tax Service sees a lot of phishing; Mail.Ru worked with = them to protect domain from abuse. =20 Vladimir Dubrovin is a Mail.Ru technical advisor and heads up DMARC = implementation for last few years. Mail.Ru acts as a resource to push = DMARC adoption within Russia. =20 Experience: DMARC used at Mail.Ru for its own domains and also inbound = processing/filtering. =20 Filtering: No significant issues aside from typical issues related to = dealing with large amounts of traffic. In the beginning, very little = impact from adopting DMARC due to little global adoption, now it is = widely used. There are exceptions that must be maintained, though. EG, = because Mail.Ru has been around for a long time, we see lots of older = traffic going through forwarding/lists. Exceptions-lists originally = constructed by analyzing log files and based on user=E2=80=99s reports. = We inspect message types and apply exceptions where it makes sense. = Messages from ESPs with broken DMARC are not accepted for domain with = DMARC reject policies due to the nature of the email flows - they do not = flow through mailing lists for example. =20 If users report problems regarding mailing lists, we can add exceptions = for the problem. This does not happen very often=E2=80=A6 maybe =C2=BD a = year ago something was added. Exceptions added apply to all users. =20 Exceptions are keyed off of DKIM signature and IP. In the future we=E2=80=99= ll add support for ARC but it will be treated just like DKIM+IP = exceptions=E2=80=A6 no expected improvements except for very unusual = circumstances. =20 It is not unusual to received malformed email that is legitimate. = Typically we show users a warning if the email might have been spoofed. = Attacks based on malformed email (Misformed of multiple From: headers, = eg) are common.. as are emails that are legitimate but sent through a = convoluted path. Also homograph attacks from non-existant domains.. we = display warnings to users via our web-based interface. We also indicate = the failure via Authentication-Results to provide an information for = MUA, but we do not know of any email clients that render authentication = results outside of web-based interfaces. =20 Exim-based SPF and DKIM implementations: No issues today. Exim has a = DKIM bug where multiple signatures from same domain with 1 valid and 1 = broken didn=E2=80=99t work. Fixed internally and submitted a patch to = exim. =20 A Mail.RU-hosted short DKIM key was discovered and fixed. Even though = the DKIM key was unused, criminals could exploit it. In the filtering = context, currently not collecting statistics if senders are using weak = keys=E2=80=A6 DKIM adoption happened fairly late in Russia and so = existing implementations are almost all 1024 or greater in RU. Haven=E2=80= =99t (yet!) seen cases where weak keys are exploited. Balance for us is = between possibility of exploit vs working with today=E2=80=99s = environment. =20 For SPF, we ignore =E2=80=9C+all=E2=80=9D policies that abusers like to = use, and might add negative weight to such SPF records. Tricky because = some records are effectively =E2=80=9C+all=E2=80=9D but using huge = netblocks. For this reason, anti-spam layer improved to process SPF = record in addition to SPF results (results are validated by MTA). =20 Filtering for business users is the same for freemail users. Freemail = users are protected by mail.ru DMARC policy, but business users=E2=80=99 = domains are not automatically given DMARC policy. In business = administration panel, a mark is given in the UI to indicate problems = with SPF and DKIM, DMARC record constructor is under development.=20 =20 Today in our web interface, warnings of suspicious email are only = displayed if DMARC record is in place. In near future, warnings will be = displayed even if DMARC record is not in place, starting if messages = fails any authentication (e.g. SPF). We=E2=80=99ll end by displaying = warnings if email lacks authentication for domains that are present in = an email. Sensitive email such as from a banks are given special = treatment/display. =20 Reporting: only aggregate reports are sent. Forensic reports are not = generated due to conflict with law, which requires recipients to = initiate information sharing. In this way our spam-reporting FBL is = possible as users hit =E2=80=9Cthis is spam=E2=80=9D which is = interpreted to mean =E2=80=9Cshare with sender that this email is not = wanted=E2=80=9D. Exceptions to the law are difficult to obtain and so = AFRF reports cannot be sent. Might change in future to send AFRF-style = reports to a sub-set of trusted parties if recipients give permission to = have AFRF generated. =20 Currently, XML report generation is relatively simple, and despite of = the huge number of reports, all reporting is done by a single host. As = DMARC popularity increases, we=E2=80=99ll have to grow the = infrastructure that produces reports. No immediate need to upgrade this = infrastructure. =20 Contact information is in each XML report: email box is monitored and = active. Support helps companies with DMARC implementation and handles = inquires related to SPF, DKIM, authentication, and DMARC. From nobody Wed Jul 5 15:24:12 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA61126B72 for ; Wed, 5 Jul 2017 15:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iD_bCRxn2kVX for ; Wed, 5 Jul 2017 15:24:09 -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 4303D12F28A for ; Wed, 5 Jul 2017 15:24:09 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id y70so540907vky.3 for ; Wed, 05 Jul 2017 15:24:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mqOJDCMTqrFkUqBriTz4to4RF01XLsHCFPwFy4nA/IM=; b=ZEEEtcvGmaLsBnvizuAw4gk3rEJ7gF4/a8XouhdI/bU/TS7ORpLwG0wYV8l+WxpjgJ Jr0kutJyWh+TC+PDrWSDXjwYpiYUsaBV3NOzblDxUVC7rdsNi/aqEG7nmyFu2AaRPFLN jNcUpYA3ID9/yz8v8FE97z1ijuzKlkkg23AqmW5SydeZhz7Es5zEa3rmwP9P7zDh2y3w rhW8eBB4cVyzvlRuHRrHx1o5pbb/Mhzua1/RlLMDTDlEe59zYOHhqwxhGbLSd7L4IfRR yurTnXwbGQNtjT4CbTUDsgv14YwI7q6ooyX+2441Z1xxKnLK1auZoIWt5mxN6Eby8fMB svqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mqOJDCMTqrFkUqBriTz4to4RF01XLsHCFPwFy4nA/IM=; b=YgJ/zVWje3XWn66Wy8Jvt+gWkmq/9ZjhEKgZfcXNkd/ai271Kwr6275/1z4SB6Uuoh xoha62wJ/U+mo+3bIY+iVEzYAtvzXHwwCLOzMHbfQD2qhPeMdRG8K6Y2RhCfN198+Nb2 rRQnbvP5qtgB3IW+s7O2s2uQsJMsYvzMcS7qT0jSynI65DZuBLFArTRQy480w1JcKvQd 5KB3W8y5Fb7d0jYjUa7pZyPrbwazZ8H24n649iOx/c0pq2TKjFTqz8u7B6QmcF/ESjPX Za+g/yBJnMKwIN4ZqGFNFPCGoKBhYoPjLVHLKp7gfZuExAJhyieh2UOjHJ8fMwkHtkpL 9MQg== X-Gm-Message-State: AKS2vOzPN2vyO7G7ZXm+zt/TI0XBn+NWGNdL97FqUaQS06lleKfkETRZ V8K/8lZi0LRejYGClEVJHVFk92jgqQ== X-Received: by 10.31.220.1 with SMTP id t1mr22434455vkg.132.1499293448331; Wed, 05 Jul 2017 15:24:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.126.196 with HTTP; Wed, 5 Jul 2017 15:24:07 -0700 (PDT) In-Reply-To: References: From: "Murray S. Kucherawy" Date: Wed, 5 Jul 2017 15:24:07 -0700 Message-ID: To: Brandon Long Cc: "Kurt Andersen (b)" , "dmarc@ietf.org" , Seth Blank , Gene Shuman Content-Type: multipart/alternative; boundary="94eb2c07ad5466e6a6055399752b" Archived-At: Subject: Re: [dmarc-ietf] ARC cv=invalid X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 22:24:11 -0000 --94eb2c07ad5466e6a6055399752b Content-Type: text/plain; charset="UTF-8" On Wed, Jun 21, 2017 at 4:18 PM, Brandon Long wrote: > On Wed, Jun 21, 2017 at 2:05 PM, Kurt Andersen (b) > wrote: > >> On Wed, Jun 21, 2017 at 1:53 PM, Gene Shuman >> wrote: >> >>> >>> It seems we have two choices available to us upon receipt of an invalid >>> chain(which is defined as AS b= unable to be computed). >>> >>> 1. Simply stop adding further ARC headers. Put arc=fail(or invalid) in >>> the AR. Further recipients will detect that the chain is broken as well, >>> for the same reasons. This is clearly the easiest solution. >>> >> >> If you put arc=fail in an AR and then the next hop ignores and strips the >> AR (per spec), what good is it? >> > > None, but what good is the broken chain? If all you're doing is avoiding > reprocessing, that seems pretty minimal. > A message that doesn't have a chain that ends with "cv=fail" or "cv=invalid" has undetermined status. You (the receiver) now have to evaluate the chain. Why make everyone downstream of you go through that if you know it's bad? Of course, there's no reason they believe you if you say it's bad, but then what benefit do you have to lie? > > >> 2. Add one further ARC-Set with an explicit cv=invalid in order to >>> 'close' the chain, using the rule that Kurt has suggested. This seems to >>> have some benefit to me, but it's minimal. It seems to wrap things up >>> nicely, and it means that all ARC chains have a well defined cv value, >>> which makes testing a little easier. However the cost is clearly added >>> complexity, both in the spec and implementations. Is there any other >>> tangible value to adding this final ARC-Set? Does it help identify the >>> failure point in the chain? Is there any other benefit? Kurt, can you >>> speak to this? >>> >> >> A terminal ARC-set with cv=invalid is the only way to "close" a chain and >> avoid reprocessing by each and every subsequent hop as far as I can see. >> > > Note that we don't have a temp fail, so cv=fail could just be due to DNS > being unavailable, so the next hop may actually be able to validate the > chain, assuming the failing hop was a non-modifying hop. > Should "cv=" have a way to indicate "pass up to here, but the hop that added this seal didn't/couldn't actually evaluate anything"? Maybe more importantly: Should the spec accommodate an operator that chooses to pass a message along with some chain status that isn't "pass" or "fail"? I would think that's a hole of some kind. Maybe we need to say you need to queue the message or tempfail it back out the front if you can't complete the evaluation. Would you expect the next hop to also had a cv=fail arc header that only > signs itself? > > I'm just fundamentally unclear what the utility of passing the fail state > forward is. > I suggested above that it tells the new receiver that this chain is probably not going to pass, so don't bother. There's no benefit to saying that when it's not true, or not saying it when it is. > That said, there are plenty of cv=fail which have nothing to do with the > chain structure, and could be dns or ams signature failures or whatever. > AR allows for a status that means "this couldn't be evaluated right now, and we decided to pass it along anyway". But DKIM signature evaluation is stateless from one hop to the next, so it's fine for DKIM. It's not-so-fine for ARC. -MSK --94eb2c07ad5466e6a6055399752b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jun 21, 2017 at 4:18 PM, Brandon Long <blong@googl= e.com> wrote:



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

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

I suggested above = that it tells the new receiver that this chain is probably not going to pas= s, so don't bother.=C2=A0 There's no benefit to saying that when it= 's not true, or not saying it when it is.
=C2=A0
That said, there are plenty of cv=3Dfail which have nothin= g to do with the chain structure, and could be dns or ams signature failure= s or whatever.

AR allows for a status that means "this couldn't be ev= aluated right now, and we decided to pass it along anyway".=C2=A0 But = DKIM signature evaluation is stateless from one hop to the next, so it'= s fine for DKIM.=C2=A0 It's not-so-fine for ARC.

-MSK
--94eb2c07ad5466e6a6055399752b-- From nobody Wed Jul 5 15:25:23 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4E0E127333 for ; Wed, 5 Jul 2017 15:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NblcrO1vQH7a for ; Wed, 5 Jul 2017 15:25:20 -0700 (PDT) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3975126B72 for ; Wed, 5 Jul 2017 15:25:19 -0700 (PDT) Received: by mail-ua0-x232.google.com with SMTP id g40so1658151uaa.3 for ; Wed, 05 Jul 2017 15:25:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JXJD/F4dYL4OX9hG/gTr9sRKt+cW+8TPxH3SX5Dbvis=; b=h1BCFp5sVKQ67QjKN24YkEUMHpVQbssbyqZEom3a9oucpFljqOj207nKlAg2mcUTVL PJoEu16qBQN5cn3mAUz+oB21St/FN6tm0v8tYsqbHs7NbQ8B43UJdpS6eAz3twBbj8Ws Ox7VKXwsAXLboSDJCxkC9jJkUYhLkgcsDiYtCjJr7cOZlUPZKFKdN/Xm/z7exw+WSYCC YvUtXuSXujUyK8AflXI+s3V5FHHxR3teLcalGnHbZRMlI3jaUwgbfsDM4fs5tmQ2ERmP tzsgAluiHig6jfThzNfa+kzoj6ul1ZhT9XatvXeM7cP6AkBMmhmJC2HvwmQwj98J+AFA Hnsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JXJD/F4dYL4OX9hG/gTr9sRKt+cW+8TPxH3SX5Dbvis=; b=OuoAepZRomM7/A4HrvpMG1nJV3lh+5eOmjIRfvlYiWNCYV/tyV0aGUBZSAqaDdY3p0 6zsg73D5Ao0WsBvM5VB5UAT/zRCv3wFfWr5Ugq/58/k3BbasfzXga+iqNvBFG7kl6ORn NN2i9232Nrmxk6xf/7SH7nnkfwcorrJivh3Plcs464AYFl+MRWK/nmKnMkuROvj5GQzl Dfak+K2RAhSEgYEUZmGji6jVK+sC4CNQ19zRRSbd/3RVtM4Z6eP6jIE+nSB9z1BcMDEI VxUoW4j7E1cbW4oph/U+pY3qtO8T9e7PcEt8muxgbX8uy+nQMReAUW0wNMcTlzPh0G+N UQGA== X-Gm-Message-State: AKS2vOxQnc2oSVt4GxVDlRJlQwbOE4tko4DeV3ltrIAL5pzSfSsc7IOu kHyY8CiXR5BHR8Kuu9uPEnG1Ck+jkw== X-Received: by 10.176.86.21 with SMTP id y21mr14439971uaa.72.1499293519102; Wed, 05 Jul 2017 15:25:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.126.196 with HTTP; Wed, 5 Jul 2017 15:25:18 -0700 (PDT) In-Reply-To: References: From: "Murray S. Kucherawy" Date: Wed, 5 Jul 2017 15:25:18 -0700 Message-ID: To: Seth Blank Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="f403045dd5b09ec890055399790b" Archived-At: Subject: Re: [dmarc-ietf] ARC cv=invalid X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 22:25:22 -0000 --f403045dd5b09ec890055399790b Content-Type: text/plain; charset="UTF-8" On Wed, Jun 21, 2017 at 6:19 PM, Seth Blank wrote: > On Wed, Jun 21, 2017 at 4:18 PM, Brandon Long wrote: >> >> If you put arc=fail in an AR and then the next hop ignores and strips the >>> AR (per spec), what good is it? >>> >> >> None, but what good is the broken chain? If all you're doing is avoiding >> reprocessing, that seems pretty minimal. >> > > A final evaluation status has merit, but it's not avoiding reprocessing, > it's transmitting and signing your name to a definitive position that the > chain is dead as you saw it. > > An ARC chain is a chain of custody, and if custody is lost, that status > shouldn't be a hot potato - it should be committed to the chain. And then > per the logic in the spec, no one else touches the chain after the chain is > declared dead. > I think I agree here. The absence of a "cap" on the end of the chain is ambiguous, while a signed "cv=fail" is not. -MSK --f403045dd5b09ec890055399790b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jun 21, 2017 at 6:19 PM, Seth Blank <seth@sethbl= ank.com> wrote:
On Wed, Jun 21, 201= 7 at 4:18 PM, Brandon Long <blong@google.com> wrote:
If you put arc=3Dfa= il in an AR and then the next hop ignores and strips the AR (per spec), wha= t good is it?

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

A final evaluation status has merit,= but it's not avoiding reprocessing, it's transmitting and signing = your name to a definitive position that the chain is dead as you saw it.

An ARC chain is a chain of custody, and if custody i= s lost, that status shouldn't be a hot potato - it should be committed = to the chain. And then per the logic in the spec, no one else touches the c= hain after the chain is declared dead.
=

I think I agree here.=C2=A0 The absence of a "cap&= quot; on the end of the chain is ambiguous, while a signed "cv=3Dfail&= quot; is not.

-MSK
--f403045dd5b09ec890055399790b-- From nobody Wed Jul 5 15:33:30 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70E83127201 for ; Wed, 5 Jul 2017 15:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pyi16AwSzF4K for ; Wed, 5 Jul 2017 15:33:23 -0700 (PDT) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3D55126B72 for ; Wed, 5 Jul 2017 15:33:23 -0700 (PDT) Received: by mail-ua0-x22d.google.com with SMTP id z22so1788742uah.1 for ; Wed, 05 Jul 2017 15:33:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZS5Pn3On80ZSg97V4x3mOoVqj/9thwS8q27q9nhf+gM=; b=to2PnokXvgHF8lDkWwLU0I817qXSJlXtEmdLulffXgm+jDR7xJk+EeJWCNhoiTEaQ0 9PneQmphezCb17xKlxYKAN8bM9tNf1g/LiQWGSH/1TGM6naKmM4VTk5wSpDVlOTicbRr FidFXF+MRfIF64TTQ3OYMkB0y/jNmgW5hskGbTKQoUHrBQbBFqJaWsWJMfTl9J/Pmc2A ETf5I/mrJQucvcTwcAfJ0L6fK3PRvC3j0yNcBjac9kj64iZV5hvzpNVMJ7rw70PEkkmY 2xTzJW6d6zTBhiNuNwWCNlkJh8NItEXkRCoKJugPEcgL85KCgDF67NTeyjLDea0x4/rv +YUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZS5Pn3On80ZSg97V4x3mOoVqj/9thwS8q27q9nhf+gM=; b=EUPWulJlsXn6zCFiIckgOpArnwt7+juTig4snkxDH90dJTAZi9CLMnIWO5IttIK8va BPANPOKPFsK84QovhsRqozGowZkBjkwKseCliZm17JIevcZ6HsudUBW7ND+iXG49lGUc uqpeGVmoEW8s7hPLjbZWB9Zg+kKAen9oFHMkdfYxiiut54zhinzWgIVNPPMmzKrhPeqh vzFpKoHKF4dw9Xebz1r1N3mu1JOMuVL8usF8auo1zLirqWku8Bj4hdygrtql3NgJTGO1 2U3BnXGYvK/9niREnSqAClit0iUfVsmw4zrTyxHZcI7i6KOEdavF2bfz6/2Bi6E5RlTY 5Epg== X-Gm-Message-State: AKS2vOxjUmw+nJGBheRPeQYGidJwp/1OL7Y7PHQ+40Ca8CnQKy/yfgZe FMV5lXkkZWNtMrc2yJJKIIQjfur38g== X-Received: by 10.159.59.93 with SMTP id j29mr24800641uah.155.1499294002875; Wed, 05 Jul 2017 15:33:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.126.196 with HTTP; Wed, 5 Jul 2017 15:33:22 -0700 (PDT) In-Reply-To: References: From: "Murray S. Kucherawy" Date: Wed, 5 Jul 2017 15:33:22 -0700 Message-ID: To: Brandon Long Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="f403043eb9b874931a05539996f2" Archived-At: Subject: Re: [dmarc-ietf] selectors in AAR. X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 22:33:25 -0000 --f403043eb9b874931a05539996f2 Content-Type: text/plain; charset="UTF-8" On Fri, Jun 23, 2017 at 3:17 PM, Brandon Long wrote: > On Wed, May 31, 2017 at 10:07 PM, Murray S. Kucherawy > wrote: > >> On Thu, May 4, 2017 at 4:19 PM, Peter Goldstein >> wrote: >> >>> So as a consumer of these reports I'd definitely like to see a >>> structured value with as much information as possible. >>> >> > [snip] > >> >>> - DKIM Selectors - Unfortunately we probably can't get the DKIM >>> signature selectors (because they aren't generally recorded in the >>> Authentication-Results, and so won't be available to downstream hops), but >>> if we can get them, that would be very helpful. >>> >>> >> They could be added to A-R, in theory, but they're not really >> user-consumable which is why they were originally omitted. >> > > Thinking some more on this while thinking about the format of the DMARC > report, I think we should consider it. > > The AuthRes header was meant to help pass information to the end user (or > their mail client) from their own mail system. > > The AAR header is meant to pass information from each hop to all of the > following hops, and meant mostly (at this point) to inform the DMARC > handling of the message. > > And part of the point of DMARC is informing admins/domain owners on how > their mail is being evaluated to help them get to stricter levels. > [...] > The original intent of selectors and domain names, going back to DomainKeys, was that selectors would be used to identify a key, and the domain name would be used to identify the source, or responsible party, regarding a message. Selectors can be rotated in and out of service for a given domain name without changing the domain name. Reputation, therefore, would be developed about the domain name (the "d=") specifically. Selectors were orthongonal. Based on discussions with Seth and Gene earlier, it sounds like the industry has sadly not taken up the habit of key and selector rotation, and instead the pairing of "s=" and "d=" now identifies a single source. Ignoring the obvious security problem this introduces, we're now talking about implicitly formalizing this tuple as identifying a source. This contradicts that original intent. In particular, if one were to develop reputation in this way, then a key being rotated out takes the reputation with it; signers would have to establish some procedure for doing so with substantial overlap so that the new key can be "warmed". Worse, in an emergency where a key is compromised, that tuple's reputation irretrievably suffers. How is this better than encouraging the industry to adopt the separation of functions that was originally intended? -MSK --f403043eb9b874931a05539996f2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jun 23, 2017 at 3:17 PM, Brandon Long <blong@googl= e.com> wrote:
On Wed, May 31, 201= 7 at 10:07 PM, Murray S. Kucherawy <superuser@gmail.com> w= rote:
On Thu, May 4, 2017 at 4:19 PM, Peter Goldstein &l= t;peter@valimail.co= m> wrote:
<= div class=3D"gmail_quote">
So as a consumer of these reports I'd definitel= y like to see a structured value with as much information as possible.

[sn= ip]=C2=A0
  • DKIM S= electors - Unfortunately we probably can't get the DKIM signature selec= tors (because they aren't generally recorded in the Authentication-Resu= lts, and so won't be available to downstream hops), but if we can get t= hem, that would be very helpful.

They could be added to A-R, in theory, but they're not rea= lly user-consumable which is why they were originally omitted.

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

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

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

And = part of the point of DMARC is informing admins/domain owners on how their m= ail is being evaluated to help them get to stricter levels.
[...]=

The original i= ntent of selectors and domain names, going back to DomainKeys, was that sel= ectors would be used to identify a key, and the domain name would be used t= o identify the source, or responsible party, regarding a message.=C2=A0 Sel= ectors can be rotated in and out of service for a given domain name without= changing the domain name.=C2=A0 Reputation, therefore, would be developed = about the domain name (the "d=3D") specifically.=C2=A0 Selectors = were orthongonal.

Based on discussions with Seth and Gene earlier, i= t sounds like the=20 industry has sadly not taken up the habit of key and selector rotation,=20 and instead the pairing of "s=3D" and "d=3D" now identi= fies a single source.=C2=A0 Ignoring the obvious security problem this intr= oduces, we're now talking about implicitly formalizing this tuple as id= entifying a source.=C2=A0 This contradicts that original intent.=C2=A0 In p= articular, if one were to develop reputation in this way, then a key being = rotated out takes the reputation with it; signers would have to establish s= ome procedure for doing so with substantial overlap so that the new key can= be "warmed".=C2=A0 Worse, in an emergency where a key is comprom= ised, that tuple's reputation irretrievably suffers.

= How is this better than encouraging the industry to adopt the separation of= functions that was originally intended?

-MSK
--f403043eb9b874931a05539996f2-- From nobody Wed Jul 5 15:34:21 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F90D12F28A for ; Wed, 5 Jul 2017 15:34:19 -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 rDieROk3h3QI for ; Wed, 5 Jul 2017 15:34:17 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82653126B72 for ; Wed, 5 Jul 2017 15:34:17 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id r125so695625vkf.1 for ; Wed, 05 Jul 2017 15:34:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xh3A0CGxZBQpYdlTV8VlnJJTxnCIomAYQe4b7QQ63HY=; b=ieJ9qyeTtyrHprRb/hWXDOqsZwPBuK6kYnrUzlCcpPGM8I6D03zQk3wW/VD2GE427V j6Y47TOfONHmHrUf1qxTwSJPp/ukqKHIoH/Oc3SwKp2y9LE83lFDCF5KdzC5dncLPwEo HpSb8KRmtGgdSM+76utWaXF96rTCNbHueGmOsnOSQuqRKo3KRVC5Dx0S8j+Zbj2gRmqi GxoQUgFdNKYnahk1wNnap+5cpaLcaR8uqzRAQXqIvONPY+mbMucZvY3x3sqt2SNdkmT1 o9q3V0n2INhE8wixi55995QvouyrUq9vj7h9cWnTUmqPa7q2nkVY7LLtX0UUxPZIdSkg HCeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xh3A0CGxZBQpYdlTV8VlnJJTxnCIomAYQe4b7QQ63HY=; b=nH5P6ga2C2liRLxdo4yB1L8Nhah8JzoFPqIJZqS2YguTf1qyiNqO94W6X7GcmFXYMq +WJSH5tbmzIW1bIv3kOPzVLPK2sIcPnAm05UM41aBekhlDCgjyS91unNvhy1jzbmfQo4 ErZedhz4z4PFrlT1MIY9ETTYdqo9IXK+1J13AfkUnIU8a0Oybx0SI4cNvpLhl24rLF9A FYr6rMUZWjS1G4BDBVFfXHyJysxiiv3cXrM1FfZtBaBKTyhbsSn1TpO7VAxr4B4PqJ3R EeWt7Ck0UGg7NWB1GLaez+0oOqVQt6ys197Dxe7cZVrG4p1jblJpT6FTP38N+KP3eDY0 aLlg== X-Gm-Message-State: AIVw1113lFADDmExr3tU/L2x3OeLFzvz6FW3DK+lnERylq5fhjodlgfD hQRQT+ytQJCL/Ukw8UmWP7+ELpHyc3ZL X-Received: by 10.31.75.66 with SMTP id y63mr4102505vka.65.1499294056731; Wed, 05 Jul 2017 15:34:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.126.196 with HTTP; Wed, 5 Jul 2017 15:34:16 -0700 (PDT) In-Reply-To: References: From: "Murray S. Kucherawy" Date: Wed, 5 Jul 2017 15:34:16 -0700 Message-ID: To: Brandon Long Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a114dad4eaa5a0e05539999c1" Archived-At: Subject: Re: [dmarc-ietf] new arc usage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 22:34:19 -0000 --001a114dad4eaa5a0e05539999c1 Content-Type: text/plain; charset="UTF-8" On Fri, Jun 30, 2017 at 2:45 PM, Brandon Long wrote: > Someone's using a keysize of 4098... that's odd. > That Dave Crocker did not take this opportunity to say "No it's not, it's even" must mean he's traveling. -MSK --001a114dad4eaa5a0e05539999c1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jun 30, 2017 at 2:45 PM, Brandon Long <blong@googl= e.com> wrote:
Someone's usi= ng a keysize of 4098... that's odd.

That Dave Crocker did not take this opportunity to say "No it's= not, it's even" must mean he's traveling.

-= MSK
--001a114dad4eaa5a0e05539999c1-- From nobody Wed Jul 5 16:36:41 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05DCB12EE46 for ; Wed, 5 Jul 2017 16:36:40 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjdEZGGUFCYC for ; Wed, 5 Jul 2017 16:36:36 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3E68129AAD for ; Wed, 5 Jul 2017 16:36:36 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id r126so1285088vkg.0 for ; Wed, 05 Jul 2017 16:36:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=bILqmVW5OALEh+UG5tIbeJ/Arr5Gc+ABEpzgGWcs7fg=; b=NNSA8m9J5xdFjood+VmwLySB7NpV+5G4+Nx/PuYCozgcS9OGhqD87xvB1/f7N28Kv+ VWtn65/a/I7+nOh91fraG6nBgd7E2KM+Lpoq56olmTRwhds8AYQCLMP8kzIRJfh6K+qo u2bm5tg48xAzgYRzzqX8chdZgWqU5UbqUnCtWJQvcxtQ5CCYfcpMchTbzwhSxKQynXQ7 Erk8Y3TV3i8d02l/yrAgMcmXQbtLPH6c+Xl60UG6AzcXefQMwOKAUmS+MVnEOkOnd2A8 fqxs6y88yaxmMvqDdC7r1Kf4upqBW600WhPlFJ5hl/lUCqbuzmAMOKQVdaUeOEeN7BJd YqVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=bILqmVW5OALEh+UG5tIbeJ/Arr5Gc+ABEpzgGWcs7fg=; b=pNfaSAHnNYZ8UqL4kaNlUEXzZFjKnEZKx1QXSoUPdG05z3hpoA0wWJaLULXHBxUsDP ldnftm/RsuDt7l11VqLp/jLvOWGAXVII/5Leq64pESkRuCAp1bCg8B5dlO+7UygXjoMo AO9zz/3ZD0DkNzw04kBm2TtMil51kGVa7Bqn9yQAPm33FlLfHg5ZezUa/oOsCr/ABlEP feYT/rfCAj4U+16O8+qxHriWewrGE/NXkG1iToQQHzfY3P44jLlg8krMmSiiDkfwyMh6 AHl0odu/Za+TXX7AH81M2V8yD0wwSZUMO9z9IdPsloJb74blRuzOeulV9OuYcpokqrbg uATw== X-Gm-Message-State: AIVw111+T8v2Zy2khg9hGo0PTb9VaSf4aahBU6PBoD+SLJ0hGvq4mumz 4ySCjvCWvOAX3GpXnkHNO7UG8LgBAMPXIoE= X-Received: by 10.31.160.80 with SMTP id j77mr12491718vke.42.1499297795408; Wed, 05 Jul 2017 16:36:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.152.80 with HTTP; Wed, 5 Jul 2017 16:36:14 -0700 (PDT) In-Reply-To: References: From: Seth Blank Date: Wed, 5 Jul 2017 16:36:14 -0700 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a114326a6825ebf05539a7801" Archived-At: Subject: Re: [dmarc-ietf] selectors in AAR. X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 23:36:40 -0000 --001a114326a6825ebf05539a7801 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 5, 2017 at 3:33 PM, Murray S. Kucherawy wrote: > On Fri, Jun 23, 2017 at 3:17 PM, Brandon Long wrote: > >> On Wed, May 31, 2017 at 10:07 PM, Murray S. Kucherawy < >> superuser@gmail.com> wrote: >> >>> On Thu, May 4, 2017 at 4:19 PM, Peter Goldstein >>> wrote: >>> >>>> So as a consumer of these reports I'd definitely like to see a >>>> structured value with as much information as possible. >>>> >>> >> [snip] >> >>> >>>> - DKIM Selectors - Unfortunately we probably can't get the DKIM >>>> signature selectors (because they aren't generally recorded in the >>>> Authentication-Results, and so won't be available to downstream hops), but >>>> if we can get them, that would be very helpful. >>>> >>>> >>> They could be added to A-R, in theory, but they're not really >>> user-consumable which is why they were originally omitted. >>> >> >> Thinking some more on this while thinking about the format of the DMARC >> report, I think we should consider it. >> >> The AuthRes header was meant to help pass information to the end user (or >> their mail client) from their own mail system. >> >> The AAR header is meant to pass information from each hop to all of the >> following hops, and meant mostly (at this point) to inform the DMARC >> handling of the message. >> >> And part of the point of DMARC is informing admins/domain owners on how >> their mail is being evaluated to help them get to stricter levels. >> [...] >> > > The original intent of selectors and domain names, going back to > DomainKeys, was that selectors would be used to identify a key, and the > domain name would be used to identify the source, or responsible party, > regarding a message. Selectors can be rotated in and out of service for a > given domain name without changing the domain name. Reputation, therefore, > would be developed about the domain name (the "d=") specifically. > Selectors were orthongonal. > > Based on discussions with Seth and Gene earlier, it sounds like the > industry has sadly not taken up the habit of key and selector rotation, and > instead the pairing of "s=" and "d=" now identifies a single source. > Ignoring the obvious security problem this introduces, we're now talking > about implicitly formalizing this tuple as identifying a source. This > contradicts that original intent. In particular, if one were to develop > reputation in this way, then a key being rotated out takes the reputation > with it; signers would have to establish some procedure for doing so with > substantial overlap so that the new key can be "warmed". Worse, in an > emergency where a key is compromised, that tuple's reputation irretrievably > suffers. > > How is this better than encouraging the industry to adopt the separation > of functions that was originally intended? > The *only* intent here is to report back services that break authentication to the domain owner in a DMARC report. As such, the selector disambiguates services (especially when there are multiple hops, some of which might have the same d=) and allows a reporter to make a clear determination to a report consumer of where authentication failed so that a service can be properly configured in SPF or with DKIM. In many cases, this process is ambiguous or impossible without the inclusion of selectors. This adds demonstrable value for a consumer of DMARC reports where mail is indirectly delivered. This solves a real problem now, and has nothing to do with reputation which would be silly to build on top of this tuple for the reasons you've outlined. Seth > > -MSK > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --001a114326a6825ebf05539a7801 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Jul 5, 2017 at 3:33 PM, Murray S. Kucherawy <superuser@gmail.com= > wrote:
On Fri, Jun 23, 2017 at 3:17 PM, Brandon Long <blong@google.com= > wrote:
= On Wed, May 31, 2017 at 10:07 PM, Murray S. Kucherawy <= ;superuser@gmail.c= om> wrote:
On Thu, May 4, 2017 at 4:19 PM, Peter Goldstein <= span dir=3D"ltr"><peter@valimail.com> wrote:
So as a consumer of these report= s I'd definitely like to see a structured value with as much informatio= n as possible.

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

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

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

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

The AAR header is meant to= pass information from each hop to all of the following hops, and meant mos= tly (at this point) to inform the DMARC handling of the message.
=
And part of the point of DMARC is informing admins/domain ow= ners on how their mail is being evaluated to help them get to stricter leve= ls.
[...]
The original intent of selectors and domain names, going back t= o DomainKeys, was that selectors would be used to identify a key, and the d= omain name would be used to identify the source, or responsible party, rega= rding a message.=C2=A0 Selectors can be rotated in and out of service for a= given domain name without changing the domain name.=C2=A0 Reputation, ther= efore, would be developed about the domain name (the "d=3D") spec= ifically.=C2=A0 Selectors were orthongonal.

Based on discussions wit= h Seth and Gene earlier, it sounds like the=20 industry has sadly not taken up the habit of key and selector rotation,=20 and instead the pairing of "s=3D" and "d=3D" now identi= fies a single source.=C2=A0 Ignoring the obvious security problem this intr= oduces, we're now talking about implicitly formalizing this tuple as id= entifying a source.=C2=A0 This contradicts that original intent.=C2=A0 In p= articular, if one were to develop reputation in this way, then a key being = rotated out takes the reputation with it; signers would have to establish s= ome procedure for doing so with substantial overlap so that the new key can= be "warmed".=C2=A0 Worse, in an emergency where a key is comprom= ised, that tuple's reputation irretrievably suffers.

= How is this better than encouraging the industry to adopt the separation of= functions that was originally intended?


The *only* intent here is to report ba= ck services that break authentication to the domain owner in a DMARC report= . As such, the selector disambiguates services (especially when there are m= ultiple hops, some of which might have the same d=3D) and allows a reporter= to make a clear determination to a report consumer of where authentication= failed so that a service can be properly configured in SPF or with DKIM.

In many cases, this process is ambiguous or impossi= ble without the inclusion of selectors. This adds demonstrable value for a = consumer of DMARC reports where mail is indirectly delivered.
This solves a real problem now, and has nothing to do with repu= tation which would be silly to build on top of this tuple for the reasons y= ou've outlined.

Seth

=


-MSK

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


--001a114326a6825ebf05539a7801-- From nobody Wed Jul 5 22:42:11 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12C391243FE for ; Wed, 5 Jul 2017 22:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bagR_aYCM3oK for ; Wed, 5 Jul 2017 22:42:07 -0700 (PDT) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5AC81200CF for ; Wed, 5 Jul 2017 22:42:07 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id w19so5715639uac.0 for ; Wed, 05 Jul 2017 22:42:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=14BZmVJHC/23zvcyJoCTtAYVCH3ZagsXMw6j01mbFW4=; b=i/78F2+CHpDjqYlNfHOCKlpbCybRqzI2GqPpNTyKEVg0yPHjqSz79Mrme97DZ0YQ7z SLU7IuRqRqmwrY0AuWgKBnHGelw7/0B3a0vZQiIacPtedoS4JUr/5FmHeCT7ivAyrhV2 eoMVuqJWaY3YYVDBtTs2FiAKF4flCqOPrURkmT5+9fkG6EtoX7yO65VX0Tr4eQm6Ub0k t+fniE2MYx1zweLsHXYWaD6jZwhlfLB5L9phd7CQRYf0kAhnNOgO4/1gtyp2pkAxnwVD ryp3af0VKLVVf0esPnpysxtCvubHG8otVwwf8PrFbxAaCJGg6eav4TY9MzkuNiqVSskf 1gGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=14BZmVJHC/23zvcyJoCTtAYVCH3ZagsXMw6j01mbFW4=; b=i7c2S7wwjGtuoCDwXgqK4xBafj79XCsDIEQxtkrqyENKbGxPApvvNEnnF69o23QUlW hv5WblqQZj5d9BrxaEaKgc/3IZIPXBSYDVgieVHtDuH3/SGekXO4wX5T20ZrK3vi49Xj LWa0vPwNtNz+vkcSWWFXm0g3u6z4v10rV5UtXWq4QoZe8UNLB5KaEGak8Pp4aenf7SMK ygqvLaXGJtp7uyFchvOk8NrsnXU6j3BbwWobZVHoI242LMuPHMn8hgR4+/MvfuEa05fv GxoMc0bgDTAwG3+CIYYtohX+YKZsMWTxrZ0CKx/CWgNaLaXoy3QWlwmjeVx3mv2oFKzX kF4A== X-Gm-Message-State: AKS2vOyZRTEWhLCJuZOyc6iMwJkWITYNkIfDQvI2JXlXarNoNwFtTotm lo3Fefo6tXxqeJqPWuEh9ybRW6ysQ03a X-Received: by 10.176.77.223 with SMTP id b31mr30603103uah.76.1499319726881; Wed, 05 Jul 2017 22:42:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.126.196 with HTTP; Wed, 5 Jul 2017 22:42:06 -0700 (PDT) In-Reply-To: References: From: "Murray S. Kucherawy" Date: Wed, 5 Jul 2017 22:42:06 -0700 Message-ID: To: Seth Blank Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="f403043c467cb9c16305539f9324" Archived-At: Subject: Re: [dmarc-ietf] selectors in AAR. X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 05:42:10 -0000 --f403043c467cb9c16305539f9324 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 5, 2017 at 4:36 PM, Seth Blank wrote: > The *only* intent here is to report back services that break > authentication to the domain owner in a DMARC report. As such, the selector > disambiguates services (especially when there are multiple hops, some of > which might have the same d=) and allows a reporter to make a clear > determination to a report consumer of where authentication failed so that a > service can be properly configured in SPF or with DKIM. > Are we talking about adding this to the DMARC reports or to A-R? Both have been suggested in this thread. I believe you're specifically talking about DMARC reports, and I have less of a concern with those. On the other hand, adding them to A-R makes less sense because that's got users partly in mind, and I don't think a user would care too much what selector is being used in a DKIM signature. Explicitly discouraging development of reputation based on an s=/d= pairing would be an added bonus. -MSK --f403043c467cb9c16305539f9324 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jul 5, 2017 at 4:36 PM, Seth Blank <seth@sethbla= nk.com> wrote:
The *onl= y* intent here is to report back services that break authentication to the = domain owner in a DMARC report. As such, the selector disambiguates service= s (especially when there are multiple hops, some of which might have the sa= me d=3D) and allows a reporter to make a clear determination to a report co= nsumer of where authentication failed so that a service can be properly con= figured in SPF or with DKIM.

<= /div>
Are we talking about adding this to the DMARC reports or to A-R?= =C2=A0 Both have been suggested in this thread.

I believe= you're specifically talking about DMARC reports, and I have less of a = concern with those.=C2=A0 On the other hand, adding them to A-R makes less = sense because that's got users partly in mind, and I don't think a = user would care too much what selector is being used in a DKIM signature.= =C2=A0 Explicitly discouraging development of reputation based on an s=3D/d= =3D pairing would be an added bonus.

-MSK
<= /div>
--f403043c467cb9c16305539f9324-- From nobody Thu Jul 6 10:20:16 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66EE113183B for ; Thu, 6 Jul 2017 10:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id idaKjc_Br9nk for ; Thu, 6 Jul 2017 10:20:12 -0700 (PDT) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CCCC131839 for ; Thu, 6 Jul 2017 10:20:12 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id z22so5785403uah.1 for ; Thu, 06 Jul 2017 10:20:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=1mIJqveW8wTUmDYNaWO1QyqGZ4GJNcNdbQo4tUXjC8Y=; b=FlL1U8GlnDjY1kYtHPc7rTWOg3P8ZSZk4AC73xPlNUG9qMO3UOIC7mVuvRWQAgHpyq twqYyf31UJ3HRa4AJHl8WbIBNt+EBgUh7Ii4mjjr2lDIV8suXM/DI8bdOHX09hRY8maL su3KtNM/pOllT1V0I7omsSoxR8i/kux1OlJWKJHUxNomEGB+ObEX18w5+n3cxz5fusTy xVgAAssi7nlc2Pk+d0rXOKDywAMykNH5gwlY0DnpqZYmkgGr0ndfiVWFPK8NwPvQMH37 LzufqD+gyr2d52AYbN6VKlTW7xQFbP4RLF71nrQwUTXnSUxH7G/uNTzVsvHI2xVl2nA9 vUNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=1mIJqveW8wTUmDYNaWO1QyqGZ4GJNcNdbQo4tUXjC8Y=; b=s5zdzjgyOsw4/dqsDybGzzxvHCEHP9LyWevcqPEtwPlMts7dw0An93mUNanwqOfpse TWv6CkaNVfcI3UJJBgD9pyBkVQAy9dnSqobPtAQEr6c8LgXailNyrSycCxWmgZ45lvfY gp889jtwj88r8qiKkkqqYF0FO6roIPSGp+e+HSY0MB6577Vvd3LfMW8yXnbC3bSYziAC zA6UaAHMUCDUSm/C1kjqGZhkFFWER/u2kU7s6La1weQq/mQd/H2iClcWj0fzljJt2w30 ud2FV76pkTizXs1Q0xBCoLCpTo/AlMqTvQDFQfCT1HSX1LWH/C+VxOe9FxhNl6V7aYuf n/3g== X-Gm-Message-State: AKS2vOwgaQL2fh74MBUQB+pwnH+heZJi1S4KNLj5XSckAKVyIZNVGSC/ OPZeBvJfoCvB0Oz1vQHbJpCj7sLD7fIzHjU= X-Received: by 10.176.79.38 with SMTP id n38mr30996567uah.101.1499361610764; Thu, 06 Jul 2017 10:20:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.152.80 with HTTP; Thu, 6 Jul 2017 10:19:50 -0700 (PDT) In-Reply-To: References: From: Seth Blank Date: Thu, 6 Jul 2017 10:19:50 -0700 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="f403043c3988335a450553a95477" Archived-At: Subject: Re: [dmarc-ietf] selectors in AAR. X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 17:20:14 -0000 --f403043c3988335a450553a95477 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 5, 2017 at 10:42 PM, Murray S. Kucherawy wrote: > Are we talking about adding this to the DMARC reports or to A-R? Both > have been suggested in this thread. > > I believe you're specifically talking about DMARC reports, and I have less > of a concern with those. On the other hand, adding them to A-R makes less > sense because that's got users partly in mind, and I don't think a user > would care too much what selector is being used in a DKIM signature. > Explicitly discouraging development of reputation based on an s=/d= pairing > would be an added bonus. > I think the reputation conversation here is a red herring. Anyone making a reputation decision (i.e. receivers) would be in receipt of the actual message, with the DKIM-Signature blocks and all other headers, and can use whatever data they want, including far more than a d,s pairing, to make a reputation judgement. This thread is only about encapsulating information useful for a consumer of DMARC reports, as that consumer will not have the message and its headers. Selectors are critical here for tying things together. The DMARC report data is generated from the AAR, because the AAR transports the relevant data (the receiver only has data on the last hop without the AAR) in a signed manner that survives manipulations to the chain. Data gets into the AAR by first being stamped in the A-R and then getting encapsulated when the ARC Set is Sealed. So putting selectors in the A-R accomplishes transmitting selectors for use in a DMARC report cleanly; only a ptype needs to be registered, and no changes to the spec or AAR construction are needed. It was floated a while back on the list of putting this information in only the AAR and not the A-R directly, but that was shot down because the consensus was the AAR should only transit information that had been stamped in an A-R, and not additional data. I'm happy to revisit this, I think selectors and source ip make more sense in the AAR than the A-R (and then we don't need new ptypes or additional headers for transmission), but I thought I'd already lost that battle ;-) Seth > -MSK > --f403043c3988335a450553a95477 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Jul 5, 2017 at 10:42 PM, Murray S. Kucherawy <superuser@gmail.com> wrote:
Are we talking about= adding this to the DMARC reports or to A-R?=C2=A0 Both have been suggested= in this thread.

I believe you're specifically talkin= g about DMARC reports, and I have less of a concern with those.=C2=A0 On th= e other hand, adding them to A-R makes less sense because that's got us= ers partly in mind, and I don't think a user would care too much what s= elector is being used in a DKIM signature.=C2=A0 Explicitly discouraging de= velopment of reputation based on an s=3D/d=3D pairing would be an added bon= us.




=
Seth
=C2=A0
-MSK

--f403043c3988335a450553a95477-- From nobody Thu Jul 6 18:05:37 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12FB2129564 for ; Thu, 6 Jul 2017 18:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XxCXA0oKpvxY for ; Thu, 6 Jul 2017 18:05:34 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 883A7127010 for ; Thu, 6 Jul 2017 18:05:34 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id w19so11894859uac.0 for ; Thu, 06 Jul 2017 18:05:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mAWR1rDH4wiLUMhqCTkxbBne45K3Lof/0BH5DHNsMGo=; b=PP2sEvKqaabeVJ+4ZOgBOTSNm3QRG6aUKUA37L1q1lFBkPMugfn1kYqa0nK8YY2UdH vFrHOTufxvxSZGAvSQmcQV6kTEi8JTvQ4ltDLkjIyt8wDYtqypQga7VgfIGVlfMdKc7R Q5M7VTC49IPvgyxKHokfEq6SXzolaJe5kQiKIBkm1tlObb95fKA7AwczSEMI/nSvM0VB RMgbTXtoVj4kk4DazLYU1O91Pg8pU4/W3M7tqIUjK3Q+oIDCrJfiQwZlJroJ+7tBTX7B MTZmGz8y/nfOHCK2q3bN6LDph1VRSEFHuI+rltEkWMdUk+Z0X7BJGr7oPq5M3eDyz4WV frww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mAWR1rDH4wiLUMhqCTkxbBne45K3Lof/0BH5DHNsMGo=; b=HC7VQXoRsZzBkfaleTYYcYb1puYy1ILLsCDyTCXuP3hwuDJCUNo1jWsDwyZ82IrayV zs3alm1V4N0yPfPG2wefiLJvQMVLzhol5Le0pTXG/T1lD6jhIrf8OXa6uYpPx+9iJsN1 CVa2lp/BMRfrngh3OyDgjX0o+SrCZDrkWoFZ4Cisjxiz6E9483uh8x0ROtvqmuVBgI0Q +iZfJouap8SIwzskJHzxEMpWJDtkR5S1d4w2eEeLPO9oSF/kELV/dvMAQ68X3mQ3p+fw q8M8VzC5Y1KjlfybeyzQh95p4pbOC/hvB6kqk7m6JUeL9zKLPLhd/sbfH2EF1DdeCG+d huCg== X-Gm-Message-State: AKS2vOxSR1Gq+BercDZB015Cwh+sB4ap2EtR13EobCGB/sr2pTBFtStP v7+1TLUy9d2PPRfSD3BY9ixZ15VYbQ== X-Received: by 10.176.71.219 with SMTP id w27mr27961542uac.3.1499389533527; Thu, 06 Jul 2017 18:05:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.126.196 with HTTP; Thu, 6 Jul 2017 18:05:32 -0700 (PDT) In-Reply-To: References: From: "Murray S. Kucherawy" Date: Thu, 6 Jul 2017 18:05:32 -0700 Message-ID: To: Seth Blank Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="f40304378b7886a3d10553afd457" Archived-At: Subject: Re: [dmarc-ietf] selectors in AAR. X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 01:05:36 -0000 --f40304378b7886a3d10553afd457 Content-Type: text/plain; charset="UTF-8" On Thu, Jul 6, 2017 at 10:19 AM, Seth Blank wrote: > This thread is only about encapsulating information useful for a consumer > of DMARC reports, as that consumer will not have the message and its > headers. Selectors are critical here for tying things together. > > The DMARC report data is generated from the AAR, because the AAR > transports the relevant data (the receiver only has data on the last hop > without the AAR) in a signed manner that survives manipulations to the > chain. Data gets into the AAR by first being stamped in the A-R and then > getting encapsulated when the ARC Set is Sealed. > > So putting selectors in the A-R accomplishes transmitting selectors for > use in a DMARC report cleanly; only a ptype needs to be registered, and no > changes to the spec or AAR construction are needed. > I think this presupposes that there's some connective tissue between, but distinct from, the DMARC report generator and the ARC implementation. Do we have to presume that, or is it enough to make space for it in the DMARC report, and then not specify how that information goes from one component to the next? Then an operator can decide how to move that information between those two components however it sees fit, and there's no need to rub up against A-R's intended use (which I would argue doesn't include relaying selectors downstream). -MSK --f40304378b7886a3d10553afd457 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jul 6, 2017 at 10:19 AM, Seth Blank <seth@sethbl= ank.com> wrote:
This th= read is only about encapsulating information useful for a consumer of DMARC= reports, as that consumer will not have the message and its headers. Selec= tors are critical here for tying things together.

= The DMARC report data is generated from the AAR, because the AAR transports= the relevant data (the receiver only has data on the last hop without the = AAR) in a signed manner that survives manipulations to the chain. Data gets= into the AAR by first being stamped in the A-R and then getting encapsulat= ed when the ARC Set is Sealed.

So putting selector= s in the A-R accomplishes transmitting selectors for use in a DMARC report = cleanly; only a ptype needs to be registered, and no changes to the spec or= AAR construction are needed.

=
I think this presupposes that there's some connective tissue= between, but distinct from, the DMARC report generator and the ARC impleme= ntation.=C2=A0 Do we have to presume that, or is it enough to make space fo= r it in the DMARC report, and then not specify how that information goes fr= om one component to the next?=C2=A0 Then an operator can decide how to move= that information between those two components however it sees fit, and the= re's no need to rub up against A-R's intended use (which I would ar= gue doesn't include relaying selectors downstream).

-= MSK
--f40304378b7886a3d10553afd457-- From nobody Thu Jul 6 18:25:54 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD4B0131574 for ; Thu, 6 Jul 2017 18:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxJCbXGx2F8M for ; Thu, 6 Jul 2017 18:25:51 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::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 CB7B0129564 for ; Thu, 6 Jul 2017 18:25:50 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id y70so9921940vky.3 for ; Thu, 06 Jul 2017 18:25:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=LdK3cDGw9JlZ1MXpDftrj33Z2/FBO6Z86ZJ5m42LmDA=; b=YWngepo+DBt2Uw023VrJGv5iEFRz9NM0QNPqbJ+QVo3EIVvza6jWqcaToyqit66mNl Xa8R1RWa7YDxZlVu8VGK9B65K5DYaEA+f6ZKEd3QFiAYK/15JQnBzFlcxb+6o0ceG7X2 uEf/3w3PKST//tWZ54z1hNWcpeM8IipYUDuRn1pe2/JM6DDv6kGP1TSZytp882FK2bbo jeASw+pKYKP29OjNMyKloiNqAemhyBx4eHOS3jPcizwqTCJFrfhz+E85vVjce5KRjxvp /IpE/ZtkpibgY7yXr+3eiq7N2AhxFsvfNBfmf6XW4T/XZsYWOAIqQ73gSGf6OUoNxLk8 6ZuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=LdK3cDGw9JlZ1MXpDftrj33Z2/FBO6Z86ZJ5m42LmDA=; b=FDk4qveBLkmyJLFJ++8jbHLgtbGq1Pv+03omFH6jfDFHhhr5cefXb8wAQ4NyrINqmv 2TqOh7Crw+BamozLABu1o7+nb8NwLaMSrYIiMbpbs88vaoIQ4DBIIJfrjmE949rOZ23C h70CLG/5CdVcta8usVcWFU780k0ml9xoZ6Wx0FxXpysc6Gb3+jrFLtNafXTbe+7dB8zS f1EDDquMZlivJtnQ8a1oV+CkxluC3g5PQvQfd46qnQY+RedR5HknU442vzHL/ga0x50S ifDyKc7vHRXI4QX24DCRS7XmP8YSCda3OsJavNm7g8mAHIRik+BVR6bCVQbuhhMRwo5+ TOTA== X-Gm-Message-State: AIVw113T/2vNM+GglzRC5PwOKTOuQVRfKO7Yub0/rQ7N8WAGKJcMoyYf bussZTm78kYdyg8FqYH7itLf4dbKqHZnltuZ8g== X-Received: by 10.31.160.80 with SMTP id j77mr15847439vke.42.1499390749672; Thu, 06 Jul 2017 18:25:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.152.80 with HTTP; Thu, 6 Jul 2017 18:25:29 -0700 (PDT) In-Reply-To: References: From: Seth Blank Date: Thu, 6 Jul 2017 18:25:29 -0700 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a114326a603d0340553b01dc2" Archived-At: Subject: Re: [dmarc-ietf] selectors in AAR. X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 01:25:53 -0000 --001a114326a603d0340553b01dc2 Content-Type: text/plain; charset="UTF-8" On Thu, Jul 6, 2017 at 6:05 PM, Murray S. Kucherawy wrote: > > I think this presupposes that there's some connective tissue between, but > distinct from, the DMARC report generator and the ARC implementation. Do > we have to presume that, or is it enough to make space for it in the DMARC > report, and then not specify how that information goes from one component > to the next? Then an operator can decide how to move that information > between those two components however it sees fit, and there's no need to > rub up against A-R's intended use (which I would argue doesn't include > relaying selectors downstream). > So this is a very fair comment. But I think it's deeply problematic. In the case of a direct mail flow, the receiver has all the needed information from the SMTP connection and A-R payload to create a report. None of this information is present once a message arrives at a receiver in an indirect manner. I would strenuously argue the charter's call for "eliminating the DMARC's effects on indirect mail flows" requires that reporting - which is the fundamental feedback mechanism for a sender - work properly under said fixes. This is impossible for a receiver to do without ARC passing the information along. And ARC has this transmission mechanism in its AAR, but we need to make sure the appropriate information is in it. --001a114326a603d0340553b01dc2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Jul 6, 2017 at 6:05 PM, Murray S. Kucherawy <superuser@gmail.com= > wrote:
I thin= k this presupposes that there's some connective tissue between, but dis= tinct from, the DMARC report generator and the ARC implementation.=C2=A0 Do= we have to presume that, or is it enough to make space for it in the DMARC= report, and then not specify how that information goes from one component = to the next?=C2=A0 Then an operator can decide how to move that information= between those two components however it sees fit, and there's no need = to rub up against A-R's intended use (which I would argue doesn't i= nclude relaying selectors downstream).
=

So this is a very fair comment. But I think it's de= eply problematic.

In the case of a direct mail flo= w, the receiver has all the needed information from the SMTP connection and= A-R payload to create a report. None of this information is present once a= message arrives at a receiver in an indirect manner.

<= div>I would strenuously argue the charter's call for "eliminating = the DMARC's effects on indirect mail flows" requires that reportin= g - which is the fundamental feedback mechanism for a sender - work properl= y under said fixes. This is impossible for a receiver to do without ARC pas= sing the information along. And ARC has this transmission mechanism in its = AAR, but we need to make sure the appropriate information is in it.
--001a114326a603d0340553b01dc2-- From nobody Fri Jul 7 06:12:43 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4C10129B94 for ; Fri, 7 Jul 2017 06:12:41 -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=eudaemon.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2LfikK2TYcy for ; Fri, 7 Jul 2017 06:12:39 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002: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 AF7591201F2 for ; Fri, 7 Jul 2017 06:12:39 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id v193so13027655ywg.2 for ; Fri, 07 Jul 2017 06:12:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eudaemon.net; s=dkey; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=8u+GXCBE6HEpPNy6H6E4Vmx/zbgWXLe3UNM5QdWk8RU=; b=b0B5l6gNSD3O6Chu9gv65Zd2BYPO7n3MhVab9RmPIRJU1g+tc6BqD8M8fpiymFq+hb bz9d9pDJU+qJYUbsirAk+svNvQ8JhSmu/9jQg5gFCoqFBPnhg7nxcuPcYq/hy4E+9sZK wjcz1O3Qi1Xn8efB2EPLV3OpUyJdrZYwTa4SQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=8u+GXCBE6HEpPNy6H6E4Vmx/zbgWXLe3UNM5QdWk8RU=; b=PaAs3VUD5vQ0BRKKPsk/YgP/zVr0Z6hlPxNr2SRhmh+3IanlERzg8FJjHOMf5k3wsa i2+WDoSr1DoSJaa4oyq+/zZpUFir3+W/OBYVbGuR9STp91o1D21WgU4nzZtj4fM406y0 wLVIXDuGMu/LJsgqGzkDD8A+UfQ0jwG6i4nqydGADgGPf+lmzi0qOZQYehpuwyUAB3sv 3N/lK/j1QfTQZ4fqOlwAjSmnp/T//EeASOzjun/f6Lu8Rqv2QPJGVkNdQYPxriVotpH/ Cfv5ItWGLSa/0y5T30VG67G93CvVF/FaUCzAyIq83/59Et7nQVL6K3d+hThm4GyeP1hT 4xsA== X-Gm-Message-State: AIVw1110J+xxK+OVRbZgGFvz6srgQMumwgWOiiin8azyNPWsaQZnigAN sttTTUp6bFgbyW9EywhKxA== X-Received: by 10.129.200.75 with SMTP id k11mr1840288ywl.253.1499433158571; Fri, 07 Jul 2017 06:12:38 -0700 (PDT) Received: from [192.168.0.12] (208-104-133-98.brvd.dsl.dyn.comporium.net. [208.104.133.98]) by smtp.gmail.com with ESMTPSA id x21sm725136ywd.76.2017.07.07.06.12.37 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Jul 2017 06:12:38 -0700 (PDT) From: Tim Draegen Content-Type: multipart/alternative; boundary="Apple-Mail=_89B4AE5F-F6FF-4AF7-8357-BC92181A454B" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 7 Jul 2017 09:12:37 -0400 References: To: "dmarc@ietf.org" In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [dmarc-ietf] using selectors to identify sources X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 13:12:42 -0000 --Apple-Mail=_89B4AE5F-F6FF-4AF7-8357-BC92181A454B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jul 5, 2017, at 6:33 PM, Murray S. Kucherawy = wrote: >=20 > Based on discussions with Seth and Gene earlier, it sounds like the = industry has sadly not taken up the habit of key and selector rotation, = and instead the pairing of "s=3D" and "d=3D" now identifies a single = source. Ignoring the obvious security problem this introduces, we're = now talking about implicitly formalizing this tuple as identifying a = source. This contradicts that original intent. In particular, if one = were to develop reputation in this way, then a key being rotated out = takes the reputation with it; signers would have to establish some = procedure for doing so with substantial overlap so that the new key can = be "warmed". Worse, in an emergency where a key is compromised, that = tuple's reputation irretrievably suffers. >=20 > How is this better than encouraging the industry to adopt the = separation of functions that was originally intended? I just caught up on the "selectors in AAR" thread, but wanted to go back = to this early statement about key rotation and pairing of "s=3D" and = "d=3D" to identify a single source. Thus a new Subject: is born. It's true key rotation is rare. People are figuring out how to do it, = though. Due to the size and scope of email's installed base, it takes a = really long time for the knowledge to slosh around the Internet. Using = multiple CNAMEs, delegating sub-domains, even out-sourcing all things = _domainkey.* is possible. Unfortunately there isn't good guidance on the = pros and cons of each way, and so people implement quick and dirty = 'cause they don't know any better. Using selectors to identify a single source of email isn't right, IMO. = Given the way things play out, once people are told that selectors are = important because they're used to identify sources of email (doesn't = even matter how true it is), then we'll be stuck with selectors being a = component of reputation. People will make do with what they've got. If nature abhors a vacuum, the missing piece is "what identifies a = source?". Selectors might fill that hole unless real guidance is = provided. Using sub-domains to differentiate services works nicely. Today lack of = clear guidance means a Domain Owner has to deal with a mashup of = different ways to integrate with 3rd party senders. 3rd party senders = make do with what they've got, and that is often very constrained. Maybe such guidance should go into the "Usage Guide". Declaring which = parts of the DMARC puzzle should be used to build reputation system = seems pretty important if interoperability is the goal. -=3D Tim --Apple-Mail=_89B4AE5F-F6FF-4AF7-8357-BC92181A454B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On = Jul 5, 2017, at 6:33 PM, Murray S. Kucherawy <superuser@gmail.com>= wrote:

Based on discussions with Seth and Gene earlier, it sounds = like the industry has sadly not taken up the habit of key and selector = rotation, and instead the pairing of "s=3D" and "d=3D" now identifies a = single source.  Ignoring the obvious security problem this = introduces, we're now talking about implicitly formalizing this tuple as = identifying a source.  This contradicts that original intent.  = In particular, if one were to develop reputation in this way, then a key = being rotated out takes the reputation with it; signers would have to = establish some procedure for doing so with substantial overlap so that = the new key can be "warmed".  Worse, in an emergency where a key is = compromised, that tuple's reputation irretrievably suffers.

How is = this better than encouraging the industry to adopt the separation of = functions that was originally = intended?

I = just caught up on the "selectors in AAR" thread, but wanted to go back = to this early statement about key rotation and pairing of "s=3D" and = "d=3D" to identify a single source. Thus a new Subject: is = born.

It's = true key rotation is rare. People are figuring out how to do it, though. = Due to the size and scope of email's installed base, it takes a really = long time for the knowledge to slosh around the Internet. Using multiple = CNAMEs, delegating sub-domains, even out-sourcing all things = _domainkey.* is possible. Unfortunately there isn't good guidance on the = pros and cons of each way, and so people implement quick and dirty = 'cause they don't know any better.

Using selectors to identify a single = source of email isn't right, IMO. Given the way things play out, once = people are told that selectors are important because they're used to = identify sources of email (doesn't even matter how true it is), then = we'll be stuck with selectors being a component of reputation. People = will make do with what they've got.

If nature abhors a vacuum, the missing = piece is "what identifies a source?". Selectors might fill that hole = unless real guidance is provided.

Using sub-domains to differentiate = services works nicely. Today lack of clear guidance means a Domain Owner = has to deal with a mashup of different ways to integrate with 3rd party = senders. 3rd party senders make do with what they've got, and that is = often very constrained.

Maybe such guidance should go into the "Usage Guide". = Declaring which parts of the DMARC puzzle should be used to build = reputation system seems pretty important if interoperability is the = goal.

-=3D = Tim

= --Apple-Mail=_89B4AE5F-F6FF-4AF7-8357-BC92181A454B-- From nobody Fri Jul 7 06:40:44 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5964131573 for ; Fri, 7 Jul 2017 06:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eudaemon.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GsM1Kxj4-Bvs for ; Fri, 7 Jul 2017 06:40:38 -0700 (PDT) Received: from mail-yb0-x22c.google.com (mail-yb0-x22c.google.com [IPv6:2607:f8b0:4002:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFCA7131551 for ; Fri, 7 Jul 2017 06:40:37 -0700 (PDT) Received: by mail-yb0-x22c.google.com with SMTP id f194so10677697yba.3 for ; Fri, 07 Jul 2017 06:40:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eudaemon.net; s=dkey; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=vN8uXBzMuoQOF1ptmhlhq/7TkweOfc6Kht0UdNu//aQ=; b=R1OCjk8yVHKeGt1rtOhnqvaYgEh/i/UnDdCHdnZWdcWD1SBuVP9YT+dxgBQMCkcPT+ fEYK+SxJH5riC/A0+o8ZuvHJF9blrU70Fys3vameIO+eJxJV7E9p1zMhbICJNqSopbKW bZkFtuRGRSl85Iv57/S4PRoinnZKKfItiyfyI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=vN8uXBzMuoQOF1ptmhlhq/7TkweOfc6Kht0UdNu//aQ=; b=JrB5PTlK5xg0Xld2XSa6WHBThvdoj7IQ5LAUn0rNTcDyKrH+Shc8v323z8hWEY6+OG D3yppuN+YCVu/OxFH3zvAyTXMnh3jTBfO3WpNyUgEvn8AqNw20wrIRLzzMUt4MoIBeMw kc8og4O+4Ere4xlZKMprF/xjMBQsu80ecWH2XxKf3LByUl3vVHyrRlVEyl0wTMMMFbVc rIvU51Suesb9CjDp7c/T8fZ4ORfijzq40nAMkW5bdFyAyzlirdhyr635qpYQeU1/qFfj xK53yTmPT80zLKV7APBQpVf+xY16pfxv//rjEVM49pjwR98hQS0A5Y2Hn1ai6nnT4tLR 5uOA== X-Gm-Message-State: AIVw110RZ9lwMs8wr6t0dviMZpnwXvibF+ab7hnObfesICFcJ3dkUcQx e2mk5LE+NuZ6kzXqWvk6eg== X-Received: by 10.37.214.12 with SMTP id n12mr4448183ybg.122.1499434836758; Fri, 07 Jul 2017 06:40:36 -0700 (PDT) Received: from [192.168.0.12] (208-104-133-98.brvd.dsl.dyn.comporium.net. [208.104.133.98]) by smtp.gmail.com with ESMTPSA id h197sm1298348ywc.10.2017.07.07.06.40.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Jul 2017 06:40:36 -0700 (PDT) From: Tim Draegen Content-Type: multipart/alternative; boundary="Apple-Mail=_B7DB3CCE-09AF-4FBF-B618-B0F933C1A3AE" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 7 Jul 2017 09:40:34 -0400 References: To: "dmarc@ietf.org" In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [dmarc-ietf] selectors in AAR. X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 13:40:40 -0000 --Apple-Mail=_B7DB3CCE-09AF-4FBF-B618-B0F933C1A3AE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jul 6, 2017, at 9:25 PM, Seth Blank wrote: >=20 > In the case of a direct mail flow, the receiver has all the needed = information from the SMTP connection and A-R payload to create a report. = None of this information is present once a message arrives at a receiver = in an indirect manner. >=20 > I would strenuously argue the charter's call for "eliminating the = DMARC's effects on indirect mail flows" requires that reporting - which = is the fundamental feedback mechanism for a sender - work properly under = said fixes. This is impossible for a receiver to do without ARC passing = the information along. And ARC has this transmission mechanism in its = AAR, but we need to make sure the appropriate information is in it. It might be useful to show what the desired DMARC reporting looks like = for email flows where ARC is at play. For example, maybe "override" just shows "arc_at_work" with existing = fields identifying the last hop (like is done today). In that case = reporting works properly. If there's a more robust presentation that is wanted, it would help the = list to see an example. Maybe then people could follow along to see why = the inclusion of selectors is necessary from a DMARC reporting = perspective. =3D- Tim --Apple-Mail=_B7DB3CCE-09AF-4FBF-B618-B0F933C1A3AE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On = Jul 6, 2017, at 9:25 PM, Seth Blank <seth@sethblank.com> = wrote:

In = the case of a direct mail flow, the receiver has all the needed = information from the SMTP connection and A-R payload to create a report. = None of this information is present once a message arrives at a receiver = in an indirect manner.

I would strenuously argue = the charter's call for "eliminating the DMARC's effects on indirect mail = flows" requires that reporting - which is the fundamental feedback = mechanism for a sender - work properly under said fixes. This is = impossible for a receiver to do without ARC passing the information = along. And ARC has this transmission mechanism in its AAR, but we need = to make sure the appropriate information is in = it.

It might be useful to show what the desired DMARC reporting = looks like for email flows where ARC is at play.

For example, maybe "override" just = shows "arc_at_work" with existing fields identifying the last hop (like = is done today). In that case reporting works properly.

If there's a more robust = presentation that is wanted, it would help the list to see an example. = Maybe then people could follow along to see why the inclusion of = selectors is necessary from a DMARC reporting = perspective.

=3D- Tim

= --Apple-Mail=_B7DB3CCE-09AF-4FBF-B618-B0F933C1A3AE-- From nobody Fri Jul 7 07:11:44 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3492013146C for ; Fri, 7 Jul 2017 07:11:43 -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 I-CPp2bRxU9g for ; Fri, 7 Jul 2017 07:11:41 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F296812EC10 for ; Fri, 7 Jul 2017 07:11:40 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 13AFEC401EB for ; Fri, 7 Jul 2017 09:11:37 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1499436697; bh=JIxcxo1sCrUU7r4mN9IwGA0DQNIrRV3TF5MLeMBABLg=; h=From:To:Subject:Date:In-Reply-To:References:From; b=DokDlu9sR9rzvSh1hS6Z8oK8Stsy3HlXs3VZnI0HHY96792xvvmM6f04YWYGEV9o3 iuLNFKPup7CxCzuntfK/GRNbWUwXODXt4YaJTJ3QaChp6pnOgoknzX1tVkfq1UMFuj Ouf186a1AyS8iQw+SQWZFXS+oQqVJx+CS/qN4FMs= From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 07 Jul 2017 10:11:36 -0400 Message-ID: <2841386.K0mPqPZNK9@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-121-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] using selectors to identify sources X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 14:11:43 -0000 On Friday, July 07, 2017 09:12:37 AM Tim Draegen wrote: > > On Jul 5, 2017, at 6:33 PM, Murray S. Kucherawy > > wrote: > > > > Based on discussions with Seth and Gene earlier, it sounds like the > > industry has sadly not taken up the habit of key and selector rotation, > > and instead the pairing of "s=" and "d=" now identifies a single source. > > Ignoring the obvious security problem this introduces, we're now talking > > about implicitly formalizing this tuple as identifying a source. This > > contradicts that original intent. In particular, if one were to develop > > reputation in this way, then a key being rotated out takes the reputation > > with it; signers would have to establish some procedure for doing so with > > substantial overlap so that the new key can be "warmed". Worse, in an > > emergency where a key is compromised, that tuple's reputation > > irretrievably suffers. > > > > How is this better than encouraging the industry to adopt the separation > > of functions that was originally intended? > I just caught up on the "selectors in AAR" thread, but wanted to go back to > this early statement about key rotation and pairing of "s=" and "d=" to > identify a single source. Thus a new Subject: is born. > > It's true key rotation is rare. People are figuring out how to do it, > though. Due to the size and scope of email's installed base, it takes a > really long time for the knowledge to slosh around the Internet. Using > multiple CNAMEs, delegating sub-domains, even out-sourcing all things > _domainkey.* is possible. Unfortunately there isn't good guidance on the > pros and cons of each way, and so people implement quick and dirty 'cause > they don't know any better. > > Using selectors to identify a single source of email isn't right, IMO. Given > the way things play out, once people are told that selectors are important > because they're used to identify sources of email (doesn't even matter how > true it is), then we'll be stuck with selectors being a component of > reputation. People will make do with what they've got. > > If nature abhors a vacuum, the missing piece is "what identifies a source?". > Selectors might fill that hole unless real guidance is provided. > > Using sub-domains to differentiate services works nicely. Today lack of > clear guidance means a Domain Owner has to deal with a mashup of different > ways to integrate with 3rd party senders. 3rd party senders make do with > what they've got, and that is often very constrained. > > Maybe such guidance should go into the "Usage Guide". Declaring which parts > of the DMARC puzzle should be used to build reputation system seems pretty > important if interoperability is the goal. I think it depends on what is meant by 'source'. Imagine a scenario where I'm the mail admin for a shop that has 5 outbound servers. As a matter of security policy, private keys are generated on the machine that will use them and never transit the network. For DKIM then, I have 5 selectors. No problem. Time passes. I remember to do key rotation, but my colleagues that manage our DNS close the ticket that to add the records for the new keys after only publishing 4 of the 5 new records. Since the DNS people closed my ticket as finished, I put my new keys in production and start using the new selectors. Being a conscientious mail admin, I check my DMARC feedback reporting regularly. To my dismay, I discover that over the next day or two my DKIM pass rate for direct mail goes from 99% to less than 80%. If I have the selector, I can identify that all the unexpected failures come from a single system. I can take it out of production while I trouble shoot and focus my efforts on what went wrong on with the key rollover for that one system. Without the selector, I don't know if it's a single 'source' or multiple 'sources'. In this context, having the selector in DMARC feedback reporting to help define a 'source' is really useful. Using the selectors to segregate different 'sources' for reputation purposes is not (in this case). Receivers know the selector. If they feed domain and selector into their Bayesian processors and get a useful distinction, they are going to use it. No RFC will change that. If there's some statistically significant difference in 'sources' identified that way, then that's their call. I think selectors in DMARC reporting would be really useful. For ARC though, I'm not at all convinced. I can't think why, as a sender, I would care. Scott K From nobody Fri Jul 7 11:09:51 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2C7C12EC0E for ; Fri, 7 Jul 2017 11:09:48 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVKPVjpaXYFh for ; Fri, 7 Jul 2017 11:09:47 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F63E126C0F for ; Fri, 7 Jul 2017 11:09:47 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id p188so34033200oia.0 for ; Fri, 07 Jul 2017 11:09:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=qhDyyp5dG65y2W78t1Ij70PBXi5YFKCgt5+fj++sPXU=; b=Ea8UedBKtxjyXd4PUQ1128ibGBPNebLK6eBPyekWLj5BlbRnw/EV/Ojn0+o1bxauQE rbr8Gk6Q7QJbRwtXwiEDXUDDE3o4HyZps+CJK1vg9UdjCwCX12AXClSR3iBRJM0/5ZZs tveBORTxfEvNjMey1kAUrJqCd5Fl8NUk+m28OGTACTZ4KqaEnfRZ5E9LC/CjKkcj8ib/ NLGwg0/y/nPpwnraXXeVsPHe/5heSxR17guo7HrqbDNYiyG5XHAVpdEZIlo342q7Igj2 I+ShJYBsiKVUEiFTkCcaJ5mWfT5jxsKNuMOKMDy5DrkoHgEs/MSOhQwT3KB2aCJZpO/8 vMvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=qhDyyp5dG65y2W78t1Ij70PBXi5YFKCgt5+fj++sPXU=; b=cVDPt+mpgDmiHhVYzv8AH2BCArCL0ppSS2M78bhwqIlkgrCNUlrNgh/d79Mx1xVj3o JDbFUKoziK6VPoMon9HPSYRFAKJNvVtWeIYmlCFatg1CJKIjbHITCbNHm9/xU0yX74ck sRhBG8zJZpDd9L0BL39daOrXrITUUntW07uvQdoHKMaje6BcKjLVCH8ImmgW0awbb3BW OVOeGPi5o3RfJA9WM2s1ubsn5v4fBDdSvfIHIeIT+fwsHGlxO3e1xpaI7q/1oWNHNwnA C73GmFy5TC5xaJzg1ch3y7uhzqO29tl43F4L+ccG+GJgxxtzMqn/wdX1J7BmPg5SbPFs I/nw== X-Gm-Message-State: AIVw1115IXDhIR8QZrFmEc7qItzrcP4LOHZrrNfvS0RY28XHFZ8wnoMF VTCmNtGxUhh62GBbPmY= X-Received: by 10.202.104.156 with SMTP id o28mr1646989oik.53.1499450986456; Fri, 07 Jul 2017 11:09:46 -0700 (PDT) Received: from ?IPv6:2602:304:cda0:8800:217d:6fe0:696a:e274? ([2602:304:cda0:8800:217d:6fe0:696a:e274]) by smtp.gmail.com with ESMTPSA id n189sm4473657oih.0.2017.07.07.11.09.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Jul 2017 11:09:44 -0700 (PDT) To: "dmarc@ietf.org" From: Dave Crocker Message-ID: <20337b3e-be49-797c-2974-1e36bd9939e0@gmail.com> Date: Fri, 7 Jul 2017 11:09:41 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [dmarc-ietf] ARC RFC status to target X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 18:09:49 -0000 G'day. Noting the considerable efforts and progress on ARC specification, implementation and testing, I've given some though to the status that makes sense for the RFC that will result. The obvious assumption is Proposed Standard. I've come to believe that it makes more sense, at this stage, to seek a status of Experimental. That's not meant as a criticism of the work, but rather to accurately reflect the current understanding of ARC dynamics. Having intermediaries signing thing and having receivers base delivery and labeling decisions on those signatures is new and, I think, significantly different that doing that for SPF or DKIM. Who should sign and when isn't yet well understood. How those signatures should get evaluated by receiving filtering engines also is not yet well-understood. I think there is enough activity and commitment by a significant portion of the email operations community to gain the necessary understanding in a reasonable amount of time. However introducing an authentication mechanism into a trust-assessing mechanism -- where the system dynamics are not yet well-understood -- seems to me to be worthy of some formal caution. Experimental status is exactly for this purpose. Thoughts? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Jul 7 11:30:11 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF2C1317CE for ; Fri, 7 Jul 2017 11:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=SImcUemJ; dkim=pass (1024-bit key) header.d=yitter.info header.b=IEGInQRm 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 TE6NMULoxkLB for ; Fri, 7 Jul 2017 11:30:08 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 598C0131698 for ; Fri, 7 Jul 2017 11:30:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 9EDF3C0354 for ; Fri, 7 Jul 2017 18:29:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1499452175; bh=w0TCNIk8GrZkY/NMPGc400XAYVcVhoGUVJmSrx11TLw=; h=Date:From:To:Subject:References:In-Reply-To:From; b=SImcUemJ1RBPjzBHVOtC5M58jEHfFMyZWeNe4teYLqJT/d2/HeeH+8+AfEufVlctu AkobkucG4d8yLud9OKshIRABmL+UiDI6eNvDENAhwuVvYXK5e/SZmu65XGLXZ3m64N iOGcWkFJjJpNqXdyFL6SpplWp/2lkX2t5iUl6YxQ= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJzpZPK5C4Nr for ; Fri, 7 Jul 2017 18:29:34 +0000 (UTC) Date: Fri, 7 Jul 2017 14:29:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1499452174; bh=w0TCNIk8GrZkY/NMPGc400XAYVcVhoGUVJmSrx11TLw=; h=Date:From:To:Subject:References:In-Reply-To:From; b=IEGInQRmGG4/PXnQ8oYlUaUgKD98wThf/ecYLG45OR/Vp/zLaSzRf5/VVH12HB0bc vG4Wf5ycmFF/fK7VguzdjJShK/hSobzt+jrYEMhLtapueNov+ugiN2KnJ713/7WaTa wR777xgrP/cKN1U6pw0zqJZMjZ2vHXSblc5rvs/4= From: Andrew Sullivan To: dmarc@ietf.org Message-ID: <20170707182932.gm3vhxluv3kcc35d@mx4.yitter.info> References: <20337b3e-be49-797c-2974-1e36bd9939e0@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20337b3e-be49-797c-2974-1e36bd9939e0@gmail.com> Archived-At: Subject: Re: [dmarc-ietf] ARC RFC status to target X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 18:30:10 -0000 On Fri, Jul 07, 2017 at 11:09:41AM -0700, Dave Crocker wrote: > > Experimental status is exactly for this purpose. > > Thoughts? I always feel like experimental status ought to come with some description of what success or failure would mean and how that would be determined. I think that is aligned with (but not entailed by) https://www.ietf.org/iesg/informational-vs-experimental.html. And it seems to me that the reasoning in this case suggests that one might indeed be able to offer such a description. I know that it would have been _very helpful_ during SPFBIS if we'd had some way of knowing what counted as evidence, and for what, so at least for the sake of future chairs who'll have to evaluate the "experimental" status, it might be nice to offer such guidance. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Fri Jul 7 11:57:45 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 736C81200ED for ; Fri, 7 Jul 2017 11:57: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 Y7X50cxhCMUL for ; Fri, 7 Jul 2017 11:57: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 04F8812EB8C for ; Fri, 7 Jul 2017 11:57:42 -0700 (PDT) Received: from shiny.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 v67IvXpN086408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Fri, 7 Jul 2017 11:57:38 -0700 (PDT) (envelope-from smj@crash.com) X-DKIM: OpenDKIM Filter v2.4.3 segv.crash.com v67IvXpN086408 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=201506-2k; t=1499453858; bh=DqxNDNXPSxSPJi9jb8iS9c7daavJ5LH3xX8JboHpRR0=; h=Subject:To:References:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=J85PyDXGKTbHdzf4j5VeqB812AMln52CKH3qGsKOJJG3HOUQWzqiAgh45tUhK0cKa GWVhcUuBJ7P6+WyxhRzlMdtA4SCb1+x8E6rUo74wfbsyiYlgbE/bSyhJ5/EC8n/K7G DPz8WunN5fox/tioEvwqmkt2eOE+t4Ls9yR/HVxHqtQS/uTFfnE8BoBfaIkg4IkwSJ Pc66LDHJjRtLe4a0QDkKvZ9mxY5EGGOn14Q5u0vCRNPDzTl4SYPrgBgo17xCfVzS9d Zj/cPyeXHQtm4vSaIfCbqvDqam957qugiau/VeIufWVPNpKbRNLrzQVT1Geo02v2MB yeuzf3PBYFXCA== X-Authentication-Warning: segv.crash.com: Host 70-36-157-26.dsl.static.fusionbroadband.com [70.36.157.26] claimed to be shiny.crash.com To: dmarc@ietf.org References: <20337b3e-be49-797c-2974-1e36bd9939e0@gmail.com> <20170707182932.gm3vhxluv3kcc35d@mx4.yitter.info> From: Steven M Jones Message-ID: <09fd1486-c712-bd50-545c-9b694b3c79dc@crash.com> Date: Fri, 7 Jul 2017 11:57:36 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170707182932.gm3vhxluv3kcc35d@mx4.yitter.info> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (segv.crash.com [72.52.75.15]); Fri, 07 Jul 2017 11:57:38 -0700 (PDT) Archived-At: Subject: Re: [dmarc-ietf] ARC RFC status to target X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 18:57:43 -0000 On 7/7/17 11:29 AM, Andrew Sullivan wrote: > On Fri, Jul 07, 2017 at 11:09:41AM -0700, Dave Crocker wrote: >> Experimental status is exactly for this purpose. > I always feel like experimental status ought to come with some > description of what success or failure would mean and how that would > be determined. Would there be a proposed schedule for that evaluation to take place? I don't so much disagree with the description of how Experimental status /should/ work, and including evaluation criteria would make sense. But I'm not thrilled with the idea of ARC being left on the Experimental track for umpteen years... --S. From nobody Fri Jul 7 11:58:42 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97336131803 for ; Fri, 7 Jul 2017 11:58:40 -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=isdg.net header.b=kUxkx8rA; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=vrbDLNup 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 YzSmm4b3QfP0 for ; Fri, 7 Jul 2017 11:58:38 -0700 (PDT) Received: from listserv.winserver.com (dkim.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id D6FF91200ED for ; Fri, 7 Jul 2017 11:58:37 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=552; t=1499453916; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=F0p2yaCl2sNQiPwHuM+Zt+syWu4=; b=kUxkx8rA187TIJzMmr9GQDu4kcWEU8l5o8zOGZHYc/sIvomrQelGyLN4HAueWH 7bj4tbCVPp6W4KYPL06N32SMRSy2wKKnOVcWKb58SQYo+OtrnAp39iKiL20tTEWM Wm5uTArxs/KYYuY9QOMHibahZyal98oA8q9GZ2mAEJtLo= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.5) for dmarc@ietf.org; Fri, 07 Jul 2017 14:58:35 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.5) with ESMTP id 3812777947.1.2596; Fri, 07 Jul 2017 14:58:34 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=552; t=1499453680; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=iBi+1nn 0S8Kk7v/aGIsY2OZoSt4Ga1CYkLYcitetSac=; b=vrbDLNup3zYO2tXT1SMdyN+ 4efCOpuO7oUGa8Wclav+gbbVRhGQ7mzW5IRXQ+gHN+qN2obGSE8Kt8LGSw2Jtrnh 0mvJQVukuS8cV/Nzsc1uai0Nib450Z7UOEz6NQKYXCJh/vNguPxh/Z/hkluN4tly QJQ9XKlzzybPmwRgUbz0= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.5) for dmarc@ietf.org; Fri, 07 Jul 2017 14:54:40 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.5) with ESMTP id 60349815.9.18544; Fri, 07 Jul 2017 14:54:38 -0400 Message-ID: <595FD9DE.5030303@isdg.net> Date: Fri, 07 Jul 2017 14:58:38 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: "dmarc@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] selectors in AAR. X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 18:58:40 -0000 On 6/26/2017 5:26 PM, Gene Shuman wrote: > I definitely support this idea, as having the selectors available is > extremely useful to us as part of service authentication. And putting > them into the AR headers seems to be the appropriate solution. > > I guess the next question is how we would actually go about sending > this information. Something like header.s? My Auth-Res processor passes the DKIM selector value as "header.s" and the DKIM identity value as "header.i" so my package would be supportive and ready for it. -- HLS From nobody Fri Jul 7 12:09:10 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3848E12EC42 for ; Fri, 7 Jul 2017 12:09:09 -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=isdg.net header.b=UycKCYt/; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=mroF7Qkh 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 CKljTkGQSGIb for ; Fri, 7 Jul 2017 12:09:07 -0700 (PDT) Received: from listserv.winserver.com (dkim.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id B00BA12EB8C for ; Fri, 7 Jul 2017 12:09:07 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=609; t=1499454545; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=vT7vUWDRBIyCK9PWg5/W2XWtgPY=; b=UycKCYt/hbxbkDZI/bQQarC33IOL7f9I6lLTby1IwB8EYmpdgbUGMssKHMPwHQ ZwFDY7NQXRcvNAhO0NfqmVbMkZvXW6gw+dmWxtrd24U2ciPSLC3FAB+OMdsp637L wmSFmDSGJ9YJC+Blk3/q+0vBUUu5WRxLfCc1vki1bYi0s= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.5) for dmarc@ietf.org; Fri, 07 Jul 2017 15:09:05 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.5) with ESMTP id 3813407926.1.480; Fri, 07 Jul 2017 15:09:04 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=609; t=1499454307; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=RGba1lP LDK0MLfhnaEybq8K6/IRkWUlR0npj6RSfupA=; b=mroF7QkhhXdjPo3CEJC87ZR BPVCYGC0yWqaPjlRAGbefqVGdPWM0OuyG+TpvALnYuMhVL4i9vFuBDxNiLjwpcAY 8NVZj++sWiUgBe4GKUVYMXvcwZxNSl2KkbSLT2R/XoVTOzhcFiH93p7wRdCm5+fg n7jrmHCId6UrA7nJ1p1A= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.5) for dmarc@ietf.org; Fri, 07 Jul 2017 15:05:07 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.5) with ESMTP id 60978002.9.44752; Fri, 07 Jul 2017 15:05:06 -0400 Message-ID: <595FDC52.5070309@isdg.net> Date: Fri, 07 Jul 2017 15:09:06 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: "dmarc@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] using selectors to identify sources X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 19:09:09 -0000 On 7/7/2017 9:12 AM, Tim Draegen wrote: > I just caught up on the "selectors in AAR" thread, but wanted to go > back to this early statement about key rotation and pairing of "s=" > and "d=" to identify a single source. Thus a new Subject: is born. > > It's true key rotation is rare. People are figuring out how to do it, > though. In our case, since day 0 of DKIM, maybe a handful of times was the selector changed for our domains. I think its basically an DNS "update" automation issue, i.e. its not "forced" or "scheduled" for rotation if automated DNS update is not in place. -- HLS From nobody Fri Jul 7 12:12:57 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B02BC13013C for ; Fri, 7 Jul 2017 12:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=G6wv3SO/; dkim=pass (1024-bit key) header.d=yitter.info header.b=Hp2I7dOT 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 8pFURyB1-obG for ; Fri, 7 Jul 2017 12:12:55 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E30012ECBF for ; Fri, 7 Jul 2017 12:12:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 8AD4DC0354 for ; Fri, 7 Jul 2017 19:12:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1499454774; bh=kk25vYjnNYWCuyFod9gxuNIl9ZMfYacUqCV3J87lpaI=; h=Date:From:To:Subject:References:In-Reply-To:From; b=G6wv3SO/B2DyJE2l+asGacGQKYlCY9J0szn5ZquHY9ogvGFyomDckyDUacsAh7oe+ v6ecQ/Z4snHUym6hUNE1dTVMBED7rmskckigS33Hf1+ybNCblwueXFuO2I1qheBLRQ iJo5TXNPLTsZG/AeKFUsfAeHoBiaVkL4t8NpMbUw= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zaeGeHJ46sR for ; Fri, 7 Jul 2017 19:12:53 +0000 (UTC) Date: Fri, 7 Jul 2017 15:12:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1499454773; bh=kk25vYjnNYWCuyFod9gxuNIl9ZMfYacUqCV3J87lpaI=; h=Date:From:To:Subject:References:In-Reply-To:From; b=Hp2I7dOT+t0YZ37NuuCTCsVJZjJJIP42o7XR2ZgR0EjYCuNdtuTknbn7mZKQ2bCLM +Pel7l4rGocHPYgWNeJXqJophqePb9TgSa3YIftnZU7cHfYG6GJQ9IUiZnkRUHv599 xa10VoW4IGjbvPK1LPVlUUpwAQzY/BlYlsUXObYI= From: Andrew Sullivan To: dmarc@ietf.org Message-ID: <20170707191251.dmnnyxgvlqf5niwf@mx4.yitter.info> References: <20337b3e-be49-797c-2974-1e36bd9939e0@gmail.com> <20170707182932.gm3vhxluv3kcc35d@mx4.yitter.info> <09fd1486-c712-bd50-545c-9b694b3c79dc@crash.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <09fd1486-c712-bd50-545c-9b694b3c79dc@crash.com> Archived-At: Subject: Re: [dmarc-ietf] ARC RFC status to target X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 19:12:57 -0000 On Fri, Jul 07, 2017 at 11:57:36AM -0700, Steven M Jones wrote: > Would there be a proposed schedule for that evaluation to take place? I > don't so much disagree with the description of how Experimental status > /should/ work, and including evaluation criteria would make sense. But > I'm not thrilled with the idea of ARC being left on the Experimental > track for umpteen years... It's a good question, but I have two responses: 1. IETF timelines are worth approximately what one pays for them :) 2. The lack of criteria by which to evaluate the experiment was itself one of the reasons offered for not undertaking a move from experimental sooner. So not having the criteria will do nothing to prevent the dragging on. (Of course, not classifying as experimental _will_ prevent that dragging on, but comes with the downsides that Dave was suggesting.) A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Fri Jul 7 12:50:45 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A96B2131560 for ; Fri, 7 Jul 2017 12:50:44 -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 qfgopA1GN-4q for ; Fri, 7 Jul 2017 12:50: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 6B4D5131552 for ; Fri, 7 Jul 2017 12:50:42 -0700 (PDT) Received: from [10.10.10.41] (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 v67JoY0x086961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Fri, 7 Jul 2017 12:50:39 -0700 (PDT) (envelope-from smj@crash.com) X-DKIM: OpenDKIM Filter v2.4.3 segv.crash.com v67JoY0x086961 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=201506-2k; t=1499457040; bh=QstL4r42JRzW81bsxhMCrjBee1vklSrH6H+mlCXz+Z0=; h=Subject:To:References:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=IM4OPuN5a9C+/zEOA3doQNaImfxWun6NxAVsYflsexjVCPj3xuh/QUAkGLwzxTLEQ 4Q92KpGCVujzfifOi/Uioz7ucHXrt7F/Pjf9M0ErHCGKGOCndVe0p8Mln+HCJWixx2 CHcPddoc178u7/lPVG9DIUOrFnoF84bEfkU+MS9lPZdJHOd/Qidy3nkSd2ZT48huMf /gym1OobOnFp6EY0Du/y9TRhuDZ/XFd1xBckUDMsrxxZCYEH6VGaSGRfffBOT9f017 kn26XKLb9wAU0sRT30O/ScRoak2YAu4i2FPEpouSp54kd0qr58wgHkCuR1LLAKFqfX 97d8evmXVfnvw== X-Authentication-Warning: segv.crash.com: Host 70-36-157-26.dsl.static.fusionbroadband.com [70.36.157.26] claimed to be [10.10.10.41] To: dmarc@ietf.org References: <20337b3e-be49-797c-2974-1e36bd9939e0@gmail.com> <20170707182932.gm3vhxluv3kcc35d@mx4.yitter.info> <09fd1486-c712-bd50-545c-9b694b3c79dc@crash.com> <20170707191251.dmnnyxgvlqf5niwf@mx4.yitter.info> From: Steven M Jones Organization: Crash Computing Message-ID: <84047ca1-456c-1234-f416-ff08be69e076@crash.com> Date: Fri, 7 Jul 2017 12:50:36 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20170707191251.dmnnyxgvlqf5niwf@mx4.yitter.info> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (segv.crash.com [72.52.75.15]); Fri, 07 Jul 2017 12:50:40 -0700 (PDT) Archived-At: Subject: Re: [dmarc-ietf] ARC RFC status to target X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 19:50:45 -0000 On 07/07/2017 12:12, Andrew Sullivan wrote: > On Fri, Jul 07, 2017 at 11:57:36AM -0700, Steven M Jones wrote: >> Would there be a proposed schedule for that evaluation to take place? > It's a good question, but I have two responses: > > 1. IETF timelines are worth approximately what one pays for them :) :D > 2. The lack of criteria by which to evaluate the experiment was > itself one of the reasons offered for not undertaking a move from > experimental sooner. So not having the criteria will do nothing to > prevent the dragging on. (Of course, not classifying as experimental > _will_ prevent that dragging on, but comes with the downsides that > Dave was suggesting.) I may be misreading your response, but I wasn't suggesting a timeline without criteria. I would hope to see criteria and a provisional timeline for when to apply them. "A, B, and C will be tracked and evaluated at IETF 101, next move to be decided then" or something vaguely similar. Perhaps the criteria would be included in the RFC, and the review would be added to the WG's work items? I'm not sure how it's usually done... Do Experimental RFCs ever get expiration dates as a forcing function, the way Internet Drafts do? --S. From nobody Fri Jul 7 13:05:10 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2995B126C3D for ; Fri, 7 Jul 2017 13:05:09 -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 gD735Gf52z0I for ; Fri, 7 Jul 2017 13:05:08 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 083DE12EC1B for ; Fri, 7 Jul 2017 13:05:08 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 33A5FC401EB for ; Fri, 7 Jul 2017 15:05:07 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1499457907; bh=24sLWmfma1gBrLtIbNDHt/ve+uvulVTzkSqBP4Qux9o=; h=From:To:Subject:Date:In-Reply-To:References:From; b=0VatwyQ7AaOuay4SSAdyNzh7LNhPX5NLKCqjvdRo3Qn5D92L6WJDoYElfKtTgJXJM osJI6rujCZ4lJbK/B1a8oLFw1XJXVkfni7N9QaZrMsETfRFOWYm+Z7dOl5ZLmc8IbU OVPZelllr3IRM3X7e4Fdfzggoj6DhSBor/BwyplE= From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 07 Jul 2017 16:05:06 -0400 Message-ID: <5885441.2dKtIzTdyY@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-121-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <20170707191251.dmnnyxgvlqf5niwf@mx4.yitter.info> References: <20337b3e-be49-797c-2974-1e36bd9939e0@gmail.com> <09fd1486-c712-bd50-545c-9b694b3c79dc@crash.com> <20170707191251.dmnnyxgvlqf5niwf@mx4.yitter.info> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] ARC RFC status to target X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 20:05:09 -0000 On Friday, July 07, 2017 03:12:51 PM Andrew Sullivan wrote: > On Fri, Jul 07, 2017 at 11:57:36AM -0700, Steven M Jones wrote: > > Would there be a proposed schedule for that evaluation to take place? I > > don't so much disagree with the description of how Experimental status > > /should/ work, and including evaluation criteria would make sense. But > > I'm not thrilled with the idea of ARC being left on the Experimental > > track for umpteen years... > > It's a good question, but I have two responses: > > 1. IETF timelines are worth approximately what one pays for them :) > > 2. The lack of criteria by which to evaluate the experiment was > itself one of the reasons offered for not undertaking a move from > experimental sooner. So not having the criteria will do nothing to > prevent the dragging on. (Of course, not classifying as experimental > _will_ prevent that dragging on, but comes with the downsides that > Dave was suggesting.) RFC 4408 said review after two years and we didn't get around to it for six. It isn't going to get re-reviewed until there is a critical mass of interest in doing so. I don't think the timeline is helpful. Scott K From nobody Fri Jul 7 13:34:24 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C784131442 for ; Fri, 7 Jul 2017 13:34:23 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vdVD_EXP8HnR for ; Fri, 7 Jul 2017 13:34:20 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E6A912EC25 for ; Fri, 7 Jul 2017 13:34:20 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id w19so27046181uac.0 for ; Fri, 07 Jul 2017 13:34:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=/goI1UXc6hqJmq36b5UZ0H38fwhHe64pVmmXHy4pD7M=; b=gfRL8eTS23LgVE3oXchF8hUeqbE7VXTt2UacvrZ6xCbeAomfSwJy2qWX3SK1KJKAMr bk6xrpwKXpJMoyYi6t3B6K9xZiOp7BsHHOPZp3M9gYgccEpHw+Yew4HkaairvePhwP20 Hr046S3uuw6gklrKNmO+gmpBiWkvjgrSuSuKLbS0SdJgv+KLrnWHd5rD+2MqA3sMzvTr BsFScXuobm8QMEDT2m1eD6fdh1f4xcOgqVuqcUA9zHA/gUqTMlYlXRhbwZZKPHJPGtHE L0KO5s+zVgQYfPiQorN3tsQaTnvaTp0rUM5uiSUVHNQ3LX04PXO3DCchoJ0KtsZagjxy FfWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=/goI1UXc6hqJmq36b5UZ0H38fwhHe64pVmmXHy4pD7M=; b=fdcrg5jJ2qnXT9nFAH9bgOizB0ef62OqeOQzyGq4GuBr7t3UuGOx1PXeZICkAowf0H BppSSPjnxn8J4DzgRBSVl34mg2gOCTCar1zdS1pwljr5lATrSx0TM2I+6n+H3cpYd2si 3RWF9mTUkIn2K95l6VvcMraBdCwNM6fbyeKCWh3if4hILQL9HsgrZg69BjqX0LHRyqRw Q7rs4P6eVYZQJzEgkkEMd5c13F6iHNeceQjcIS5k6Jt5JfW4n+XJNnWD/lAyrVsJcie1 Bl/f0YEp7uywvlVT2qeVL9aW51OUqB8o65o7yBf31OHcpLUk+fiCgg/DF6pZl0NW9eWy /MfA== X-Gm-Message-State: AIVw112DIwjlpmInBaSAQqGhvutKz577Mi6vQcq7REMM2ApA5xB+bcF+ 9RWWrNGK/92fo7fUd4xXNvc6fHIMYnyXqQI= X-Received: by 10.176.91.19 with SMTP id u19mr1543471uae.152.1499459658827; Fri, 07 Jul 2017 13:34:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.152.80 with HTTP; Fri, 7 Jul 2017 13:33:58 -0700 (PDT) In-Reply-To: <2841386.K0mPqPZNK9@kitterma-e6430> References: <2841386.K0mPqPZNK9@kitterma-e6430> From: Seth Blank Date: Fri, 7 Jul 2017 13:33:58 -0700 Message-ID: To: dmarc@ietf.org Content-Type: multipart/alternative; boundary="f403045f8b7451e7ae0553c028e5" Archived-At: Subject: Re: [dmarc-ietf] using selectors to identify sources X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 20:34:23 -0000 --f403045f8b7451e7ae0553c028e5 Content-Type: text/plain; charset="UTF-8" On Fri, Jul 7, 2017 at 7:11 AM, Scott Kitterman wrote: > I think it depends on what is meant by 'source'. > > Imagine a scenario where I'm the mail admin for a shop that has 5 outbound > servers. As a matter of security policy, private keys are generated on the > machine that will use them and never transit the network. For DKIM then, I > have 5 selectors. No problem. > > Time passes. I remember to do key rotation, but my colleagues that manage > our > DNS close the ticket that to add the records for the new keys after only > publishing 4 of the 5 new records. > > Since the DNS people closed my ticket as finished, I put my new keys in > production and start using the new selectors. > > Being a conscientious mail admin, I check my DMARC feedback reporting > regularly. To my dismay, I discover that over the next day or two my DKIM > pass rate for direct mail goes from 99% to less than 80%. > > If I have the selector, I can identify that all the unexpected failures > come > from a single system. I can take it out of production while I trouble > shoot > and focus my efforts on what went wrong on with the key rollover for that > one > system. Without the selector, I don't know if it's a single 'source' or > multiple 'sources'. > > In this context, having the selector in DMARC feedback reporting to help > define a 'source' is really useful. > > Using the selectors to segregate different 'sources' for reputation > purposes > is not (in this case). > > Receivers know the selector. If they feed domain and selector into their > Bayesian processors and get a useful distinction, they are going to use it. > No RFC will change that. If there's some statistically significant > difference > in 'sources' identified that way, then that's their call. > Agreed 100% > > I think selectors in DMARC reporting would be really useful. For ARC > though, > I'm not at all convinced. I can't think why, as a sender, I would care. > So this use case is exactly correct, and I think it very clearly demonstrates the value of the selector when it comes to reporting back on ARC in a DMARC report. Take the following case, extending Scott's example: When we have a direct sender -> receiver relationship, in aggregate, the receiver will see 5 DKIM-Signatures, four of which pass and one of which fails. This information can be reported back to the sender to fix the broken key. Now, with a sender -> intermediary -> receiver relationship (and assuming the intermediary modifies the message and breaks the signature, so ARC is needed for delivery), in aggregate, all 5 sender DKIM-Signatures will be broken. Without a selector, it is impossible to disambiguate which keys are problematic and need fixing since they all share the same header.d/header.i. And to be very specific about this above case, in the aggregate for AAR for i=1 you'd see "dkim=pass header.i=example.com" four times and "dkim=fail header.i=example.com" once, but all signatures will fail to validate at the receiver. Adding the selector makes it possible to disambiguate these statuses so that the sender, to whom these selectors are meaningful, can fix broken configurations. Does this make sense or is the example and value of selectors still unclear? Seth > Scott K > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --f403045f8b7451e7ae0553c028e5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Jul 7, 2017 at 7:11 AM, Scott Kitterman <sklist@kitterman.com= > wrote:
=
I think it depends on= what is meant by 'source'.

Imagine a scenario where I'm the mail admin for a shop that has 5 outbo= und
servers.=C2=A0 As a matter of security policy, private keys are generated o= n the
machine that will use them and never transit the network.=C2=A0 For DKIM th= en, I
have 5 selectors.=C2=A0 No problem.

Time passes.=C2=A0 I remember to do key rotation, but my colleagues that ma= nage our
DNS close the ticket that to add the records for the new keys after only publishing 4 of the 5 new records.

Since the DNS people closed my ticket as finished, I put my new keys in
production and start using the new selectors.

Being a conscientious mail admin, I check my DMARC feedback reporting
regularly.=C2=A0 To my dismay, I discover that over the next day or two my = DKIM
pass rate for direct mail goes from 99% to less than 80%.

If I have the selector, I can identify that all the unexpected failures com= e
from a single system.=C2=A0 I can take it out of production while I trouble= shoot
and focus my efforts on what went wrong on with the key rollover for that o= ne
system.=C2=A0 Without the selector, I don't know if it's a single &= #39;source' or
multiple 'sources'.

In this context, having the selector in DMARC feedback reporting to help define a 'source' is really useful.

Using the selectors to segregate different 'sources' for reputation= purposes
is not (in this case).

Receivers know the selector.=C2=A0 If they feed domain and selector into th= eir
Bayesian processors and get a useful distinction, they are going to use it.=
No RFC will change that.=C2=A0 If there's some statistically significan= t difference
in 'sources' identified that way, then that's their call.

Agreed 100%
=C2=A0

I think selectors in DMARC reporting would be really useful.=C2=A0 For ARC = though,
I'm not at all convinced.=C2=A0 I can't think why, as a sender, I w= ould care.

So this use case is exactly = correct, and I think it very clearly demonstrates the value of the selector= when it comes to reporting back on ARC in a DMARC report.

Take the following case, extending Scott's example:
=
When we have a direct sender -> receiver relationship, in= aggregate, the receiver will see 5 DKIM-Signatures, four of which pass and= one of which fails. This information can be reported back to the sender to= fix the broken key.

Now, with a sender -> inte= rmediary -> receiver relationship (and assuming the intermediary modifie= s the message and breaks the signature, so ARC is needed for delivery), in = aggregate, all 5 sender DKIM-Signatures will be broken. Without a selector,= it is impossible to disambiguate which keys are problematic and need fixin= g since they all share the same header.d/header.i.

And to be very specific about this above case, in the aggregate for AAR fo= r i=3D1 you'd see "dkim=3Dpass header.i=3Dexample.com" four times and "dkim=3Dfail header.i=3Dexample.com" once, but all signatures= will fail to validate at the receiver. Adding the selector makes it possib= le to disambiguate these statuses so that the sender, to whom these selecto= rs are meaningful, can fix broken configurations.

= Does this make sense or is the example and value of selectors still unclear= ?

Seth
=C2=A0
Scott K

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

--f403045f8b7451e7ae0553c028e5-- From nobody Fri Jul 7 13:38:02 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3159131694 for ; Fri, 7 Jul 2017 13:38:00 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jc13zW8oMtJU for ; Fri, 7 Jul 2017 13:37:59 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3540812EC25 for ; Fri, 7 Jul 2017 13:37:59 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id p188so36983744oia.0 for ; Fri, 07 Jul 2017 13:37:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=QLGwfaKlULEUjxvpkB7n6NbDCwj6K8gfYriNUdasQHQ=; b=dZAtBBfZhj37RyWR5KRXnQLOhzMxPsIwWcfNY1dWdQPIdgcqeAuP/ga2Bel1EJ9xc8 mtWC+cSDWtOhh1dskZb/obakedroKdImzNxUQKr9ZjCHDD4YYWOwRo5L1uJ4hByKFHDV Mfl4gqMdu8ezzPW1z9xRjYCX74A4ff3pa4O9wQLJMfATAegBKPZackhZmqXoG2PC98JJ N0x9cm1nahye4D5RIloLM78NRuN7rl/2GXgBKF5230ca8Yt+6FDZjY7kYcqluVplyEaU Fkv+cJ+zr/FZr1k51hc0YiBiUxYYVv0vKkkyQYVoD48VwJIqmTNeH6vHWTcE7uBVgW6e HKaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=QLGwfaKlULEUjxvpkB7n6NbDCwj6K8gfYriNUdasQHQ=; b=hel/RV5ufwXCcskFwqpK0iE/tBlnCso/0uJS1RFqZZTOAs72fDPP7+9OuEE3q4vHlE DchEaW6Fr7LZNuaZ8/AZO3g5JjpobLOXB9F1t+YoTJ9/0nI5/B5c7OhRFrHoV2DZeAx0 pFqTYcOtDuxIwVFrAQf77Ub8OGk/9JGXm6Xd9ehoWRUv8Nzr4X2EAvHzZNAKyEAJ6JVZ HYFlLCnjgiwavdt/aeHb7kC4zOfJyMl/20iebeANqhY6M6rF0sK1omEP4EpfWq0w0Smp LWcSB/DXJhYMdJQcg+V9JWfwYUVKMET8uH7bwikruIMEOQb0roIwJPVCBhL4c0pKgpy0 DpNQ== X-Gm-Message-State: AIVw112pmkJ+W7G9tyvcfcHv2j5uc69439j1MP6ILur4T9sizvnmhlNo c1cyPc8qVglh26gg4Qo= X-Received: by 10.202.83.77 with SMTP id h74mr1661468oib.194.1499459878417; Fri, 07 Jul 2017 13:37:58 -0700 (PDT) Received: from ?IPv6:2602:304:cda0:8800:217d:6fe0:696a:e274? ([2602:304:cda0:8800:217d:6fe0:696a:e274]) by smtp.gmail.com with ESMTPSA id 187sm5943463oie.15.2017.07.07.13.37.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Jul 2017 13:37:57 -0700 (PDT) To: Seth Blank , dmarc@ietf.org References: <2841386.K0mPqPZNK9@kitterma-e6430> From: Dave Crocker Message-ID: Date: Fri, 7 Jul 2017 13:37:54 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] using selectors to identify sources X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 20:38:01 -0000 On 7/7/2017 1:33 PM, Seth Blank wrote: > Receivers know the selector. If they feed domain and selector into > their > Bayesian processors and get a useful distinction, they are going to > use it. > No RFC will change that. If there's some statistically significant > difference > in 'sources' identified that way, then that's their call. > > > Agreed 100% This was a hot topic when DKIM first came out. It represents a failure to use or understand the role of selectors properly. The reputation /should/ rely only on the domain name /without/ the selector, so the selector can be used only for administrative purposes, such as rolling over to a new key. Note, for example, that including the selector in the reputation analysis means that the history of the actor is lost when a new selector is used. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Jul 7 13:44:50 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB92C126D05 for ; Fri, 7 Jul 2017 13:44:43 -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 E2SjAUOqrtqH for ; Fri, 7 Jul 2017 13:44:41 -0700 (PDT) Received: from mail.wordtothewise.com (mail.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id E9E0612EC25 for ; Fri, 7 Jul 2017 13:44:41 -0700 (PDT) Received: from [IPv6:2001:470:1f05:33:f42e:cef8:e4c4:1b9c] (unknown [IPv6:2001:470:1f05:33:f42e:cef8:e4c4:1b9c]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 8F4FE23379 for ; Fri, 7 Jul 2017 13:45:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1499460301; bh=KV8Y+U3aNhO9DEZpOyZ2xu3WIMPXBWQqL5YRVes2cd0=; h=From:Subject:Date:References:To:In-Reply-To:From; b=nfmxE0dlFWbt1myfW1MRPrgktDdNMmAluNheaMKfJ1e3kEUZS718S+8FdW2uvxysH RpKC4K+GzqDd1J+QqjfSWkN6BUmVoCHlk1FuBIrl76X2iRLjlc+l+J4qHj8oqmfCs2 terEWuJNnaZa5/e0gzNR9FA0L6TJV/Dvc4XJ4aMk= From: Steve Atkins Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 7 Jul 2017 13:44:41 -0700 References: <2841386.K0mPqPZNK9@kitterma-e6430> To: dmarc@ietf.org In-Reply-To: Message-Id: <563EC8DA-7EED-4E42-A926-8C5F3E6A1505@wordtothewise.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [dmarc-ietf] using selectors to identify sources X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 20:44:44 -0000 > On Jul 7, 2017, at 1:37 PM, Dave Crocker wrote: >=20 > On 7/7/2017 1:33 PM, Seth Blank wrote: >> Receivers know the selector. If they feed domain and selector = into >> their >> Bayesian processors and get a useful distinction, they are going = to >> use it. >> No RFC will change that. If there's some statistically = significant >> difference >> in 'sources' identified that way, then that's their call. >> Agreed 100% >=20 > This was a hot topic when DKIM first came out. It represents a = failure to use or understand the role of selectors properly. The = reputation /should/ rely only on the domain name /without/ the selector, = so the selector can be used only for administrative purposes, such as = rolling over to a new key. >=20 > Note, for example, that including the selector in the reputation = analysis means that the history of the actor is lost when a new selector = is used. That a particular major ISP uses (or claims to use, or used to claim to = use) selectors to identify particular senders is (or was, or was and = continues to be) a major reason that some ESPs refuse to rotate keys at = all.=20 Cheers, Steve From nobody Fri Jul 7 14:35:31 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46CBD131665 for ; Fri, 7 Jul 2017 14:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 xWygrbTfOxyY for ; Fri, 7 Jul 2017 14:35:28 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24A1912EB8E for ; Fri, 7 Jul 2017 14:35:28 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id E45AFC403E4 for ; Fri, 7 Jul 2017 16:35:25 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1499463325; bh=0fYd50aFDxTc0xTGriuburi9SfwHmkZYGXkZdHskVqY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=qO2PgGwVTd2QdWaOudok0wGHkbHEr0RCoad9kxKGDKb5fA13DaN5iWyn4DMMUgpLP TeyXE17SUWtZFXJAri/UmHrr1DVm/mvHQ17tSdbWe6l4qb4eLEThY8l+M4B3uKYlP+ cZsDxYdAlq+hfKV5JkOn0x+reQXpG5gnIei7fQ50= From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 07 Jul 2017 17:35:25 -0400 Message-ID: <1850132.zVlZ2uGbS6@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-121-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <2841386.K0mPqPZNK9@kitterma-e6430> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] using selectors to identify sources X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 21:35:30 -0000 On Friday, July 07, 2017 01:33:58 PM Seth Blank wrote: > On Fri, Jul 7, 2017 at 7:11 AM, Scott Kitterman > > wrote: > > I think it depends on what is meant by 'source'. > > > > Imagine a scenario where I'm the mail admin for a shop that has 5 outbound > > servers. As a matter of security policy, private keys are generated on > > the > > machine that will use them and never transit the network. For DKIM then, > > I > > have 5 selectors. No problem. > > > > Time passes. I remember to do key rotation, but my colleagues that manage > > our > > DNS close the ticket that to add the records for the new keys after only > > publishing 4 of the 5 new records. > > > > Since the DNS people closed my ticket as finished, I put my new keys in > > production and start using the new selectors. > > > > Being a conscientious mail admin, I check my DMARC feedback reporting > > regularly. To my dismay, I discover that over the next day or two my DKIM > > pass rate for direct mail goes from 99% to less than 80%. > > > > If I have the selector, I can identify that all the unexpected failures > > come > > from a single system. I can take it out of production while I trouble > > shoot > > and focus my efforts on what went wrong on with the key rollover for that > > one > > system. Without the selector, I don't know if it's a single 'source' or > > multiple 'sources'. > > > > In this context, having the selector in DMARC feedback reporting to help > > define a 'source' is really useful. > > > > Using the selectors to segregate different 'sources' for reputation > > purposes > > is not (in this case). > > > > Receivers know the selector. If they feed domain and selector into their > > Bayesian processors and get a useful distinction, they are going to use > > it. > > No RFC will change that. If there's some statistically significant > > difference > > in 'sources' identified that way, then that's their call. > > Agreed 100% > > > I think selectors in DMARC reporting would be really useful. For ARC > > though, > > I'm not at all convinced. I can't think why, as a sender, I would care. > > So this use case is exactly correct, and I think it very clearly > demonstrates the value of the selector when it comes to reporting back on > ARC in a DMARC report. > > Take the following case, extending Scott's example: > > When we have a direct sender -> receiver relationship, in aggregate, the > receiver will see 5 DKIM-Signatures, four of which pass and one of which > fails. This information can be reported back to the sender to fix the > broken key. > > Now, with a sender -> intermediary -> receiver relationship (and assuming > the intermediary modifies the message and breaks the signature, so ARC is > needed for delivery), in aggregate, all 5 sender DKIM-Signatures will be > broken. Without a selector, it is impossible to disambiguate which keys are > problematic and need fixing since they all share the same header.d/header.i. > > And to be very specific about this above case, in the aggregate for AAR for > i=1 you'd see "dkim=pass header.i=example.com" four times and "dkim=fail > header.i=example.com" once, but all signatures will fail to validate at the > receiver. Adding the selector makes it possible to disambiguate these > statuses so that the sender, to whom these selectors are meaningful, can > fix broken configurations. > > Does this make sense or is the example and value of selectors still unclear? If my mail flow was 100% indirect it would, but that's atypical. If direct mails were at 98% and indirect was at 80% it wouldn't matter what ARC says, I'd consider it somebody else's problem. Even if I had no direct mail and the indirect was 80%, I don't think I'd view what somebody told me about what somebody told them about mail I sent as a reliable basis for action. I'd leave it out of ARC for now and focus on getting it into the DMARC aggregate reports. Once it's there and there's some operator experience with the data, then we'll be in a better position to assess if there is utility for ARC. At the moment, we're purely arguing theory. Scott K From nobody Fri Jul 7 15:34:43 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE82B131724 for ; Fri, 7 Jul 2017 15:34: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S64EA15PImFI for ; Fri, 7 Jul 2017 15:34:39 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::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 36A4B1205F0 for ; Fri, 7 Jul 2017 15:34:39 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id v193so18529676ywg.2 for ; Fri, 07 Jul 2017 15:34:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uPzB/Udkn/3HwlHUmQH3R+OdTx7jTDR0ByFUdbM5/Q8=; b=R30/GhdSr+W6WvtL7eVWqS1DZxQeIR27lvps7+YuJcFBMiyBqjP4GHnyORarhiE6Ct wea4GU1G+PriJ31RNf55f7aOw1rsgv2aS6k5Bvj0CtFvEQ5IUNdN9Gv5Rx+ttLCK5CK5 pj+b+9dzNsqhFTvgwRALO89Ddd+5PSE5b1wAAL0rkKoVrQ/SUgjUEP13guh/qOMMnUvV xsYrCuLWpBXo+1oN5E6X2OvWVfIGJXvwg3QmCLVBo1jCCrykxdgfNjBtpKliGpBzWK+u /E6OThviFxR+0A84DRRthD3lCeFHIw1nB1Pq5LsLheKMsO+Ne8IWtCBM6MxVq/Tc+SqI IjGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uPzB/Udkn/3HwlHUmQH3R+OdTx7jTDR0ByFUdbM5/Q8=; b=i0K14ozyKISbjENu1Z2V0xpJE7FgujqE4FFWVCVDQPUCvhr/UcWdzlriM/N4pQs0OX YfLiiBGv9uVIuJt6LXcXzwC9/m86VJACuToP8+yIEiKv21y4VxdRJ6Jzj8Jins45igQ2 Pg8r6+NYxXWqbeeof6LuJO2xgOUMvLh7h9Ku9jC6qU4oYO6BsLUCk9sXggXDQdUbxLTT YnZeY6uNm4JAFCZTDlvhN4MBrDEid38s2y9YlmbrfnhxY6kuWRqQMVxXJp/zBK7AOIyP j1E2JaZ9wdcXo8lyr/iSpXZZ8kw4hOI53nbd36PAawQjCKpwWU4f7O9tCXBWJuCRgCOm fZ8w== X-Gm-Message-State: AIVw1125Mvew7s7779w7enDCDpsBMeQLBpfOdvTVJe0zCBM+8D5h6CI/ i2vegmOjALAt3H9Vfg+zEu+4oI8JabQY X-Received: by 10.129.44.85 with SMTP id s82mr3742152yws.16.1499466878509; Fri, 07 Jul 2017 15:34:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.61.3 with HTTP; Fri, 7 Jul 2017 15:34:38 -0700 (PDT) In-Reply-To: References: From: Gene Shuman Date: Fri, 7 Jul 2017 15:34:38 -0700 Message-ID: To: Kurt Andersen Cc: Brandon Long , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a11423ce6a59a120553c1d66e" Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-05.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 22:34:42 -0000 --001a11423ce6a59a120553c1d66e Content-Type: text/plain; charset="UTF-8" I think there's still something missing from the draft wrt fail/invalid. In section 5.2.2, it says that gross violations MUST be capped in the manner specified. This seems to only encompass what we were previously considering cv=invalid. Does it say somewhere that cv=fail should be handled in this fashion as well? Or does what was previously cv=fail still sign all arc sets? Are we handling these differently? I'm not necessarily sure we should. Also, the language here is MUST. Shouldn't this be optional, as we'd discussed? On Fri, Jun 30, 2017 at 4:48 PM, Kurt Andersen wrote: > > On Jun 30, 2017 2:37 PM, Brandon Long wrote: > > Looking through the changes, I see that in 5.2.2 we previously and still > say that the AAR field should be unknown. Unknown is a valid value for > result names for dkim-adsp and rrvs, but I'm curious why we would use that > and not just fail? fail seems to match better, especially now that we > don't differentiate between invalid and fail in the cv value. > > > Fair point. I'll look at rephrasing that. > > We also discussed signing/verifying a cv=fail differently, which isn't in > the draft yet (I don't think, I was looking at the diff not the whole > document). > > We discussed that the signing/verifying of a cv=fail would only do so > based on the single (presumably last) hop that contained the cv=fail. > > So, the AMS would be added/verified like normal, but the AS would only > sign the as/ams/aar of that hop. > > > That is already the specified handling in the case of fail. > > --Kurt > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --001a11423ce6a59a120553c1d66e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think there's still something missing from the draft= wrt fail/invalid.=C2=A0 In section 5.2.2, it says that gross violations MU= ST be capped in the manner specified. This seems to only encompass what we = were previously considering cv=3Dinvalid.=C2=A0 Does it say somewhere that = cv=3Dfail should be handled in this fashion as well?=C2=A0 Or does what was= previously cv=3Dfail still sign all arc sets?=C2=A0 Are we handling these = differently?=C2=A0 I'm not necessarily sure we should.=C2=A0 Also, the = language here is MUST.=C2=A0 Shouldn't this be optional, as we'd di= scussed?

On = Fri, Jun 30, 2017 at 4:48 PM, Kurt Andersen <kandersen@linkedin.com= > wrote:

On Jun 30, 2017 2:37 PM, Brandon Long <blong@google.com> wr= ote:
Looking through the changes, I see that in 5.2.2 we previo= usly and still say that the AAR field should be unknown.=C2=A0 Unknown is a= valid value for result names for dkim-adsp and rrvs, but I'm curious w= hy we would use that and not just fail? =C2=A0fail seems to match better, especially now that we don't differentiate betw= een invalid and fail in the cv value.

Fair point. I'll look at rephrasing that.

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

We discussed that the signing/verifying of a cv=3Dfail would only do so bas= ed on the single (presumably last) hop that contained the cv=3Dfail.

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

That is already the specified handling in the case= of fail.

--Kurt


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


--001a11423ce6a59a120553c1d66e-- From nobody Fri Jul 7 15:43:06 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60E9C1316F0 for ; Fri, 7 Jul 2017 15:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFKcHz9lrcbQ for ; Fri, 7 Jul 2017 15:43:03 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BD2F12EC27 for ; Fri, 7 Jul 2017 15:43:03 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id r125so25075276vkf.1 for ; Fri, 07 Jul 2017 15:43:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=mwVswtvtfUv9Nk7LXqiZReIA2XQ5DzFXmLVUWfiFf5o=; b=Q8gESghc6NHu38I4IDUg3reeagRN3wtGr3btShlEJc2R3PIA7AQ0qdg64vx6iz4iD6 2qflRy4FL+wrPyo3NvwbeKPWAhv1jMG38W5OX0y//D3Lyh+RCPlsD+nDhiflYH9WJbyh IvZxc4ZgsxNPe4Fir11vezpJC/bUqLgXhJ4j/Ovv5TFtBGfU4u5P48WeKS5SsmJ2N2CS AcZ6UQYXUx9fJcSqszXrLNlxZx7UUq2+z6UnUMjCGDvvRnQ1NAlo7BINKXrqlGzQt/tb XkRS0xUYQh0bQhq4SfMfZNIEmXC3pt26nkeunQg8/OhPJifuqBadItKP4mE2VssYGQkW F2/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=mwVswtvtfUv9Nk7LXqiZReIA2XQ5DzFXmLVUWfiFf5o=; b=ANRkhlbKZpTamy3Kvfnm1kLsuuyVa/WKXIBCdjUSUsS8iQ66H8Fyc+q5LvDGTTkx80 mZRq82YyKEM5aPPK3Kgw/tym52K/LmV9w73MAloK8ulPhBiOxDfVxT5wQV/8MRHBeqwk GvYxSoHKEWpmJ7Iw6Qblu6RFv3sNfsM5HWCpWIGKpjDuBR+0jln0fOzITj4CsPPQVPhO q7lc1x2mY81aycw1bFpvpzjhqkpesPJTZEqqkpsGxvBEncspYCaLVv8trH1VNN5FbZNs 2VKCuzAp0PARQInYIL5BJYc9K5FwZpJjEox73K29JyKTZe3j0KTZGcwJz+alx7Bt1S7L gLpw== X-Gm-Message-State: AIVw110voOOe1clro+XNHQ+bn44u8bfhAQoXis+djpjmjNnrsXYDobEs zuQ9KI0gKQffJnonBSTWp2ECbc6Kfb9nEVjUGA== X-Received: by 10.31.149.215 with SMTP id x206mr2070793vkd.83.1499467381869; Fri, 07 Jul 2017 15:43:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.152.80 with HTTP; Fri, 7 Jul 2017 15:42:41 -0700 (PDT) In-Reply-To: <1850132.zVlZ2uGbS6@kitterma-e6430> References: <2841386.K0mPqPZNK9@kitterma-e6430> <1850132.zVlZ2uGbS6@kitterma-e6430> From: Seth Blank Date: Fri, 7 Jul 2017 15:42:41 -0700 Message-ID: To: dmarc@ietf.org Content-Type: multipart/alternative; boundary="001a11426780a62dcd0553c1f4d6" Archived-At: Subject: Re: [dmarc-ietf] using selectors to identify sources X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 22:43:05 -0000 --001a11426780a62dcd0553c1f4d6 Content-Type: text/plain; charset="UTF-8" The philosophical questions about how DKIM should best be used, best practices for selector usage, or how receivers determine reputation, are besides a very practical concern here that we're trying to address: As a domain owner, the keys I use to sign messages are well known to me. Determining which key was used at the beginning of an ARC flow is impossible without transmitting the selector. On Fri, Jul 7, 2017 at 2:35 PM, Scott Kitterman wrote: > On Friday, July 07, 2017 01:33:58 PM Seth Blank wrote: > > On Fri, Jul 7, 2017 at 7:11 AM, Scott Kitterman > > > > wrote: > > > I think it depends on what is meant by 'source'. > > > > > > Imagine a scenario where I'm the mail admin for a shop that has 5 > outbound > > > servers. As a matter of security policy, private keys are generated on > > > the > > > machine that will use them and never transit the network. For DKIM > then, > > > I > > > have 5 selectors. No problem. > > > > > > Time passes. I remember to do key rotation, but my colleagues that > manage > > > our > > > DNS close the ticket that to add the records for the new keys after > only > > > publishing 4 of the 5 new records. > > > > > > Since the DNS people closed my ticket as finished, I put my new keys in > > > production and start using the new selectors. > > > > > > Being a conscientious mail admin, I check my DMARC feedback reporting > > > regularly. To my dismay, I discover that over the next day or two my > DKIM > > > pass rate for direct mail goes from 99% to less than 80%. > > > > > > If I have the selector, I can identify that all the unexpected failures > > > come > > > from a single system. I can take it out of production while I trouble > > > shoot > > > and focus my efforts on what went wrong on with the key rollover for > that > > > one > > > system. Without the selector, I don't know if it's a single 'source' > or > > > multiple 'sources'. > > > > > > In this context, having the selector in DMARC feedback reporting to > help > > > define a 'source' is really useful. > > > > > > Using the selectors to segregate different 'sources' for reputation > > > purposes > > > is not (in this case). > > > > > > Receivers know the selector. If they feed domain and selector into > their > > > Bayesian processors and get a useful distinction, they are going to use > > > it. > > > No RFC will change that. If there's some statistically significant > > > difference > > > in 'sources' identified that way, then that's their call. > > > > Agreed 100% > > > > > I think selectors in DMARC reporting would be really useful. For ARC > > > though, > > > I'm not at all convinced. I can't think why, as a sender, I would > care. > > > > So this use case is exactly correct, and I think it very clearly > > demonstrates the value of the selector when it comes to reporting back on > > ARC in a DMARC report. > > > > Take the following case, extending Scott's example: > > > > When we have a direct sender -> receiver relationship, in aggregate, the > > receiver will see 5 DKIM-Signatures, four of which pass and one of which > > fails. This information can be reported back to the sender to fix the > > broken key. > > > > Now, with a sender -> intermediary -> receiver relationship (and assuming > > the intermediary modifies the message and breaks the signature, so ARC is > > needed for delivery), in aggregate, all 5 sender DKIM-Signatures will be > > broken. Without a selector, it is impossible to disambiguate which keys > are > > problematic and need fixing since they all share the same > header.d/header.i. > > > > And to be very specific about this above case, in the aggregate for AAR > for > > i=1 you'd see "dkim=pass header.i=example.com" four times and "dkim=fail > > header.i=example.com" once, but all signatures will fail to validate at > the > > receiver. Adding the selector makes it possible to disambiguate these > > statuses so that the sender, to whom these selectors are meaningful, can > > fix broken configurations. > > > > Does this make sense or is the example and value of selectors still > unclear? > > If my mail flow was 100% indirect it would, but that's atypical. If direct > mails were at 98% and indirect was at 80% it wouldn't matter what ARC says, > I'd consider it somebody else's problem. Even if I had no direct mail and > the > indirect was 80%, I don't think I'd view what somebody told me about what > somebody told them about mail I sent as a reliable basis for action. > > I'd leave it out of ARC for now and focus on getting it into the DMARC > aggregate reports. Once it's there and there's some operator experience > with > the data, then we'll be in a better position to assess if there is utility > for > ARC. > > At the moment, we're purely arguing theory. > > Scott K > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --001a11426780a62dcd0553c1f4d6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The philosophical questions about how DKIM should bes= t be used, best practices for selector usage, or how receivers determine re= putation, are besides a very practical concern here that we're trying t= o address:

As a domain owner, the keys I use to si= gn messages are well known to me. Determining which key was used at the beg= inning of an ARC flow is impossible without transmitting the selector.
<= /div>


On Fri, Jul 7, 2017 at 2:35 PM, Scott Kitterman = <sklist@kitter= man.com> wrote:
On Friday, July 07, 2017 01:33:58 PM Seth Bla= nk wrote:
> On Fri, Jul 7, 2017 at 7:11 AM, Scott Kitterman <sklist@kitterman.com>
>
> wrote:
> > I think it depends on what is meant by 'source'.
> >
> > Imagine a scenario where I'm the mail admin for a shop that h= as 5 outbound
> > servers.=C2=A0 As a matter of security policy, private keys are g= enerated on
> > the
> > machine that will use them and never transit the network.=C2=A0 F= or DKIM then,
> > I
> > have 5 selectors.=C2=A0 No problem.
> >
> > Time passes.=C2=A0 I remember to do key rotation, but my colleagu= es that manage
> > our
> > DNS close the ticket that to add the records for the new keys aft= er only
> > publishing 4 of the 5 new records.
> >
> > Since the DNS people closed my ticket as finished, I put my new k= eys in
> > production and start using the new selectors.
> >
> > Being a conscientious mail admin, I check my DMARC feedback repor= ting
> > regularly.=C2=A0 To my dismay, I discover that over the next day = or two my DKIM
> > pass rate for direct mail goes from 99% to less than 80%.
> >
> > If I have the selector, I can identify that all the unexpected fa= ilures
> > come
> > from a single system.=C2=A0 I can take it out of production while= I trouble
> > shoot
> > and focus my efforts on what went wrong on with the key rollover = for that
> > one
> > system.=C2=A0 Without the selector, I don't know if it's = a single 'source' or
> > multiple 'sources'.
> >
> > In this context, having the selector in DMARC feedback reporting = to help
> > define a 'source' is really useful.
> >
> > Using the selectors to segregate different 'sources' for = reputation
> > purposes
> > is not (in this case).
> >
> > Receivers know the selector.=C2=A0 If they feed domain and select= or into their
> > Bayesian processors and get a useful distinction, they are going = to use
> > it.
> > No RFC will change that.=C2=A0 If there's some statistically = significant
> > difference
> > in 'sources' identified that way, then that's their c= all.
>
> Agreed 100%
>
> > I think selectors in DMARC reporting would be really useful.=C2= =A0 For ARC
> > though,
> > I'm not at all convinced.=C2=A0 I can't think why, as a s= ender, I would care.
>
> So this use case is exactly correct, and I think it very clearly
> demonstrates the value of the selector when it comes to reporting back= on
> ARC in a DMARC report.
>
> Take the following case, extending Scott's example:
>
> When we have a direct sender -> receiver relationship, in aggregate= , the
> receiver will see 5 DKIM-Signatures, four of which pass and one of whi= ch
> fails. This information can be reported back to the sender to fix the<= br> > broken key.
>
> Now, with a sender -> intermediary -> receiver relationship (and= assuming
> the intermediary modifies the message and breaks the signature, so ARC= is
> needed for delivery), in aggregate, all 5 sender DKIM-Signatures will = be
> broken. Without a selector, it is impossible to disambiguate which key= s are
> problematic and need fixing since they all share the same header.d/hea= der.i.
>
> And to be very specific about this above case, in the aggregate for AA= R for
> i=3D1 you'd see "dkim=3Dpass header.i=3Dexample.com" four t= imes and "dkim=3Dfail
> header.i=3Dexample.com" once, but all signatures will fail to valida= te at the
> receiver. Adding the selector makes it possible to disambiguate these<= br> > statuses so that the sender, to whom these selectors are meaningful, c= an
> fix broken configurations.
>
> Does this make sense or is the example and value of selectors still un= clear?

If my mail flow was 100% indirect it would, but that's atyp= ical.=C2=A0 If direct
mails were at 98% and indirect was at 80% it wouldn't matter what ARC s= ays,
I'd consider it somebody else's problem.=C2=A0 Even if I had no dir= ect mail and the
indirect was 80%, I don't think I'd view what somebody told me abou= t what
somebody told them about mail I sent as a reliable basis for action.

I'd leave it out of ARC for now and focus on getting it into the DMARC<= br> aggregate reports.=C2=A0 Once it's there and there's some operator = experience with
the data, then we'll be in a better position to assess if there is util= ity for
ARC.

At the moment, we're purely arguing theory.

Scott K

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

--001a11426780a62dcd0553c1f4d6-- From nobody Fri Jul 7 16:43:28 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC2D12EC03 for ; Fri, 7 Jul 2017 16:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nnKO_mcD4_8o for ; Fri, 7 Jul 2017 16:43:25 -0700 (PDT) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9335D129AEB for ; Fri, 7 Jul 2017 16:43:25 -0700 (PDT) Received: by mail-pg0-x22c.google.com with SMTP id t186so23930070pgb.1 for ; Fri, 07 Jul 2017 16:43:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=sP5XQvxD3SnnfGnamgunIIfLrgwvkE9bLCndMvKMaAU=; b=PCPQwsQZIOVcaorXj1NOZdRxype8u/IULz95xp3gsRX7KTijWI50sXtwJvt5Mro1pp wvKGA4f6sXQwkGzNGG0A7AYCBGQtS7eMqahJrNcbfa1KJ/BoJv49zWN6ot8Xbjj+hgg4 HJSytfpjISsYYYOlpFU+XGp+NKmJ4xwzYkuVPJRJRGvUxd+MnyfuLgJJpv3DLKS9jMEm OpKNaSOrAwWGacXEXkDFjC0en86L9LY9VhAD94VWqB20bANlM0YzU9A5gJ/qfKc0bAkY ln2cAdCxbtnbBiWGU8wmRDq0OBqPC3lghhZtzvreVslgDrj4TO14U1Q6GNbD5LK3j9N2 p6Jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=sP5XQvxD3SnnfGnamgunIIfLrgwvkE9bLCndMvKMaAU=; b=eKAO2x7IdFctfG4nlthqBmjmelqW/zwww98arKpD7yUnf44SRrPYfppQIQC4bm9ocJ Df4yWfcjfUGNPJ1utgKY3BUZxo6Yw6ESp+dAZL6ek++GsrPpxFmzvWeh5PsXT7qO23wT tQM5hqtzE8perWOx0AIg049C/X/oPFOVQXghWnYYNH3r8pnaBsYOo1MjjUszAZQRPaPA Xe8ZFMlu+CtbgLOcJXizK0HRlwziZDcvumPxii9Sw5p/HM9OWfQxlwZKp2L4nSfQ4uxp A6XI/quX4jpBTmHZzHvdC1bBlNVM9Kwo1tvrIlMAuV0AS3gfULZ6gF5gdDhcmDfBYaOQ Hagg== X-Gm-Message-State: AIVw110xhhW6vlKBd/N3KTQTcXnWHk5I89V1XplW+pPzFByIiI3x+bz0 Yl8wTC8M8zfUSFdB5LA= X-Received: by 10.84.215.208 with SMTP id g16mr5628402plj.191.1499471004808; Fri, 07 Jul 2017 16:43:24 -0700 (PDT) Received: from ?IPv6:2602:304:cda0:8800:217d:6fe0:696a:e274? ([2602:304:cda0:8800:217d:6fe0:696a:e274]) by smtp.gmail.com with ESMTPSA id d89sm8846560pfl.7.2017.07.07.16.43.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Jul 2017 16:43:24 -0700 (PDT) To: Steve Atkins , dmarc@ietf.org References: <2841386.K0mPqPZNK9@kitterma-e6430> <563EC8DA-7EED-4E42-A926-8C5F3E6A1505@wordtothewise.com> From: Dave Crocker Message-ID: <367fc126-bba5-84f7-3c85-501290099c19@gmail.com> Date: Fri, 7 Jul 2017 16:43:20 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <563EC8DA-7EED-4E42-A926-8C5F3E6A1505@wordtothewise.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] using selectors to identify sources X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 23:43:27 -0000 On 7/7/2017 1:44 PM, Steve Atkins wrote: > That a particular major ISP uses (or claims to use, or used to claim to use) selectors to identify particular senders is (or was, or was and continues to be) a major reason that some ESPs refuse to rotate keys at all. Then it would be helpful to the industry to attempt to get that ISP to change it's behavior. Whether it would help to issue a BCP, which explicitly directs receivers not to factor selector into filtering analysis and provides a detailed explanation of why such factoring is problematic, is something I'll ask and then leave it to others to decide about... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Jul 7 16:45:26 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0438712EC03 for ; Fri, 7 Jul 2017 16:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BBNyKuKbhzkr for ; Fri, 7 Jul 2017 16:45:23 -0700 (PDT) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::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 B9D4F129AEB for ; Fri, 7 Jul 2017 16:45:23 -0700 (PDT) Received: by mail-pg0-x22a.google.com with SMTP id j186so23800022pge.2 for ; Fri, 07 Jul 2017 16:45:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=UD/uky8e09r/ROenZBPgwhtNAr6psn3yJo6hbfneG84=; b=lRs4ZAagBjiuJ+0+4fXSXVJciPMZDHGKOH00Qgt81FGJf7Y+0kJtPgzr7IlU52+i/V +7K0uFCyIpJkjwO1SbdyeJqQYTP+NB2oRlOS+nqjSNhk2XO+GUue6HvIWWPJVwvhDsBf yXUi+9w0LenR9YiVuXOr+HyVnTHKTfwETBUOaKcrI2WdOLvNB4jcg0S1bNn3Za2diCLq iCISIRZ3nBRdXEDhof2yYJZ6a67FESXR6lYO8tXE9TYzGFmzEG2623VGnSxjQRW9i27P 6x/wJulPZrILwr68lySHEzgVBidh0Yj0FTyFpfbZJnSWwZkM9ozCXslhcAtc3PgY1qYR l7hA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=UD/uky8e09r/ROenZBPgwhtNAr6psn3yJo6hbfneG84=; b=jrizFvxikENXxaR2XDoryLC5RGgXQ02zRepHtyoPyQHeGaWDZwZjLibwFK9KjSRoOx 8E4pY/DuvFwoAV/KHtquwiNfn+C8Cf3HslJSaVmBGAvFJIbwkxD/qHfvKIuWI7xvxU/+ KYYrZxQRAqF4G8f+tCkgtx45x36i6sFbgmJ4IbdN3RbunGBonl0RX/Aus1CCosj6sgX7 DKoolEdN0D6xgeHyn6Wmg6hm83h4Tu890SS0uRz+WsfbVb0IVpx5x0yMvd1MSZ8w/Thy 7+V/d8Nozab6hr7H9hg5Xmfj+u3bik+plxDdzVPJXy8ATj4XNbVr9+qB9PWSBNzi5tzs y8Mg== X-Gm-Message-State: AIVw112fVuYvJT3LF0MIcv4QmKYB/gq7FKkxJsy+N643aVXu8AGv2VL+ V1h8Mv97r5NMkX9llH8= X-Received: by 10.99.123.74 with SMTP id k10mr3767969pgn.226.1499471123115; Fri, 07 Jul 2017 16:45:23 -0700 (PDT) Received: from ?IPv6:2602:304:cda0:8800:217d:6fe0:696a:e274? ([2602:304:cda0:8800:217d:6fe0:696a:e274]) by smtp.gmail.com with ESMTPSA id h90sm11339955pfh.133.2017.07.07.16.45.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Jul 2017 16:45:22 -0700 (PDT) To: Seth Blank , dmarc@ietf.org References: <2841386.K0mPqPZNK9@kitterma-e6430> <1850132.zVlZ2uGbS6@kitterma-e6430> From: Dave Crocker Message-ID: Date: Fri, 7 Jul 2017 16:45:19 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] using selectors to identify sources X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 23:45:25 -0000 On 7/7/2017 3:42 PM, Seth Blank wrote: > As a domain owner, the keys I use to sign messages are well known to me. > Determining which key was used at the beginning of an ARC flow is > impossible without transmitting the selector. transmitting to whom? and the issue isn't carriage of the selector. if you mean in reporting, that's fine. the issue is whether selector is factored into filtering analysis, thereby defeating the ability to use it for strictly administrative purposes as was intended. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Jul 7 16:51:25 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FBCE129AEB for ; Fri, 7 Jul 2017 16:51:24 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cD4AJM780Pd for ; Fri, 7 Jul 2017 16:51:22 -0700 (PDT) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADE93126D05 for ; Fri, 7 Jul 2017 16:51:22 -0700 (PDT) Received: by mail-ua0-x22a.google.com with SMTP id w19so29047838uac.0 for ; Fri, 07 Jul 2017 16:51:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=cOocXlH4DjdKp7xdQupBKNi/w02dC9UtpwWC/vKVrGk=; b=aBN9IPftCjYTHcaMk7cr7YRRR3vq0CN34m+Qo2TZxpbi2ElcO44G3qbC9HLbxwixNi AM6Y27MPABhNB5u3bBONUx9jmJsGXMrEiGl/LCn/ujcOQAxFhqs7mI7BzioUPH5aHgSB cM3+U1l25YuInxLBG5jS/Bc78ruFIwXYGTm8TIedSNdvkFIyaXvo+z5q9N2f0/rxm8+n jsSdPsx45bEWZgV7tmMrXKHn91CSusqw8tTEEgcQg3ljMIkd6yS/QWGv56HEoB6v4yTI chKJN/QxRK8/4g1iWTWO+P3b+kkgkjBjTiM+fSmHhmQwnNg2l9p8Gc9+AoGupvVl8o0b vzMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=cOocXlH4DjdKp7xdQupBKNi/w02dC9UtpwWC/vKVrGk=; b=CeHc9TRzNQxWx3TwoniXH9353ZQAh/AxGsb7MkwHq2qYo5BYL+1eBwx3i/FEibtST4 v/3ZjCSWO60PFS8Y6e1/bI0sH4q0/zGnEeLSCGv+o/FOhSOGoRQ0JAxxITzRgjBDYfxA s/iE1bKru7gtqvjEsU9LrEKrAnJWiu0anNL/WJ/YO7eL3qrPLdK6EduCf8D+YnOW62xr ejHpAFQLPBXvuqKNj/mZ6oNUPWUh0f3V/fnQa2ExTVoXW22CO1zVgcr8oA7Zq+UYe2z3 EfAPQSCJdu5sQYnXa6GvGFo44bb2oI1FBMm30A+tyfEUog7/1mboOHUmJU4+RxMPUJnH /0BQ== X-Gm-Message-State: AIVw111DQueXcx1gd7+IjNIW+5iFsWDYyy+vAya52jVJJN3DKNqRBEga LtE93ChWbTEZs7Zll/EOwp6015wh4nrkHBg= X-Received: by 10.176.17.26 with SMTP id e26mr1931041uab.94.1499471481554; Fri, 07 Jul 2017 16:51:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.152.80 with HTTP; Fri, 7 Jul 2017 16:51:01 -0700 (PDT) In-Reply-To: References: <2841386.K0mPqPZNK9@kitterma-e6430> <1850132.zVlZ2uGbS6@kitterma-e6430> From: Seth Blank Date: Fri, 7 Jul 2017 16:51:01 -0700 Message-ID: To: dmarc@ietf.org Content-Type: multipart/alternative; boundary="f403045e3e36026f990553c2e98b" Archived-At: Subject: Re: [dmarc-ietf] using selectors to identify sources X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 23:51:24 -0000 --f403045e3e36026f990553c2e98b Content-Type: text/plain; charset="UTF-8" On Fri, Jul 7, 2017 at 4:45 PM, Dave Crocker wrote: > On 7/7/2017 3:42 PM, Seth Blank wrote: > >> As a domain owner, the keys I use to sign messages are well known to me. >> Determining which key was used at the beginning of an ARC flow is >> impossible without transmitting the selector. >> > > transmitting to whom? and the issue isn't carriage of the selector. if > you mean in reporting, that's fine. > yes, 1000% we are *only* discussing about a DMARC report, and transmitting the selector via A-R/AAR so that it can be returned in a report. > the issue is whether selector is factored into filtering analysis, thereby > defeating the ability to use it for strictly administrative purposes as was > intended. > > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > --f403045e3e36026f990553c2e98b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Jul 7, 2017 at 4:45 PM, Dave Crocker <dcrocker@gmail.com> wrote:
On 7/7/2017 3:= 42 PM, Seth Blank wrote:
As a domain owner, the keys I use to sign messages are well known to me. De= termining which key was used at the beginning of an ARC flow is impossible = without transmitting the selector.

 transmitting to whom?=C2=A0 and the issue isn't carriage of the selecto= r.=C2=A0 if you mean in reporting, that's fine.
yes, 1000%

we are *only* discussing a= bout a DMARC report, and transmitting the selector via A-R/AAR so that it c= an be returned in a report.
=C2=A0
the issue is whether selector is factored into filtering analysis, thereby = defeating the ability to use it for strictly administrative purposes as was= intended.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

--f403045e3e36026f990553c2e98b-- From nobody Fri Jul 7 22:54:57 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62E7D12783A for ; Fri, 7 Jul 2017 22:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u0iJR0zNS1Ss for ; Fri, 7 Jul 2017 22:54:53 -0700 (PDT) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 946F3127867 for ; Fri, 7 Jul 2017 22:54:53 -0700 (PDT) Received: by mail-ua0-x22d.google.com with SMTP id j53so30821990uaa.2 for ; Fri, 07 Jul 2017 22:54:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gUjS0PH4wAls5i+qkJefKMR91gk1iTcAPN9jRxAsKt8=; b=e/EhHYaspId/7PPF7oh8dXXN9aqgYABsGaUYg/+sDl5PCIRCh3smlKHhTsobCSG1Pd Ncv5xtMvkWlkAvrCIU182CjXPwG1tTOqmqwBT/Mw658j1SxQiEbZX4i4ViJq+DtAWDaE Hr8YT12N7vTRS3BNUakdLKSoZWXNpDoAjJY15es31lPmSAH5r/Ub6V8bOZKjfu6Ea8s9 BI755dWwj+G+3edY4RqZup6/yGlhKI2dkEC3kHue6kysFz97VpZFQ3UdxZp4K//zeFYv SXYf07JNfnC29sg8UpG3ngDXwbUj1WS3gzjdiylfqsfoXGB++qD0TMtK/Bn2iB1ZOsio uGcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gUjS0PH4wAls5i+qkJefKMR91gk1iTcAPN9jRxAsKt8=; b=HzdRqn/5qOoAroCuO4y8iBRwcxYrnF515B8kSr0NqG/WuBiYSdPUn+i6HsP+zcSxR+ DXUxa2HiCqG/lZT748w6K2fJehowGaWHt8KU03D8nPQ5Ng67vXbynuFajWc+jR/9jt5n ZcXf3dMpF+uWa8wrQo72vqQ1/5uHq0MBao1ZCo/BGW3hu0yfHgZ5IkTASdMJT3l8A0XC 7Pl2Qn3NpVsMuUxewaunEd6xIaD/4Is1/pEWtUbCxlr4cgEF+lyX9H8b3kYuI3h5dzxY 1UeQn3hze22EcI8xed2JMNlyNfzEIDQGlwhbofa6K48eq5Kw0G7fp7hRddtm5r/ix3S8 Sryw== X-Gm-Message-State: AIVw111e8Cj7Otq4AGEQv6pqvTYl+IEIick4BHS1TUXSkICdOZHPMxxy e8/sxlURxIt81dA7ZguemH7fmsDsAsLeAuo= X-Received: by 10.176.4.50 with SMTP id 47mr2840169uav.151.1499493292555; Fri, 07 Jul 2017 22:54:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.126.196 with HTTP; Fri, 7 Jul 2017 22:54:51 -0700 (PDT) In-Reply-To: <2841386.K0mPqPZNK9@kitterma-e6430> References: <2841386.K0mPqPZNK9@kitterma-e6430> From: "Murray S. Kucherawy" Date: Fri, 7 Jul 2017 22:54:51 -0700 Message-ID: To: Scott Kitterman Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a114b927e0bc1cf0553c7fd30" Archived-At: Subject: Re: [dmarc-ietf] using selectors to identify sources X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jul 2017 05:54:55 -0000 --001a114b927e0bc1cf0553c7fd30 Content-Type: text/plain; charset="UTF-8" On Fri, Jul 7, 2017 at 7:11 AM, Scott Kitterman wrote: > In this context, having the selector in DMARC feedback reporting to help > define a 'source' is really useful. > The DMARC report also includes other things that might be able to help you identify the bad source, like the IP address. But I do hear what you're saying. Just to be clear, I don't really have any issue with adding selectors to DMARC reports. My trepidation specifically involves using A-R to transport the selector to wherever. The purpose of A-R going back to RFC5451 was primarily to make available (i.e., highlight) to users those portions of a message that were primary input to an authentication decision: "We validated signed content X against a published key for domain Y and it passed" (for DKIM), or "we validated IP address X against the policy for domain Y and it passed" (for SPF). Given most selectors out there, in my experience, identify time ranges for which the keys are meant to be valid, or are otherwise not names meaningful to an end user, providing the selector name seems antithetical to this purpose; what, for example, would a user do with the knowledge that ietf.org's "ietf1" key or kitterman.com's "201409" key or Scott's hypothetical "machine-number-5" key signed this message? If Gmail showed that, highlighted, on a message, would it help or confuse a typical user? I think the latter, and if that's the case, I would argue that A-R is not the place to put it. This smells like feature creep to me. If consensus is that it's good feature creep, then that's what we do, but I'd like to know that we're sure we want to water down A-R's definition in this way. I don't have a problem with having some way to get the selector into the DMARC report, but I'm not convinced A-R is the right or only way to do it. -MSK --001a114b927e0bc1cf0553c7fd30 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jul 7, 2017 at 7:11 AM, Scott Kitterman <skli= st@kitterman.com> wrote:
In t= his context, having the selector in DMARC feedback reporting to help
define a 'source' is really useful.

=
The DMARC report also includes other things that might be able to help= you identify the bad source, like the IP address.=C2=A0 But I do hear what= you're saying.=C2=A0 Just to be clear, I don't really have any iss= ue with adding selectors to DMARC reports.=C2=A0 My trepidation specificall= y involves using A-R to transport the selector to wherever.

The purp= ose of A-R going back to RFC5451 was primarily to make available (i.e., hig= hlight) to users those portions of a message that were primary input to an = authentication decision: "We validated signed content X against a publ= ished key for domain Y and it passed" (for DKIM), or "we validate= d IP address X against the policy for domain Y and it passed" (for SPF= ).=C2=A0 Given most selectors out there, in my experience, identify time ra= nges for which the keys are meant to be valid, or are otherwise not names m= eaningful to an end user, providing the selector name seems antithetical to= this purpose; what, for example, would a user do with the knowledge that <= a href=3D"http://ietf.org">ietf.org's "ietf1" key or kitterman.com's "201409" key= or Scott's hypothetical "machine-number-5" key signed this m= essage?=C2=A0 If Gmail showed that, highlighted, on a message, would it hel= p or confuse a typical user?=C2=A0 I think the latter, and if that's th= e case, I would argue that A-R is not the place to put it.

This smells like feature creep to me.=C2=A0 If consensus is that it's= good feature creep, then that's what we do, but I'd like to know t= hat we're sure we want to water down A-R's definition in this way.= =C2=A0 I don't have a problem with having some way to get the selector = into the DMARC report, but I'm not convinced A-R is the right or only w= ay to do it.

-MSK
--001a114b927e0bc1cf0553c7fd30-- From nobody Fri Jul 7 22:57:22 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BFBE129AFC for ; Fri, 7 Jul 2017 22:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VGGTUWcry-pF for ; Fri, 7 Jul 2017 22:57:14 -0700 (PDT) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C267912783A for ; Fri, 7 Jul 2017 22:57:13 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id j53so30834590uaa.2 for ; Fri, 07 Jul 2017 22:57:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=W3gdCOfThpkjvxpT/Vwk1CpsjqJb1yYeoFqCwCyWkWc=; b=MhDhAVN4jX3SSH5xLgXSGx17/yNSVyYMsqN8J/1SBoBphMesU11fZ9n+qPvPvONnnY en3M0/b4oI4jmaZmJJQR1rbzcNQZL0KiH1I64hzTUjXHRw+xOmadkYYl/O8Ji/TI8zSf zFLpOF1nYPxSXz55eodMUcw5i2htmA108v9AIX2CXgJ1a9RIbhHGHAwth+bLfPnvcU37 VulUz3o6XkwBUyV1+xiEz1q7y/1pdvIMWyQCOE72+8UgcuLlW/lKhFx1pNkyQ6sx38F7 ABUEA2xS4BYVMBsEkUli/51lmRpi7I6932PRoUDU6uNHgjroymM/Q3W8AtfceHriKia7 NmRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=W3gdCOfThpkjvxpT/Vwk1CpsjqJb1yYeoFqCwCyWkWc=; b=Mf41CO5LjkD0n7fzyNKYpxkIEliSDtTGPsW2CaQB4irhqN1sO2MipZ2rgU+r1B9EG2 bPmOSpv+83cYkJCmhD4PSQRFYmHoA/l3/iVVgAI8Hz0Ag854C2GKnOML6yKkGVyIcqzZ MrUeadZc7QQy4Q8qdlg8c5LZSq7b6rjFKrkkLvaekR4onv629Xq3camuflM62W823SBx R4FwKEDUpOqkBJRKLlx2enzRPkAqZEcCOGWPwezm23ltQSiPc/r5SO9OJES58CoDUNKx geiOazG5qeGIKf4OjltjPqhPLNy2FGM5t8UM85UB9F9cF/AAQFqG3rvvZb8FyxSCPT+n lB0Q== X-Gm-Message-State: AIVw112nDzS3GezHSfN9o0qfzqV1Vqgn1XKMODTY14TZNVO0/UYqHEnv RAPLQGfZlyvUQ5ZXmuk8Jps/hJXukXvB X-Received: by 10.176.17.71 with SMTP id g7mr2777198uac.61.1499493432942; Fri, 07 Jul 2017 22:57:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.126.196 with HTTP; Fri, 7 Jul 2017 22:57:12 -0700 (PDT) In-Reply-To: <20170707182932.gm3vhxluv3kcc35d@mx4.yitter.info> References: <20337b3e-be49-797c-2974-1e36bd9939e0@gmail.com> <20170707182932.gm3vhxluv3kcc35d@mx4.yitter.info> From: "Murray S. Kucherawy" Date: Fri, 7 Jul 2017 22:57:12 -0700 Message-ID: To: Andrew Sullivan Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="f4030437a8ac69e5c90553c80502" Archived-At: Subject: Re: [dmarc-ietf] ARC RFC status to target X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jul 2017 05:57:17 -0000 --f4030437a8ac69e5c90553c80502 Content-Type: text/plain; charset="UTF-8" On Fri, Jul 7, 2017 at 11:29 AM, Andrew Sullivan wrote: > I always feel like experimental status ought to come with some > description of what success or failure would mean and how that would > be determined. I think that is aligned with (but not entailed by) > https://www.ietf.org/iesg/informational-vs-experimental.html. And it > seems to me that the reasoning in this case suggests that one might > indeed be able to offer such a description. > I would expect the same, especially since the only RFCs I've ever worked on that were Experimental had to have this sort of thing before the IESG would let it go. So, yeah, +1, etc. -MSK --f4030437a8ac69e5c90553c80502 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jul 7, 2017 at 11:29 AM, Andrew Sullivan <aj= s@anvilwalrusden.com> wrote:
I always feel like experimental status ought to come with some
description of what success or failure would mean and how that would
be determined.=C2=A0 I think that is aligned with (but not entailed by)
https://www.ietf.org/iesg/informati= onal-vs-experimental.html.=C2=A0 And it
seems to me that the reasoning in this case suggests that one might
indeed be able to offer such a description.

=
I would expect the same, especially since the only RFCs I've ever = worked on that were Experimental had to have this sort of thing before the = IESG would let it go.=C2=A0 So, yeah, +1, etc.

-MSK
--f4030437a8ac69e5c90553c80502-- From nobody Fri Jul 7 23:00:41 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA59712896F for ; Fri, 7 Jul 2017 23:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OFlrpIKa7vPk for ; Fri, 7 Jul 2017 23:00:38 -0700 (PDT) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::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 53BF712783A for ; Fri, 7 Jul 2017 23:00:38 -0700 (PDT) Received: by mail-ua0-x22b.google.com with SMTP id g40so30915757uaa.3 for ; Fri, 07 Jul 2017 23:00:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0Mfo4+svo8M+xibjel/9zUMv5B1ybAvEeWF/GH5Pv54=; b=ajIO0Qmw6qGBy7VqSKgWba7CycRp+y350E0gZIkbgU4Cs2bAC9z6jFyF7MovFVlahZ oJm7/gEklwI/89Vk7mPml3aA+AqpjdCQcZhwpRTy6d2P2edtRI1kNysSRWeU8XnHxA+k gREMjZB/fxK/CH/DmU/zW0CB8YDQ2/o7U1yZEa1ky5xWnm88eo8MuojFCuS6UMhtnblO 4KcbSEEbI8X6Yk9AoWglbY+ioIuYZ6BHfLVBS9h0aHbcHrVzBcRIZXNCJSLBZYUqsHOm 5hCY6YYRGw/2Ky0dtFbrSxp0y70Ff++X1qMqBbtbpACpcDCDy8SuyACRpBlb4dyCLHpX 1tdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0Mfo4+svo8M+xibjel/9zUMv5B1ybAvEeWF/GH5Pv54=; b=GrXUGBDwUJvnTeZZWGyjXL32fAXJdLj+56g3/8aGln9hkvyh69dor1ts3bQO/beJFS B8u6aIEgM2mJgGT7LZWus8mQ01RkKNEV1BDqOrf6iF0SsYyjfU2TX3YYhnbI4GB5cRSo KGNLs3vl4vYqWiVvucDYnJCadMmcmQ01CHpNfaTI0qs1LvyIU20C1IjLdy4Qq2KRjNpD BBal2YfcpV+O2uq878sLSFyXCFLgt/AGaRNZ0Q3Y0lM/+I4nOQAutHV5+WQagpVH9UD+ 0uReceOuqYcmP9r3PT27iMDIKCQZMv7ty/0ZSlblvAJ9/8DAoqOhri4+qBUdXeaR/OE8 bZTQ== X-Gm-Message-State: AIVw110eQaGwyeKKXQ/mjDW2v/qpO4TncafVPTgG7CDj4S+CN2kOXBaP csxkAihn+goEId9vH9opXWlH3PZk87m7 X-Received: by 10.159.36.215 with SMTP id 81mr2797241uar.48.1499493637449; Fri, 07 Jul 2017 23:00:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.126.196 with HTTP; Fri, 7 Jul 2017 23:00:36 -0700 (PDT) In-Reply-To: <84047ca1-456c-1234-f416-ff08be69e076@crash.com> References: <20337b3e-be49-797c-2974-1e36bd9939e0@gmail.com> <20170707182932.gm3vhxluv3kcc35d@mx4.yitter.info> <09fd1486-c712-bd50-545c-9b694b3c79dc@crash.com> <20170707191251.dmnnyxgvlqf5niwf@mx4.yitter.info> <84047ca1-456c-1234-f416-ff08be69e076@crash.com> From: "Murray S. Kucherawy" Date: Fri, 7 Jul 2017 23:00:36 -0700 Message-ID: To: Steven M Jones Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a113e15c89a6b5a0553c811ee" Archived-At: Subject: Re: [dmarc-ietf] ARC RFC status to target X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jul 2017 06:00:40 -0000 --001a113e15c89a6b5a0553c811ee Content-Type: text/plain; charset="UTF-8" On Fri, Jul 7, 2017 at 12:50 PM, Steven M Jones wrote: > I may be misreading your response, but I wasn't suggesting a timeline > without criteria. I would hope to see criteria and a provisional > timeline for when to apply them. "A, B, and C will be tracked and > evaluated at IETF 101, next move to be decided then" or something > vaguely similar. > > Perhaps the criteria would be included in the RFC, and the review would > be added to the WG's work items? I'm not sure how it's usually done... > Do Experimental RFCs ever get expiration dates as a forcing function, > the way Internet Drafts do? For example, Section 7 of RFC6541 didn't lay out a timeline (it probably should have, but then capping an experiment executed by volunteers seems silly), but it made it clear that this was an experiment and someone was collecting results and would report back. Since there were only ever two implementations that only involved a fingers-on-one-hand number of domains, no report was ever made. -MSK --001a113e15c89a6b5a0553c811ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jul 7, 2017 at 12:50 PM, Steven M Jones <smj@crash.c= om> wrote:
I may be misreading your response, bu= t I wasn't suggesting a timeline
without criteria. I would hope to see criteria and a provisional
timeline for when to apply them. "A, B, and C will be tracked and
evaluated at IETF 101, next move to be decided then" or something
vaguely similar.

Perhaps the criteria would be included in the RFC, and the review would
be added to the WG's work items? I'm not sure how it's usually = done...
Do Experimental RFCs ever get expiration dates as a forcing function,
the way Internet Drafts do?

For example, Se= ction 7 of RFC6541 didn't lay out a timeline (it probably should have, = but then capping an experiment executed by volunteers seems silly), but it = made it clear that this was an experiment and someone was collecting result= s and would report back.=C2=A0 Since there were only ever two implementatio= ns that only involved a fingers-on-one-hand number of domains, no report wa= s ever made.

-MSK
--001a113e15c89a6b5a0553c811ee-- From nobody Fri Jul 7 23:05:20 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4889C129AB8 for ; Fri, 7 Jul 2017 23:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[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 LBtZiXnl1ay1 for ; Fri, 7 Jul 2017 23:05:18 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::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 10BD912783A for ; Fri, 7 Jul 2017 23:05:18 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id y70so27153748vky.3 for ; Fri, 07 Jul 2017 23:05:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yNio6j64hVARAvQEYtjYuJOntfWyGfsXnCF8m/UCABQ=; b=T+f/LcSAC+ZT9McH92tRwr7lOv8BW9Lj+DFsZ6F7SnvnEpu4qS2q6xYZXPkASakXzx l9oIHHMkM3i+Ojsx1nP2qeP431G3fE8Ug4CcKugDTNQBnAAsl3AKvSuzhCCcQ4d7k3VR BZRvmosiqlNQOGd/SaAxMvH0rMu3ACxZqcstnnU3XyKys3wfMoH+MYEAzZzGU+wKhtJG r4jqjIqDtrL4anmF5LlAHutaGIHO+IzxUN+nY8gtTbeXUxu7V3VdK35kt8AHunPxrU9A ULn7aKLkDrhE52z5Y86cWQOp9tEuB4B5IesaH5AVRhCuVdQ4rPGpPLByaVOskG4rhnD1 EoVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yNio6j64hVARAvQEYtjYuJOntfWyGfsXnCF8m/UCABQ=; b=BwGg1lRyXrL7xmwrHUPIzoKrWZ2w0idgxIeb4yJe/mQ+0bf9UaknRjp4nbWEkIBDGk YEEUi9qxRVFnAMb2sKwhy0dSXK+/Pl+LDu/5TKP1IJmiPzl8YujL2rcg9QG6oQIzbkpq 72UPF/pLbfrSN5UXiM6YwD3BdftRoiyArbQPz26PgDnmPOwvPgVW2U7G3402KMU+0wul aITfW1Sxqn3MkUkLWb7VU6wZQdBXqC/byTXcx1+lWulNmApFE4ghr2ud8TZNTHYsPRkN cAmPjmFYlehtWADBf3jzCZejRERGgI5/Yq9tefMOsrdTU5xhruZm68LOiFJge+pUKYWN o1Gg== X-Gm-Message-State: AIVw112URGXRzufaT9FhEGxeVv6qjc0QFqc+lNl5ROXZA+eiTNtdB1iR 1R0Xhny3Tr7+04Bj50qgCIjG8ibQXA== X-Received: by 10.31.136.9 with SMTP id k9mr2566639vkd.50.1499493917195; Fri, 07 Jul 2017 23:05:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.126.196 with HTTP; Fri, 7 Jul 2017 23:05:16 -0700 (PDT) In-Reply-To: <20337b3e-be49-797c-2974-1e36bd9939e0@gmail.com> References: <20337b3e-be49-797c-2974-1e36bd9939e0@gmail.com> From: "Murray S. Kucherawy" Date: Fri, 7 Jul 2017 23:05:16 -0700 Message-ID: To: Dave Crocker Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a11441d744702670553c82268" Archived-At: Subject: Re: [dmarc-ietf] ARC RFC status to target X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jul 2017 06:05:19 -0000 --001a11441d744702670553c82268 Content-Type: text/plain; charset="UTF-8" On Fri, Jul 7, 2017 at 11:09 AM, Dave Crocker wrote: > I've come to believe that it makes more sense, at this stage, to seek a > status of Experimental. That's not meant as a criticism of the work, but > rather to accurately reflect the current understanding of ARC dynamics. > > Having intermediaries signing thing and having receivers base delivery and > labeling decisions on those signatures is new and, I think, significantly > different that doing that for SPF or DKIM. Who should sign and when isn't > yet well understood. How those signatures should get evaluated by > receiving filtering engines also is not yet well-understood. > I think at the time DKIM went to Proposed Standard, one could've made the same argument about it as well, especially on your last two points. On the other hand, DKIM back then had way more investment of person-hours on implementations and WG list participation than DMARC and ARC do now, so I had a lot more confidence in the final product. I also think there's enough in flux about the current base document for ARC that I would argue pretty hard for Experimental if we were pressed to publish sooner. It doesn't feel "done" to me. -MSK --001a11441d744702670553c82268 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jul 7, 2017 at 11:09 AM, Dave Crocker <dcrocker@= gmail.com> wrote:
I've come to believe that = it makes more sense, at this stage, to seek a status of Experimental.=C2=A0= That's not meant as a criticism of the work, but rather to accurately = reflect the current understanding of ARC dynamics.

Having intermediaries signing thing and having receivers base delivery and = labeling decisions on those signatures is new and, I think, significantly d= ifferent that doing that for SPF or DKIM.=C2=A0 Who should sign and when is= n't yet well understood.=C2=A0 How those signatures should get evaluate= d by receiving filtering engines also is not yet well-understood.

I think at the time DKIM went to Proposed Standa= rd, one could've made the same argument about it as well, especially on= your last two points.=C2=A0 On the other hand, DKIM back then had way more= investment of person-hours on implementations and WG list participation th= an DMARC and ARC do now, so I had a lot more confidence in the final produc= t.

I also think there's enough in flux about the curr= ent base document for ARC that I would argue pretty hard for Experimental i= f we were pressed to publish sooner.=C2=A0 It doesn't feel "done&q= uot; to me.

-MSK
--001a11441d744702670553c82268-- From nobody Fri Jul 7 23:12:41 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6249129AA3 for ; Fri, 7 Jul 2017 23:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J9l6ZoeBSIAE for ; Fri, 7 Jul 2017 23:12:37 -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 7C1A712783A for ; Fri, 7 Jul 2017 23:12:37 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id 191so27250218vko.2 for ; Fri, 07 Jul 2017 23:12:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=oNn1L4bxyZGgicBEHLEgAjiRuWjQYTUPr4QpFiztbIw=; b=j6ZhNwNg/InaO1UIM/Ke6j8/GeGK5BqpQ99Yt+67Va2fCvSCnMc9fw0Rri9+KeIs3Q uFCffBfZPwuqr3r3hpgLLFHrb0Xr6ebZ0o1QsFuOvcRmoa0hEQ8dVJGKAChZDZyem/+I ica2I1/6ZAsc3k+Zz2MPj5wHriw8jk8jbpxjSG68CQKqr06/xIU/0k/zV3+lYUSFMVmy j/JpLU/ZtwgM3vXz80SF42h34WZVQEwSnPZ30oDFOpXQR3Sh69SLv7VMtFUry9orJtDt ZJWUdSR3DWzAfn7Cohh4hteKWuvxG2q2W94bwMhluryhDyKyz+tcUqCXQTh8YstETnbu JmJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=oNn1L4bxyZGgicBEHLEgAjiRuWjQYTUPr4QpFiztbIw=; b=mw/MTu7Y+k1/81fVNXVqC3dKlQGHKaasjmMZmsxYYhaUnUBGrUMkEFJg73PPrwTyaI O0INl/PO2LNVtzJEM4xUL0ywIBavlSIV1dvCGeBW7Nreo/s/eaVoGSFAbnUqhFpKsahJ Jlr9f8iNKDTwVx38QLyWbgWMlrPkzSBRa4ejeR9r9+ukmH5oXAQ8C3laJ5bTX34/oZJM ZlSQNDB+WETvlB1nsqgNFuwsQlltvZIDE72z/kIFYidK6SlOUU/khKW0Lfzv+52CCnwO 7Ol9XHzdr2elC7C3dN5ojlkzm5WCPgTf3QEwWc7twmKzKRXWO42+bkUwxJk5oNEb5+ES rWsA== X-Gm-Message-State: AIVw112CwtTjA6Kq3uI1BfHVEBNxPi9nW6YUzeoml8vfC2TWCxndppU7 QsM4ujB1Ba+FYQy+zLYtw8og8hc/30Ynqj0xyw== X-Received: by 10.31.190.135 with SMTP id o129mr2493679vkf.35.1499494356201; Fri, 07 Jul 2017 23:12:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.152.80 with HTTP; Fri, 7 Jul 2017 23:12:15 -0700 (PDT) In-Reply-To: References: <2841386.K0mPqPZNK9@kitterma-e6430> From: Seth Blank Date: Fri, 7 Jul 2017 23:12:15 -0700 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a1142f13471d1660553c83c03" Archived-At: Subject: Re: [dmarc-ietf] using selectors to identify sources X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jul 2017 06:12:40 -0000 --001a1142f13471d1660553c83c03 Content-Type: text/plain; charset="UTF-8" On Fri, Jul 7, 2017 at 10:54 PM, Murray S. Kucherawy wrote: > On Fri, Jul 7, 2017 at 7:11 AM, Scott Kitterman > wrote: > >> In this context, having the selector in DMARC feedback reporting to help >> define a 'source' is really useful. >> > > The DMARC report also includes other things that might be able to help you > identify the bad source, like the IP address. But I do hear what you're > saying. Just to be clear, I don't really have any issue with adding > selectors to DMARC reports. > Great > My trepidation specifically involves using A-R to transport the selector > to wherever. > The purpose of A-R going back to RFC5451 was primarily to make available > (i.e., highlight) to users those portions of a message that were primary > input to an authentication decision: "We validated signed content X against > a published key for domain Y and it passed" (for DKIM), or "we validated IP > address X against the policy for domain Y and it passed" (for SPF). Given > most selectors out there, in my experience, identify time ranges for which > the keys are meant to be valid, or are otherwise not names meaningful to an > end user, providing the selector name seems antithetical to this purpose; > what, for example, would a user do with the knowledge that ietf.org's > "ietf1" key or kitterman.com's "201409" key or Scott's hypothetical > "machine-number-5" key signed this message? If Gmail showed that, > highlighted, on a message, would it help or confuse a typical user? I > think the latter, and if that's the case, I would argue that A-R is not the > place to put it. > > This smells like feature creep to me. If consensus is that it's good > feature creep, then that's what we do, but I'd like to know that we're sure > we want to water down A-R's definition in this way. I don't have a problem > with having some way to get the selector into the DMARC report, but I'm not > convinced A-R is the right or only way to do it. > The way I read it, the consensus in this thread and others is that selectors and source ip make sense to transmit for DMARC report reasons, but where/how they should be transmitted does not have consensus. An earlier thread discussed putting this information in the AAR, but the consensus in that thread was that the AAR definition in the spec should be kept as minimal as possible, and a better place for the selector was the A-R, but the source ip didn't belong in the A-R at all. If neither of these pieces of information make sense in an A-R, to me it makes sense to revisit the conversation around transmitting via AAR instead of discussing new headers altogether (which is where the source ip conversation went), which definitely does feel like feature creep. Or maybe, put a different way, the question is: what's the simplest way, with the least delta to the spec, that allows for transmission of selectors and source ip? This would enable DMARC reports for messages delivered due to ARC to have the same report payload as messages delivered directly. > > > -MSK > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --001a1142f13471d1660553c83c03 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Jul 7, 2017 at 10:54 PM, Murray S. Kucherawy <superuser@gmail.com> wrote:
On Fri, Jul 7, 2017 at 7:11 AM, Scott= Kitterman <sklist@kitterman.com> wrote:
In this context, having the s= elector in DMARC feedback reporting to help
define a 'source' is really useful.

=
The DMARC report also includes other things that might be able = to help you identify the bad source, like the IP address.=C2=A0 But I do he= ar what you're saying.=C2=A0 Just to be clear, I don't really have = any issue with adding selectors to DMARC reports.

Great
=C2=A0
My trepidation specifically involves usi= ng A-R to=C2=A0transport the selector to wherever.
<= /blockquote>
The purpose = of A-R going back to RFC5451 was primarily to make available (i.e., highlig= ht) to users those portions of a message that were primary input to an auth= entication decision: "We validated signed content X against a publishe= d key for domain Y and it passed" (for DKIM), or "we validated IP= address X against the policy for domain Y and it passed" (for SPF).= =C2=A0 Given most selectors out there, in my experience, identify time rang= es for which the keys are meant to be valid, or are otherwise not names mea= ningful to an end user, providing the selector name seems antithetical to t= his purpose; what, for example, would a user do with the knowledge that ietf.org's "ietf1&q= uot; key or kitterman.co= m's "201409" key or Scott's hypothetical "machin= e-number-5" key signed this message?=C2=A0 If Gmail showed that, highl= ighted, on a message, would it help or confuse a typical user?=C2=A0 I thin= k the latter, and if that's the case, I would argue that A-R is not the= place to put it.

This smells like feature creep to me.= =C2=A0 If consensus is that it's good feature creep, then that's wh= at we do, but I'd like to know that we're sure we want to water dow= n A-R's definition in this way.=C2=A0 I don't have a problem with h= aving some way to get the selector into the DMARC report, but I'm not c= onvinced A-R is the right or only way to do it.

The way I read it, the consensus in this threa= d and others is that selectors and source ip make sense to transmit for DMA= RC report reasons, but where/how they should be transmitted does not have c= onsensus.

An earlier thread discussed putting this= information in the AAR, but the consensus in that thread was that the AAR = definition in the spec should be kept as minimal as possible, and a better = place for the selector was the A-R, but the source ip didn't belong in = the A-R at all.

If neither of these pieces of info= rmation make sense in an A-R, to me it makes sense to revisit the conversat= ion around transmitting via AAR instead of discussing new headers altogethe= r (which is where the source ip conversation went), which definitely does f= eel like feature creep.

Or maybe, put a different = way, the question is: what's the simplest way, with the least delta to = the spec, that allows for transmission of selectors and source ip? This wou= ld enable DMARC reports for messages delivered due to ARC to have the same = report payload as messages delivered directly.
=C2=A0


-MSK

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


--001a1142f13471d1660553c83c03-- From nobody Fri Jul 7 23:30:04 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1FC2129AA4 for ; Fri, 7 Jul 2017 23:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9byBZ68L-9Rn for ; Fri, 7 Jul 2017 23:30:01 -0700 (PDT) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::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 464701286D6 for ; Fri, 7 Jul 2017 23:30:01 -0700 (PDT) Received: by mail-ua0-x230.google.com with SMTP id w19so31338277uac.0 for ; Fri, 07 Jul 2017 23:30:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fkwwu2EVGX2OGErQb464OSXbu6S1I1nQyPYBnTGeEIQ=; b=DObUId1L7+5TCqvk0LKX2XC0yyfXLM7Ch7g+ZCGatLmPMvShCfhbVintiJ4nsBYGtp IhhB6cRYtgUxNaFrpBb+zfU4eLvcbs+6Sa5kwqgEvuNHX2fbslbdP5Lo1jXSN1IPjK3s wWZli4AHdIznaxW4RaNmlwSW0JjX39CmumUmy3EN4j8R3GGISIz36jBSfASHVoU0TFcM 52le339TafyIRxAyCAZlZmxcbnVz3YXd36V2GCEAB0fl21P7GpYbxMSfYWyqwUujSbrK MpFq8PTKJerVCeWl6w0Mk1JuXfdiUQNljRfhqnsGwnUnWDst2yiTUFAIauxfvwSdMaIe x/vA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fkwwu2EVGX2OGErQb464OSXbu6S1I1nQyPYBnTGeEIQ=; b=tNs3KtOkhGrRsnkxAG63yUP+ZBXJV7hl5wxAlORy8g2shKkJoISIMRCDfIbSYFD7hN Tzi2rmZerUQWMf0DzaBqxGdlhcYJeK7AWUNemF97V1n920DojNrZgzTkruwzspOG/Ajv d3kl9x3pbnucT+ML1NPxkIglWyValf8pZNuD7czcpfyjQgZKKoIRqdbUFy6fodgjY83x TvC7nDUAnrwD0HlRoUjqzdEHhfclh3JWseHuheSOyaTvBJi5gsyDGibrHZ/V4fNEp9H0 vNFr0yYxDDQ/F28Y0BRW08VdWPVaCd6gnOA49Ym/9GNvLKOGxoh+dXfWQgZ5kQ4lOeVU VPqQ== X-Gm-Message-State: AIVw113uT7KnTu4afq5FQ6QNzGzLvYX0Zr53qrQssfQA0vFg1E4l2rB+ idTeRJ3vPyoPyJ9m5y7N4rnCWvSWnjFy X-Received: by 10.159.36.215 with SMTP id 81mr2841238uar.48.1499495400332; Fri, 07 Jul 2017 23:30:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.126.196 with HTTP; Fri, 7 Jul 2017 23:29:59 -0700 (PDT) In-Reply-To: References: <2841386.K0mPqPZNK9@kitterma-e6430> From: "Murray S. Kucherawy" Date: Fri, 7 Jul 2017 23:29:59 -0700 Message-ID: To: Seth Blank Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a113e15c8ade23a0553c87a95" Archived-At: Subject: Re: [dmarc-ietf] using selectors to identify sources X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jul 2017 06:30:04 -0000 --001a113e15c8ade23a0553c87a95 Content-Type: text/plain; charset="UTF-8" On Fri, Jul 7, 2017 at 11:12 PM, Seth Blank wrote: > Or maybe, put a different way, the question is: what's the simplest way, > with the least delta to the spec, that allows for transmission of selectors > and source ip? This would enable DMARC reports for messages delivered due > to ARC to have the same report payload as messages delivered directly. > I would suggest not specifying it at all, and letting implementations figure out some private way to do it that works for them. To give a real example, OpenARC could put it in A-R or A-A-R if it wants to, to be consumed downstream by OpenDMARC. But the ARC RFC doesn't have to say that this is "the" way to do it. This is fine since RFC7601 says anything else that ever sees an unknown ptype.property pairing ("header.s", for example) is not supposed to use it. -MSK --001a113e15c8ade23a0553c87a95 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jul 7, 2017 at 11:12 PM, Seth Blank <seth@sethbl= ank.com> wrote:
Or maybe, pu= t a different way, the question is: what's the simplest way, with the l= east delta to the spec, that allows for transmission of selectors and sourc= e ip? This would enable DMARC reports for messages delivered due to ARC to = have the same report payload as messages delivered directly.

I would suggest not specifying it a= t all, and letting implementations figure out some private way to do it tha= t works for them.

To give a real example, OpenARC could p= ut it in A-R or A-A-R if it wants to, to be consumed downstream by OpenDMAR= C.=C2=A0 But the ARC RFC doesn't have to say that this is "the&quo= t; way to do it.=C2=A0 This is fine since RFC7601 says anything else that e= ver sees an unknown ptype.property pairing ("header.s", for examp= le) is not supposed to use it.

-MSK
--001a113e15c8ade23a0553c87a95-- From nobody Sat Jul 8 06:10:36 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D796D124B0A for ; Sat, 8 Jul 2017 06:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 AY-web7r3Qdn for ; Sat, 8 Jul 2017 06:10:33 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88F0112441E for ; Sat, 8 Jul 2017 06:10:33 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id p188so46354625oia.0 for ; Sat, 08 Jul 2017 06:10:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=ul3ep7Ww3AE3FZbgbtYwvdhNVwArU3VA6JXzzClHLfg=; b=a1bDTlS2bVrWPQfMFkVSFi+fjDZgaeAzF/OZMy93UoQi5Bebwr+vCI2yyfhbe2FEJe 8Xqz9fBUcFbSzdjYmNFqnf6ni1JPQPwNIgwMzoeNWUuAKyXwBKjMZq1IYS46yxlVQMEu VTOXPPEx3LSQPnAwkMrOyqkJeiAOtR5VaPgGhS77qeTTvPuzoACy5Qk/LMGNyrXd9xtN 5m/BrcrjETiqzbHEKY7y0ZtlqFzZnGTdxejftjW0ECDP+qnRAbtuXP+Yiu/geS1eOFk1 GtR+UL8BqEEB1n3Kd40EWppZjKjOl3vxmY0Co16wFEOXRYQLZ6NtTVbKGezIq0DccZ19 2kag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ul3ep7Ww3AE3FZbgbtYwvdhNVwArU3VA6JXzzClHLfg=; b=eQkTVcomSvhy5KQ0+W/6A/g4+BkBZr2byHuARF+mKEXgdclM2zMZAp0Gdp+mmUBd9b zYV4XrRi+hAcOwbxv+5jbc4dZVW0uGcQ8SNvlINDNc4lzVy7SHxqDIRM7L0qny8l5css cGrCpMVyijrAv2R4nDUYakzMoBiuE4JEncXe6ZQvYVhA7CFSN4taeZaUNZCO6llX+vlD yA/Jbfw6Owbr2x2CNF5nQk2nctYpsNjUIQNHS9Qp1PMj6mEUC+oKviITD33ThTuyGgew MWxGcQ1OpAPiZcW2Jninf5GFcN74W4qq3FAz4TiiCalvt+NwLphFId8xECPuo2mYBsuP HUuA== X-Gm-Message-State: AIVw111nnFPYv2G5aJ+dwiOunIo9IBC9unwFZnAGS94bYgo/LmQe3SLy ELMQ0CzK3DM0519ELwE= X-Received: by 10.202.104.217 with SMTP id o86mr3497549oik.127.1499519432623; Sat, 08 Jul 2017 06:10:32 -0700 (PDT) Received: from ?IPv6:2602:304:cda0:8800:d17e:7fe3:9cb7:7c98? ([2602:304:cda0:8800:d17e:7fe3:9cb7:7c98]) by smtp.gmail.com with ESMTPSA id j84sm11553105oiy.36.2017.07.08.06.10.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Jul 2017 06:10:31 -0700 (PDT) To: "Murray S. Kucherawy" Cc: "dmarc@ietf.org" References: <20337b3e-be49-797c-2974-1e36bd9939e0@gmail.com> From: Dave Crocker Message-ID: <90cb1e02-0fa6-9d40-4785-705d801c73bb@gmail.com> Date: Sat, 8 Jul 2017 06:10:30 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] ARC RFC status to target X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jul 2017 13:10:35 -0000 On 7/7/2017 11:05 PM, Murray S. Kucherawy wrote: > On Fri, Jul 7, 2017 at 11:09 AM, Dave Crocker > wrote: > Having intermediaries signing thing and having receivers base > delivery and labeling decisions on those signatures is new and, I > think, significantly different that doing that for SPF or DKIM. Who > should sign and when isn't yet well understood. How those > signatures should get evaluated by receiving filtering engines also > is not yet well-understood. > > I think at the time DKIM went to Proposed Standard, one could've made > the same argument about it as well, especially on your last two points. > On the other hand, DKIM back then had way more investment of > person-hours on implementations and WG list participation than DMARC and > ARC do now, so I had a lot more confidence in the final product. 0. I should note and stress that my suggestion is not based on any concern about the very low-level mechanics of ARC. First, signing an object is an extremely well-understood algorithmic component mechanism. Second, ARC derives from DKIM, which moves the component mechanism maturity question out from general theory to specific practice. 1. The components and dynamics of DKIM are quite straighforward. I think the only construct that might be called problematic is the selector, and the problem is one of nuance, not basics. Anyhow, the IETF wg DKIM spec was really version 4 of the work. Yahoo had done 2 versions and the ad hoc private consortium that created DKIM did another. So although the wg changes were substantive, they were not fundamental and DKIM was really quite mature, far beyond IETF norms for Proposed. 2. The mechanics of cascading signatures that ARC does /is/ unusual and possibly unique. I believe the only operationally established exemplar in this space is the X.509 cert signature hierarchy. However it is an relatively static, offline-signature model for signing the cert hierarchy -- as opposed to the dynamic act of using the cert to sign payload -- while the cascading ARC signature sequence is entirely on the fly. Both technically and operationally, this is a non-trivial point. The simplest aspect of this is that we don't know how fragile this will prove. 3. Having the receiver filtering engine evaluate intermediaries in the way that ARC enables is, I believe, new. In terms of the usual filtering models I also believe it is conceptually quite different, or at least not widely appreciated. 4. Whether or how to evaluate the origination identifier, through the ARC-signed Results packaging, is also new and involves a model of indirect trust that I believe has not be done before (or, again, at least not widely.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Jul 8 10:55:49 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 524A112F3D0 for ; Sat, 8 Jul 2017 10:55:47 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 bXeNnnJAVOBv for ; Sat, 8 Jul 2017 10:55:45 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CC1612F28B for ; Sat, 8 Jul 2017 10:55:45 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id x187so49090614oig.3 for ; Sat, 08 Jul 2017 10:55:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=90MbtYYzlSSGLozZOabUnF8vi5RHk7AkGPZxXLJbN9Y=; b=eyOMUsAbfbpL3Vu/kqU/IF38YSm5s0cI/EhwtoIwM3l2lS0d8+98fTggE9D1Wraug8 Rf2M2PTH3tGsp1jSzEQk17gt3AhemVchJNYaITQGIv1rWiBiT009GibK9wGbNZOc2oVU cqrHgSspE2aiRfd4EVGD3DMvL+hddOZuPffILFTiCf4ewSgTmeAZmdSHARUVTryHKXwn pBnXlOgGngFQNF3kHi9LXYQdWIl9xQbWO6hCjt2usZhl8IAK2wNRuVaKytLN3LvLr/ta xEOyt1sRPqHmXPmY7zoX85SCJ4Ijh0bs2nUuz0V7uQL4coTemYKsaD3HOmq2nFkIwAol wefg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=90MbtYYzlSSGLozZOabUnF8vi5RHk7AkGPZxXLJbN9Y=; b=M7dcj8tojFzbCfzGkpw7bpymjEKltUvCXfewYzvKp29gHFgFR4Gvw52rAsigUCswrh DBAtDgvXoSfjK9162uAAedlwA1RhevlqYTyWXYKJ/y9pDxqbk0tz7iNXsZsj+8w7fmjb I8PiM/r/XhKcKhVdG0pw/okwjiUzvtBBXjMW4YHtox1TcEKtRG3QvbfwdtLsaTDHXelD 4/LGbzoRCIwcyCSn+U1U40tR3GCt/R0J079P4XPv8AeZaRC3tobmu7Mq5iEXo3m1jNs9 he8KxCFjhrUbxn2NPzYkKaQA9nClSfadCb5WjBQUzX/WSREF1nf6zhYnXGBnkTRl76Ba U9cQ== X-Gm-Message-State: AIVw113YS1TIfoN+dbxHwZw8pTUGZkknc06NG60TAR4mmR5/y/RF2wZq byF46Tq0e/bu78AOAlE= X-Received: by 10.202.83.74 with SMTP id h71mr4032752oib.135.1499536544681; Sat, 08 Jul 2017 10:55:44 -0700 (PDT) Received: from ?IPv6:2602:304:cda0:8800:d17e:7fe3:9cb7:7c98? ([2602:304:cda0:8800:d17e:7fe3:9cb7:7c98]) by smtp.gmail.com with ESMTPSA id p65sm12449913oie.8.2017.07.08.10.55.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Jul 2017 10:55:44 -0700 (PDT) From: Dave Crocker To: "Murray S. Kucherawy" Cc: "dmarc@ietf.org" References: <20337b3e-be49-797c-2974-1e36bd9939e0@gmail.com> Message-ID: <92626495-ea27-bb24-9175-ad0a4501b859@gmail.com> Date: Sat, 8 Jul 2017 10:55:42 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] ARC RFC status to target X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jul 2017 17:55:47 -0000 On 7/7/2017 11:05 PM, Murray S. Kucherawy wrote: > On Fri, Jul 7, 2017 at 11:09 AM, Dave Crocker > wrote: > Having intermediaries signing thing and having receivers base > delivery and labeling decisions on those signatures is new and, I > think, significantly different that doing that for SPF or DKIM. Who > should sign and when isn't yet well understood. How those > signatures should get evaluated by receiving filtering engines also > is not yet well-understood. > > I think at the time DKIM went to Proposed Standard, one could've made > the same argument about it as well, especially on your last two points. > On the other hand, DKIM back then had way more investment of > person-hours on implementations and WG list participation than DMARC and > ARC do now, so I had a lot more confidence in the final product. 0. I should note and stress that my suggestion is not based on any concern about the very low-level mechanics of ARC. First, signing an object is an extremely well-understood algorithmic component mechanism. Second, ARC derives from DKIM, which moves the component mechanism maturity question out from general theory to specific practice. 1. The components and dynamics of DKIM are quite straighforward. I think the only construct that might be called problematic is the selector, and the problem is one of nuance, not basics. Anyhow, the IETF wg DKIM spec was really version 4 of the work. Yahoo had done 2 versions and the ad hoc private consortium that created DKIM did another. So although the wg changes were substantive, they were not fundamental and DKIM was really quite mature, far beyond IETF norms for Proposed. 2. The mechanics of cascading signatures that ARC does /is/ unusual and possibly unique. I believe the only operationally established exemplar in this space is the X.509 cert signature hierarchy. However it is an relatively static, offline-signature model for signing the cert hierarchy -- as opposed to using the cert to sign payload -- while ARC is entirely on the fly. Both technically and operationally, this is a non-trivial point. The simplest aspect of this is that we don't know how fragile this will prove. 3. Having the receiver filtering engine evaluate intermediaries in the way that ARC enables is, I believe, new. In terms of the usual filtering models I also believe it is conceptaly quite different, or at least not widely appreciated. 4. Whether or how to evaluate the origination identifier, through the ARC-signed Results packaging, is also new and involves a model of indirect trust that I believe has not be done before (or, again, at least not widely.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Jul 8 11:24:36 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78F39130154 for ; Sat, 8 Jul 2017 11:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VGfIAidW-5mz for ; Sat, 8 Jul 2017 11:24:32 -0700 (PDT) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::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 ACB94130141 for ; Sat, 8 Jul 2017 11:24:32 -0700 (PDT) Received: by mail-ua0-x230.google.com with SMTP id w19so36032893uac.0 for ; Sat, 08 Jul 2017 11:24:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OM5jjjJ4JqjtCtABqlw+0esG/iifI7ZobU9OdBWTK0w=; b=Or97v1RP959XQvVEv6hhRH4WHrT+Z0xM2nA+oWtRd7zZyxYgJIO+qzEMbKi3QBd3zZ sKDHmRvjA3Mp9IFuOXIGFtQ2LDiK4J/23/MjKa3p1dsCCCXMvF1A+wiDrh4KZBYGBmk6 V6I9CCmRHZtx4lQE+pHh6u7X+2Xv+/Ahs8gjO0f9NAsX1axsOvHfw3RaGcKzZtt650yz z/+wlaDu7owI7NJyNRG7+fBJ703fBJHHhLVSsFFm8RP0PZSpcZvybqa3m0sagAhRnE8r p0wbam0N3Mu578qRHXxrJOg/dAB0mo/hdP8Cl37OcUzWZ7JO4IQp5eTT7ZyryiVOqqf9 3ZAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OM5jjjJ4JqjtCtABqlw+0esG/iifI7ZobU9OdBWTK0w=; b=gdZY8vwzmd+7oHJvp+g2CLW/IjwNpQYmrI0I4sfJHfWDRqn29p7BdK7njm89107p0k uj/XZI1X60jW5CUDh3DLmxfWw9c5KWokmpI6rxn08BoG2VfCgoXKYKwMacui9fdTBAHn ZTar3OFxV+S2nMvWCx2Rdpek+igjmdkjZ/bH6dMAkp7SpQ9T1e0I2CgzcXlEy/B2kiUO gQ5C4aES2nRRxUO0cCmg/gMFqoTfQSzUqz21CW7WUdvi5VAGgjpsoCVR+BoBIEQzQPGd AQeDOqB5kB6bg5qi5UFc86rHlSIFei1xrqxxSvRABxN8i+UTp+JEN5WlSjDRWHu9nape R1og== X-Gm-Message-State: AIVw113Zl1Z1BVEALVf79edqeYRaZBv9fesAzBVOPGkJDJHqxh3zASEU 5rHZfXiiotd+rCiLMEoQuHhJk7jsBA== X-Received: by 10.176.17.71 with SMTP id g7mr4144608uac.61.1499538271391; Sat, 08 Jul 2017 11:24:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.126.196 with HTTP; Sat, 8 Jul 2017 11:24:30 -0700 (PDT) In-Reply-To: <92626495-ea27-bb24-9175-ad0a4501b859@gmail.com> References: <20337b3e-be49-797c-2974-1e36bd9939e0@gmail.com> <92626495-ea27-bb24-9175-ad0a4501b859@gmail.com> From: "Murray S. Kucherawy" Date: Sat, 8 Jul 2017 11:24:30 -0700 Message-ID: To: Dave Crocker Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="f4030437a8acfe53890553d275d5" Archived-At: Subject: Re: [dmarc-ietf] ARC RFC status to target X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jul 2017 18:24:34 -0000 --f4030437a8acfe53890553d275d5 Content-Type: text/plain; charset="UTF-8" On Sat, Jul 8, 2017 at 10:55 AM, Dave Crocker wrote: > 2. The mechanics of cascading signatures that ARC does /is/ unusual > and possibly unique. I believe the only operationally established exemplar > in this space is the X.509 cert signature hierarchy. However it is an > relatively static, offline-signature model for signing the cert hierarchy > -- as opposed to using the cert to sign payload -- while ARC is entirely on > the fly. Both technically and operationally, this is a non-trivial point. > The simplest aspect of this is that we don't know how fragile this will > prove. > > 3. Having the receiver filtering engine evaluate intermediaries in the > way that ARC enables is, I believe, new. In terms of the usual filtering > models I also believe it is conceptaly quite different, or at least not > widely appreciated. > > 4. Whether or how to evaluate the origination identifier, through the > ARC-signed Results packaging, is also new and involves a model of indirect > trust that I believe has not be done before (or, again, at least not > widely.) > There's interest verging on anxiety to get this deployed, and thus there are both private and public implementations of it that are relatively stable (modulo some open questions about the draft content). It won't be long before we're able to gather efficacy details based on live operation, even if the draft hasn't been given an RFC number yet. But you're right, there's some new stuff here, and strange side effects could take a while to manifest, or it could take us a while to figure out how to deal with them when they appear. So if it's more important to get an RFC published than it is to wait for some modicum of deployed maturity -- which will take months, at least, I would guess -- then Experimental is indeed something we should consider, and I also agree with Andrew that the experiment should be reasonably well described and bounded. -MSK --f4030437a8acfe53890553d275d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Jul 8, 2017 at 10:55 AM, Dave Crocker <dcrocker@= gmail.com> wrote:
=C2=A0 =C2=A0 2. The mechanics of cascading signatures that ARC does /is/ u= nusual and possibly unique. I believe the only operationally established ex= emplar in this space is the X.509 cert signature hierarchy.=C2=A0 However i= t is an relatively static, offline-signature model for signing the cert hie= rarchy -- as opposed to using the cert to sign payload -- while ARC is enti= rely on the fly. Both technically and operationally, this is a non-trivial = point.=C2=A0 The simplest aspect of this is that we don't know how frag= ile this will prove.

=C2=A0 =C2=A03.=C2=A0 Having the receiver filtering engine evaluate interme= diaries in the way that ARC enables is, I believe, new.=C2=A0 In terms of t= he usual filtering models I also believe it is conceptaly quite different, = or at least not widely appreciated.

=C2=A0 =C2=A04.=C2=A0 Whether or how to evaluate the origination identifier= , through the ARC-signed Results packaging, is also new and involves a mode= l of indirect trust that I believe has not be done before (or, again, at le= ast not widely.)

There's interest= verging on anxiety to get this deployed, and thus there are both private a= nd public implementations of it that are relatively stable (modulo some ope= n questions about the draft content).=C2=A0 It won't be long before we&= #39;re able to gather efficacy details based on live operation, even if the= draft hasn't been given an RFC number yet.

But = you're right, there's some new stuff here, and strange side effects= could take a while to manifest, or it could take us a while to figure out = how to deal with them when they appear.=C2=A0 So if it's more important= to get an RFC published than it is to wait for some modicum of deployed ma= turity -- which will take months, at least, I would guess -- then Experimen= tal is indeed something we should consider, and I also agree with Andrew th= at the experiment should be reasonably well described and bounded.

<= /div>
-MSK
--f4030437a8acfe53890553d275d5-- From nobody Sat Jul 8 11:45:22 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97B1B12EC51 for ; Sat, 8 Jul 2017 11:45: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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 5jqlu29sbLqV for ; Sat, 8 Jul 2017 11:45:20 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26C34126DFF for ; Sat, 8 Jul 2017 11:45:20 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id x187so49523605oig.3 for ; Sat, 08 Jul 2017 11:45:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=yM6z80yvttc3OmyPjS3RfeMxaMao/1gI+oChb45x/cI=; b=h8zf951vQ7meF8uEXJFIrD8iv8feBe5N0C1A9qtftcmi0JiPPHcu3GAtNwtJEV6hQ8 m91iXESsz5yquif1ii8AVO+dWCIVD4DYo52id4i1Q1W1K0Qo6S20tik5tAjYn7AooDIS 1QgmGK7TSiZIE31JGxktDLSEKulj853v6DS+04S1UOUJWpgsJnibkQVVd5eNjDgl24tV GMvmVXUI16ctt3eTx5GySFww8hw1vtQV8OanjefQe26WHVnD5ihSciLANK6LXqVyEQ/z dZxEK2yQj6TPCclVUn9pPQMM3ij3HC5mETDJ8i0pl1mHaFFCGK0tXsXlI0fxytVsqptz YC2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=yM6z80yvttc3OmyPjS3RfeMxaMao/1gI+oChb45x/cI=; b=YDSnNrd6Sx6fXuTlVDKCVRqVfO4aNEKjc7SWWT0IoYjySIKI3fmuBRnWCGOd+Oo6J5 FTtn5TQhrOQj77H5gW9H/EUO1NlogX8vA10buWNhwLh7GWGBJgAlf2TAHWSi+g84KAGg wPAkx4TccFzs2BNsuXVpltZyJQSFOSIMx9U9Ik+iIyzRLKXqsUos5qbfuf6xEm97Ud8m wv/qQWcaE3RuhBqnfQB0OXo/MRCUNeDXsJWr4h5QLA9BI2GlpfPOFCg+0ltL5t9HII4I EhIqEMiR6dV6G2M33n5mWgUDWmt2aNNOMP5fC2uKc5f4wv8iqD+eFgbs5urtgxi+14x4 azHA== X-Gm-Message-State: AIVw110zn97PeYbSrBV/q1kP7hkihupp1Z6UPw5kvv4wFRVr2+qMj5+n PYATrH/ukNNfXHPJ89s= X-Received: by 10.202.204.149 with SMTP id c143mr3617297oig.211.1499539519319; Sat, 08 Jul 2017 11:45:19 -0700 (PDT) Received: from ?IPv6:2602:304:cda0:8800:d17e:7fe3:9cb7:7c98? ([2602:304:cda0:8800:d17e:7fe3:9cb7:7c98]) by smtp.gmail.com with ESMTPSA id v125sm6518611oif.14.2017.07.08.11.45.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Jul 2017 11:45:18 -0700 (PDT) To: "Murray S. Kucherawy" Cc: "dmarc@ietf.org" References: <20337b3e-be49-797c-2974-1e36bd9939e0@gmail.com> <92626495-ea27-bb24-9175-ad0a4501b859@gmail.com> From: Dave Crocker Message-ID: Date: Sat, 8 Jul 2017 11:45:05 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] ARC RFC status to target X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jul 2017 18:45:22 -0000 On 7/8/2017 11:24 AM, Murray S. Kucherawy wrote: > There's interest verging on anxiety to get this deployed, and thus there > are both private and public implementations of it that are relatively > stable (modulo some open questions about the draft content). It won't > be long before we're able to gather efficacy details based on live > operation, even if the draft hasn't been given an RFC number yet. I think the document can introduce itself better and give a more helpful conceptual framework at the start. But that's not a comment on the technical details. While it's possible that there is some interesting technical deficiency lurking there, I'm not especially worried about that. Rather... > But you're right, there's some new stuff here, and strange side effects > could take a while to manifest, or it could take us a while to figure It's these sorts of issues. I'm reacting from intuition here, not a specific bit of insight or concern. Just a general feeling that the operational dynamics of this require some breadth of experience. > out how to deal with them when they appear. So if it's more important > to get an RFC published than it is to wait for some modicum of deployed > maturity -- which will take months, at least, I would guess -- then > Experimental is indeed something we should consider, and I also agree > with Andrew that the experiment should be reasonably well described and > bounded. If I thought that bench-testing would suffice, then I'd suggest doing it and holding the RFC until we get the results. But I think the question of dynamics and operations is more complex and requires some breadth of deployment experience to resolve. (Even if 'resolve' means a solid 'no problems' comeback rather than any interesting statements about nuance or implication.) On the matter of a goal for the experiment I'll repeat that I think we merely need to target development of a Deployment and Use BCP. When we have good community support for the contents of such a document, based on significant experience, then the spec will be ready for standards track. (The formal rules for Proposed do not require field experience or even implementation. Except sometimes. And there's no clear rule about when it's required. My own sense of the rule is "when we don't adequately understand how it will work in the real world and especially when problems could have an infrastructure effect." I see this as one of those cases.) d/ d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Jul 8 14:08:31 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E35BB126C3D for ; Sat, 8 Jul 2017 14:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bcnrfg6POz6d for ; Sat, 8 Jul 2017 14:08:28 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 257C3124217 for ; Sat, 8 Jul 2017 14:08:28 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id r125so32403050vkf.1 for ; Sat, 08 Jul 2017 14:08:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=tZlaV2wFT6cinqhvzf/cN4IUBNss7U+As//vfUlCRLw=; b=dbYLWot2niJBfX5vdxPX7TTDDZ5yvujWnw9IyEdLyD9JCmz+45wAkOBd4/mWxQIjUV rfvWGGKIrtbLy7YyOu18oTkUc5lE5pnCHQ9ZPwMQsUWBYfWYXtfOzRyt83FgBKlHrnHR 5SpUtl9GvGVmR0zr7n/pcSVQB+nSO6gUsF73jkpUWt/zl7DBTtSuhpzEE7LjR+T7SmSX vQ+c07qNqCiVl4pqu6ww9H1PgVItlAv5z4+r8L7CupYcCbi0JxuMscLyKOWUqugNfxUi yMTL1IKdf6t3Ox7ckGpj8V4c0/8lrXUjPmdDoXwB2OgoOzqwd3+sW759r+nyHGgbk6pl 6UkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=tZlaV2wFT6cinqhvzf/cN4IUBNss7U+As//vfUlCRLw=; b=FLe+zM1hYgjV39E5boBSlQPD8XJoOB/BCYtsrkBBzpOUNWSH1ZPg+k7jm4FQNtCKwf L53fvdtIEww0WNKLW/rvmFHgym8H+rvsJSA2Hv+M/0/TLP1vDRQNn9FGdr7z5k2pWUOy BCsBQvxyvhQWPhevoWn4bUNTHlvJ03iYAnlFmNEUGWpvSdcv5ZT28uxaBMpjoKvAVwwr ITgEk2tEihZU7NVCvNhU8P1r8X0Ctq+hIEuWkP8XGZ6AyQGMyhMXsLZTOwTbiFdKqt2q tkMa/XBsCo7Jra0hxTQxEJzwxhqPRjhtkQ6adc5MQBZGoM7qKdZu8HoE9u4T+pkRwTCa f8cA== X-Gm-Message-State: AIVw111/HeMD+5puDvJpWv6WtW7+ZnKsmhBHnp8zEjAjTR9Nz72h7ZGq Jp4FU7mDGJtU3DLHKIOMIzCFiZbEU08e5zc= X-Received: by 10.31.149.215 with SMTP id x206mr4281464vkd.83.1499548106928; Sat, 08 Jul 2017 14:08:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.152.80 with HTTP; Sat, 8 Jul 2017 14:08:06 -0700 (PDT) In-Reply-To: References: <2841386.K0mPqPZNK9@kitterma-e6430> From: Seth Blank Date: Sat, 8 Jul 2017 14:08:06 -0700 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a114267803cd5c70553d4c03a" Archived-At: Subject: Re: [dmarc-ietf] using selectors to identify sources X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jul 2017 21:08:30 -0000 --001a114267803cd5c70553d4c03a Content-Type: text/plain; charset="UTF-8" On Fri, Jul 7, 2017 at 11:29 PM, Murray S. Kucherawy wrote: > On Fri, Jul 7, 2017 at 11:12 PM, Seth Blank wrote: > >> Or maybe, put a different way, the question is: what's the simplest way, >> with the least delta to the spec, that allows for transmission of selectors >> and source ip? This would enable DMARC reports for messages delivered due >> to ARC to have the same report payload as messages delivered directly. >> > > I would suggest not specifying it at all, and letting implementations > figure out some private way to do it that works for them. > > To give a real example, OpenARC could put it in A-R or A-A-R if it wants > to, to be consumed downstream by OpenDMARC. But the ARC RFC doesn't have > to say that this is "the" way to do it. This is fine since RFC7601 says > anything else that ever sees an unknown ptype.property pairing ("header.s", > for example) is not supposed to use it. > I think it needs to be specified. Receivers construct DMARC reports in a known manner, they shouldn't need to guess how to get the appropriate information out of ARC headers in an intermediary-implementation-specific manner. The spec should make it unambiguous how information can be transmitted to the receivers in a consistent and interoperable manner. > -MSK > --001a114267803cd5c70553d4c03a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Jul 7, 2017 at 11:29 PM, Murray S. Kucherawy <superuser@gmail.com> wrote:
On Fri, Jul 7, 2017 at 11:12 PM, Seth Blank = <seth@sethblank.= com> wrote:
Or maybe, put a different way, the question is: what's the simplest wa= y, with the least delta to the spec, that allows for transmission of select= ors and source ip? This would enable DMARC reports for messages delivered d= ue to ARC to have the same report payload as messages delivered directly.

I would suggest= not specifying it at all, and letting implementations figure out some priv= ate way to do it that works for them.

To give a real exam= ple, OpenARC could put it in A-R or A-A-R if it wants to, to be consumed do= wnstream by OpenDMARC.=C2=A0 But the ARC RFC doesn't have to say that t= his is "the" way to do it.=C2=A0 This is fine since RFC7601 says = anything else that ever sees an unknown ptype.property pairing ("heade= r.s", for example) is not supposed to use it.
<= /blockquote>

I think it needs to be specified. Receivers= construct DMARC reports in a known manner, they shouldn't need to gues= s how to get the appropriate information out of ARC headers in an intermedi= ary-implementation-specific manner. The spec should make it unambiguous how= information can be transmitted to the receivers in a consistent and intero= perable manner.
=C2=A0
-MSK

--001a114267803cd5c70553d4c03a-- From nobody Sat Jul 8 21:25:14 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 159741242F7 for ; Sat, 8 Jul 2017 21:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l0kHJig9Uba9 for ; Sat, 8 Jul 2017 21:25:11 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::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 82924120454 for ; Sat, 8 Jul 2017 21:25:11 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id j53so38533771uaa.2 for ; Sat, 08 Jul 2017 21:25:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qSGxEBByK7BiN8nW+ntVmnEhWPPVUql0GTDO1KKiB2I=; b=i/A5am29IpSZzwIYEUMJDbLZafsxNgnomsrrZfWbxqtcvRrsBRsu5pjfK+MobJuq8z 34WDVYX2s1t4pAl98RT4SyNBry1sOASnqNdxeiemalSWwwBe5t1D1VrWjf67vBrl0DMa ucOJ8CF77iEG4FF1ZjsJlQGFYJZoqhwfXQn5w9vo/rdUpn5wsmxeTLnvMSSn5NOji6gL g/wwF2qElCtDwhgvGP930kFhT4fi2uIq5ImNjvbhmj49neFxq1H+B+oKcUkggENk52YZ qF95fIeZg/Z0xyy7cUDSsSFmcnRJtb4ZA/3e7ceDbbUOu1Px/W7NdNyugqSV7Z6vx7ks Wslw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qSGxEBByK7BiN8nW+ntVmnEhWPPVUql0GTDO1KKiB2I=; b=gwQ+KM8T2n8UH8zJuyPe5sBlDRTWdalJfQDP3wY+20caKjVd/1BH3b6kCs/yVLwy/J CFKW91NQcsSTjcCX9d6DjUnHa30RuLcmGThf/ptcjAXrmT7WawkWeOXM3otcXJZRoNA/ fzM5WgwdZUfcVL2cUPIu2ZWFepkMzhIbQPB4b36rVuRchFnuwel3lBP5j5VEsf0adfL4 KQQcmUHT64Hpv6Sg6iAwzXzTR6L/qynO3by1F4ZjJ7Ju2O4VHBcqaM6uNb21cLRh/24+ S5WN/gTHemSqOeq/SwGY3U+R61hwAcQ3pjUfBcsKss5Kytp2HRR1xhsHhWiljIKUqwrQ noog== X-Gm-Message-State: AIVw110SThOQAMg2u6ZzTjqpkrf1DfKJd2udRBfY1tSJm4W1SLyzTS8t rXbgJxPl2QuplQFk6GxNG6UkimHs1JGO X-Received: by 10.176.76.96 with SMTP id d32mr4347107uag.4.1499574310648; Sat, 08 Jul 2017 21:25:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.126.196 with HTTP; Sat, 8 Jul 2017 21:25:09 -0700 (PDT) In-Reply-To: References: <2841386.K0mPqPZNK9@kitterma-e6430> From: "Murray S. Kucherawy" Date: Sat, 8 Jul 2017 21:25:09 -0700 Message-ID: To: Seth Blank Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="f4030436153619bf260553dada98" Archived-At: Subject: Re: [dmarc-ietf] using selectors to identify sources X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jul 2017 04:25:13 -0000 --f4030436153619bf260553dada98 Content-Type: text/plain; charset="UTF-8" On Sat, Jul 8, 2017 at 2:08 PM, Seth Blank wrote: > On Fri, Jul 7, 2017 at 11:29 PM, Murray S. Kucherawy > wrote: > >> On Fri, Jul 7, 2017 at 11:12 PM, Seth Blank wrote: >> >>> Or maybe, put a different way, the question is: what's the simplest way, >>> with the least delta to the spec, that allows for transmission of selectors >>> and source ip? This would enable DMARC reports for messages delivered due >>> to ARC to have the same report payload as messages delivered directly. >>> >> >> I would suggest not specifying it at all, and letting implementations >> figure out some private way to do it that works for them. >> >> To give a real example, OpenARC could put it in A-R or A-A-R if it wants >> to, to be consumed downstream by OpenDMARC. But the ARC RFC doesn't have >> to say that this is "the" way to do it. This is fine since RFC7601 says >> anything else that ever sees an unknown ptype.property pairing ("header.s", >> for example) is not supposed to use it. >> > > I think it needs to be specified. Receivers construct DMARC reports in a > known manner, they shouldn't need to guess how to get the appropriate > information out of ARC headers in an intermediary-implementation-specific > manner. The spec should make it unambiguous how information can be > transmitted to the receivers in a consistent and interoperable manner. > So evidently we've got a conflict between what A-R was intended to be used for, and an apparent need to create a channel between ARC and DMARC to relay stuff like selectors and source IP addresses. If consensus exists that the need is real and in scope for this WG, we either need to come to consensus on allowing feature creep of A-R, or come up with another way to meet that need. With respect to the source IP in particular, we had that battle all the way up to a formal appeal to the IESG and that too was resolved with a decision that such details weren't appropriate for A-R. This resulted in what is now Appendix C of RFC7601, and the client IP address was left out. Also, assuming you're referring to the ARC base draft, I don't agree that "with the least delta to the spec" is a legitimate constraint here. -MSK --f4030436153619bf260553dada98 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Jul 8, 2017 at 2:08 PM, Seth Blank <seth@sethbla= nk.com> wrote:
On Fri, Jul 7, 2017 = at 11:29 PM, Murray S. Kucherawy <superuser@gmail.com> wro= te:
On Fri, Jul 7,= 2017 at 11:12 PM, Seth Blank <seth@sethblank.com> wrote:
Or maybe, put a different way, the questi= on is: what's the simplest way, with the least delta to the spec, that = allows for transmission of selectors and source ip? This would enable DMARC= reports for messages delivered due to ARC to have the same report payload = as messages delivered directly.

=
I would suggest not specifying it at all, and letting imp= lementations figure out some private way to do it that works for them.
<= br>
To give a real example, OpenARC could put it in A-R or A-A-R = if it wants to, to be consumed downstream by OpenDMARC.=C2=A0 But the ARC R= FC doesn't have to say that this is "the" way to do it.=C2=A0= This is fine since RFC7601 says anything else that ever sees an unknown pt= ype.property pairing ("header.s", for example) is not supposed to= use it.

I t= hink it needs to be specified. Receivers construct DMARC reports in a known= manner, they shouldn't need to guess how to get the appropriate inform= ation out of ARC headers in an intermediary-implementation-specific ma= nner. The spec should make it unambiguous how information can be transmitte= d to the receivers in a consistent and interoperable manner.

So evidently we've got a conf= lict between what A-R was intended to be used for, and an apparent need to = create a channel between ARC and DMARC to relay stuff like selectors and so= urce IP addresses.=C2=A0 If consensus exists that the need is real and in s= cope for this WG, we either need to come to consensus on allowing feature c= reep of A-R, or come up with another way to meet that need.

With respect to the source IP in particular, we had that battle all the = way up to a formal appeal to the IESG and that too was resolved with a deci= sion that such details weren't appropriate for A-R.=C2=A0 This resulted= in what is now Appendix C of RFC7601, and the client IP address was left o= ut.

Also, assuming you're referring to the ARC base d= raft, I don't agree that "with the least delta to the spec" i= s a legitimate constraint here.

-MSK
--f4030436153619bf260553dada98-- From nobody Sun Jul 9 00:20:28 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0597512F27D for ; Sun, 9 Jul 2017 00:20:28 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=iJoGpqf8; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Miyo0nnd 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 Xg5HBpHwbf3M for ; Sun, 9 Jul 2017 00:20:26 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA21112F274 for ; Sun, 9 Jul 2017 00:20:26 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 0DA37208C3; Sun, 9 Jul 2017 03:20:26 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Sun, 09 Jul 2017 03:20:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=NxQYyF9T+QyZEEm+NH OaG20bZi0tYEtcKVMzT3ne9n4=; b=iJoGpqf8yQi+iM+PyFxZwQhja8yKPCjF6j Z+IVVpNAJ9CbN7l4jz+qKobd4IuuebAgvwzFSaTUYTO4X8j7c+xUuA8c5mEDPB3J arSGObVdwdos7SS0R1XY8/tS68qoU4nQeGFuqvtPWsGrD8/NqGw2rlu44usPZ6l2 28s+9e3cT0Qq6+QYL2LSGx+NjWdRzLm3XC43yOuEMu8zjNq4Kou3VJjE2ySnRW/Z zMyLNwPvhebyejT5vwILoevNU4c9noCeh7VaIHL9hw/eacSjWzCY8HRoZHilLfG1 ExtjiBRYH5M79eVkMC0dEJE1fgA0rMCblB5ydDQ4jXWJq+/bES9Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=NxQYyF9T+QyZEEm+NHOaG20bZi0tYEtcKVMzT3ne9n4=; b=Miyo0nnd OTG/Euvji5RSzKiAM2Bw40+MpbKrXujHJTCrS16FzRWP/NdHMFUM2r2XLEJSUOEr BgcAHau/0P/d4VLxAyxBCNjKiu+XdH7MVw4tLsn6pWSM10o8cZC3SSIo02kh7pRN E1Ol77S2UNb7HGSQSERte+6lVedMosYh+QsOsH+ztKgunWUM4FD1pPgSwyrc3tni ClzCoFEjGrecRdDSIF3ey+CIHtaA6H3+q9hUs852mI4iQuNCf7vfkbMrwONkvAGe vjR0oJm8V/H4ad07jv5fssUlrazEKGib38uU3/yY0uAIiNjwGHahYYHsPj25S30N oKiFg5tWcqbLpg== X-ME-Sender: X-Sasl-enc: UvUm2NZq9AlHseUR8ctvAl2ShyPEE9nSvA9TStk3mSvQ 1499584825 Received: from [192.168.0.6] (cpc121086-nmal24-2-0-cust54.19-2.cable.virginm.net [77.97.145.55]) by mail.messagingengine.com (Postfix) with ESMTPA id A2E0A248A1; Sun, 9 Jul 2017 03:20:25 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPad Mail (14F89) In-Reply-To: <84047ca1-456c-1234-f416-ff08be69e076@crash.com> Date: Sun, 9 Jul 2017 08:44:37 +0100 Cc: dmarc@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <9E3A0EC4-4D0C-4F5B-AB5A-9CCE3D6F3C05@fastmail.fm> References: <20337b3e-be49-797c-2974-1e36bd9939e0@gmail.com> <20170707182932.gm3vhxluv3kcc35d@mx4.yitter.info> <09fd1486-c712-bd50-545c-9b694b3c79dc@crash.com> <20170707191251.dmnnyxgvlqf5niwf@mx4.yitter.info> <84047ca1-456c-1234-f416-ff08be69e076@crash.com> To: Steven M Jones Archived-At: Subject: Re: [dmarc-ietf] ARC RFC status to target X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jul 2017 07:20:28 -0000 > On 7 Jul 2017, at 20:50, Steven M Jones wrote: > > Perhaps the criteria would be included in the RFC, and the review would > be added to the WG's work items? I'm not sure how it's usually done... > Do Experimental RFCs ever get expiration dates as a forcing function, > the way Internet Drafts do? No expiration date by default. From nobody Sun Jul 9 09:24:28 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C3C8126C23 for ; Sun, 9 Jul 2017 09:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 Dk9FBQzrz3Ua for ; Sun, 9 Jul 2017 09:24:25 -0700 (PDT) Received: from mail.wordtothewise.com (mail.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id 30A351243F3 for ; Sun, 9 Jul 2017 09:24:25 -0700 (PDT) Received: from [IPv6:2001:470:1f05:33:d08b:2d82:5fb4:7f10] (unknown [IPv6:2001:470:1f05:33:d08b:2d82:5fb4:7f10]) by mail.wordtothewise.com (Postfix) with ESMTPSA id BA1F623379; Sun, 9 Jul 2017 09:24:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1499617484; bh=4S0rSRkcfMgSDTvVzllRuOc3cDWffzE+ZYfAqaNpjxg=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=LaUk5aYAG+05KVF9ANhb80jwJqm+Rw0Y+/hjfy4J9ZknTtcrW5VqsLpwHZ4kKXgH1 LAv0aoy63s/3FgnH/ab74mTP+o8C6E33oRkSSnh6VV/JjbYSdQas7mBI8oG0uYRcL1 nHfuKsDz3KJwEChyKFQeNrxwkpAi+CMp/ro1kIeQ= From: Laura Atkins Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_781EE2E9-50EE-4A0D-BA77-CF54B2C5071A" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sun, 9 Jul 2017 09:24:24 -0700 In-Reply-To: <367fc126-bba5-84f7-3c85-501290099c19@gmail.com> Cc: dmarc@ietf.org To: Dave Crocker References: <2841386.K0mPqPZNK9@kitterma-e6430> <563EC8DA-7EED-4E42-A926-8C5F3E6A1505@wordtothewise.com> <367fc126-bba5-84f7-3c85-501290099c19@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [dmarc-ietf] using selectors to identify sources X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jul 2017 16:24:26 -0000 --Apple-Mail=_781EE2E9-50EE-4A0D-BA77-CF54B2C5071A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 7, 2017, at 4:43 PM, Dave Crocker wrote: >=20 > On 7/7/2017 1:44 PM, Steve Atkins wrote: >> That a particular major ISP uses (or claims to use, or used to claim = to use) selectors to identify particular senders is (or was, or was and = continues to be) a major reason that some ESPs refuse to rotate keys at = all. >=20 > Then it would be helpful to the industry to attempt to get that ISP to = change it's behavior. I believe it=E2=80=99s no longer the case. There was quite a bit of work = done to convince them this was a bad idea. The ISP in question has also = changed hands and mail handling is being transferred to another backend.=20= But they were rather open about it for a while. Part of it was requiring = senders to pre-register selectors. laura=20 --=20 Having an Email Crisis? 800 823-9674=20 Laura Atkins Word to the Wise laura@wordtothewise.com (650) 437-0741 =09 Email Delivery Blog: http://wordtothewise.com/blog=09 --Apple-Mail=_781EE2E9-50EE-4A0D-BA77-CF54B2C5071A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jul 7, 2017, at 4:43 PM, Dave Crocker <dcrocker@gmail.com> = wrote:

On 7/7/2017 1:44 PM, Steve Atkins wrote:
That a particular major = ISP uses (or claims to use, or used to claim to use) selectors to = identify particular senders is (or was, or was and continues to be) a = major reason that some ESPs refuse to rotate keys at all.

Then it would be helpful to the = industry to attempt to get that ISP to change it's behavior.

I = believe it=E2=80=99s no longer the case. There was quite a bit of work = done to convince them this was a bad idea. The ISP in question has also = changed hands and mail handling is being transferred to another = backend. 

But they were rather = open about it for a while. Part of it was requiring senders to = pre-register selectors.

laura 

-- 
Having an Email Crisis? =  800 823-9674 

Laura Atkins
Word to the Wise
laura@wordtothewise.com
(650) = 437-0741 =

Email Delivery Blog: http://wordtothewise.com/blog =






= --Apple-Mail=_781EE2E9-50EE-4A0D-BA77-CF54B2C5071A-- From nobody Sun Jul 9 11:38:30 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41C18126DEE for ; Sun, 9 Jul 2017 11:38:29 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIYAhaOKF3-4 for ; Sun, 9 Jul 2017 11:38:27 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9869712EAAA for ; Sun, 9 Jul 2017 11:38:27 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id x187so59750016oig.3 for ; Sun, 09 Jul 2017 11:38:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=JL+Tx97AHPIIB9TNQW8jvFBkd+awKGdqzbr7ytIyQV4=; b=FxA0WMon4K/Xryoo+j/4MWnM7SnvLWrrDZrgBuIFHE4qyvt0Vn0T/p/bV4Xoloyh76 EV3afGSzpj0Io9NXP3MWDObUAHsrhjd09SIjTYb7hr5E8SJZ44iiarr1VpcKK+BOsF+l gTNWfAieSZIzjicQPGTZRU1ubCCH8YQ4mL/kABNNRxBM0PtB93jB/DW3s43R/W2xM/oB PQ43a6u6uw8lVWAaJ+gzWvadwEAgsOhWElf7tseWBGZVXhH1V7FiBI3AZwaTr0u7OCGV mp1hAhZz0FXDSrZkqIBi2zxcoaZenCxC1F+JG/LqI8fj2D/A7MAYJm0kSkexx2uuQtTV Nc9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=JL+Tx97AHPIIB9TNQW8jvFBkd+awKGdqzbr7ytIyQV4=; b=s77lZwEo8xySlSpJoH/jknfu408Z1worsqOpplzhm32F6Q36XWjXFpMFBzPnyOkYbs qqovpLErNI+lG5syRFv83iy40flKNd+RUbTjbhouA5LyA3f8BS+X6e6jOEQgtgBz0sIV M3sUBfSBWqebaiD+5yxeSf79eejC0ByTCEyqe44hT9vyhgVgJMxUfoSj04P9cyAAs0oG L7oEDWmUxAgqy4+jnR+qpdBsZLmWtPTsmZbwnKvRxsGLhhvh8LJt+tJzUUUWoPnIzBs/ XLTLiuEDjhf/spyOfF+NbZ+qSe05QCcK1RbAFBSExkDubCg8oFJUWknuj5Zb2EOsdSoF Kjlw== X-Gm-Message-State: AIVw112JR6WY3plca0entemb6F7m96HVj6RZtbBkKYZQLxPyr/qCdoR7 6lW7rBJJ2zIq+QZNL1c= X-Received: by 10.202.10.212 with SMTP id k81mr5575645oiy.100.1499625506706; Sun, 09 Jul 2017 11:38:26 -0700 (PDT) Received: from ?IPv6:2602:304:cda0:8800:d17e:7fe3:9cb7:7c98? ([2602:304:cda0:8800:d17e:7fe3:9cb7:7c98]) by smtp.gmail.com with ESMTPSA id a187sm12851852oii.13.2017.07.09.11.38.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 09 Jul 2017 11:38:25 -0700 (PDT) To: Laura Atkins Cc: dmarc@ietf.org References: <2841386.K0mPqPZNK9@kitterma-e6430> <563EC8DA-7EED-4E42-A926-8C5F3E6A1505@wordtothewise.com> <367fc126-bba5-84f7-3c85-501290099c19@gmail.com> From: Dave Crocker Message-ID: <786423ca-51da-e222-793e-1d13947c0866@gmail.com> Date: Sun, 9 Jul 2017 11:38:22 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] using selectors to identify sources X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jul 2017 18:38:29 -0000 On 7/9/2017 9:24 AM, Laura Atkins wrote: > Part of it was requiring senders to pre-register selectors. wow. that is (or, I guess, was) such a distinctly misguided understanding of the role of selectors that it's impressive. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun Jul 9 12:25:07 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B77D12ECCE for ; Sun, 9 Jul 2017 12:25:06 -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 xBySvJMHSIhW for ; Sun, 9 Jul 2017 12:25:04 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCC4D12ECC3 for ; Sun, 9 Jul 2017 12:25:04 -0700 (PDT) Received: from android-df929938bd25e485.home.kitterman.com (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id B1B85C4005E; Sun, 9 Jul 2017 14:25:02 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1499628302; bh=DwFQf5XaPFhF5MNKP5qUlJidiP9q/Mh216t1ti28i6k=; h=Date:In-Reply-To:References:Subject:To:From:From; b=dbG975+Qy3lkL8a2kawVDr8MI0hOCgiW6GPoy8yT4KjiVtpcnp823NzqIp+AHijhL BHjOjjRlPwqVr4+U8u1OHxEzxWtKb1g4rothfvRMNYjUy43n6msFTOa4UBhJOLroLu fwDw+JufwfKeo1js+49cKOdOQmYsLQVypifO0Zro= Date: Sun, 09 Jul 2017 19:24:58 +0000 In-Reply-To: <786423ca-51da-e222-793e-1d13947c0866@gmail.com> References: <2841386.K0mPqPZNK9@kitterma-e6430> <563EC8DA-7EED-4E42-A926-8C5F3E6A1505@wordtothewise.com> <367fc126-bba5-84f7-3c85-501290099c19@gmail.com> <786423ca-51da-e222-793e-1d13947c0866@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dmarc@ietf.org From: Scott Kitterman Message-ID: Archived-At: Subject: Re: [dmarc-ietf] using selectors to identify sources X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jul 2017 19:25:06 -0000 On July 9, 2017 2:38:22 PM EDT, Dave Crocker wrote: >On 7/9/2017 9:24 AM, Laura Atkins wrote: >> Part of it was requiring senders to pre-register selectors=2E > > >wow=2E that is (or, I guess, was) such a distinctly misguided=20 >understanding of the role of selectors that it's impressive=2E > >d/ In the early days of SPF/Sender ID there was one major free webmail provid= er that had such an odd implementation that if your SPF record wasn't alrea= dy in their DNS cache, the check would inevitably time out and fail=2E The= ir solution was to provide a method for domain owners to manually submit "m= issing" records=2E There's no end to the inventiveness of such entities=2E Scott K From nobody Sun Jul 9 17:20:42 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B20B712F4B2 for ; Sun, 9 Jul 2017 17:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwKWECCJBNeV for ; Sun, 9 Jul 2017 17:20:38 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::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 7684512EC46 for ; Sun, 9 Jul 2017 17:20:38 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id 191so62591027oii.2 for ; Sun, 09 Jul 2017 17:20:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Los7ZrVRc/1+06VcAQYiMIOECQIcnia0IVCIHgAHu1s=; b=mn+GkvcReI85OWJgUhVRVg7nj3tR9My3QmBvoduTdlv5uS6Qj8gL2P0hPLOC75oCWw DESzyk5TNG7SxCRp7fg1zXOKdHFZinsgsFoq1ClLDYsXAJ4yvel6pljn8URBsHciJ32Q lsUh0r2dYr4RDY7tQ3FI7tOrzukMLnak47yCcs+4uYDdtQ/mWPbF9F/Tlx81OcYBWHoK 54jIVUzBE2MKmEPkf6whRiWRuLLLXCFw1yPcOCuDYNT0bZC3du24g2KNq3BA7cg2mUSK QO/Bh8tZ9WyymaSYznIqV4teRSY9nSSojvpZBL+w/Ea2Urn2PR+/GPuHKZkEWZMyAQ/7 eO0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Los7ZrVRc/1+06VcAQYiMIOECQIcnia0IVCIHgAHu1s=; b=UllnqLw3rhQoLvzRK4NGMfZgpmK+f3NQw95SVB28qGCdXLiq1MdPds/ukjG8U5JQ+f tjHSiFvEVlZ4QFrezKlhZJBL9ndAcBWsfFWs6js79PegGcPzgIPSeCJ0IhAL/ImrVBJm M2buU1VJ76/ZCVmsN8k81aK0TcG4evwzvaG5C3W7s8B19cIiveMyJ6EJqZAWCXzFk9M6 5nkuWCDvJsTku+WSXIbNLig9e5yfmhUi2qLWRP+XhFMsU7GiMgFn9wNw51RejamDAwfC VhOEzk82yHuxax4TB0NNAiBIUx2Q3Wf17ROl5EGAp5UOTl5XVRlU/BYURz8gwuWfPD6O h0oQ== X-Gm-Message-State: AIVw1100ZAYARUBgUSPZmmWU8xB+x932gUhzLP2bwgYgEG3Fp8d5VRVH VE8fUd+AdEuTID5nW28/zuAPysocEO7F X-Received: by 10.202.193.133 with SMTP id r127mr6690269oif.117.1499646037385; Sun, 09 Jul 2017 17:20:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.131.17 with HTTP; Sun, 9 Jul 2017 17:20:36 -0700 (PDT) Received: by 10.74.131.17 with HTTP; Sun, 9 Jul 2017 17:20:36 -0700 (PDT) In-Reply-To: References: <2841386.K0mPqPZNK9@kitterma-e6430> From: Brandon Long Date: Sun, 9 Jul 2017 17:20:36 -0700 Message-ID: To: "Murray S. Kucherawy" Cc: Seth Blank , dmarc@ietf.org Content-Type: multipart/alternative; boundary="001a113dbd7c5969460553eb8d71" Archived-At: Subject: Re: [dmarc-ietf] using selectors to identify sources X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 00:20:41 -0000 --001a113dbd7c5969460553eb8d71 Content-Type: text/plain; charset="UTF-8" Can someone send a pointer the archive for the ip question for spf? I'd love to read about it. Brandon On Jul 8, 2017 9:25 PM, "Murray S. Kucherawy" wrote: > On Sat, Jul 8, 2017 at 2:08 PM, Seth Blank wrote: > >> On Fri, Jul 7, 2017 at 11:29 PM, Murray S. Kucherawy > > wrote: >> >>> On Fri, Jul 7, 2017 at 11:12 PM, Seth Blank wrote: >>> >>>> Or maybe, put a different way, the question is: what's the simplest >>>> way, with the least delta to the spec, that allows for transmission of >>>> selectors and source ip? This would enable DMARC reports for messages >>>> delivered due to ARC to have the same report payload as messages delivered >>>> directly. >>>> >>> >>> I would suggest not specifying it at all, and letting implementations >>> figure out some private way to do it that works for them. >>> >>> To give a real example, OpenARC could put it in A-R or A-A-R if it wants >>> to, to be consumed downstream by OpenDMARC. But the ARC RFC doesn't have >>> to say that this is "the" way to do it. This is fine since RFC7601 says >>> anything else that ever sees an unknown ptype.property pairing ("header.s", >>> for example) is not supposed to use it. >>> >> >> I think it needs to be specified. Receivers construct DMARC reports in a >> known manner, they shouldn't need to guess how to get the appropriate >> information out of ARC headers in an intermediary-implementation-specific >> manner. The spec should make it unambiguous how information can be >> transmitted to the receivers in a consistent and interoperable manner. >> > > So evidently we've got a conflict between what A-R was intended to be used > for, and an apparent need to create a channel between ARC and DMARC to > relay stuff like selectors and source IP addresses. If consensus exists > that the need is real and in scope for this WG, we either need to come to > consensus on allowing feature creep of A-R, or come up with another way to > meet that need. > > With respect to the source IP in particular, we had that battle all the > way up to a formal appeal to the IESG and that too was resolved with a > decision that such details weren't appropriate for A-R. This resulted in > what is now Appendix C of RFC7601, and the client IP address was left out. > > Also, assuming you're referring to the ARC base draft, I don't agree that > "with the least delta to the spec" is a legitimate constraint here. > > -MSK > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --001a113dbd7c5969460553eb8d71 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Can someone send a pointer the archive for the ip questio= n for spf?=C2=A0 I'd love to read about it.

=
Brandon

On Jul 8, 2017 9:25 PM, "Murray S. Kucherawy"= <superuser@gmail.com> wro= te:
On Sat, Jul 8, 2017 at 2:08 PM, Seth Blank <seth@sethblank.com>= wrote:
On Fri, Jul 7, 2017 at 11:29 PM, Murray S. Ku= cherawy <superuser@gmail.com> wrote:
On Fri, Jul 7, 2017 at 11:12 PM, Seth = Blank <seth@sethblank.com> wrote:
Or maybe, put a different way, the question is: what's the si= mplest way, with the least delta to the spec, that allows for transmission = of selectors and source ip? This would enable DMARC reports for messages de= livered due to ARC to have the same report payload as messages delivered di= rectly.

I woul= d suggest not specifying it at all, and letting implementations figure out = some private way to do it that works for them.

To give a = real example, OpenARC could put it in A-R or A-A-R if it wants to, to be co= nsumed downstream by OpenDMARC.=C2=A0 But the ARC RFC doesn't have to s= ay that this is "the" way to do it.=C2=A0 This is fine since RFC7= 601 says anything else that ever sees an unknown ptype.property pairing (&q= uot;header.s", for example) is not supposed to use it.

I think it needs to be spec= ified. Receivers construct DMARC reports in a known manner, they shouldn= 9;t need to guess how to get the appropriate information out of ARC headers= in an intermediary-implementation-specific manner. The spec should ma= ke it unambiguous how information can be transmitted to the receivers in a = consistent and interoperable manner.

So evidently we've got a conflict between what A-R wa= s intended to be used for, and an apparent need to create a channel between= ARC and DMARC to relay stuff like selectors and source IP addresses.=C2=A0= If consensus exists that the need is real and in scope for this WG, we eit= her need to come to consensus on allowing feature creep of A-R, or come up = with another way to meet that need.

With respect to the s= ource IP in particular, we had that battle all the way up to a formal appea= l to the IESG and that too was resolved with a decision that such details w= eren't appropriate for A-R.=C2=A0 This resulted in what is now Appendix= C of RFC7601, and the client IP address was left out.

Al= so, assuming you're referring to the ARC base draft, I don't agree = that "with the least delta to the spec" is a legitimate constrain= t here.

-MSK

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

--001a113dbd7c5969460553eb8d71-- From nobody Sun Jul 9 18:26:09 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D48A5131461 for ; Sun, 9 Jul 2017 18:26:06 -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 XhPNQLF6_HZi for ; Sun, 9 Jul 2017 18:26:05 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5D31126D05 for ; Sun, 9 Jul 2017 18:26:04 -0700 (PDT) Received: from android-df929938bd25e485.home.kitterman.com (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 0FCCDC4005E; Sun, 9 Jul 2017 20:26:02 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1499649962; bh=RpHLmH2CnmU/PogyzNIHeH806Igk7fEhFMKRABn/obY=; h=Date:In-Reply-To:References:Subject:To:From:From; b=ucjEID9S3WQ4rkjBjOy6eHNDt6ye9FCFW07clCb4EPguq1gvn3GVB1fvNo57/GREX ao7g3Phb926ktw0UC7Gv5Xhv/7KQZvKQZIRFOJV5yyTep41oOfUCI87GcZxxHBj7hV 9BrsdKgHq1zjkXMb0/3OZ+b6J+d5IRagFFWPj0ic= Date: Mon, 10 Jul 2017 01:26:00 +0000 In-Reply-To: References: <2841386.K0mPqPZNK9@kitterma-e6430> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dmarc@ietf.org From: Scott Kitterman Message-ID: <21971B88-59C1-4F81-B23D-486F9A61F095@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] authentication results archeology X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 01:26:07 -0000 This isn't a bad place to start: http://mipassoc=2Eorg/pipermail/mail-vet-discuss/2009q1/000570=2Ehtml Scott K On July 9, 2017 8:20:36 PM EDT, Brandon Long wrote: >Can someone send a pointer the archive for the ip question for spf?=20 >I'd >love to read about it=2E > >Brandon From nobody Mon Jul 10 00:27:23 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1776C128768 for ; Mon, 10 Jul 2017 00:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 Gx18hDDOcXLL for ; Mon, 10 Jul 2017 00:27:21 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01800126B72 for ; Mon, 10 Jul 2017 00:27:20 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id 191so42302724vko.2 for ; Mon, 10 Jul 2017 00:27:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/pMNtoP6A5AlTVhGra7HqyX4xZhxVpcuoBD4Pa6Q3tU=; b=KEYsimxvHGIDKcnEkwiCIYnY/iaQ0SIygkllAuaJQI93c2ZYnLD5iyE8sKK/h/dECI 47VvYnjqynA6KSRfUc+BWgZZj9yP+G/9dA0om3QhHlpQjPzgog1g5kKcl1CLkU8YQ51B +RRg6AQ9YXoS2Fl2n1Ig0hVNgOO1oYODKZhF4el/Ftk+L2scmp6UAeRdE8W6XCEFeMGn bbsSOePDXsdJpNhRaPeuiTNmQEcjhF2QhMjAgv844pWQH3Ohr4QfW9pfau6wTEwiLYTS zw4xxekceAKMMSexQRkMSwUm2/Gvo23pp4hImaZLRqUhKXVBCMo+ceG/z7cE7IQXti5Q aEYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/pMNtoP6A5AlTVhGra7HqyX4xZhxVpcuoBD4Pa6Q3tU=; b=Ycdsqxp8oghxaMF6HXeDIe037MO/wCVpYHbcS0h814LrFZIUHkWNiwffYFaM8d6qnT MaeWCqobKJ/27HA/e8ZEp5DwDfq9bdHtCCUOnjkTCeYuOhA7lXl1iHbmwv5H45kLoCtN VkI9+Hhkxn/Rh+zBZ6LIl/OuGdEEVPUdhNwpxZHZlWBijth2l+NAarL/1QsKNBX/QWgm nCdk/Bl6+pUJrHtRjkAm3nE25EVO+K9wbAyRyObqmERsdyG+j0NvUtsF89aJtVDzbXIc I46skHsVx50lKjdozoxg/48A1LAFtMHe19i1mxgBrgWLyso90e1M7PxLRsz5TdjLn5j/ oVEA== X-Gm-Message-State: AIVw111NakEGW2Zhn9/79pfGYnAXcybh+L76Q8E1uDyQHg+l11DVTFFv 8XpPbTrZFhSQtVYQB6Ux1MefrVXJ6FA3 X-Received: by 10.31.136.9 with SMTP id k9mr6778076vkd.50.1499671639995; Mon, 10 Jul 2017 00:27:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.126.196 with HTTP; Mon, 10 Jul 2017 00:27:19 -0700 (PDT) In-Reply-To: References: <2841386.K0mPqPZNK9@kitterma-e6430> From: "Murray S. Kucherawy" Date: Mon, 10 Jul 2017 00:27:19 -0700 Message-ID: To: Seth Blank Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a11441d7461b9510553f18364" Archived-At: Subject: Re: [dmarc-ietf] using selectors to identify sources X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 07:27:22 -0000 --001a11441d7461b9510553f18364 Content-Type: text/plain; charset="UTF-8" On Sat, Jul 8, 2017 at 2:08 PM, Seth Blank wrote: > I think it needs to be specified. Receivers construct DMARC reports in a > known manner, they shouldn't need to guess how to get the appropriate > information out of ARC headers in an intermediary-implementation-specific > manner. The spec should make it unambiguous how information can be > transmitted to the receivers in a consistent and interoperable manner. > How do receivers include the source IP address in DMARC records today, when A-R doesn't give it to them? -MSK --001a11441d7461b9510553f18364 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Jul 8, 2017 at 2:08 PM, Seth Blank <seth@sethbla= nk.com> wrote:
I think it ne= eds to be specified. Receivers construct DMARC reports in a known manner, t= hey shouldn't need to guess how to get the appropriate information out = of ARC headers in an intermediary-implementation-specific manner. The spec = should make it unambiguous how information can be transmitted to the receiv= ers in a consistent and interoperable manner.

How do receivers include the source IP address in DMAR= C records today, when A-R doesn't give it to them?

-M= SK
--001a11441d7461b9510553f18364-- From nobody Mon Jul 10 08:53:29 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE0BE129AD7 for ; Mon, 10 Jul 2017 08:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bweVky_CoRHh for ; Mon, 10 Jul 2017 08:53:24 -0700 (PDT) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58F05129AD1 for ; Mon, 10 Jul 2017 08:53:24 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id w19so57445666uac.0 for ; Mon, 10 Jul 2017 08:53:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:from:date:message-id:subject:to; bh=L5VFQBfcAsBbA5HibXEx0uHtvlV+9pNLsE053+xekxE=; b=bZPoXJp3KnmOKcjHSWD/XCOgXsavnl84kGaQHknqNBxhy1E0TMazwCimWH1BW13mXV UXl0LURLREJVWj0xsaVvsekxB15x/eNSg1UhF32xkk/dMEopSWmQw76700TeQBFqUFcI R7pD4rqFiUcmh460En3GvturqqBrwm/Ov4J84= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=L5VFQBfcAsBbA5HibXEx0uHtvlV+9pNLsE053+xekxE=; b=i2Yi7ATil5Rhy3KJr5TDWtvJmUehhNXv/J1pCLF6feIWw09x3k4FPYeohK+gyRkGPu nLO1EZa7BW1WCryJ9CpIhJbyS/xASuYNxwCt0MVRE8wI2VS6HUeXyal4uhiCTxtBqhC6 9UDxjGP65vXRsxf0Gdos42PotXoNTJ/0NPOw19U0PEDnwttNwI4EtXwQGgMtHwmJrWVA QBFvVRLI7H0DmaLfFdqtV0MIvx5K9y55g7bU+kQvbH0XN1LaJf0aEBa6AT+UCPMUdHS8 dG8HI/mYciwf5qXNOij9ftP62/CmHLtPISbGgXEc1hN9Iphmiei/GHA+BckTnn/Y2BEn t+KQ== X-Gm-Message-State: AIVw110MzfDTKwbO5NWt3ztxCmKqJrM/+8QKf84yZygZnFpHVKtPjHUI u3CQALWjSE4F2q4ayvFcRaJZ8rYhdtkgoSfO5Q== X-Received: by 10.159.59.220 with SMTP id y28mr8993916uah.12.1499702003101; Mon, 10 Jul 2017 08:53:23 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.176.71.204 with HTTP; Mon, 10 Jul 2017 08:53:22 -0700 (PDT) From: "Kurt Andersen (b)" Date: Mon, 10 Jul 2017 08:53:22 -0700 X-Google-Sender-Auth: agK1W8RhmGK3iBnSX4vHtfAJruU Message-ID: To: "dmarc@ietf.org" , ARC Discussion Content-Type: multipart/alternative; boundary="94eb2c0e9a902a945f0553f895c6" Archived-At: Subject: [dmarc-ietf] IETF99 hackathon, interop, and F2F meetings X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 15:53:27 -0000 --94eb2c0e9a902a945f0553f895c6 Content-Type: text/plain; charset="UTF-8" For those on the list, but not planning to attend IETF99 next week in Prague, I wanted to let you know about a couple of activities which are planned: 1) Hackathon - Saturday (July 15: 0800 - 2100 CEST) and Sunday (July 16: 0900 - 1330 CEST); project details can be seen at https://www.ietf.org/registration/MeetingWiki/wiki/99hackathon 2) DMARC WG meeting and DCRUP (DKIM Crypto Update) meetings starting at 2017-07-20 0930 CEST with remote participation information available at https://datatracker.ietf.org/meeting/99/agenda.html#2017-07-20-083000 Our plan coming out of the F2F meeting is to have a final set of changes identified for the ARC protocol which will allow us to move to last call once they have been integrated. --Kurt --94eb2c0e9a902a945f0553f895c6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For those on the list, but not planning to attend IETF99 n= ext week in Prague, I wanted to let you know about a couple of activities w= hich are planned:

1) Hackathon - Saturday (July 15: 0800= - 2100 CEST) and Sunday (July 16: 0900 - 1330 CEST); project details can b= e seen at=C2=A0https://www.ietf.org/registration/MeetingWiki/wiki/99hackath= on

2) DMARC WG meeting and DCRUP (DKIM Crypto = Update) meetings starting at 2017-07-20 0930 CEST with remote participation= information available at=C2=A0https://datatracker.ietf.org/meeting/= 99/agenda.html#2017-07-20-083000

Our plan comi= ng out of the F2F meeting is to have a final set of changes identified for = the ARC protocol which will allow us to move to last call once they have be= en integrated.

--Kurt
--94eb2c0e9a902a945f0553f895c6-- From nobody Mon Jul 10 12:48:58 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7881E131897 for ; Mon, 10 Jul 2017 12:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZsnDPq2Y95TE for ; Mon, 10 Jul 2017 12:48:55 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003: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 AEA6012EC0C for ; Mon, 10 Jul 2017 12:48:55 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id l130so84262281oib.1 for ; Mon, 10 Jul 2017 12:48:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qmWT+ypu92uxOxtGFGvaXJTeHyVu0A769XsRt5oAilE=; b=ljnd9vqDboPg1/mHwwE8AJQBLTSsfrpDLq2DU+gSNqn10FHLobcggtWfxTOa17sVCj RyTPC7cuKP1Vzg8r7A49kWr/7FicGj+LNobBO1+0PLORuSuHAiRk5tn6FLVZhxpJHC+m J7W6BgmKWohQ/56W2ILNc4B0wMq8SodLRUZfUnWNctfpd6f7+rDEqvoR1HBCmVL4aYY9 ucVl/jL8NRbD/Hut9rbbEzapLMvJ7ewIfw5aqx96Nr2V7m0QNYUv9K9+U5Mj6lrhyocd gZn7388Q7wARC3dFMSMm1i734yWI2AS2p2jCqzMKw80chtryvwURbyYR6g58cRktHqMy XZUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qmWT+ypu92uxOxtGFGvaXJTeHyVu0A769XsRt5oAilE=; b=ej8Y/8oQMu1CJRfTQiBR4/ouEy7RGLhqMguvZzLldk7hTjcso+i+I82wPO7fDLgJLh FV6jQR5Ye6dzNgLOLKwmOLBCLFiz3l3GOPd6F1iIMsrmiqEvVkiMY49hBdYV1MdciwaZ /z9aM4YIAP3g4T/Q5691XA6H0nIZA+weu0irFmx7R8G2RnzrBojB8qItXuPNp8mfk8RR umBlfUAJ7oRfbFsGv++1CZaJbVP2QCPUpvompHGBWUPGS/1lnxIhBNv7jo80obqHA3PT 7rmZ77BIXhQImFW7vNqR6/9RKSVGgh0Zr/rq3yhVlzv5OXDRzY+SCJp+gSJkjLXzf7vU pUfg== X-Gm-Message-State: AIVw113vZ6AlyKJZcCo/TlvIxsW56QRG8kkNKbWfNky23vczzEP/TsHH 13OvBRMJ6f5WgWUqbgE4avcMuspHqGHLYEQ= X-Received: by 10.202.69.197 with SMTP id s188mr9162909oia.148.1499716134656; Mon, 10 Jul 2017 12:48:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.131.17 with HTTP; Mon, 10 Jul 2017 12:48:53 -0700 (PDT) In-Reply-To: References: <2841386.K0mPqPZNK9@kitterma-e6430> From: Brandon Long Date: Mon, 10 Jul 2017 12:48:53 -0700 Message-ID: To: "Murray S. Kucherawy" Cc: Seth Blank , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a113dd3be7910660553fbdfe9" Archived-At: Subject: Re: [dmarc-ietf] using selectors to identify sources X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 19:48:57 -0000 --001a113dd3be7910660553fbdfe9 Content-Type: text/plain; charset="UTF-8" On Mon, Jul 10, 2017 at 12:27 AM, Murray S. Kucherawy wrote: > On Sat, Jul 8, 2017 at 2:08 PM, Seth Blank wrote: > >> I think it needs to be specified. Receivers construct DMARC reports in a >> known manner, they shouldn't need to guess how to get the appropriate >> information out of ARC headers in an intermediary-implementation-specific >> manner. The spec should make it unambiguous how information can be >> transmitted to the receivers in a consistent and interoperable manner. >> > > How do receivers include the source IP address in DMARC records today, > when A-R doesn't give it to them? > I think this highlights the challenge we're having with this conversation. Today, DMARC reports only contain information about the current hop where the report is being generated. Obviously, at the current hop, any information available to that hop, such as IP and selectors, can be logged directly for generating the report. We're talking about how, with ARC, we want to include information in the DMARC report from the previous hops. The best way to pass information from previous hops is through the AAR. It might be possible to parse the Received headers for IPs, or extract the selectors by walking the header.b information that is in the AAR headers, but obviously being more direct is preferred. Brandon --001a113dd3be7910660553fbdfe9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jul 10, 2017 at 12:27 AM, Murray S. Kucherawy <superuser@gma= il.com> wrote:
On Sat, Jul 8, 2017 at 2:08 PM, Seth Blank <seth@s= ethblank.com> wrote:
<= /span>I think it needs to be specified. Receivers construct DMARC reports i= n a known manner, they shouldn't need to guess how to get the appropria= te information out of ARC headers in an intermediary-implementation-sp= ecific manner. The spec should make it unambiguous how information can be t= ransmitted to the receivers in a consistent and interoperable manner.
=

How do receivers includ= e the source IP address in DMARC records today, when A-R doesn't give i= t to them?

I think = this highlights the challenge we're having with this conversation.

Today, DMARC reports only contain information about th= e current hop where the report is being generated.

Obviously,= at the current hop, any information available to that hop, such as IP and = selectors, can be logged directly for generating the report.

= We're talking about how, with ARC, we want to include information in th= e DMARC report from the previous hops.=C2=A0 The best way to pass informati= on from previous hops is through the AAR.

It might= be possible to parse the Received headers for IPs, or extract the selector= s by walking the header.b information that is in the AAR headers, but obvio= usly being more direct is preferred.

Brandon
=
--001a113dd3be7910660553fbdfe9-- From nobody Mon Jul 10 12:53:43 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B666F13189D for ; Mon, 10 Jul 2017 12:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TAWVIBoGUXxi for ; Mon, 10 Jul 2017 12:53:39 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A392C12EC0C for ; Mon, 10 Jul 2017 12:53:39 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id l130so84369349oib.1 for ; Mon, 10 Jul 2017 12:53:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=186QriV4E0P/Bma1GJiVOI6UfeZzyzaUDg6JUwcReNM=; b=m+RwaLLe9ZQn64D8XmmtG5VjU1lK/lHKLlmMGtldvkk2N2fYeSSqTrtyVFZI6rz5+f KsFyBBBo2o2WFUALkiE9SqCx3Bys//wRfwOm6j5KgJK6hgm220+RF2qt+pCr48p4Tdum +3kbaQfPv63svYWTlkiu9yPuin3PFhrdLVkDzc/pwEyxfF3naXIN3WSYMdIEX1FQU+W6 8SgAZ2V3MGCbQaWa6J3okIw95fLysLuPO6ado6Vk+3EcznPeD6e7m+RoqImnb6Qk2VT6 h5zZWjNkFB51JniRRWm3nIuoyUjeQRk5qnXbC1i+XH1n3EG0kc4DmWmuYtTpvPUtYgVM tTVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=186QriV4E0P/Bma1GJiVOI6UfeZzyzaUDg6JUwcReNM=; b=UmCOBLcjLy5hz4S9PjZjHCS+nLxRX5UjOHq/ZR7BvoyvKeMvlD2Jyq3QqlnBLbuBQS ZR/3CRbDlUSdjX51a8heR0XwEi5IYdoLsm/O4mTAc6rQ38vil2YmYemSwzycHMK37kCe SYLzZ7yJvzpb5G0VmN0xFf/RCHBve5iHtFLJh+EGW3QE2igid4DNt19HI0OSC/sW67It pYmlqouX8BOvtp/iLWeD+nCvLTCbyN8jg/stn+fZyf+56CccXeHbgjxln8EOoCFGAUFA t1KnMuZUVQo+WYtI563P0ylvB1nIcfVASU3O07fIleH4HCDD7lp8fJHoPhL43dRaAAQt YK+g== X-Gm-Message-State: AIVw112Oki5Jgl7kHMnDSExAOZHDlR6pM7UEglsFALOsjw0GZBivAPLc 2Gs0k8/J7/MEZa8utmgEnvq4ArYb8C4vSEc= X-Received: by 10.202.212.65 with SMTP id l62mr10413147oig.65.1499716418723; Mon, 10 Jul 2017 12:53:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.131.17 with HTTP; Mon, 10 Jul 2017 12:53:38 -0700 (PDT) In-Reply-To: References: From: Brandon Long Date: Mon, 10 Jul 2017 12:53:38 -0700 Message-ID: To: Tim Draegen Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a113df3e66768d50553fbf08d" Archived-At: Subject: Re: [dmarc-ietf] using selectors to identify sources X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 19:53:42 -0000 --001a113df3e66768d50553fbf08d Content-Type: text/plain; charset="UTF-8" On Fri, Jul 7, 2017 at 6:12 AM, Tim Draegen wrote: > On Jul 5, 2017, at 6:33 PM, Murray S. Kucherawy > wrote: > > Based on discussions with Seth and Gene earlier, it sounds like the > industry has sadly not taken up the habit of key and selector rotation, and > instead the pairing of "s=" and "d=" now identifies a single source. > Ignoring the obvious security problem this introduces, we're now talking > about implicitly formalizing this tuple as identifying a source. This > contradicts that original intent. In particular, if one were to develop > reputation in this way, then a key being rotated out takes the reputation > with it; signers would have to establish some procedure for doing so with > substantial overlap so that the new key can be "warmed". Worse, in an > emergency where a key is compromised, that tuple's reputation irretrievably > suffers. > > How is this better than encouraging the industry to adopt the separation > of functions that was originally intended? > > > I just caught up on the "selectors in AAR" thread, but wanted to go back > to this early statement about key rotation and pairing of "s=" and "d=" to > identify a single source. Thus a new Subject: is born. > > It's true key rotation is rare. People are figuring out how to do it, > though. Due to the size and scope of email's installed base, it takes a > really long time for the knowledge to slosh around the Internet. Using > multiple CNAMEs, delegating sub-domains, even out-sourcing all things > _domainkey.* is possible. Unfortunately there isn't good guidance on the > pros and cons of each way, and so people implement quick and dirty 'cause > they don't know any better. > > Using selectors to identify a single source of email isn't right, IMO. > Given the way things play out, once people are told that selectors are > important because they're used to identify sources of email (doesn't even > matter how true it is), then we'll be stuck with selectors being a > component of reputation. People will make do with what they've got. > > If nature abhors a vacuum, the missing piece is "what identifies a > source?". Selectors might fill that hole unless real guidance is provided. > > Using sub-domains to differentiate services works nicely. Today lack of > clear guidance means a Domain Owner has to deal with a mashup of different > ways to integrate with 3rd party senders. 3rd party senders make do with > what they've got, and that is often very constrained. > > Maybe such guidance should go into the "Usage Guide". Declaring which > parts of the DMARC puzzle should be used to build reputation system seems > pretty important if interoperability is the goal. > But selectors do identify a source, to some extent. Even with rotation, if I hand out a key to some service or just give them a couple CNAMES, its obvious that's a different source than another. And it's that ability we're talking about using with DMARC reporting and the companies trying to get folks to p=reject. Yes, building reputation on selectors is a really bad idea when it comes to rotation. I'm sure we can all figure out how to handle rotation to ramp slowly to work around that, but that seems like an insane extra step to add to something that is already too hard for most folks to do as often as they should. Brandon --001a113df3e66768d50553fbf08d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Jul 7, 2017 at 6:12 AM, Tim Draegen <tim@eudaemon.net> wrote:
On Jul 5, 2017, at 6:33 PM, Mur= ray S. Kucherawy <superuser@gmail.com> wrote:

Based on discussions with Seth and Gene e= arlier, it sounds like the industry has sadly not taken up the habit of key= and selector rotation, and instead the pairing of "s=3D" and &qu= ot;d=3D" now identifies a single source.=C2=A0 Ignoring the obvious se= curity problem this introduces, we're now talking about implicitly form= alizing this tuple as identifying a source.=C2=A0 This contradicts that ori= ginal intent.=C2=A0 In particular, if one were to develop reputation in thi= s way, then a key being rotated out takes the reputation with it; signers w= ould have to establish some procedure for doing so with substantial overlap= so that the new key can be "warmed".=C2=A0 Worse, in an emergenc= y where a key is compromised, that tuple's reputation irretrievably suf= fers.

How is this better than encouraging the industry to adopt= the separation of functions that was originally intended?

I just caught up on the "selectors in AAR"= thread, but wanted to go back to this early statement about key rotation a= nd pairing of "s=3D" and "d=3D" to identify a single so= urce. Thus a new Subject: is born.

It's true k= ey rotation is rare. People are figuring out how to do it, though. Due to t= he size and scope of email's installed base, it takes a really long tim= e for the knowledge to slosh around the Internet. Using multiple CNAMEs, de= legating sub-domains, even out-sourcing all things _domainkey.* is possible= . Unfortunately there isn't good guidance on the pros and cons of each = way, and so people implement quick and dirty 'cause they don't know= any better.

Using selectors to identify a single = source of email isn't right, IMO. Given the way things play out, once p= eople are told that selectors are important because they're used to ide= ntify sources of email (doesn't even matter how true it is), then we= 9;ll be stuck with selectors being a component of reputation. People will m= ake do with what they've got.

If nature abhors= a vacuum, the missing piece is "what identifies a source?". Sele= ctors might fill that hole unless real guidance is provided.

=
Using sub-domains to differentiate services works nicely. Today = lack of clear guidance means a Domain Owner has to deal with a mashup of di= fferent ways to integrate with 3rd party senders. 3rd party senders make do= with what they've got, and that is often very constrained.
<= br>
Maybe such guidance should go into the "Usage Guide"= ;. Declaring which parts of the DMARC puzzle should be used to build reputa= tion system seems pretty important if interoperability is the goal.

But selectors do identify a source, to= some extent.=C2=A0 Even with rotation, if I hand out a key to some service= or just give them a couple CNAMES, its obvious that's a different sour= ce than another.=C2=A0 And it's that ability we're talking about us= ing with DMARC reporting and the companies trying to get folks to p=3Drejec= t.

Yes, building reputation on selectors is a real= ly bad idea when it comes to rotation.=C2=A0 I'm sure we can all figure= out how to handle rotation to ramp slowly to work around that, but that se= ems like an insane extra step to add to something that is already too hard = for most folks to do as often as they should.

Bran= don=C2=A0

--001a113df3e66768d50553fbf08d-- From nobody Mon Jul 10 13:52:23 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 948F41318EA for ; Mon, 10 Jul 2017 13:52:20 -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 0ROHwXsWV1DA for ; Mon, 10 Jul 2017 13:52:18 -0700 (PDT) Received: from mail.wordtothewise.com (mail.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id E92151318D7 for ; Mon, 10 Jul 2017 13:52:18 -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 BAFA323379 for ; Mon, 10 Jul 2017 13:52:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1499719958; bh=fWDfkl23aGnGT8Vtw4CHKJTSuq6mDMkTstgIyA4/XX0=; h=From:Subject:Date:References:To:In-Reply-To:From; b=L/dc+To70heQRW1kt+cvXMlvJ0FJiTjAWuQi9D5E5LgBjXnmTEwImNrgJVRa2efll rKBFUW8qwXsAEROo4MHSnZCePtGFoU/+4OcNiD+D1SBLaUGGszv38GS5bn/vZfvt4k YnyE7UzGDBoSP/8FZFnAxO8Q2EMDuBTTQw1Nj0lk= From: Steve Atkins Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 10 Jul 2017 13:52:17 -0700 References: To: "dmarc@ietf.org" In-Reply-To: Message-Id: <89B0E961-68F0-440E-A9A2-D3E339FA70A9@wordtothewise.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [dmarc-ietf] using selectors to identify sources X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 20:52:20 -0000 > On Jul 10, 2017, at 12:53 PM, Brandon Long wrote: >=20 >=20 >=20 > On Fri, Jul 7, 2017 at 6:12 AM, Tim Draegen wrote: >> On Jul 5, 2017, at 6:33 PM, Murray S. Kucherawy = wrote: >>=20 >> Based on discussions with Seth and Gene earlier, it sounds like the = industry has sadly not taken up the habit of key and selector rotation, = and instead the pairing of "s=3D" and "d=3D" now identifies a single = source. Ignoring the obvious security problem this introduces, we're = now talking about implicitly formalizing this tuple as identifying a = source. This contradicts that original intent. In particular, if one = were to develop reputation in this way, then a key being rotated out = takes the reputation with it; signers would have to establish some = procedure for doing so with substantial overlap so that the new key can = be "warmed". Worse, in an emergency where a key is compromised, that = tuple's reputation irretrievably suffers. >>=20 >> How is this better than encouraging the industry to adopt the = separation of functions that was originally intended? >=20 > I just caught up on the "selectors in AAR" thread, but wanted to go = back to this early statement about key rotation and pairing of "s=3D" = and "d=3D" to identify a single source. Thus a new Subject: is born. >=20 > It's true key rotation is rare. People are figuring out how to do it, = though. Due to the size and scope of email's installed base, it takes a = really long time for the knowledge to slosh around the Internet. Using = multiple CNAMEs, delegating sub-domains, even out-sourcing all things = _domainkey.* is possible. Unfortunately there isn't good guidance on the = pros and cons of each way, and so people implement quick and dirty = 'cause they don't know any better. >=20 > Using selectors to identify a single source of email isn't right, IMO. = Given the way things play out, once people are told that selectors are = important because they're used to identify sources of email (doesn't = even matter how true it is), then we'll be stuck with selectors being a = component of reputation. People will make do with what they've got. >=20 > If nature abhors a vacuum, the missing piece is "what identifies a = source?". Selectors might fill that hole unless real guidance is = provided. >=20 > Using sub-domains to differentiate services works nicely. Today lack = of clear guidance means a Domain Owner has to deal with a mashup of = different ways to integrate with 3rd party senders. 3rd party senders = make do with what they've got, and that is often very constrained. >=20 > Maybe such guidance should go into the "Usage Guide". Declaring which = parts of the DMARC puzzle should be used to build reputation system = seems pretty important if interoperability is the goal. >=20 > But selectors do identify a source, to some extent. Even with = rotation, if I hand out a key to some service or just give them a couple = CNAMES, its obvious that's a different source than another. And it's = that ability we're talking about using with DMARC reporting and the = companies trying to get folks to p=3Dreject. >=20 > Yes, building reputation on selectors is a really bad idea when it = comes to rotation. I'm sure we can all figure out how to handle = rotation to ramp slowly to work around that, but that seems like an = insane extra step to add to something that is already too hard for most = folks to do as often as they should. I don't foresee key rotation being commonplace until there's something - = either within the spec or outside it - that treats old keys differently = to new keys. Not even if an RFC and several major ISPs loudly proclaim = that they track reputation and identify sources based solely on the d=3D = (or i=3D, if they want to) and not via a selector. Some operational risk = vs none (other than the risk of key compromises) is an easy enough = decision to make. If a large recipient ISP, say, started keeping track of the first time = it saw any public key and treated any mail using old keys with disdain = then people would jump on key rotation right away. Much the same = approach as pushing bulk senders to send all their mail, even the least = confidential junks mail, via TLS by making unencrypted mail less = attractive to the recipient. But if the key compromises remain mostly theoretical there doesn't seem = much point to worrying about it, other than the aesthetics of the thing. Cheers, Steve From nobody Mon Jul 10 14:46:21 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1C3412F27C for ; Mon, 10 Jul 2017 14:46:18 -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 qf5_33WhYDJd for ; Mon, 10 Jul 2017 14:46:17 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::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 D00A01318F1 for ; Mon, 10 Jul 2017 14:46:16 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id m68so46676537ith.1 for ; Mon, 10 Jul 2017 14:46:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=z/bMB56xZl6SEOdqVSWdNS7lCxp+htQe/QP+z86pW7c=; b=JM/YtCQHpZU6vKIwOvIbQCLxpoRRjl/21AhLdm9lNbhrpigjde8EhY2BslxLnWunfd k48vl8Eqai8nJl1k0FoPoZXihVu6NOx8+afZzKLkmK1eARvsP4g1uVe/T1u++a+Wdl7y Ecz8Faqm4WgBDES5LpZF0fL2ztKVSsc40iTub6VcCrKgWgDVF7zZzcDwX/tkhfy1syPH OLDUj0L0XC44uBL7ODr3Ud93M96u+LzMmceZgVoz49YiEzceTRRgqnnzo3afI7Tir1MV B5nID5sa1D018g+zMZqA3Uc+jGlxRwMfaP7B7eBKRwJbMSKIh7hP3tmDDVvBKtdlIuvz YOjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=z/bMB56xZl6SEOdqVSWdNS7lCxp+htQe/QP+z86pW7c=; b=bS48F/EkvrDtie1dScfPSZGiD/wpdVpVWUPkJZ5ZtHKSC4J4rqCLfBmzdDkTVMoxuf 32PYcpHmTd+r7wobY4oubYcqgI/zzu9/nFY1u/AnEcp34LbnvZ5O+TjCo0zVYGiBjKF6 lP6i9znVntumcKw0Q6B8p57L9iM3COdpXYvFkww5zlTwKljv9iUjPW7Bl4cdHfChpgYq XbQXJXE/stowICGH5/PWF4NiyoLDSPy/3SIyjXEF0X79vx0CJxiJ3DAEpqoCidV6Mtzv ML+oAI+ztqdrMgzvcKAgS0UPu+68VPM/eaTbAWJTcoK5J5UY8UC8AV2IbJqCMBHCqAb6 Cf6A== X-Gm-Message-State: AIVw112ZDLqElvth0+qww//PjWaEu7A5pRhwBBcnksYakwmYTnHmy2Rm RFo//UxKA7NnRrz3dZ2jdS8vhaxgDQ== X-Received: by 10.36.37.197 with SMTP id g188mr404875itg.30.1499723176246; Mon, 10 Jul 2017 14:46:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.106.130 with HTTP; Mon, 10 Jul 2017 14:46:15 -0700 (PDT) In-Reply-To: References: From: Gene Shuman Date: Mon, 10 Jul 2017 14:46:15 -0700 Message-ID: To: Kurt Andersen Cc: Brandon Long , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a1143d68e2e874d0553fd83de" Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-05.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 21:46:19 -0000 --001a1143d68e2e874d0553fd83de Content-Type: text/plain; charset="UTF-8" (resending from my personal account to avoid the spam filter) I think there's still something missing from the draft wrt fail/invalid. In section 5.2.2, it says that gross violations MUST be capped in the manner specified. This seems to only encompass what we were previously considering cv=invalid. Does it say somewhere that cv=fail should be handled in this fashion as well? Or does what was previously cv=fail still sign all arc sets? Are we handling these differently? I'm not necessarily sure we should. Also, the language here is MUST. Shouldn't this be optional, as we'd discussed? On Fri, Jun 30, 2017 at 4:48 PM, Kurt Andersen wrote: > > On Jun 30, 2017 2:37 PM, Brandon Long wrote: > > Looking through the changes, I see that in 5.2.2 we previously and still > say that the AAR field should be unknown. Unknown is a valid value for > result names for dkim-adsp and rrvs, but I'm curious why we would use that > and not just fail? fail seems to match better, especially now that we > don't differentiate between invalid and fail in the cv value. > > > Fair point. I'll look at rephrasing that. > > We also discussed signing/verifying a cv=fail differently, which isn't in > the draft yet (I don't think, I was looking at the diff not the whole > document). > > We discussed that the signing/verifying of a cv=fail would only do so > based on the single (presumably last) hop that contained the cv=fail. > > So, the AMS would be added/verified like normal, but the AS would only > sign the as/ams/aar of that hop. > > > That is already the specified handling in the case of fail. > > --Kurt > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --001a1143d68e2e874d0553fd83de Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(resending from my p= ersonal account to avoid the spam filter)

I think = there's still something missing from the draft wrt fail/invalid.=C2=A0 = In section 5.2.2, it says that gross violations MUST be capped in the manne= r specified. This seems to only encompass what we were previously consideri= ng cv=3Dinvalid.=C2=A0 Does it say somewhere that cv=3Dfail should be handl= ed in this fashion as well?=C2=A0 Or does what was previously cv=3Dfail sti= ll sign all arc sets?=C2=A0 Are we handling these differently?=C2=A0 I'= m not necessarily sure we should.=C2=A0 Also, the language here is MUST.=C2= =A0 Shouldn't this be optional, as we'd discussed?
=

On Fri, Jun 30, 2= 017 at 4:48 PM, Kurt Andersen <kandersen@linkedin.com> = wrote:

On Jun 30, 2017 2:37 PM, Brandon Long <blong@google.com> wr= ote:
Looking through the changes, I see that in 5.2.2 we previo= usly and still say that the AAR field should be unknown.=C2=A0 Unknown is a= valid value for result names for dkim-adsp and rrvs, but I'm curious w= hy we would use that and not just fail? =C2=A0fail seems to match better, especially now that we don't differentiate betw= een invalid and fail in the cv value.

Fair point. I'll look at rephrasing that.

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

We discussed that the signing/verifying of a cv=3Dfail would only do so bas= ed on the single (presumably last) hop that contained the cv=3Dfail.

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

That is already the specified handling in the case= of fail.

--Kurt


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


--001a1143d68e2e874d0553fd83de-- From nobody Mon Jul 10 15:12:56 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1201300CE for ; Mon, 10 Jul 2017 15:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p_GE8un6yMfk for ; Mon, 10 Jul 2017 15:12:52 -0700 (PDT) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 955E812F27C for ; Mon, 10 Jul 2017 15:12:52 -0700 (PDT) Received: by mail-ua0-x233.google.com with SMTP id z22so63383044uah.1 for ; Mon, 10 Jul 2017 15:12:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=whjgP0Pozn+wELLjlede+YtdCH1lPB65+dLz0G8JIp8=; b=ZI7wDui5E2WqiKlAmYgVE+moetigT9gcaM5RNK08xD6Wnd+uc/X8L5diqi3pvrvDBi Besx2xzkWgKqAwkb0aViUlYLMV5/VZH8CTAsEumocw/pPpp9A3lAiOmWklyjt3XfbOmo kw8dkMY9De53ejreARFjgdFoLrdNtA6LZXVZI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=whjgP0Pozn+wELLjlede+YtdCH1lPB65+dLz0G8JIp8=; b=Nbv+CqUB/C0Jy8KuaSymEdB/TK5lM5QRxufOwQ4/2YBUuzEPX22T5iLsSkdWIj4QsX Mwt1KKuj0+cs4ZFoqfqjAfPt8xnQpLCG7uHBRN2+QTl+orlJVbUhDe5/6vKTT+x5ko0j 9Pv/eIiPRj5WrxakdbbfeFuxaEkv2dkll2PSGHcvtKllZtVmfqxeMTi6yphvONnB/Ufj bIMvkjQxj5jwva4h8CLBM0Q5Jh8CCWU9uO9k038jyB33c/6CSqF+us5LJne63t84acOW saFk8ziCPu0xmHMqgPWEwHAYGqOMA1MoohONP+6VfZFfrqgbWnw61RIIijIpaG+u5jpD nd1A== X-Gm-Message-State: AIVw111ijGxrH0oGsUSDmjcAi60IPq16RoXlkCQcS4towe3DqY2nmwmn eKn8IO6Tzk0FsSx36TAinYMU0ncoFBF2 X-Received: by 10.176.3.162 with SMTP id 31mr9369065uau.54.1499724771634; Mon, 10 Jul 2017 15:12:51 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.176.71.204 with HTTP; Mon, 10 Jul 2017 15:12:51 -0700 (PDT) In-Reply-To: References: From: "Kurt Andersen (b)" Date: Mon, 10 Jul 2017 15:12:51 -0700 X-Google-Sender-Auth: ers59uarkT53fiAXoJJ_43X_nm0 Message-ID: To: Gene Shuman Cc: Kurt Andersen , Brandon Long , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c05ae02465c510553fde2d2" Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-05.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 22:12:55 -0000 --94eb2c05ae02465c510553fde2d2 Content-Type: text/plain; charset="UTF-8" On Mon, Jul 10, 2017 at 2:46 PM, Gene Shuman wrote: > (resending from my personal account to avoid the spam filter) > > I think there's still something missing from the draft wrt fail/invalid. > In section 5.2.2, it says that gross violations MUST be capped in the > manner specified. This seems to only encompass what we were previously > considering cv=invalid. Does it say somewhere that cv=fail should be > handled in this fashion as well? Or does what was previously cv=fail still > sign all arc sets? Are we handling these differently? I'm not necessarily > sure we should. Also, the language here is MUST. Shouldn't this be > optional, as we'd discussed? > I still think (and find it compatible with the tenor of other conversational threads) that MUST is appropriate. As usual, people can choose to not follow the spec :-( To your other points: 1. Section 6.1 para 2 says: "Until the chain is determined to be failed, and marked with an ARC set bearing the "cv=fail" indication, each participating ADMD SHOULD apply their own seal." 2. Section 5.2.2 para 2 says: "Because the violations can not be readily enumerated, the header fields signed by the AS header field in the case of a major violation MUST be only the matching 'i=' instance headers created by the MTA which detected the malformed chain, as if this newest ARC set was the only set present." I see now that I did not properly expand the scope of that directive to cover all cases where a cv=fail verdict is determined to be necessary, but I think that is the right approach. cv=fail --> sign only the current (latest) ARC set (regardless of the failure reason) --Kurt --94eb2c05ae02465c510553fde2d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Jul 10, 2017 at 2:46 PM, Gene Shuman <geneshuman@gmail.com><= /span> wrote:
(resending from my personal = account to avoid the spam filter)

I think there's still something missing from the draft wrt fail/= invalid.=C2=A0 In section 5.2.2, it says that gross violations MUST be capp= ed in the manner specified. This seems to only encompass what we were previ= ously considering cv=3Dinvalid.=C2=A0 Does it say somewhere that cv=3Dfail = should be handled in this fashion as well?=C2=A0 Or does what was previousl= y cv=3Dfail still sign all arc sets?=C2=A0 Are we handling these differentl= y?=C2=A0 I'm not necessarily sure we should.=C2=A0 Also, the language h= ere is MUST.=C2=A0 Shouldn't this be optional, as we'd discussed?

I still think (and find = it compatible with the tenor of other conversational threads) that MUST is = appropriate. As usual, people can choose to not follow the spec :-(

To your other points:
  1. Section 6.1 para = 2 says: =C2=A0"Until the chain is determined to be failed, and marked = with an ARC set bearing the "cv=3Dfail" indication, each particip= ating ADMD SHOULD apply their own seal."
  2. Section 5.2.2 para 2 = says: "Because the violations can not be readily enumerated, the heade= r fields signed by the AS header field in the case of a major violation MUS= T be only the matching 'i=3D' instance headers created by the MTA w= hich detected the malformed chain, as if this newest ARC set was the only s= et present."
    I see now that I did not properly expand the scope of= that directive to cover all cases where a cv=3Dfail verdict is determined = to be necessary, but I think that is the right approach. cv=3Dfail --> s= ign only the current (latest) ARC set (regardless of the failure reason)
--Kurt
--94eb2c05ae02465c510553fde2d2-- From nobody Mon Jul 10 15:32:36 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E83F01317CF for ; Mon, 10 Jul 2017 15:32:29 -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 3ZCtkkzyA7Rb for ; Mon, 10 Jul 2017 15:32:28 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::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 B048D13193E for ; Mon, 10 Jul 2017 15:32:26 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id v202so47399024itb.0 for ; Mon, 10 Jul 2017 15:32:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=W9hdyzProH0iLMcnX3TxR853mAd8nv5mSpEA62P8yGA=; b=PLg4GIBZdYQ3S8B5ePuFsE0jdkKEug4wIbLkExmcyUYs7qIsEh8yjjkoGhYNU+Lv6j b7Y/YbwNqwrBx88H0AO+As59UmDCMUcvTu4ucnHsmzE4s8HieH/6s5MDSaaIqgeKtfyf dtxGYhe5ZCEGRh4Q3GbdHb+17D/QzFhCNZNV4D/gJ1GZpqCYwjdoeuX4Syx/0YJ3MspL KMozA5b4q/wEXRvoM7vjeUJL6aUyaK10RTpsfyNYTP3BoTlv/Ta4FPtsoTrvhdCsljQ3 xE9/sqrBTtDsUYWsClVN69OlAsH3AdnZ9Bk0gWRQx+PpU1Cbwf1RLmkDwDV7rULemuAW btNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=W9hdyzProH0iLMcnX3TxR853mAd8nv5mSpEA62P8yGA=; b=KzmRDXL6IclwhWJTlJ827YbHtrXkQJuPunPX/MlCTNz1mwl+d3ODJgPa8mBSFyQcHM feDDejWjUCgs7LUvPOgATZcQrhRQqgeXnjunGyv9nipn4DMWIuCofJVvg08qbO5wKQbY 2T+ra44MXtxqRjpc1SwQ45AV2ZlZyT0omo3wM/1i35rpBDMqC7OLKtkvlotvNGGTH4My qrpj2Q33pT40Ruq2Gc7V7pg32WbTKvdPnnnE491R05Z3X+CCmQ9pxW2eE+IUXroElQ4n HWz502BbJkw7pllpW14YVnIeVqPBc3KamYbBqYv1ZOdW5gZcHSFnni3PEjV0fAvKCDKE iA8A== X-Gm-Message-State: AIVw111C1zhB1kcelHAgFhb4wAMpwJL9Y0U+UttxpTTM6lfoy+ukk25a B2bfmY1FPBZ6M7SDy58jBSJBoum7gg== X-Received: by 10.36.0.142 with SMTP id 136mr515812ita.99.1499725946114; Mon, 10 Jul 2017 15:32:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.106.130 with HTTP; Mon, 10 Jul 2017 15:32:25 -0700 (PDT) In-Reply-To: References: From: Gene Shuman Date: Mon, 10 Jul 2017 15:32:25 -0700 Message-ID: To: "Kurt Andersen (b)" Cc: Kurt Andersen , Brandon Long , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a11c14292476fa00553fe28bd" Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-05.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 22:32:30 -0000 --001a11c14292476fa00553fe28bd Content-Type: text/plain; charset="UTF-8" OK cool, totally agreed with all of these points. On Mon, Jul 10, 2017 at 3:12 PM, Kurt Andersen (b) wrote: > On Mon, Jul 10, 2017 at 2:46 PM, Gene Shuman wrote: > >> (resending from my personal account to avoid the spam filter) >> >> I think there's still something missing from the draft wrt fail/invalid. >> In section 5.2.2, it says that gross violations MUST be capped in the >> manner specified. This seems to only encompass what we were previously >> considering cv=invalid. Does it say somewhere that cv=fail should be >> handled in this fashion as well? Or does what was previously cv=fail still >> sign all arc sets? Are we handling these differently? I'm not necessarily >> sure we should. Also, the language here is MUST. Shouldn't this be >> optional, as we'd discussed? >> > > I still think (and find it compatible with the tenor of other > conversational threads) that MUST is appropriate. As usual, people can > choose to not follow the spec :-( > > To your other points: > > 1. Section 6.1 para 2 says: "Until the chain is determined to be > failed, and marked with an ARC set bearing the "cv=fail" indication, each > participating ADMD SHOULD apply their own seal." > 2. Section 5.2.2 para 2 says: "Because the violations can not be > readily enumerated, the header fields signed by the AS header field in the > case of a major violation MUST be only the matching 'i=' instance headers > created by the MTA which detected the malformed chain, as if this newest > ARC set was the only set present." > I see now that I did not properly expand the scope of that directive > to cover all cases where a cv=fail verdict is determined to be necessary, > but I think that is the right approach. cv=fail --> sign only the current > (latest) ARC set (regardless of the failure reason) > > --Kurt > --001a11c14292476fa00553fe28bd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
OK cool, totally agreed with all of these points. =C2=A0

On Mon, Jul 1= 0, 2017 at 3:12 PM, Kurt Andersen (b) <kboth@drkurt.com> wrot= e:
On Mon, Jul 10, 2017 at 2= :46 PM, Gene Shuman <geneshuman@gmail.com> wrote:
(resending from my personal account to avoid the = spam filter)

I think there's still something missing from the draft wrt fail= /invalid.=C2=A0 In section 5.2.2, it says that gross violations MUST be cap= ped in the manner specified. This seems to only encompass what we were prev= iously considering cv=3Dinvalid.=C2=A0 Does it say somewhere that cv=3Dfail= should be handled in this fashion as well?=C2=A0 Or does what was previous= ly cv=3Dfail still sign all arc sets?=C2=A0 Are we handling these different= ly?=C2=A0 I'm not necessarily sure we should.=C2=A0 Also, the language = here is MUST.=C2=A0 Shouldn't this be optional, as we'd discussed?<= /span>

I still think (a= nd find it compatible with the tenor of other conversational threads) that = MUST is appropriate. As usual, people can choose to not follow the spec :-(=

To your other points:
  1. Section 6= .1 para 2 says: =C2=A0"Until the chain is determined to be failed, and= marked with an ARC set bearing the "cv=3Dfail" indication, each = participating ADMD SHOULD apply their own seal."
  2. Section 5.2.2= para 2 says: "Because the violations can not be readily enumerated, t= he header fields signed by the AS header field in the case of a major viola= tion MUST be only the matching 'i=3D' instance headers created by t= he MTA which detected the malformed chain, as if this newest ARC set was th= e only set present."
    I see now that I did not properly expand the = scope of that directive to cover all cases where a cv=3Dfail verdict is det= ermined to be necessary, but I think that is the right approach. cv=3Dfail = --> sign only the current (latest) ARC set (regardless of the failure re= ason)
    3. =
--Kurt

--001a11c14292476fa00553fe28bd-- From nobody Mon Jul 10 18:22:43 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2CB126BF3 for ; Mon, 10 Jul 2017 18:22:38 -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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBo9aTzSD6Nw for ; Mon, 10 Jul 2017 18:22:37 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F30F0129B41 for ; Mon, 10 Jul 2017 18:22:36 -0700 (PDT) Received: (qmail 23124 invoked by uid 100); 11 Jul 2017 01:22:35 -0000 Delivered-To: reroute list-iecc-lists-ietf-dmarc@johnlevine.com Date: 11 Jul 2017 01:22:35 -0000 Message-ID: From: "John Levine" To: dmarc@ietf.org Organization: Taughannock Networks, Trumansburg NY References: <20337b3e-be49-797c-2974-1e36bd9939e0@gmail.com><20337b3e-be49-797c-2974-1e36bd9939e0@gmail.com> Cleverness: some X-Newsreader: trn 4.0-test77 (Sep 1, 2010) Originator: johnl@aryv.qy (John L) Archived-At: Subject: Re: [dmarc-ietf] ARC RFC status to target X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 01:22:38 -0000 In article , Murray S. Kucherawy wrote: >I think at the time DKIM went to Proposed Standard, one could've made the >same argument about it as well, especially on your last two points. Sorta kinda. At that point there wasn't any question that people would use it to tie messages to domain names, since domainkeys already did that. We still have no consensus on what you do with the domains once you have them. With ARC, I expect it'll be pretty clear whether stuff forwarded through mailing lists and the like is getting through. >I also think there's enough in flux about the current base document for ARC >that I would argue pretty hard for Experimental if we were pressed to >publish sooner. It doesn't feel "done" to me. Agreed. I expect that after a six months or a year we'll have a lot better idea whether ARC is fixing the mailing list issues and what tweaks might help. R's, John From nobody Tue Jul 11 08:39:17 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 668E2131737 for ; Tue, 11 Jul 2017 08:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8UihvdBMhQ6 for ; Tue, 11 Jul 2017 08:39:14 -0700 (PDT) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D607C1250B8 for ; Tue, 11 Jul 2017 08:39:13 -0700 (PDT) Received: by mail-ua0-x22d.google.com with SMTP id w19so2504464uac.0 for ; Tue, 11 Jul 2017 08:39:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=dSxmz66oIGBoE+m0/FnZQbR2BUHa1gK1GRwll7UzGW0=; b=ApXAfnLB/8/N+2goxyS+v/RTaMAUYzLpdL75gkM8YgIbBThnTDla5iGgMfsqMdfn9r gjxmgdjSvwcSjWXy6UHEUYA5+0M0DswyqkTJ3Clf9MJ1CdvinQyj95ZU4NZWprwg6QBm V7gNUXeGT2oENCM2F/qvLoy9OwcilbwaDgOhw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=dSxmz66oIGBoE+m0/FnZQbR2BUHa1gK1GRwll7UzGW0=; b=TBQJLATCpDPA3ImsWMorlyPaNfn7On2XbegEaDovtpM4UEzviSBvUYbLSDaC295QOn 44mUDG0kINBbnYYr71jw1AcCuo1m3fnZ4aMHwZtEzIUr13SPJVmfzwlrh9ThjTab3+uc U7p8laXQ+nvniIj+FwY8ZqoZ8cXCRcxEYhF7VBYNGhPXKQOWImmKZVG09Paf/IBL8ALw JSeHyq+GVQkuQ2k4YB0Lp2UlRI1stYByq+GaAL9QTZxbbBl14UbbA0+SjVdF/KoWLLAk jCDaDgzySSMQskad0iB5K7/mOJsKB4pzzbgYLiB+oGRHPMI4i7DtmjZBIR7M3VhBf6kd s9Kw== X-Gm-Message-State: AIVw11000IGVjFocAQwMrMO3SIgRYJrqIBmz42AQIWwGHbG33TjbMSnZ Nhwiw/He9kH7HJBZXfpBHltwXE8LtJIX X-Received: by 10.159.59.220 with SMTP id y28mr345995uah.12.1499787552958; Tue, 11 Jul 2017 08:39:12 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.176.71.204 with HTTP; Tue, 11 Jul 2017 08:39:12 -0700 (PDT) In-Reply-To: References: <20337b3e-be49-797c-2974-1e36bd9939e0@gmail.com> <92626495-ea27-bb24-9175-ad0a4501b859@gmail.com> From: "Kurt Andersen (b)" Date: Tue, 11 Jul 2017 08:39:12 -0700 X-Google-Sender-Auth: uCk_7DHH9W-nV6zanK9k1UbobgI Message-ID: To: Dave Crocker Cc: "Murray S. Kucherawy" , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0e9a90553ef505540c80d0" Archived-At: Subject: Re: [dmarc-ietf] ARC RFC status to target X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 15:39:15 -0000 --94eb2c0e9a90553ef505540c80d0 Content-Type: text/plain; charset="UTF-8" On Sat, Jul 8, 2017 at 11:45 AM, Dave Crocker wrote: > On 7/8/2017 11:24 AM, Murray S. Kucherawy wrote: > >> . . . if it's more important to get an RFC published than it is to wait >> for some modicum of deployed maturity -- which will take months, at least, >> I would guess -- then Experimental is indeed something we should consider, >> and I also agree with Andrew that the experiment should be reasonably well >> described and bounded. >> > > If I thought that bench-testing would suffice, then I'd suggest doing it > and holding the RFC until we get the results. But I think the question of > dynamics and operations is more complex and requires some breadth of > deployment experience to resolve. (Even if 'resolve' means a solid 'no > problems' comeback rather than any interesting statements about nuance or > implication.) > > On the matter of a goal for the experiment I'll repeat that I think we > merely need to target development of a Deployment and Use BCP. When we > have good community support for the contents of such a document, based on > significant experience, then the spec will be ready for standards track. > > (The formal rules for Proposed do not require field experience or even > implementation. Except sometimes. And there's no clear rule about when > it's required. My own sense of the rule is "when we don't adequately > understand how it will work in the real world and especially when problems > could have an infrastructure effect." I see this as one of those cases.) Now being back at the keyboard after our "Christmas in July" break, I see lots of threads going on about the spec. I will endeavour to have at least some talking points regarding a proposed goals and evaluation framework for an experimental foray as well as seek to integrate all the other feedback into a draft update. Regarding timelines, I think that we can have wishes and hopes, but, since we will now be holding our seventh(!) interop event during the IETF99 hackathon, I don't expect that "months" is even the right scale upon which to base our expectations. Maybe thinking that we could draw some conclusions before IETF110 would be more aligned with reality (and yes, I'm keeping in mind that even _this_ is subject to the planning fallacy). But I don't think that it will provide any benefit to put this into the draft. --Kurt --94eb2c0e9a90553ef505540c80d0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= at, Jul 8, 2017 at 11:45 AM, Dave Crocker <dcrocker@gmail.com> wrote:
On 7/8/2017 1= 1:24 AM, Murray S. Kucherawy wrote:
. . . if it's more important to get an R= FC published than it is to wait for some modicum of deployed maturity -- wh= ich will take months, at least, I would guess -- then Experimental is indee= d something we should consider, and I also agree with Andrew that the exper= iment should be reasonably well described and bounded.

 If I thought that bench-testing would suffice, then I'd suggest doing i= t and holding the RFC until we get the results.=C2=A0 But I think the quest= ion of dynamics and operations is more complex and requires some breadth of= deployment experience to resolve.=C2=A0 (Even if 'resolve' means a= solid 'no problems' comeback rather than any interesting statement= s about nuance or implication.)

On the matter of a goal for the experiment I'll repeat that I think we = merely need to target development of a Deployment and Use BCP.=C2=A0 When w= e have good community support for the contents of such a document, based on= significant experience, then the spec will be ready for standards track.
(The formal rules for Proposed do not require field experience or even impl= ementation.=C2=A0 Except sometimes.=C2=A0 And there's no clear rule abo= ut when it's required.=C2=A0 My own sense of the rule is "when we = don't adequately understand how it will work in the real world and espe= cially when problems could have an infrastructure effect."=C2=A0 I see= this as one of those cases.)

Now being bac= k at the keyboard after our "Christmas in July" break, I see lots= of threads going on about the spec. I will endeavour to have at least some= talking points regarding a proposed goals and evaluation framework for an = experimental foray as well as seek to integrate all the other feedback into= a draft update.

Regarding timelines, I think that= we can have wishes and hopes, but, since we will now be holding our sevent= h(!) interop event during the IETF99 hackathon, I don't expect that &qu= ot;months" is even the right scale upon which to base our expectations= . Maybe thinking that we could draw some conclusions before IETF110 would b= e more aligned with reality (and yes, I'm keeping in mind that even _th= is_ is subject to the planning fallacy). But I don't think that it will= provide any benefit to put this into the draft.

-= -Kurt=C2=A0
--94eb2c0e9a90553ef505540c80d0-- From nobody Tue Jul 11 09:12:29 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E1FF127B73 for ; Tue, 11 Jul 2017 09:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2DYN2pOGam9 for ; Tue, 11 Jul 2017 09:12:17 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA1DF131752 for ; Tue, 11 Jul 2017 09:12:16 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id j53so3079147uaa.2 for ; Tue, 11 Jul 2017 09:12:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=oZAeDISQFoCI64wazJl+BhWcbqnAbqSyTrBZEbrJSeo=; b=Tyh+A+FeW7N7I0gN1z5Oa5VVnXyKReP31rzaAE4pg+eMiRFVZaEeW/VkCHlwvgc5Km V7IlVRJiAkkxATwhzGha/60feAZista7CqwTCsTEnyHUxdEDfQ+aaS9NfEOE5IoEArJM dOq3iV9mkJdiiuYqHOzSv+6wFAxX8hVWZXkkU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=oZAeDISQFoCI64wazJl+BhWcbqnAbqSyTrBZEbrJSeo=; b=DTQTWDkblqPoEePydY3yUDLqVT1EujkSu9+qsLxnYeaSy7rkHo7ikylW3kBU2rUy7s qV9tLTBPjYZZIUUu9iXdvu2dLtUffac2SCl6b4D4nxkk9Mn/Gxjg90p0q2tqjNwhgVVZ A9hjBkvsCU7miMDrLpPsSiTlXIh75VY2WoWDAEJQy8exzHEQJDvRf3b6CTgedBsLvZcU IVwqP1/59mXhIZxbQWlh4njePiBsLVtPQOLEtQWMz9QgjNajLevIYoBCUE92C+oikS9G dcVEPxYp6R4R+bdTJTHLJvKfTai/sVOYSiC5Cpv4v78A9DunKuWr7O5YNZ+D32X/Imtw ktFg== X-Gm-Message-State: AIVw113k5ObcQAM5LkE4hBuLFMIXdZ4HOT8h5YgYaZrJDOYcXBVzozFm 3t6uHDy0cDRiZJxLp99l2g08Urso4yOA X-Received: by 10.176.75.28 with SMTP id h28mr420296uaf.133.1499789535883; Tue, 11 Jul 2017 09:12:15 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.176.71.204 with HTTP; Tue, 11 Jul 2017 09:12:15 -0700 (PDT) In-Reply-To: References: <2841386.K0mPqPZNK9@kitterma-e6430> From: "Kurt Andersen (b)" Date: Tue, 11 Jul 2017 09:12:15 -0700 X-Google-Sender-Auth: W-biIgImTl-kRsZ6Kr4dqBSfGao Message-ID: To: Brandon Long Cc: "Murray S. Kucherawy" , "dmarc@ietf.org" , Seth Blank Content-Type: multipart/alternative; boundary="f403045e80aa86468605540cf6ea" Archived-At: Subject: Re: [dmarc-ietf] using selectors to identify sources X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 16:12:28 -0000 --f403045e80aa86468605540cf6ea Content-Type: text/plain; charset="UTF-8" On Mon, Jul 10, 2017 at 12:48 PM, Brandon Long wrote: > > > On Mon, Jul 10, 2017 at 12:27 AM, Murray S. Kucherawy > wrote: > >> On Sat, Jul 8, 2017 at 2:08 PM, Seth Blank wrote: >> >>> I think it needs to be specified. Receivers construct DMARC reports in a >>> known manner, they shouldn't need to guess how to get the appropriate >>> information out of ARC headers in an intermediary-implementation-specific >>> manner. The spec should make it unambiguous how information can be >>> transmitted to the receivers in a consistent and interoperable manner. >>> >> >> How do receivers include the source IP address in DMARC records today, >> when A-R doesn't give it to them? >> > > I think this highlights the challenge we're having with this conversation. > > Today, DMARC reports only contain information about the current hop where > the report is being generated. > > Obviously, at the current hop, any information available to that hop, such > as IP and selectors, can be logged directly for generating the report. > > We're talking about how, with ARC, we want to include information in the > DMARC report from the previous hops. The best way to pass information from > previous hops is through the AAR. > > It might be possible to parse the Received headers for IPs, or extract the > selectors by walking the header.b information that is in the AAR headers, > but obviously being more direct is preferred. > On Sat, Jul 8, 2017 at 9:25 PM, Murray S. Kucherawy wrote: > > So evidently we've got a conflict between what A-R was intended to be used > for, and an apparent need to create a channel between ARC and DMARC to > relay stuff like selectors and source IP addresses. If consensus exists > that the need is real and in scope for this WG, we either need to come to > consensus on allowing feature creep of A-R, or come up with another way to > meet that need. > > With respect to the source IP in particular, we had that battle all the > way up to a formal appeal to the IESG and that too was resolved with a > decision that such details weren't appropriate for A-R. This resulted in > what is now Appendix C of RFC7601, and the client IP address was left out. > > Also, assuming you're referring to the ARC base draft, I don't agree that > "with the least delta to the spec" is a legitimate constraint here. > As I see it, there are two possible approaches to address this dilemma: 1) Include the additional information in the AAR which is wanted downstream for a DMARC report to be emitted from a receiver N hops away - this requires additional fields to the basic RFC7601 A-R spec 2) Create a fourth member of the ARC set of headers to convey this additional information (this is partially was was proposed with the Origin-IP header, but not fleshed out enough to be really useful in an unlimited number of hops scenario). I'm somewhat opposed to creating a fourth member for an ARCset because I think that increases the fragility of the chain, but, OTOH, it may be an easier delta for new implementers than creating a basic A-R and an "enhanced" version to post as the AAR. I'm definitely opposed to making these fields *required* because that would require ARC validation to parse the AAR (or fourth header) to determine validity and we've tried to stay away from that (leaving it to the report generating code to have to worry about AAR contents). --Kurt --f403045e80aa86468605540cf6ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Jul 10, 2017 at 12:48 PM, Brandon Long <blong@google.com>= wrote:
<= div class=3D"gmail_extra">
On Mon, Jul 10, 2017 at 12:27 AM, Murray S. Kucherawy <superuser@gm= ail.com> wrote:
On Sat, Jul 8, 2017 at 2:08 PM, Seth Blank <= span dir=3D"ltr"><seth@sethblank.com> wrote:
I think it needs to be specified. Receivers construct= DMARC reports in a known manner, they shouldn't need to guess how to g= et the appropriate information out of ARC headers in an intermediary-implem= entation-specific manner. The spec should make it unambiguous how info= rmation can be transmitted to the receivers in a consistent and interoperab= le manner.

How do = receivers include the source IP address in DMARC records today, when A-R do= esn't give it to them?

I think this highlights the challenge we're having with = this conversation.

Today, DMARC reports only conta= in information about the current hop where the report is being generated.

Obviously, at the current hop, any information available to th= at hop, such as IP and selectors, can be logged directly for generating the= report.

We're talking about how, with ARC, we want to in= clude information in the DMARC report from the previous hops.=C2=A0 The bes= t way to pass information from previous hops is through the AAR.
=
It might be possible to parse the Received headers for IPs, = or extract the selectors by walking the header.b information that is in the= AAR headers, but obviously being more direct is preferred.

=C2=A0On Sat, Jul 8, 2017 at 9:25 = PM, Murray S. Kucherawy=C2=A0<superuser@gmail.com>=C2=A0wr= ote:

So evidently we've got a conflict betwee= n what A-R was intended to be used for, and an apparent need to create a ch= annel between ARC and DMARC to relay stuff like selectors and source IP add= resses.=C2=A0 If consensus exists that the need is real and in scope for th= is WG, we either need to come to consensus on allowing feature creep of A-R= , or come up with another way to meet that need.

With res= pect to the source IP in particular, we had that battle all the way up to a= formal appeal to the IESG and that too was resolved with a decision that s= uch details weren't appropriate for A-R.=C2=A0 This resulted in what is= now Appendix C of RFC7601, and the client IP address was left out.

=
Also, assuming you're referring to the ARC base draft, I don= 't agree that "with the least delta to the spec" is a legitim= ate constraint here.

As I see it, there are two possible approaches to address this dilemma:
1) Include the additional information in the AAR which is wanted d= ownstream for a DMARC report to be emitted from a receiver N hops away - th= is requires additional fields to the basic RFC7601 A-R spec
2) Cr= eate a fourth member of the ARC set of headers to convey this additional in= formation (this is partially was was proposed with the Origin-IP header, bu= t not fleshed out enough to be really useful in an unlimited number of hops= scenario).

I'm somewhat opposed to creating a= fourth member for an ARCset because I think that increases the fragility o= f the chain, but, OTOH, it may be an easier delta for new implementers than= creating a basic A-R and an "enhanced" version to post as the AA= R. I'm definitely opposed to making these fields *required* because tha= t would require ARC validation to parse the AAR (or fourth header) to deter= mine validity and we've tried to stay away from that (leaving it to the= report generating code to have to worry about AAR contents).
--Kurt
--f403045e80aa86468605540cf6ea-- From nobody Tue Jul 11 20:36:04 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1661C126D05 for ; Tue, 11 Jul 2017 20:36:02 -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 uJUoarKeHbbc for ; Tue, 11 Jul 2017 20:36:00 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::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 B5964126B6E for ; Tue, 11 Jul 2017 20:36:00 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id r125so6069431vkf.1 for ; Tue, 11 Jul 2017 20:36:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ha2hXtL4aFqIDfr4zRXzdDDvqdRRFyvpAeECryB5R7U=; b=RcYrC/f0haHEO+ItxXq/taSqwrJSpkadnZZaWByuU3zMfnstw8Tl9yGJSsy2aSnhch D65OsjdtRpw70w/8Bv4BR2AmOqt8AoqQe8BGYqbvc+vuYVDqzKce0sSZzpVGGpucng1N /pGVR/97eeux0Wn0AnIJfnyiTaEg8PHYVKuFB2AJ5gRt9hDKs2B3NzpdZL1VlmXjfU8d 8ba/91Bnxq3NTp4jE8G8j5vBSTpsajklX0zNuZPVJhl8yiWQoYGUaXx61tKTRvbT2dzE HK8V3XIpKlZ45cGcHusyVgDzQ9SG4q7Qf7GgWNrOgOWOSZglR8/fVZ4RDZJT9TFRKyDB f8WA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ha2hXtL4aFqIDfr4zRXzdDDvqdRRFyvpAeECryB5R7U=; b=G2jJGGqYcAgArVcmp2BfWildtoVWDcxNWuTIOaQ23rHzfqlQkhK8zczayOUSBiAnbu Lb/ENFXGzEw1h6JK1GKxEWNi1TGMUH086TJgzAT51a2LwUF3yEiEqqM6W/qvD+h5TW/l 3wTzoI58DHkrC6d4xAviMdxEW9jqgGM7JjW9l4EtHeKt/m+ck39tXDGiRDQqeQyNYSYh 10zK1/4TA7yHJufTkuZY5R5A6BkjDO7dYakGZBxO/CxlHvPFoQcEp0mLueUFJpKAC0iD weasl3tsmGHo1rMcx81/By6xN0ckGiq7KO6cDWxyeleNrn7mFpK0CehF3Z5dYyT+Hl0Z jyYQ== X-Gm-Message-State: AIVw112OnpK0OOEdkwvUF5D2oXXGbnrxmIIz5Yjzcf+UYf4CmJQpABnX kD4Iqho1/X1hUlSKRp2Luxn/0h4xFw== X-Received: by 10.31.138.82 with SMTP id m79mr145686vkd.91.1499830559874; Tue, 11 Jul 2017 20:35:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.126.196 with HTTP; Tue, 11 Jul 2017 20:35:59 -0700 (PDT) In-Reply-To: References: <20337b3e-be49-797c-2974-1e36bd9939e0@gmail.com> <92626495-ea27-bb24-9175-ad0a4501b859@gmail.com> From: "Murray S. Kucherawy" Date: Tue, 11 Jul 2017 20:35:59 -0700 Message-ID: To: "Kurt Andersen (b)" Cc: Dave Crocker , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a1142ee00bea68e0554168325" Archived-At: Subject: Re: [dmarc-ietf] ARC RFC status to target X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 03:36:02 -0000 --001a1142ee00bea68e0554168325 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 11, 2017 at 8:39 AM, Kurt Andersen (b) wrote: > Regarding timelines, I think that we can have wishes and hopes, but, since > we will now be holding our seventh(!) interop event during the IETF99 > hackathon, I don't expect that "months" is even the right scale upon which > to base our expectations. Maybe thinking that we could draw some > conclusions before IETF110 would be more aligned with reality (and yes, I'm > keeping in mind that even _this_ is subject to the planning fallacy). But I > don't think that it will provide any benefit to put this into the draft. > > --Kurt > IETF 110 is in March 2021, location TBD. Isn't that a bit of an aggressive timeline for this kind of work? ;-) -MSK --001a1142ee00bea68e0554168325 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 11, 2017 at 8:39 AM, Kurt Andersen (b) <kboth@= drkurt.com> wrote:
Regardi= ng timelines, I think that we can have wishes and hopes, but, since we will= now be holding our seventh(!) interop event during the IETF99 hackathon, I= don't expect that "months" is even the right scale upon whic= h to base our expectations. Maybe thinking that we could draw some conclusi= ons before IETF110 would be more aligned with reality (and yes, I'm kee= ping in mind that even _this_ is subject to the planning fallacy). But I do= n't think that it will provide any benefit to put this into the draft.<= span class=3D"HOEnZb">

--Kurt=C2= =A0

IETF 110 is in March 2021, location TBD.= =C2=A0 Isn't that a bit of an aggressive timeline for this kind of work= ?=C2=A0 ;-)

-MSK
--001a1142ee00bea68e0554168325-- From nobody Tue Jul 11 20:40:57 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60ECF127337 for ; Tue, 11 Jul 2017 20:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e44a7DQirJ0s for ; Tue, 11 Jul 2017 20:40:52 -0700 (PDT) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::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 AEB59126B6E for ; Tue, 11 Jul 2017 20:40:52 -0700 (PDT) Received: by mail-ua0-x230.google.com with SMTP id w19so6906617uac.0 for ; Tue, 11 Jul 2017 20:40:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=k5ZQxYMqSnzxUlrkcAwv7UnDa/glAuyANgBM3E0z5Ec=; b=bLD2W1DN5dTK6xiRWY0CnLQNwGtnHFFuHi8IiibFJcVqyJQeJ2RWDYLAdEKJQ69j/A 3wqoLs92th7v9RzABXMWjcEviB//CeM7XRqlYLPterOHd4zOD8Kc7dwAvmlrO3XbitJy nDMuSjCNIx3ol50kKey/TEp/4LvmuT1nEGB9maxD9LtIheitmJ0NyDwxWVKchyhx4d4O 4ONvI4lfVNmDFMR7Y/bo9ypMfRXlqwcrpQF82XcQI6lidl1RjfP/pYnxq88qKZmukBGI 0kzbb4ywjQB0sNy/Ef4ankdDZxG4yx3MUB1Nsg+ti7YtexTfJpnOHQkEEvy8FRlVB6zJ gowQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=k5ZQxYMqSnzxUlrkcAwv7UnDa/glAuyANgBM3E0z5Ec=; b=ZDK0HwyBx/H9tJpQHNMaMYVprdvXFf7b1zQ/BeFNMHNQ/VtZ/Kt+fzqaF7cq1RLugX kY6kIBamW5IkMRNfjYzxd8Y+MS0lAQNsQwU5ELmERjGj7bo1u0U2xobyBASjBr3fzC+p +FVSZchl/WrAXe54BXUt0j+KQB8aMnqNkgZqVmlHqd11PDJwOUrUwvavv3G1CmWHodj3 NV5h8rtAg6pfhpfV8hFClz1jf2a9WwvIbWrI4qDMht018Fs2d0d6+dLlFZyT5iz6N8u8 WREB06JJaWf5GTRdYcFrSeOKJBBY4k8ewn1Zyo836+4iS64U9gBmiN+3tPq4AMG12WXr iphQ== X-Gm-Message-State: AIVw113HYHzEblyYGwIEE83EMlw5LbwgwmuQWz0uOEqpctvX2K72UoRZ kp+QoXO/JaZDLzyvxbfA2G7Wt5zjfA== X-Received: by 10.176.17.71 with SMTP id g7mr2040637uac.61.1499830851862; Tue, 11 Jul 2017 20:40:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.126.196 with HTTP; Tue, 11 Jul 2017 20:40:50 -0700 (PDT) In-Reply-To: References: <2841386.K0mPqPZNK9@kitterma-e6430> From: "Murray S. Kucherawy" Date: Tue, 11 Jul 2017 20:40:50 -0700 Message-ID: To: "Kurt Andersen (b)" Cc: Brandon Long , "dmarc@ietf.org" , Seth Blank Content-Type: multipart/alternative; boundary="f4030437a8ac260851055416955e" Archived-At: Subject: Re: [dmarc-ietf] using selectors to identify sources X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 03:40:54 -0000 --f4030437a8ac260851055416955e Content-Type: text/plain; charset="UTF-8" On Tue, Jul 11, 2017 at 9:12 AM, Kurt Andersen (b) wrote: > > 1) Include the additional information in the AAR which is wanted > downstream for a DMARC report to be emitted from a receiver N hops away - > this requires additional fields to the basic RFC7601 A-R spec > This seems to be the least painful, since ARC "owns" AAR and is thus free to do what it wants here, but then there's no way to do what you want in non-ARC environments which I infer would be a helpful thing from Seth's comments. > 2) Create a fourth member of the ARC set of headers to convey this > additional information (this is partially was was proposed with the > Origin-IP header, but not fleshed out enough to be really useful in an > unlimited number of hops scenario). > I think that's even cleaner. I'm somewhat opposed to creating a fourth member for an ARCset because I > think that increases the fragility of the chain, > How is it any more fragile than already having to stack and hash ordered groups of three ordered things? > but, OTOH, it may be an easier delta for new implementers than creating a > basic A-R and an "enhanced" version to post as the AAR. I'm definitely > opposed to making these fields *required* because that would require ARC > validation to parse the AAR (or fourth header) to determine validity and > we've tried to stay away from that (leaving it to the report generating > code to have to worry about AAR contents). > You would just need to be clear in prose how its presence and/or absence is expected to affect interoperability (if at all). -MSK --f4030437a8ac260851055416955e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 11, 2017 at 9:12 AM, Kurt Andersen (b) <kboth@= drkurt.com> wrote:

1) = Include the additional information in the AAR which is wanted downstream fo= r a DMARC report to be emitted from a receiver N hops away - this requires = additional fields to the basic RFC7601 A-R spec

This seems to be the least painful, since ARC "= owns" AAR and is thus free to do what it wants here, but then there= 9;s no way to do what you want in non-ARC environments which I infer would = be a helpful thing from Seth's comments.
=C2=A0
2) Create a fourth member of the ARC set of headers t= o convey this additional information (this is partially was was proposed wi= th the Origin-IP header, but not fleshed out enough to be really useful in = an unlimited number of hops scenario).
=

I think that's even cleaner.

I'm somewhat opposed to creating a fourth member= for an ARCset because I think that increases the fragility of the chain,

How is it any more f= ragile than already having to stack and hash ordered groups of three ordere= d things?
=C2=A0
but, OTOH, it may be an easier delta fo= r new implementers than creating a basic A-R and an "enhanced" ve= rsion to post as the AAR. I'm definitely opposed to making these fields= *required* because that would require ARC validation to parse the AAR (or = fourth header) to determine validity and we've tried to stay away from = that (leaving it to the report generating code to have to worry about AAR c= ontents).

You would just need t= o be clear in prose how its presence and/or absence is expected to affect i= nteroperability (if at all).

-MSK
<= /div> --f4030437a8ac260851055416955e-- From nobody Wed Jul 12 12:41:37 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1A8312EC17 for ; Wed, 12 Jul 2017 12:41: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=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 byeW8O86vuM5 for ; Wed, 12 Jul 2017 12:41:34 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::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 156FF12EA74 for ; Wed, 12 Jul 2017 12:41:34 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id r125so18852831vkf.1 for ; Wed, 12 Jul 2017 12:41:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:from:date:message-id:subject:to; bh=NHPR2GNiH84nCsbu8lwNKP6PaEhargyh4YwhB5XKOHc=; b=KIKwLEq3mpJtYi8GwyGmrChUSVMMIKFrQ/Ri+nfVIMlCzjIJVG+m46gU1wYk3rHoX4 9CEV1quAI5qwvXRAfDJxgzERAytQrsHL0FrYHQ7X7PVCzQoNf9x2Mbq8HfLL8oYXQKVN SqUtUOSs/f/mzSnJqygMGVh7LVy6R+4Ba7B/s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=NHPR2GNiH84nCsbu8lwNKP6PaEhargyh4YwhB5XKOHc=; b=chm3GghaD1/8/DBKevwuxgfcmI4hND5vVdmczaExMLLFTM9MWFLEBvfClC+F5RY+x+ xi79hvV2FV8+6zUzqpGU3e7884irwi7wGYNLZcF5FzrRb//6gl/gr99kdUvdYlv24+c+ 0fBceZ/XjS7NliCcRWeB2Rg1vlu5D+9hoeIfA63tB8qQJVrs98PbYgyvZZNgpqW14W5Y K1oy4e76DGndDu2miHKcRD2jSpHlQZY6tCyebVTwAaAxAjViNn5sJQkkgypfMOCqiqUG 3WVcTF8qAduzC+LPhUT2dAREhXHqz3Ba8OQ1/pv+UGJE1sykqsiSna5aWBiol8BQtGc9 6F5Q== X-Gm-Message-State: AIVw110kutWyyVXYf4nqtrbugwCXSzsqRIKvIzgRSXy4Ig+t/2pD48y0 2GVGRGZGi7Xfh3EOQ6Qt8B8df2s+1ClL X-Received: by 10.31.33.16 with SMTP id h16mr98577vkh.103.1499888493066; Wed, 12 Jul 2017 12:41:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.71.204 with HTTP; Wed, 12 Jul 2017 12:41:32 -0700 (PDT) From: Kurt Andersen Date: Wed, 12 Jul 2017 12:41:32 -0700 Message-ID: To: Terry Zink , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a11c0436ad50d030554240045" Archived-At: Subject: [dmarc-ietf] "Fixing" A-R for ARC's AAR use (and downstream DMARC reporting) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 19:41:36 -0000 --001a11c0436ad50d030554240045 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 12, 2017 at 11:38 AM, Terry Zink via arc-discuss < arc-discuss@dmarc.org> wrote: > This structure has always bugged me: > > > authentication-results: google.com; dkim=none (message not signed) > > header.d=none;google.com; dmarc=none action=none header.from= > linkedin.com; > > What's going on is that there are separate agents that do the DKIM > evaluation and the DMARC evaluation. Their output result is domain>; . They are all concatenated onto the end of the > Authentication-Results header. There isn't a "clean up" afterwards (DKIM > and DMARC agents individually may fail as well which gets even more > confusing, but at least one of them gets stamped). And on an outbound > message (which is what you see here), there is no SPF check so it just > looks weird. > I don't know if you've see the other threads on the dmarc@ietf list, but the A-R header(s) and the content thereof have been a bit of an open item. If we were to recreate something other than RFC7601 to become the AAR header, do you have some suggestions for a better approach? --Kurt --001a11c0436ad50d030554240045 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Jul 12, 2017 at 11:38 AM, Terry Zink via arc-discuss = <arc-discuss@= dmarc.org> wrote:
This structure has always bugged me:

> authentication-results:=C2=A0<= /span>google.com; dkim=3Dnone (message not signed)
= >=C2=A0 header.d=3Dnone;google.com; dmarc=3Dnone = action=3Dnone header.from=3Dlinkedin.com;

W= hat's going on is that there are separate agents that do the DKIM evalu= ation and the DMARC evaluation. Their output result is <recipient domain= >; <output of agent>. They are all concatenated onto the end of th= e Authentication-Results header. There isn't a "clean up" aft= erwards (DKIM and DMARC agents individually may fail as well which gets eve= n more confusing, but at least one of them gets stamped). And on an outboun= d message (which is what you see here), there is no SPF check so it just lo= oks weird.

I don't k= now if you've see the other threads on the dmarc@ietf list, but the A-R= header(s) and the content thereof have been a bit of an open item. If we w= ere to recreate something other than RFC7601 to become the AAR header, do y= ou have some suggestions for a better approach?

--= Kurt
--001a11c0436ad50d030554240045-- From nobody Wed Jul 12 12:43:54 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70237131792 for ; Wed, 12 Jul 2017 12:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjuvaHCeM-zz for ; Wed, 12 Jul 2017 12:43:51 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 656DC12EA74 for ; Wed, 12 Jul 2017 12:43:51 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id x187so28664542oig.3 for ; Wed, 12 Jul 2017 12:43:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tOvWa0ySizUPzUgSQqBJaCuMsDqnfPG/99hssmXdaCE=; b=ty6FQGKGzmbmGyQ4EHgPu/BoIpChp1fsJuvw7Ei22oRb+Rk+tpW/5SLVLEgArXoyMk 78LUX/pjAi3Gm83b4Ukpog+8kWiGaLV7OJnnFiLegJqUc4U6xqH6bEpcogSVHcvusWlQ nvrS85eApnlWJQTVc+xqHBgQY3pxglLOg4nfw2x5x1FhCb4wW6JB98QEoewPOOw39ozN EAN/8wqzsvFVawmEubIOyuMgMRfJzz9W/fsypjtjnhnkOLsYwW1GvJDwA9gT/qpLSZaq EbujEM+FKAvJdiveEm8QDSBWKlcFmHtVicQ3GnbkyYPs1FJ1ApvCuKhyrRdDbYovi26R 0UdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tOvWa0ySizUPzUgSQqBJaCuMsDqnfPG/99hssmXdaCE=; b=qBXfnjiBgFaq8YyexU+q1T4w4yragAUcwq8cksQUUcx9qrw4kuA0DtHBjYLW57jeRL ZPMFN/+AwDv+AjSMPI+s+MfEvfbcfm7IvaPsez0K+SWgh8rbPdeynrIeBABGygLl09bj aci6+n1doI+suNvoQ9DfP/I0B8Yi79JdhhtjVMZ8sxsgBJKxvIRow7R49JhFXzGwIkgq ZhHWHalm26fzFLKsMkbvJ3JaAjnBb6SDMlicfJwVPH5uy3A4SjTwnIJROlJVLnpnb6oj oJi64027gimcRTYWnev0v+eaKSNgWOpVkdaORTelGY0sS/D2vn/2IvzpBeAI0Z6Hogov 39SA== X-Gm-Message-State: AIVw112G3tlHHIQ568p9yZDnYJfLWeyQUsU2XMVsUvKpHGsZKmUlrlzd E0j4zHopEFN5j8Cz7sMm6uNLv99hFBNa X-Received: by 10.202.193.133 with SMTP id r127mr137159oif.117.1499888630373; Wed, 12 Jul 2017 12:43:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.131.17 with HTTP; Wed, 12 Jul 2017 12:43:49 -0700 (PDT) In-Reply-To: References: From: Brandon Long Date: Wed, 12 Jul 2017 12:43:49 -0700 Message-ID: To: Kurt Andersen Cc: Terry Zink , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a113dbd7c04aea005542409eb" Archived-At: Subject: Re: [dmarc-ietf] "Fixing" A-R for ARC's AAR use (and downstream DMARC reporting) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 19:43:53 -0000 --001a113dbd7c04aea005542409eb Content-Type: text/plain; charset="UTF-8" I think he means that what bugs him is the fact that their authres header doesn't match the spec... at least, I hope that's the case. Brandon On Wed, Jul 12, 2017 at 12:41 PM, Kurt Andersen wrote: > On Wed, Jul 12, 2017 at 11:38 AM, Terry Zink via arc-discuss < > arc-discuss@dmarc.org> wrote: > >> This structure has always bugged me: >> >> > authentication-results: google.com; dkim=none (message not signed) >> > header.d=none;google.com; dmarc=none action=none header.from= >> linkedin.com; >> >> What's going on is that there are separate agents that do the DKIM >> evaluation and the DMARC evaluation. Their output result is > domain>; . They are all concatenated onto the end of the >> Authentication-Results header. There isn't a "clean up" afterwards (DKIM >> and DMARC agents individually may fail as well which gets even more >> confusing, but at least one of them gets stamped). And on an outbound >> message (which is what you see here), there is no SPF check so it just >> looks weird. >> > > I don't know if you've see the other threads on the dmarc@ietf list, but > the A-R header(s) and the content thereof have been a bit of an open item. > If we were to recreate something other than RFC7601 to become the AAR > header, do you have some suggestions for a better approach? > > --Kurt > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --001a113dbd7c04aea005542409eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think he means that what bugs him is the fact that their= authres header doesn't match the spec... at least, I hope that's t= he case.

Brandon
<= br>
On Wed, Jul 12, 2017 at 12:41 PM, Kurt Anders= en <kurta@drkurt.com> wrote:
On= Wed, Jul 12, 2017 at 11:38 AM, Terry Zink via arc-discuss <arc-discus= s@dmarc.org> wrote:
This structure has always bugged me:

> authentication-results:=C2=A0google.com; dkim= =3Dnone (message not signed)
>=C2=A0 header.d=3Dnone;google.com; dmarc=3Dnone action=3Dn= one header.from=3Dlinkedin.com;

What's= going on is that there are separate agents that do the DKIM evaluation and= the DMARC evaluation. Their output result is <recipient domain>; <= ;output of agent>. They are all concatenated onto the end of the Authent= ication-Results header. There isn't a "clean up" afterwards (= DKIM and DMARC agents individually may fail as well which gets even more co= nfusing, but at least one of them gets stamped). And on an outbound message= (which is what you see here), there is no SPF check so it just looks weird= .

I don't know if yo= u've see the other threads on the dmarc@ietf list, but the A-R header(s= ) and the content thereof have been a bit of an open item. If we were to re= create something other than RFC7601 to become the AAR header, do you have s= ome suggestions for a better approach?

--Kurt
<= /div>
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc


--001a113dbd7c04aea005542409eb-- From nobody Fri Jul 14 16:49:14 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 030CB12EC25 for ; Fri, 14 Jul 2017 16:49:13 -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 ANdcASsyxe9m for ; Fri, 14 Jul 2017 16:49:11 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::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 B0A0512EC17 for ; Fri, 14 Jul 2017 16:49:11 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id m84so32857391ita.0 for ; Fri, 14 Jul 2017 16:49:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=ugQ78IunjuLvgoeECf/7jlu2lsXjSS+ymFy1JsTR2js=; b=ffhgX0F9lPIgM/7usPAY3vV/FC5rsyCqk4a6I+Er2BlJo/jK42SG6YXpRR4xsFC02I 0cp6TSazHl/qxVEkXglkBkITbVQubufOda6I5EtB9i+qp2FztLgy2IdE4pmHGlb/mGAQ vZU4HCMgGSq4HjPfecjBHJ+0RZMcEFppv8rWmx3Z3X7pxyve1oxmldDhknNhgJTwqbXZ z4wposGJw91jJfRgUKP67RLAehUfV9BJtOFBNsIIwFR3m1R2ktIgf7usz7c3gAL9NcDk wVdXzl0MK69qfKIK0te2J3N2z+KM6gykDzL6rSquryqw1XgMF+iIUaZfeREWC6vcmd5n L9YA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ugQ78IunjuLvgoeECf/7jlu2lsXjSS+ymFy1JsTR2js=; b=dZ53Y1OuNCPltPe4RBq0o2IBEJs7l04ptdp6KhNvkhvnzIHpXqwWejv+R5N7wN2aa2 sk/cdjpO0e3nlhDqyPItKz0UlTrdG6/nVK6X0i5CbX7Z1CjFRf8zRwl0FN0771Bqeh9A 4t9D4xaDV1S4rRq4lQWKG64Zndueb+cMz/3M6rDqGYpIO6N7ZWZ8/+3Mg2zk5hxbTgrc 8/edPRqOnPgUEfSnfZA4483AfAYXsMAlkZwj824tXOtCxEhrZRtPJb5lNH+mpb1ywW/U vb86/aE4YYFXFWeh1bP/Llwn8WTuMG5wEHarbzYi2FAO6XEDpZffV//9N8ZIlMx3Mho1 1tnQ== X-Gm-Message-State: AIVw113eMQwufs/KEAd0vLPDDWPA/UmY+DetqJ1xRas2GYFjbF1jebpI 0YQAxVgBjMN6Rh7s+mWRbhW3mpyDADogfMY= X-Received: by 10.36.172.29 with SMTP id s29mr6205354ite.32.1500076150995; Fri, 14 Jul 2017 16:49:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.106.130 with HTTP; Fri, 14 Jul 2017 16:49:10 -0700 (PDT) From: Gene Shuman Date: Fri, 14 Jul 2017 16:49:10 -0700 Message-ID: To: dmarc@ietf.org Content-Type: multipart/alternative; boundary="94eb2c1f9ec01dd7a005544fb28d" Archived-At: Subject: [dmarc-ietf] working arc software for IETF hackathon X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2017 23:49:13 -0000 --94eb2c1f9ec01dd7a005544fb28d Content-Type: text/plain; charset="UTF-8" Hello, For those of you attending the IETF hackathon tomorrow, I have a list of some software packages that may be of use: ARC Test Suite - https://github.com/ValiMail/arc_test_suite has been updated & is conformant with the most recent version of the spec authentication-results-python - https://pypi.python.org/pypi/authres/1.0.0 now does minimal arc stamping authheaders - https://pypi.python.org/pypi/authheaders python library for general email authentication checks & signing. supports dmarc, arc, spf & dkim dkimpy - https://pypi.python.org/pypi?%3Aaction=pkg_edit&name=valimail-dkimpy this is a fork of dkimpy, as it wasn't able to get merged on time. Validates against the test suite Mailman - https://github.com/ValiMail/mailman/tree/arc This branch of mailman successfully arc signs & verifies messages. If you have any questions/issues, feel free to email me. Regards, =Gene --94eb2c1f9ec01dd7a005544fb28d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

For those of you attending the I= ETF hackathon tomorrow, I have a list of some software packages that may be= of use:


now does minimal arc stamping
=
python l= ibrary for general email authentication checks & signing. =C2=A0support= s dmarc, arc, spf & dkim

this is a fork of dkimpy, as it wasn't able to g= et merged on time.=C2=A0 Validates against the test suite

This branch= of mailman successfully arc signs & verifies messages. =C2=A0

If you have any questions/issues, feel free to email me. = =C2=A0

Regards,
=3DGene

--94eb2c1f9ec01dd7a005544fb28d-- From nobody Sat Jul 15 00:20:07 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85A15131AA6 for ; Sat, 15 Jul 2017 00:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ml14YX_0B9O for ; Sat, 15 Jul 2017 00:20:03 -0700 (PDT) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F93B1318A8 for ; Sat, 15 Jul 2017 00:20:02 -0700 (PDT) Received: by mail-ua0-x22c.google.com with SMTP id 46so83629uai.0 for ; Sat, 15 Jul 2017 00:20:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RZNRhqf4eFM2Q8UZ5NBdKoqCSH+gwkegZcFDJLCl6Ko=; b=BikDX4Dkbnlv5v8LdGFoFNJsJJXhQHqyoN/PT2ehlnsdX7zUOMd4xtKCvS5YBzJHp6 cIZMofg/ne0DzG0OrTQAE/izQAh4Q9mTdrU1LaDYVAgc8xtFCiAH8XMeqOqFPAtJSjf2 coG5Ed6EBW9dST/1GMUhJPo2pqot6hQEVp8Cw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RZNRhqf4eFM2Q8UZ5NBdKoqCSH+gwkegZcFDJLCl6Ko=; b=Cudv6oAT163HI/5Y11DUcFNnP2imUzgdO2BkK6BVcqXgHgp8tVGTeCMTOXwEbnJnE2 MmUdxw5yaW5U4uU4rimqcXppdmnkl3q94Mo8BxqW0YX9Bl1sa+6Dv/aFyQx55iysnboH EvfaCLbA4BB8/A72fFgxrwJ1nrmjBE6JVMd7ZKVajmycSMSZhM7OrKG4Ey5xG9JV/522 ZIfSnV9jnb2yZe2eBuof/ygjp+jKmVsIiyC06hfc9slTUqzv3P4WygEDfqf/xrqedzLM AkTONmuuGVlM05AbPmVEWArJqYMzDZJKnn1HgGY53iUk9oyOD7nv19olPibT36O1z80l 7eZg== X-Gm-Message-State: AIVw112IfJqKB3JGBubBBXIMYC/mGXBMCRK0br/6wZpMw2jFz+juxwJO qIjeWmbMalD52jFmh8J726wMH/DUpLNquko= X-Received: by 10.159.59.175 with SMTP id r47mr8217841uah.91.1500103201766; Sat, 15 Jul 2017 00:20:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.26.39 with HTTP; Sat, 15 Jul 2017 00:20:01 -0700 (PDT) In-Reply-To: <15b6aa31-5986-8573-d2fe-4d5dda209597@sapienti-sat.org> References: <8005ec7b-eb64-b542-3b74-539b7f42b1fb@andreasschulze.de> <1b50f7f0-36a1-a3f5-f6e1-5d03c0e4b779@andreasschulze.de> <76da3ccb-d147-3bb3-3442-0600d2466e08@andreasschulze.de> <15b6aa31-5986-8573-d2fe-4d5dda209597@sapienti-sat.org> From: Kurt Andersen Date: Sat, 15 Jul 2017 09:20:01 +0200 Message-ID: To: "dmarc@ietf.org" Cc: ARC Discussion , Juri Haberland Content-Type: multipart/alternative; boundary="f403043eb08477d4fc055455fe78" Archived-At: Subject: Re: [dmarc-ietf] [arc-discuss] openarc defer messages X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 07:20:05 -0000 --f403043eb08477d4fc055455fe78 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 12, 2017 at 2:56 PM, Juri Haberland via arc-discuss < arc-discuss@dmarc.org> wrote: > > I've seen now a couple of emails from Hotmail/Outlook.com being deferred by > OpenArc. Looks like Microsoft is experimenting with A-R headers, but they > get it wrong. > [elided] > But OpenArc defers mail with a valid empty A-R header, too: > > Authentication-Results: batleth.sapienti-sat.org; none > > I'll open a ticket about it on GitHub. > It seems like there is another problem here if OpenARC is trying to take a "foreign" A-R header and suck it into being "your" AAR header. The only auth results that should ever be trusted is the one you create (per RFC7601). --Kurt --f403043eb08477d4fc055455fe78 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Jul 12, 2017 at 2:56 PM, Juri Haberland via arc-discuss <arc-discu= ss@dmarc.org> wrote:

I've seen now a couple of emails from Hotmail/Outlook.com being deferre= d by
OpenArc. Looks like Microsoft is experimenting with A-R headers, but they get it wrong.
[elided]=C2=A0
But OpenArc defers mail with a valid empty A-R header, too:
> Authentication-Results: batleth.sapienti-sat.org; none

I'll open a ticket about it on GitHub.

<= div>It seems like there is another problem here if OpenARC is trying to tak= e a "foreign" A-R header and suck it into being "your" = AAR header. The only auth results that should ever be trusted is the one yo= u create (per RFC7601).

--Kurt=C2=A0
--f403043eb08477d4fc055455fe78-- From nobody Sat Jul 15 00:46:19 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7C85131B02 for ; Sat, 15 Jul 2017 00:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jigcnPOeS2Dw for ; Sat, 15 Jul 2017 00:46:16 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B1CC131761 for ; Sat, 15 Jul 2017 00:46:16 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id r125so56943958vkf.1 for ; Sat, 15 Jul 2017 00:46:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:from:date:message-id:subject:to; bh=DFS725ZB9fV2zeu3ZeMTcSd6SgNpPT8XlSmv8FyzwI8=; b=d5OHM+b6ToPhTkwrP+dKak5u9G/vTb8I8wMVg38DmJ7xHfYCavUGfdYPLAV4pl2vC0 cESKxaBWw6OkWphwMYGlShvw14z+wCbYKfhujO/PiZ2szUvnUhH5Jib9h3uC7apiDV4G arsp9Xvn1v4Kbjg6BptOua64+QKoRY+d1KtNg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=DFS725ZB9fV2zeu3ZeMTcSd6SgNpPT8XlSmv8FyzwI8=; b=tZoitUdjVQOzGkkpsi4YHmP1Hun/SloVseRfvWpngOUnVPlvjR4mxzDWXuqCcm7B1F Rdl5zboj6nqv6ZVW0ycnNf7gUeErCZI2YqsCsf+bK4AtohLB6G3eBOwq9Rjt85V9fEEu FZ+908wqnBp2auAZXN5aIrz3kqTS4Cuwy9oAHDJX3U15I2s86qikoMnF9mW0wyp7eoiu mhPgUD6uaZty4xA+7jREK4jcnv2aHU9/SpDVXhQWmApL9kkbqtmaODZgnK94TdSVBW4z dBGtCU8dW7ywKlMWOO9RzLtaVASzlKoJ5Qd8Lcu6mleMterj9BdPNe4NZu2yzvrhDvfD suNg== X-Gm-Message-State: AIVw113U0515e7bPuu4CauH2PUWcBCiLxJtD6WIYHQZlipFRaRepLCHP 1VDZDmhplinn2C7HEUQI6fs5srHkSQWzmY0EMg== X-Received: by 10.31.33.16 with SMTP id h16mr7210070vkh.103.1500104775148; Sat, 15 Jul 2017 00:46:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.26.39 with HTTP; Sat, 15 Jul 2017 00:46:14 -0700 (PDT) From: Kurt Andersen Date: Sat, 15 Jul 2017 09:46:14 +0200 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a11c0436a3fbd330554565c1d" Archived-At: Subject: [dmarc-ietf] Agenda for IETF99 F2F X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 07:46:18 -0000 --001a11c0436a3fbd330554565c1d Content-Type: text/plain; charset="UTF-8" If there are any missing items, please let us know as early as you can. Here's the proposed agenda: https://datatracker.ietf.org/meeting/99/agenda/dmarc/ --Kurt --001a11c0436a3fbd330554565c1d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If there are any missing items, please let us know as earl= y as you can. Here's the proposed agenda:=C2=A0https://datatracker.ietf.org/meet= ing/99/agenda/dmarc/

--Kurt
--001a11c0436a3fbd330554565c1d-- From nobody Sat Jul 15 00:53:30 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B52EB131B03 for ; Sat, 15 Jul 2017 00:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nOZweVbvnMC9 for ; Sat, 15 Jul 2017 00:53:26 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c: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 A21C5131B02 for ; Sat, 15 Jul 2017 00:53:26 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id r125so56982023vkf.1 for ; Sat, 15 Jul 2017 00:53:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ayEXIdZir2rpu58mkltstwxd8uH2tP6HiiCgMlCjL4w=; b=Q50fEZWfHe53r6JxkGU7POrSJQ5LiU3XSksStiqNIY8PPjEfuLlLOT/jjzaTCkE54l HtYY1qM0iMcFkXSQq0HCsNsDvlujuyePbYzK1G7Ln8mL49izV0NNw/SaIBMh84sH8PYX QHPJ65ydskN2tH4hFbo2z5bFQmUANPapiNxn0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ayEXIdZir2rpu58mkltstwxd8uH2tP6HiiCgMlCjL4w=; b=aai0oVzxY6mvNdz6DKnc+b87t25OyKAFmJLBVwXpdPqecKvRKjn+J2oeW8PlSayzzP 6gJRMUvVv6sUnVZq6iL01u3eRvrGSS9tF4EybUMdKlR/lwjIPdv/Fke2V7Ee8FQNPjDs t0xJifBRIAaDjHk8UYvHPf8eUID0QoIrpAwNsNY+mtnKBOrerrQQ8gSuR9ZZpc67OUHc OPhGzVxWtdAdEFbkqocgWVi8rMB7zAJ9NIOeYoSQuv8YBcewRqMPPU8G74IJmQGY2vVn 93S1W6eh3CFhoYsmpDrW5gmXB3bC5KnFBvxKnBY3PNAxgEN7MP1rPuieMS+veel+XQVU GoKg== X-Gm-Message-State: AIVw1105nxDq8Sk3boK4JVg287v65acxWSS13Pt0R5TlmgMhIIo/xP4J 4QbL3E+PNwrQz8v0ReScwEflOKTdsDmf X-Received: by 10.31.108.133 with SMTP id j5mr7597771vki.152.1500105205708; Sat, 15 Jul 2017 00:53:25 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.176.26.39 with HTTP; Sat, 15 Jul 2017 00:53:25 -0700 (PDT) In-Reply-To: References: From: "Kurt Andersen (b)" Date: Sat, 15 Jul 2017 09:53:25 +0200 X-Google-Sender-Auth: vqVyAmtbBttNGRx_6Auy5hJKabQ Message-ID: To: Gene Shuman Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a11478364e98d31055456757b" Archived-At: Subject: Re: [dmarc-ietf] working arc software for IETF hackathon X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 07:53:29 -0000 --001a11478364e98d31055456757b Content-Type: text/plain; charset="UTF-8" On Sat, Jul 15, 2017 at 1:49 AM, Gene Shuman wrote: > Hello, > > For those of you attending the IETF hackathon tomorrow, I have a list of > some software packages that may be of use: > > > > Mailman - https://github.com/ValiMail/mailman/tree/arc > This branch of mailman successfully arc signs & verifies messages. > > If you have any questions/issues, feel free to email me. > Gene, Thanks for the list of resources. A question for you regarding the ARC patch to mailman: does this provide any hook in mailman suppressing any bounce handling for any messages rejected due to DMARC or other auth handling by recipients that may not be ARC-aware? --Kurt --001a11478364e98d31055456757b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= at, Jul 15, 2017 at 1:49 AM, Gene Shuman <geneshuman@gmail.com><= /span> wrote:
Hello,
For those of you attending the IETF hackathon tomorrow, I h= ave a list of some software packages that may be of use:

<elided>=C2=A0

This branch of = mailman successfully arc signs & verifies messages. =C2=A0
If you have any questions/issues, feel free to email me. =C2= =A0

=C2=A0Gene,

<= /div>
Thanks for the list of resources. A question for you regarding th= e ARC patch to mailman: does this provide any hook in mailman suppressing a= ny bounce handling for any messages rejected due to DMARC or other auth han= dling by recipients that may not be ARC-aware?

--K= urt
--001a11478364e98d31055456757b-- From nobody Sat Jul 15 01:27:17 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 268F7131B72 for ; Sat, 15 Jul 2017 01:27:16 -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 (2048-bit key) header.d=sapienti-sat.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 O-h25TsydEQd for ; Sat, 15 Jul 2017 01:27:15 -0700 (PDT) Received: from batleth.sapienti-sat.org (batleth.sapienti-sat.org [IPv6:2a01:4f8:131:20a1::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA00A131B03 for ; Sat, 15 Jul 2017 01:27:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sapienti-sat.org; h=content-transfer-encoding:content-language:content-type :content-type:in-reply-to:mime-version:user-agent:date:date :message-id:from:from:references:subject:subject; s= dkim20170413; t=1500107231; bh=jjiqEIpaf0foSYHCSklLxSO3kVCpKCcyn nHIdKnzZrE=; b=nLNM1/tmDbWfZg+Dk1pYNi3TOzOKj2UXTX+ojK7KcVYlDoLVZ iwVzx4j8DDuHA0w3IWuirVgW43Ktql+duLcBzagz2Oor6KkIv/L6VDTR6zHWQLx6 +Dps7MAeN4OZWZKPfsYfI97nL8btCKcI/f8AG8siiOLdSKZmURazbY+Y+s/ydbeI fgA5RwNwvJaAoV3zU8EgUHVDUpUrLpRvOne+kfHr7Wfb0FPDaT9kRTb5UsQk2gvY 5KmRrUtxqdqLONoa8R4hWNlKKvzmSxz8GZQwBrMyaRIuOYHfNcvzLuPPLSUxF95v JH6YVGPFK3ILLjnSchhgH+VrGxs9+r7ZnVULQ== X-Virus-Scanned: Debian amavisd-new at sapienti-sat.org Received: from [IPv6:2003:d9:b3c3:c900:25c9:9764:b512:4859] (p200300D9B3C3C90025C99764B5124859.dip0.t-ipconnect.de [IPv6:2003:d9:b3c3:c900:25c9:9764:b512:4859]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: juri@sapienti-sat.org) by batleth.sapienti-sat.org (Postfix) with ESMTPSA id 38FBB33E08BB; Sat, 15 Jul 2017 10:27:11 +0200 (CEST) To: Kurt Andersen , "dmarc@ietf.org" Cc: ARC Discussion References: <8005ec7b-eb64-b542-3b74-539b7f42b1fb@andreasschulze.de> <1b50f7f0-36a1-a3f5-f6e1-5d03c0e4b779@andreasschulze.de> <76da3ccb-d147-3bb3-3442-0600d2466e08@andreasschulze.de> <15b6aa31-5986-8573-d2fe-4d5dda209597@sapienti-sat.org> From: Juri Haberland Message-ID: Date: Sat, 15 Jul 2017 10:27:10 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] [arc-discuss] openarc defer messages X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 08:27:16 -0000 On 15.07.2017 09:20, Kurt Andersen wrote: > It seems like there is another problem here if OpenARC is trying to take a > "foreign" A-R header and suck it into being "your" AAR header. The only > auth results that should ever be trusted is the one you create (per > RFC7601). OpenARC parses all A-R headers and reads them into a structure - one by one. After an A-R header is parsed, the AuthServID is compared and if it matches, the parsed A-R header is further used - else it is ignored. So no problem here. Juri From nobody Sat Jul 15 01:33:47 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 889EA131B72 for ; Sat, 15 Jul 2017 01:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XyA_su6tQj2N for ; Sat, 15 Jul 2017 01:33:43 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23D3F127058 for ; Sat, 15 Jul 2017 01:33:43 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id f68so53419094vkg.2 for ; Sat, 15 Jul 2017 01:33:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XJK13GjZY+9hqgObkerkGXgMdVtXF/fftGiJivdnSeU=; b=J5F+pOBW+vEsMGW1q2RO1377fxcSQIfozw64kz+8G36IzsR5yUXI+5YuXO3/zs2I9g DHuQomQ1CSD61bd0VIQKT6upRn4jPdXe6U8IijGygRcI9k3IRZ4uMUtlqE5GdTUQlUEI xyObpV4CKRNgs4Gro0t5qxfjmLVuu5v14l1+E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XJK13GjZY+9hqgObkerkGXgMdVtXF/fftGiJivdnSeU=; b=fd2SbtlFZCmNH0Q2c1Ow1YIhyavDqmHwW3REINL9tjdoCV8oN7s5ldNO4k6bCPIU8M WCcWnRlMkoIDaTOC0UEvFOsaDQUouQr7PZzw7XKw3MRw13SB5ngkSFBTAKYgkz9YxcyY GqHjUXwcldq0idbLH9LlF4LPDur88OhkFmpvQZzv7qETnye0EnK+j1SO2XZZB2aNC9Rc RvV4QkJcWAR5z6stppVf2rpQQ+gk07BkSn0rh7wSPbNdw4J13L3u8cfw4Lzb4pIbWiag EKuNSh+7wIPTC5zxNjfWGM/VNvEz/kI4RlER5jAN/DpjN+WWmF7E1yqxkIo6F3Iut54r TodQ== X-Gm-Message-State: AIVw113kSDQqnQSRLS6XMRLNGkmCrppKoYy8pf/cTyaG6m2SSJn4n+2W RQUcLCpe7xcRPRA/KDtwBOpAB3cuNn67RiV5mw== X-Received: by 10.31.33.16 with SMTP id h16mr7272045vkh.103.1500107622081; Sat, 15 Jul 2017 01:33:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.26.39 with HTTP; Sat, 15 Jul 2017 01:33:41 -0700 (PDT) In-Reply-To: References: <8005ec7b-eb64-b542-3b74-539b7f42b1fb@andreasschulze.de> <1b50f7f0-36a1-a3f5-f6e1-5d03c0e4b779@andreasschulze.de> <76da3ccb-d147-3bb3-3442-0600d2466e08@andreasschulze.de> <15b6aa31-5986-8573-d2fe-4d5dda209597@sapienti-sat.org> From: Kurt Andersen Date: Sat, 15 Jul 2017 10:33:41 +0200 Message-ID: To: Juri Haberland Cc: "dmarc@ietf.org" , ARC Discussion Content-Type: multipart/alternative; boundary="001a11c0436af07ced0554570599" Archived-At: Subject: Re: [dmarc-ietf] [arc-discuss] openarc defer messages X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 08:33:44 -0000 --001a11c0436af07ced0554570599 Content-Type: text/plain; charset="UTF-8" On Sat, Jul 15, 2017 at 10:27 AM, Juri Haberland wrote: > On 15.07.2017 09:20, Kurt Andersen wrote: > > > It seems like there is another problem here if OpenARC is trying to take > a > > "foreign" A-R header and suck it into being "your" AAR header. The only > > auth results that should ever be trusted is the one you create (per > > RFC7601). > > OpenARC parses all A-R headers and reads them into a structure - one by > one. After an A-R header is parsed, the AuthServID is compared and if it > matches, the parsed A-R header is further used - else it is ignored. > > So no problem here. > > Juri > But if the parsing fails, then it was hanging and causing message deferral, even if the AuthServID would have disqualified that header from being used further? --Kurt --001a11c0436af07ced0554570599 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --001a11c0436af07ced0554570599-- From nobody Sat Jul 15 02:28:24 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A63D131B03 for ; Sat, 15 Jul 2017 02:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sapienti-sat.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 OkDooET8htJ1 for ; Sat, 15 Jul 2017 02:28:22 -0700 (PDT) Received: from batleth.sapienti-sat.org (batleth.sapienti-sat.org [IPv6:2a01:4f8:131:20a1::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAE7412EC4B for ; Sat, 15 Jul 2017 02:28:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sapienti-sat.org; h=content-transfer-encoding:content-language:content-type :content-type:in-reply-to:mime-version:user-agent:date:date :message-id:from:from:references:subject:subject; s= dkim20170413; t=1500110898; bh=wb0J4MBZWQMnv17dRLenSXIluKrSW+IH1 aHxX9dgloA=; b=ghlpllRR/x6TYkomkHH34N8zA/EtBrWjPZ3NAU7I0AgxqM/FN BSkc9RJEzf3bwT70pE+OUgK0VifdMcznaAmn5KZTPNb5v5d7uf86sIpqZ2wh2r0R Z6ppy5zI71McI5ADZez1SuPdx/WoiDj2edjzzqV+dnm/NpDHKDbzQlJouT0SgOvd yWCOp/H6iwsBm3e5pwvzcvcyyAmQ5L90O2z/FTiCUfcO0TVkpL3oQg6TnqCHLHDt 9JmysgIBS3EfrD4XKpWAp1nQboa0C8bXT4oJ8od8FOLLap5JSIX1/z+4tXzri21a ASUMZ5lZW7iGH5N+cqyM7SBBr3jEM27T7h3Rw== X-Virus-Scanned: Debian amavisd-new at sapienti-sat.org Received: from [IPv6:2003:d9:b3c3:c900:25c9:9764:b512:4859] (p200300D9B3C3C90025C99764B5124859.dip0.t-ipconnect.de [IPv6:2003:d9:b3c3:c900:25c9:9764:b512:4859]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: juri@sapienti-sat.org) by batleth.sapienti-sat.org (Postfix) with ESMTPSA id AFB0233E08BB; Sat, 15 Jul 2017 11:28:18 +0200 (CEST) To: Kurt Andersen Cc: "dmarc@ietf.org" , ARC Discussion References: <8005ec7b-eb64-b542-3b74-539b7f42b1fb@andreasschulze.de> <1b50f7f0-36a1-a3f5-f6e1-5d03c0e4b779@andreasschulze.de> <76da3ccb-d147-3bb3-3442-0600d2466e08@andreasschulze.de> <15b6aa31-5986-8573-d2fe-4d5dda209597@sapienti-sat.org> From: Juri Haberland Message-ID: <0fbf94e0-ab8d-e5c8-e4d0-e88ea83b10d7@sapienti-sat.org> Date: Sat, 15 Jul 2017 11:28:18 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] [arc-discuss] openarc defer messages X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 09:28:24 -0000 On 15.07.2017 10:33, Kurt Andersen wrote: > On Sat, Jul 15, 2017 at 10:27 AM, Juri Haberland > wrote: > >> On 15.07.2017 09:20, Kurt Andersen wrote: >> >> > It seems like there is another problem here if OpenARC is trying to take >> a >> > "foreign" A-R header and suck it into being "your" AAR header. The only >> > auth results that should ever be trusted is the one you create (per >> > RFC7601). >> >> OpenARC parses all A-R headers and reads them into a structure - one by >> one. After an A-R header is parsed, the AuthServID is compared and if it >> matches, the parsed A-R header is further used - else it is ignored. >> >> So no problem here. > But if the parsing fails, then it was hanging and causing message deferral, > even if the AuthServID would have disqualified that header from being used > further? It was not hanging, it returned a temp failure to the MTA on purpose (in all cases where OpenARC cannot parse an A-R header) - which is debatable... I have created a pull request to just skip such headers, see https://github.com/mskucherawy/OpenARC/pull/42 Juri From nobody Sat Jul 15 02:43:44 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62BC7129B2C for ; Sat, 15 Jul 2017 02:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NYUGy-6y3b7 for ; Sat, 15 Jul 2017 02:43:42 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2890126CD8 for ; Sat, 15 Jul 2017 02:43:41 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id 35so16573729uax.3 for ; Sat, 15 Jul 2017 02:43:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9STKj6AAO4m8cR4iGDuzo0MRIJZfbEcp4ffN4gCPMIc=; b=NdEdbKv7SiHmM1MALnO8ZDQtM0bCcXFhK8x3tkilsphs9AEewIR7KQxGMrg4mgkH9B eMq1bW+44rTysqb+dT0KYMb3v4gqpnrQ6m6C+3Y+q7WQcuUqZ41A/1j42ABvGVwIEvii HTfcVUnSsT9x0QE9iuIUNBVOunXLiYwniQCp8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9STKj6AAO4m8cR4iGDuzo0MRIJZfbEcp4ffN4gCPMIc=; b=o9sY5w9+fDNGJrKr09HRuHVd4tWbPI8WHHWhPA/A8rTiKslAQ5IZMyQbbnpd01V6ay c+ekqJXl7t5P3Whhq3JwPzLwWBX7zL9p09pnLpZERBP2UYapU1lIGEx3ipFBT7LvhqZ/ clvU8Eo0P03oaVEYb8HvMn5+NxVHluNYHOvCJQGCN5DLo2vHcEhsMJmQkNRTELUFYl7g Oca8yJxi0z6EN2ulOJRWUxiAsdFgyZ3nQOYVoyRJliIA5WEcgpTgMN9cdJj4hsZrmQBY UFF4KNPBOuguzaTtJSJGQhwcRhxKPOdYSPsTD6iNHAmOwgtqcKMVT0vjzas32+KxvE5m kAKQ== X-Gm-Message-State: AIVw113l73oj6rGQnqCe7cSwAnqV1cy2x65myDVTf6GQ51c0kcPICO2W ijn9dRJwbfzJWdKf9Ofwz2VSI3QuzM+L X-Received: by 10.176.75.28 with SMTP id h28mr8011679uaf.133.1500111820912; Sat, 15 Jul 2017 02:43:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.26.39 with HTTP; Sat, 15 Jul 2017 02:43:40 -0700 (PDT) In-Reply-To: <0fbf94e0-ab8d-e5c8-e4d0-e88ea83b10d7@sapienti-sat.org> References: <8005ec7b-eb64-b542-3b74-539b7f42b1fb@andreasschulze.de> <1b50f7f0-36a1-a3f5-f6e1-5d03c0e4b779@andreasschulze.de> <76da3ccb-d147-3bb3-3442-0600d2466e08@andreasschulze.de> <15b6aa31-5986-8573-d2fe-4d5dda209597@sapienti-sat.org> <0fbf94e0-ab8d-e5c8-e4d0-e88ea83b10d7@sapienti-sat.org> From: Kurt Andersen Date: Sat, 15 Jul 2017 11:43:40 +0200 Message-ID: To: Juri Haberland Cc: "dmarc@ietf.org" , ARC Discussion Content-Type: multipart/alternative; boundary="f403045e80aa3591f90554580008" Archived-At: Subject: Re: [dmarc-ietf] [arc-discuss] openarc defer messages X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 09:43:43 -0000 --f403045e80aa3591f90554580008 Content-Type: text/plain; charset="UTF-8" On Sat, Jul 15, 2017 at 11:28 AM, Juri Haberland wrote: > On 15.07.2017 10:33, Kurt Andersen wrote: > > > But if the parsing fails, then it was hanging and causing message > deferral, > > even if the AuthServID would have disqualified that header from being > used > > further? > > It was not hanging, it returned a temp failure to the MTA on purpose (in > all cases where OpenARC cannot parse an A-R header) - which is debatable... > I have created a pull request to just skip such headers, see > https://github.com/mskucherawy/OpenARC/pull/42 > Yes, I saw your PR but had not looked at the details - thanks very much! --Kurt --f403045e80aa3591f90554580008 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
--Kurt
<= /div> --f403045e80aa3591f90554580008-- From nobody Sat Jul 15 09:22:05 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 497FA1318A2 for ; Sat, 15 Jul 2017 09:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id anX3vYbLpEG5 for ; Sat, 15 Jul 2017 09:22:02 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54828131562 for ; Sat, 15 Jul 2017 09:22:02 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id r126so59994831vkg.0 for ; Sat, 15 Jul 2017 09:22:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LnZ5HD4RLgrznXLWWPGYp8IIb1TqmuVQQ/qeFX9+bEw=; b=GDY4U/3VVTFPVRacSgFJYc7Kn4BBEktR2HYziAFraelY/E8l4GVclkAo9WX5GAAOki 24SDo0vTUYaeWpHSV5nsUuqWkmdF3zxVPTgjEkpTLn86Orxu3+6YdMuHRBT3W4CgXltV q3R/tUCQNC5tCDmTPHga88kRLJ4RP8Ti/J/y1Sh6PXa7xvxi2h1H1TKIuUEMiPAFVZVT NSSMVd0vORlwiHoGkIZjfQUAt/gumajCyP+/lP1IhyAM9sJqPG/JGiEFFuKROqePuwnU oGv5lgKSXacoLTicO/FT5/uaBq24axhP7TtJGRVgfB/VV8MCoPO+NO60ZRRBZdak9mO6 e8Iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LnZ5HD4RLgrznXLWWPGYp8IIb1TqmuVQQ/qeFX9+bEw=; b=l4HODZLVkhbGYYvoewCRU8GSJsLuTYA+ee7XtPLfxgC6gtvXD5mqda3g6vPY0qfUeD 3hpVcSXAmmQ4Mmvk2ehEvRf0bZ4IP7kwJSHXKTR3nksw9glkoCUJR1svEe+VJrIKTuyH txukVz5dk7SpqARV4pQF1mYuMgHynfW+d0HnJleKq4mXdTByHu7D+3iPfcv6oygi3RLe vMuAz7IZquAC8vaOLrmhdCLweOTC0x0MLWKezPTFmAh1MpUyxGiAQFo5IQSI2tJeW1ks sJm4pHZAG9TnAKNqzyHFzvnqLxY0KjjqWptZnM5KFQv68sWlKeozV4kY+aehPMwDjxLM XwRQ== X-Gm-Message-State: AIVw1111+pTIo5XanohiEjSOMuMRgumdRyrVRs89PJwhhO1suOkwdJ0N y02NI0SuGmEZUpO/izzMQPLtkEWXqcmw X-Received: by 10.31.209.199 with SMTP id i190mr8223384vkg.125.1500135721519; Sat, 15 Jul 2017 09:22:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.126.196 with HTTP; Sat, 15 Jul 2017 09:22:00 -0700 (PDT) In-Reply-To: References: From: "Murray S. Kucherawy" Date: Sat, 15 Jul 2017 09:22:00 -0700 Message-ID: To: Kurt Andersen Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a114e6e18cbd16305545d90a7" Archived-At: Subject: Re: [dmarc-ietf] Agenda for IETF99 F2F X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 16:22:04 -0000 --001a114e6e18cbd16305545d90a7 Content-Type: text/plain; charset="UTF-8" Why is OpenARC's status an IETF agenda item? On Sat, Jul 15, 2017 at 12:46 AM, Kurt Andersen wrote: > If there are any missing items, please let us know as early as you can. > Here's the proposed agenda: https://datatracker. > ietf.org/meeting/99/agenda/dmarc/ > > --Kurt > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --001a114e6e18cbd16305545d90a7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Why is OpenARC's status an IETF agenda item?
=

On Sat, Jul 15, 2= 017 at 12:46 AM, Kurt Andersen <kurta@drkurt.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
If there are any missing ite= ms, please let us know as early as you can. Here's the proposed agenda:= =C2=A0https://datatracker.ietf.org/meeting/99/agenda/dma= rc/

-= -Kurt

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


--001a114e6e18cbd16305545d90a7-- From nobody Sat Jul 15 09:23:59 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F8C4128CFF for ; Sat, 15 Jul 2017 09:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvn1eqMvYX6M for ; Sat, 15 Jul 2017 09:23:50 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B1961317BB for ; Sat, 15 Jul 2017 09:23:50 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id y70so59496198vky.3 for ; Sat, 15 Jul 2017 09:23:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ti3wwYNaeyclk66VjcIlhyEcpObultZOuyHGBwUQNpA=; b=Uc1unZZvAD+++D9ZsrYnavbMNW28SoX9wu0rXB6o+bTdu54SM4hzIXqodfi8puVGAa BzUoGG6qY+ifjGKybsaJZ5x+QXzh8oXS4t8PeIdTU+SjTiRJEcrT+uZdbta1p25k9i6J +SbgGxYy4AAcAF6ybtZx9AcQyD76fatQ7TrWEUDJ9MxyC/bYCNgSuquzdfKL/crvBSXn DlNgVOh19M7rdpLt8JgEJwUOLzLRz6h29jcGjEzk7kMSrcxqKD/jSiZ4TAUwTjS30W1b CQwG2Aa0wcKYmY87idXbv1tVfr0J9JxUfsehLdo5VFRrd9KspTpzwYiVse9REwv/2Zfn IzjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Ti3wwYNaeyclk66VjcIlhyEcpObultZOuyHGBwUQNpA=; b=YrbmOmFp3sSRFHOytihsMQzT6oCxChMzGxJM6PyOs2/R4sesK0qh+1D+RQitMCU+S9 MyXIbqwOkO3fNFjLlXTizg9vtXlgqFYZNqN5T12nHqCcYQkrbm2hk3x8ISDAYcsZ1YCU ac17d+riEvgoP7JpfDXHOqRLfSeIZSUDRHsSxAaJlCxOCC4oNJX7oOm3MieOMZxzpm2K fdDtgt+XTqe/32KgTaZB29adBvQgTuh78i4Wh32U9QRIg3G95VP9GTpYI8uSJ7QaOWku 58UpKZKiuvl9jVozKI5ZtlW/H8FzrpYN0TwSgRmjpjE9v2qkTmUP/3ukcNn3Z6b67ejt lfkw== X-Gm-Message-State: AIVw1136a+li327JNpzV3KNfsiASbT2KQsZw8PNDz34tUcIDZCNGDYRS ljikmkZAgyHqflURMQSURQ4zgh5jiQ== X-Received: by 10.31.232.7 with SMTP id f7mr8302068vkh.32.1500135829671; Sat, 15 Jul 2017 09:23:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.126.196 with HTTP; Sat, 15 Jul 2017 09:23:48 -0700 (PDT) In-Reply-To: References: <8005ec7b-eb64-b542-3b74-539b7f42b1fb@andreasschulze.de> <1b50f7f0-36a1-a3f5-f6e1-5d03c0e4b779@andreasschulze.de> <76da3ccb-d147-3bb3-3442-0600d2466e08@andreasschulze.de> <15b6aa31-5986-8573-d2fe-4d5dda209597@sapienti-sat.org> <0fbf94e0-ab8d-e5c8-e4d0-e88ea83b10d7@sapienti-sat.org> From: "Murray S. Kucherawy" Date: Sat, 15 Jul 2017 09:23:48 -0700 Message-ID: To: Kurt Andersen Cc: Juri Haberland , "dmarc@ietf.org" , ARC Discussion Content-Type: multipart/alternative; boundary="94eb2c093ad23e187e05545d97ec" Archived-At: Subject: Re: [dmarc-ietf] [arc-discuss] openarc defer messages X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 16:23:55 -0000 --94eb2c093ad23e187e05545d97ec Content-Type: text/plain; charset="UTF-8" On Sat, Jul 15, 2017 at 2:43 AM, Kurt Andersen wrote: > On Sat, Jul 15, 2017 at 11:28 AM, Juri Haberland > wrote: > >> On 15.07.2017 10:33, Kurt Andersen wrote: >> >> > But if the parsing fails, then it was hanging and causing message >> deferral, >> > even if the AuthServID would have disqualified that header from being >> used >> > further? >> >> It was not hanging, it returned a temp failure to the MTA on purpose (in >> all cases where OpenARC cannot parse an A-R header) - which is >> debatable... >> I have created a pull request to just skip such headers, see >> https://github.com/mskucherawy/OpenARC/pull/42 >> > > Yes, I saw your PR but had not looked at the details - thanks very much! > I don't think OpenARC development details are appropriate for the IETF list, are they? -MSK --94eb2c093ad23e187e05545d97ec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Jul 15, 2017 at 2:43 AM, Kurt Andersen <kurta@dr= kurt.com> wrote:
On Sat, Jul 15, 20= 17 at 11:28 AM, Juri Haberland <juri@sapienti-sat.org> w= rote:
On 15= .07.2017 10:33, Kurt Andersen wrote:

> But if the parsing fails, then it= was hanging and causing message deferral,
> even if the AuthServID would have disqualified that header from being = used
> further?

It was not hanging, it returned a temp failure to the MTA on purpose= (in
all cases where OpenARC cannot parse an A-R header) - which is debatable...=
I have created a pull request to just skip such headers, see
https://github.com/mskucherawy/OpenARC/pull/42

Yes, I saw your PR but had not looked at the details - thanks very much!

--94eb2c093ad23e187e05545d97ec-- From nobody Sun Jul 16 00:51:35 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAB531275AB for ; Sun, 16 Jul 2017 00:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id joWqjwr-jKtL for ; Sun, 16 Jul 2017 00:51:32 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81BCA127180 for ; Sun, 16 Jul 2017 00:51:32 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id 21so12675854qtx.3 for ; Sun, 16 Jul 2017 00:51:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=JD/vYGiXIT6uNyjCkC5gL6bkJLYpNGGylAZ+FFdAN34=; b=awdQu+PmGOqbV8zXiZU2HjRqOeISSn/Y8eQkhMuAc7Nc+W5hrgKXCs5oTxjMzdGguJ khxj1WFwUUllEZV55Hey78gJaepqQLzOlIWxXhz+K3lUWnjXBJpSmk/VY49GH5IC0Dsd SSoCQPIgpXd6oMcYGK/ab+FsuNF49Dvech7pwJiGoNDXutxrytjsy0NNy4mhorrlesoI jKwz8tWg/XDD9RQTUtHc0AAHSUZpblUgkOI12n/dB62b53t13nqXrSTwUcLd+EjxMGo/ CA0cJ+v+ImGPUILUcQxD2YCz40fWFG3ZykONC7tE6Os0ObD8awIQl1D/cd8HfsmRLz6D 7DJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=JD/vYGiXIT6uNyjCkC5gL6bkJLYpNGGylAZ+FFdAN34=; b=Lhj+ooTjoQHTO+rgGeZd8LwNZOoFrvnBOb6hXrZepbX3Otjak6s5Ej1I/PajOD57Ms CrPGHqjLBwkfchJHBDIx9JLmsZI1KrvZO2svxyxrupxVSlMWWSmdEysdhUTGL4JY4jVL JlA43IBOSLqHCyD9JEijD9Jq+/Dl8bDSifgeGvhFEcikIy1OVkkEbAuRDluzwga3yUQD KKP3W20rgDK+f5LKXAEVQnurtkjJoA+bpiv+RiBj7EI3YOKssQBHEywxUMav+wyEhhe7 VO5LzZuvIfXv02YD2L/t1U1aqlT8FJRcsVmRPSDbJViXMrhDuosJbLYB27uYvRyU/vEn +1mw== X-Gm-Message-State: AIVw111UaA0ix4seccHUwhv658uytJlABtedtO6O3w121yl6bSbxfTmr JXRtDwJBaaIDTfMdNOuTjVcXFLGS2w== X-Received: by 10.237.38.195 with SMTP id q61mr22410208qtd.245.1500191491763; Sun, 16 Jul 2017 00:51:31 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 10.200.37.40 with HTTP; Sun, 16 Jul 2017 00:51:31 -0700 (PDT) In-Reply-To: References: From: Barry Leiba Date: Sun, 16 Jul 2017 09:51:31 +0200 X-Google-Sender-Auth: KBtzgpQw5vV_0LyEjW5iaXmxuHQ Message-ID: To: "Murray S. Kucherawy" Cc: Kurt Andersen , "dmarc@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [dmarc-ietf] Agenda for IETF99 F2F X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 07:51:34 -0000 > Why is OpenARC's status an IETF agenda item? Because someone in the working group asked for a summary, and I thought it would be a quick and easy agenda item. If you object to giving a status report in the session, I'll strike it. Barry From nobody Sun Jul 16 00:53:38 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A50411275AB for ; Sun, 16 Jul 2017 00:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhuVYtobscVl for ; Sun, 16 Jul 2017 00:53:36 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64DB6127180 for ; Sun, 16 Jul 2017 00:53:36 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id d78so101898697qkb.1 for ; Sun, 16 Jul 2017 00:53:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=/pzvKnKFt8eOTRlAMmlE+QM0eFWueZY2QVB+Om/sRw0=; b=Y3+EYQeWHEIMAepVUStNxhrpEmioGVF4yZhrV25ZEykR8POMVv3bDu/kNyGfHYEshT A1AVI7YxF9Z0VhQ3azU48MiPrEWv1sKuqyCbGf+eICDEFBoNmrBY+AKB28prEy6ueE1F K2z+pm9sxSZO9Ok/4b2M6OtHGzq+ymIbCvVlnrEJ7Y8NRcOtQxgk0E0zmNvBM0fzOCm5 kpab0JxLEP6Nek/JeH+/TKpvw+sxOz6lCbFfx1UjNVQZ78QqGzq6RhAB6aW4hSK+HNeQ OJfzdP5ut4gytxJm65fIxNC51/0ZhWCoU0aDUotNi8jobad0c7NuEDcuvS2ZK/Zg5Rf8 EMlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=/pzvKnKFt8eOTRlAMmlE+QM0eFWueZY2QVB+Om/sRw0=; b=pdq7uIxJPKW5XOATf+2PkhTzyfyjn2Cgs0BtKxmSUyYRHr0RuUjCi5lekl60jtOxa8 La0O1s2dft/8H5ZiDQUUn+XzPT21q455ZDMZp/dsGtKiucYyu+yXAR546QtNfz3jVlw+ /jCKKTMuCfAHgkRceH+m8+gx71M2ggqM+kORuET4rHfsq3zcS6w0FlD/26eiHyabCwDF 9sox4R7O+yVRCZBiyw2DA8dzlcDfQ+Umce/9WVhGm8cjc3OoOuAP50t0+pYFJNUxLaME faKv3PwKVuEG8hCdS+ZUSk+l8Z54ZUKUDLOs4w1l1dbOI1FyRXz6mUla/9MDx94Yma33 S81w== X-Gm-Message-State: AIVw113n0IHF1ZEjGMz8oHctI090lA8sHB0zB2+HSutCtH0R2kIhIHEW uoM2GEnn8ocpokcsMakcDjomjeopIg== X-Received: by 10.233.235.3 with SMTP id b3mr21695026qkg.138.1500191615643; Sun, 16 Jul 2017 00:53:35 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 10.200.37.40 with HTTP; Sun, 16 Jul 2017 00:53:35 -0700 (PDT) In-Reply-To: References: <8005ec7b-eb64-b542-3b74-539b7f42b1fb@andreasschulze.de> <1b50f7f0-36a1-a3f5-f6e1-5d03c0e4b779@andreasschulze.de> <76da3ccb-d147-3bb3-3442-0600d2466e08@andreasschulze.de> <15b6aa31-5986-8573-d2fe-4d5dda209597@sapienti-sat.org> <0fbf94e0-ab8d-e5c8-e4d0-e88ea83b10d7@sapienti-sat.org> From: Barry Leiba Date: Sun, 16 Jul 2017 09:53:35 +0200 X-Google-Sender-Auth: sVO6BHVWilBzwvWhtWoyBFeJ4fg Message-ID: To: "Murray S. Kucherawy" Cc: Kurt Andersen , "dmarc@ietf.org" , ARC Discussion , Juri Haberland Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [dmarc-ietf] [arc-discuss] openarc defer messages X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 07:53:38 -0000 > I don't think OpenARC development details are appropriate for the IETF list, > are they? For extended discussion, perhaps not, but it speaks to running code. If discussion of implementations can lead to a better understanding of the spec, or fixes to the spec, or whatever, tant mieux. Barry From nobody Sun Jul 16 03:28:43 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB5D12EBF9; Sun, 16 Jul 2017 03:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kK7lfQJATpRn; Sun, 16 Jul 2017 03:28:41 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::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 4C9AB126B6E; Sun, 16 Jul 2017 03:28:41 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id v202so38244222itb.0; Sun, 16 Jul 2017 03:28:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=sgZZ1ewuEIfpvbmrwlW/het3gskfd4J/Bjm1gd2Mn14=; b=u5ov6mavMQgGlqtykLOPjOeC77wmLr/z9rYPO43dGvKGM2rSJ3JYzkRmTdncHM87Un vR7AuRR5qZgCfw+1Mxb0ow5mCAJpxOSgcID8Mz2+s+P6Pn7przB0cGhuiFmXUZcu3Cor zQjvwMior1/5MWJMrCmNq8ZfML7UrodCsrl9SUvfd47MJnxypLCljgswo6fo98ibSkEg s1kOL8Wtug20J8Nn3MTKQ/xrNLWAYGrdxI9RfABDNmvCaZy2VBl1q72F5OKsVkW+kX32 zNFxn1jjavsY7/uroCRKYZMDDRK0tDwQTPPP36LF+nel4syo1jnQffKWyWtLOwqXDAFY oluw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=sgZZ1ewuEIfpvbmrwlW/het3gskfd4J/Bjm1gd2Mn14=; b=RiHBZGWM25HSkiescGn9enMxwCXt/ghy3Fd5/xxrBnnngUCDeEoG6pnkSPsrf33R4X i0YLFOg0Ifk7h9tM26dIuXvHm/zlQjbqdQWxDSMtWkNodj5TKN+4rs0FTfk696KvkonZ zqRE0sv3KgplazM721qqVGwo1pYNuaIQi6gndlXUyyNH6ErRxCpNiQhGVghKyVFxTKtI iROdpzIcWceWlvvVdR1CjtMiJHE0ADw2IEV0iTPxMtWMSMJMT+bKm9erY9l+VI+AHas0 7iqzCKOVAEcHFcdlObFZ+6aD69Nvb8YhjR4CEtW4odPw6fOj94RV1i1kXA7A9D4lbvrA iB1Q== X-Gm-Message-State: AIVw113kgmZdmYcAwMy8jFgwp0yrMhjnBRq2HvWUpYLT+WCJ6WmVkwYV 7LnijsjhDTxu45ZL9FK2o6DslTjofIs6 X-Received: by 10.36.40.196 with SMTP id h187mr1098451ith.43.1500200920406; Sun, 16 Jul 2017 03:28:40 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 10.107.152.80 with HTTP; Sun, 16 Jul 2017 03:28:39 -0700 (PDT) From: Barry Leiba Date: Sun, 16 Jul 2017 12:28:39 +0200 X-Google-Sender-Auth: lmzgE1BUPZtb0Yu8xY797Qdyukg Message-ID: To: "dmarc@ietf.org" , dcrup@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [dmarc-ietf] Reducing the gap between the DMARC and DCRUP sessions on Thursday at IETF 99 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 10:28:42 -0000 The DMARC and DCRUP working groups share the morning session on Thursday, with DKIM scheduled from 9:30 to 10:30, and DCRUP scheduled to start at 11:00. To avoid having people hanging out for half an hour, we have reduced the time between the sessions to 10 minutes. The DCRUP session will now start at 10:40 and end at 11:10. The 10 minutes will allow time for chair changes and setup, and for Meetecho to end the DMARC recording and begin DCRUP. So, again, the change: The DCRUP session in the Berlin/Brussels room on Thursday is moved 20 minutes earlier, now 10:40 to 11:10. -- Barry From nobody Sun Jul 16 08:43:22 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE514127241 for ; Sun, 16 Jul 2017 08:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4bdCV_glhnGW for ; Sun, 16 Jul 2017 08:43:19 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6855A126CC7 for ; Sun, 16 Jul 2017 08:43:19 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id 35so26432077uax.3 for ; Sun, 16 Jul 2017 08:43:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9umkhGGkwpKkG046XgZ5QdXCbZpLvQppgKV2op9XVig=; b=SOxvMunCz+LkLjIswOvTJAFB0iuLc84UN56VEaEeDjdDdSAfKbZNoVQRZZJg9MeZXq RoIUSKpxSIALgiqdDPVpqtrveJwTcHyKZljbyK1qf2IXACqTqeclXYBp1w74ANlXeP0d f9boP2z9emUKwfl7nA3/7w+RoALMQh9VwTDBJbPJ0hEqmvgE5JrkT+uGPxmT11d8vlhx dOnHCSzxriDmCIfwWsOTUcJxCLXfFY2GotWcQFDoQvx0PtWctRN9WARtd+HVh9c20plN t//fMqVSMB+NhLah3xpeUktKCexDc6/XCGxuG3/4l/ffZKwcBXOHDUQmSdA6aaL7jbg1 3Rag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9umkhGGkwpKkG046XgZ5QdXCbZpLvQppgKV2op9XVig=; b=UFuLU2bZAj5XnPW+b5RdAK3gi+o3bZ4j4d4n0WL+y9SObhFYMXLsJEWw7J4LCVUeA7 vnAE4rrdhlIqiUV97rOlXtdUkaa5n83BjS4opuNW+QDWX4+ld0CYGQ+qx6F1pA4w3axk pasmpXXi4G/yrl8I5zEPrYpIdDFKkXOx/NRCayl3GVImromtl5ATZGCvjpc9+jARr37t MP5B/LPJfOSVbSuITeJSKaV3zi4HRvcxtBfFKSoQXhWQd96AJaG2N49kC5CLnQK99eJe jzCGU6N5yQ+q10hJuuvNuwiV2s0tDZYrLVGwYeKLrDFdQLh8rrpAKazXLj3WOe4XrqiK BpuA== X-Gm-Message-State: AIVw112zScq//v7k+gx/XATBaQOrnQ5AiJcVaKPvn2pJThqSIQFC85Qh JEepzhtE5vNwM7dvDJAbUNvp0jqUNw== X-Received: by 10.176.10.29 with SMTP id q29mr1354421uah.151.1500219798592; Sun, 16 Jul 2017 08:43:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.126.196 with HTTP; Sun, 16 Jul 2017 08:43:17 -0700 (PDT) In-Reply-To: References: From: "Murray S. Kucherawy" Date: Sun, 16 Jul 2017 17:43:17 +0200 Message-ID: To: Barry Leiba Cc: Kurt Andersen , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0e99102e20b5055471247d" Archived-At: Subject: Re: [dmarc-ietf] Agenda for IETF99 F2F X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 15:43:21 -0000 --94eb2c0e99102e20b5055471247d Content-Type: text/plain; charset="UTF-8" Status reports are great list material. I don't think it's useful for mic time. Unless something specific about OpenARC is germane to the draft(s), I feel we have plenty of other stuff to discuss during face time. On Sun, Jul 16, 2017 at 9:51 AM, Barry Leiba wrote: > > Why is OpenARC's status an IETF agenda item? > > Because someone in the working group asked for a summary, and I > thought it would be a quick and easy agenda item. If you object to > giving a status report in the session, I'll strike it. > > Barry > --94eb2c0e99102e20b5055471247d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Status reports are great list material.=C2=A0 I don't = think it's useful for mic time.=C2=A0 Unless something specific about O= penARC is germane to the draft(s), I feel we have plenty of other stuff to = discuss during face time.

On Sun, Jul 16, 2017 at 9:51 AM, Barry Leiba <barr= yleiba@computer.org> wrote:
> Why is OpenARC's status an IETF agenda item?

Because someone in the working group asked for a summary, and I
thought it would be a quick and easy agenda item.=C2=A0 If you object to giving a status report in the session, I'll strike it.

Barry

--94eb2c0e99102e20b5055471247d-- From nobody Sun Jul 16 11:21:18 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5176F13170E for ; Sun, 16 Jul 2017 11:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TO3t7vqs42ug for ; Sun, 16 Jul 2017 11:21:15 -0700 (PDT) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09B031316BE for ; Sun, 16 Jul 2017 11:21:14 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id 35so28173772uax.3 for ; Sun, 16 Jul 2017 11:21:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ep+GEw7ChDqxhvQM8JjZ/ym6d8PC7BCoebqw3F/XxdE=; b=K9Konygouro+BNHJFB3+FTGdCFMYs+xFe5VbbodE3m0fCaoOhZKvITLFSd2Lq0n7K6 8lkI6H5Wa9JumUY6ziA7M62PTkqhp55K3HSddYbv8F37GIEkcmFMrvMdz96kj+1Rms/q 1atTsaiDohEDl9gWjFLGrT5krueMbqN+bIV5M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Ep+GEw7ChDqxhvQM8JjZ/ym6d8PC7BCoebqw3F/XxdE=; b=DbqokVcekJbRfL4tC18As/51bggCBEp1wFytGJ2kbVUKkMkX8xTq7PUKeibjbKPJ+l z7zybCpVNe2Ij9FB3QBzHmH38wSq8RX0q+JepfWQDVuFM0bqC8gco9y5/0ray3vJbT67 m5ER7R9F+juBTof36NXqNfvgMTLEmhumw+GqCs8+CVUjC61NYPtVmAlqDOpkXQ17d5rf cOQ58wGvWiYhT4zx3j+/ADmfaAzUiXTo9Sx7U4yjzi/3DUtWUi8obpSUoY/dxkuCK6Vq CJj8aEamZ/xukX9O8beBEprJHNoIABE96pwV2WDnrQKb7Pn55gfjk2WOPO46ESxrkCC4 KBEQ== X-Gm-Message-State: AIVw113MGTAZz+ZXZaRF9BEAfDB/LeUYtZegvCdmfp6gSshh2OK7izvD 2mE7trp+BpaJRRy7YP+H/JoytgTNB/FKS7w= X-Received: by 10.176.75.28 with SMTP id h28mr11128165uaf.133.1500229273896; Sun, 16 Jul 2017 11:21:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.26.39 with HTTP; Sun, 16 Jul 2017 11:21:13 -0700 (PDT) In-Reply-To: References: From: Kurt Andersen Date: Sun, 16 Jul 2017 20:21:13 +0200 Message-ID: To: "Murray S. Kucherawy" Cc: Barry Leiba , "dmarc@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [dmarc-ietf] Agenda for IETF99 F2F X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 18:21:16 -0000 On Sun, Jul 16, 2017 at 5:43 PM, Murray S. Kucherawy wrote: > Status reports are great list material. I don't think it's useful for mic > time. Unless something specific about OpenARC is germane to the draft(s), I > feel we have plenty of other stuff to discuss during face time. I'll definitely write up some notes from our interop/hackathon work this weekend and send it to the list in the next day or so. --Kurt From nobody Sun Jul 16 12:52:43 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 468D612EC39 for ; Sun, 16 Jul 2017 12:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HDUQcjy1a1t for ; Sun, 16 Jul 2017 12:52:40 -0700 (PDT) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BDB9129AFF for ; Sun, 16 Jul 2017 12:52:40 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id z22so75983164uah.1 for ; Sun, 16 Jul 2017 12:52:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:from:date:message-id:subject:to; bh=ehL/5d4y3Nc5AfkR7cjQ3G8xT1aVW9kTtiqJI4Hnd3o=; b=F3Wz5pX6WuIyySppowjNcUel2+WvSqVuW6p66RNLe7XdsY6uxLK50rSCHQsjWumGwt G1vU/kSm7pN5MRQvDmRHUoWVwdMev78gAoXUs8yphiZFgFEAAxgLa2L9eTzx3gHFI0Ww PZW3T81+Rrt47NMzcu3aVVW6tjp/94pjLGutw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=ehL/5d4y3Nc5AfkR7cjQ3G8xT1aVW9kTtiqJI4Hnd3o=; b=T4HVvoOfN2PkcKhm11iFlTO7M6yZTgO6VJDcx5R06zxeIopNodJlJNvHb6O8+nklkn 8NQ1AWZZcskPGLJA7Qr6KDeA6/LimEtLMj8OiDnouffVlhwYtfT0wxZKqk1b/H/HGkLx V1j+BHJ0TETuEWJS95e+n61Hqs8IZNwg7Nz3wTAq95+hlflk7y0ml1lpYcYBd7vzVEhr aitEkuU7Lj6tJa9ABQHMoh9POCPg4MAcub9OEqU1ncGWQ5HptVqFk+6eNqG/VN1hhFq6 d1V+Fsy3GHudh06vt8BJ5T0xOZ7QVKDK6DNoeF+uNRbyZI8+XcnorkBBY1OjlXpnV/SG rhcg== X-Gm-Message-State: AIVw111NSupCZ84iZKiHzyiSyKgp6Cm2qT7tC8/eYlKEguixFzEVXSuf uVw+fpsQZY2iLaoBTqc4uSZ4hIInPzoep0h60Q== X-Received: by 10.31.56.16 with SMTP id f16mr10509353vka.86.1500234758896; Sun, 16 Jul 2017 12:52:38 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.176.26.39 with HTTP; Sun, 16 Jul 2017 12:52:38 -0700 (PDT) From: "Kurt Andersen (b)" Date: Sun, 16 Jul 2017 21:52:38 +0200 X-Google-Sender-Auth: 2ZTajGdNo9Hzdh2TJrb1YG_6eXo Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a1143185ae254ba0554749fa3" Archived-At: Subject: [dmarc-ietf] Report from the IETF99 hackathon on ARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 19:52:42 -0000 --001a1143185ae254ba0554749fa3 Content-Type: text/plain; charset="UTF-8" We had 6-8 people through the weekend working on various interoperability things: - Andreas Schulze was able to obtain openarc.org and has stood up a forwarder using OpenARC to process the mail both with verification on the way in and sealing on the way out, but the AMS which are generated fail signature validation :-( but the ARC-Seal headers are good! - Steven Jones worked with getting OpenARC to build on FreeBSD and Debian - Juri Haberland contributed patches and pull requests to fix various issues in the OpenARC repo (working remotely) - Barry Lieba provided moral support and kept tabs on the overall work effort - Chris Newman worked on building an independent implementation for DKIM and ARC that can be used within the Oracle messaging suite (I'm sure it has some more official name) - Kurt Andersen worked on testing interoperability between Google, AOL, dkimpy, OpenARC, MailerQ, and Rspamd - Bron Gondwana and one of the other FastMail guys (sorry that I didn't catch the name) worked on adding ARC analysis to their PERL Mail::Milter::Authentication module ( https://github.com/fastmail/authentication_milter/). At the end of the hackathon, they had something that would evaluate the validity of ARC chains working! - Alexey Melnikov dropped by just before the hackathon presentations kicked off - he is building an independent C-based ARC implementation. You can see more details and various notes from the participants in the interop at https://bit.ly/arc-interop7 . My apologies to anyone that I've left out of the participation list. Please chime in with any other notable findings or questions. --Kurt Andersen --001a1143185ae254ba0554749fa3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We had 6-8 people through the weekend working on various i= nteroperability things:
  • Andreas Schulze was able to obtain openarc.org and has stood up a forwarder usi= ng OpenARC to process the mail both with verification on the way in and sea= ling on the way out, but the AMS which are generated fail signature validat= ion :-( but the ARC-Seal headers are good!
  • Steven Jones worked with= getting OpenARC to build on FreeBSD and Debian
  • Juri Haberland cont= ributed patches and pull requests to fix various issues in the OpenARC repo= (working remotely)
  • Barry Lieba provided moral support and kept tab= s on the overall work effort
  • Chris Newman worked on building an ind= ependent implementation for DKIM and ARC that can be used within the Oracle= messaging suite (I'm sure it has some more official name)
  • Kurt= Andersen worked on testing interoperability between Google, AOL, dkimpy, O= penARC, MailerQ, and Rspamd
  • Bron Gondwana and one of the other Fast= Mail guys (sorry that I didn't catch the name) worked on adding ARC ana= lysis to their PERL Mail::Milter::Authentication module (https://github.com/fastmail/au= thentication_milter/). At the end of the hackathon, they had something = that would evaluate the validity of ARC chains working!
  • Alexey Meln= ikov dropped by just before the hackathon presentations kicked off - he is = building an independent C-based ARC implementation.
You can s= ee more details and various notes from the participants in the interop at <= a href=3D"https://bit.ly/arc-interop7">https://bit.ly/arc-interop7 . My= apologies to anyone that I've left out of the participation list. Plea= se chime in with any other notable findings or questions.
<= br>
--Kurt Andersen
--001a1143185ae254ba0554749fa3-- From nobody Sun Jul 16 12:52:58 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3178C129AFF for ; Sun, 16 Jul 2017 12:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WLeBhyq5k9WQ for ; Sun, 16 Jul 2017 12:52:40 -0700 (PDT) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47125127978 for ; Sun, 16 Jul 2017 12:52:40 -0700 (PDT) Received: by mail-ua0-x22a.google.com with SMTP id z22so75983130uah.1 for ; Sun, 16 Jul 2017 12:52:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:from:date:message-id:subject:to; bh=6Sj3Z6DbB7Du3GPHEm7G5rs2qMzEmLyxjFtQ8ylH7Ac=; b=TXqAkHpJ112NABVNvLCaQVCYY1EblC4hqdRkxUfVIyJ6J2w8VVYHJv5oj/we7lkZK8 rI0FWiHazSDdKiKpD1UCAiY9T0IUQx1C5D5vbKEzU6XJQS6bJe3ZhPj+q84mkWj+tD0Y LijdwHV4wlr7iXu3YcAU2EI2WmbTuQv4G55pc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=6Sj3Z6DbB7Du3GPHEm7G5rs2qMzEmLyxjFtQ8ylH7Ac=; b=M8I4MYijt0tsPS3PZE8zm/aVd3DcRnSL+JocPA9oZNq3WVHOFDYOr0+jBEVhrUD2Uq Z4lvDROzcWvhslVX4xLNfLleKIeXgTSzhhaLc01cj5FqcF0Npf6nYIp6eeAo5rMKX+Rb z/ghXjbhoeDoeOS8CQdkkKTMvPV6bXpJuKaLlzqygQ6GTxFirSFfVL1EkrOOMijl9tml lkC4l/QbkW86JWYGqM1/Is1IPGNiw4oQvgcG4UrPNxia0RvWgR7wjekMFzsTmpA+86t6 pLA2dF6+1nruilH40OMxBBPo0/fKyqJkjxiR+OYZGjrhzZvcjAn9PQnoevItE+HQTLWO VPDA== X-Gm-Message-State: AIVw11265cV4RcqmCcWqdmBXgDeVzwy6ikaqC7pKKu5pP/9lbf/Ii7vk VRt8NoMzj3r8oG85i6Ev4edNwZtN4Eu99Kh24A== X-Received: by 10.31.33.16 with SMTP id h16mr10331417vkh.103.1500234758881; Sun, 16 Jul 2017 12:52:38 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.176.26.39 with HTTP; Sun, 16 Jul 2017 12:52:38 -0700 (PDT) From: "Kurt Andersen (b)" Date: Sun, 16 Jul 2017 21:52:38 +0200 X-Google-Sender-Auth: sBv2lWjehdTfcvExOMKCK6QPFgI Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a11c0436ae216e50554749f41" Archived-At: Subject: [dmarc-ietf] Report from the IETF99 hackathon on ARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 19:52:43 -0000 --001a11c0436ae216e50554749f41 Content-Type: text/plain; charset="UTF-8" We had 6-8 people through the weekend working on various interoperability things: - Andreas Schulze was able to obtain openarc.org and has stood up a forwarder using OpenARC to process the mail both with verification on the way in and sealing on the way out, but the AMS which are generated fail signature validation :-( but the ARC-Seal headers are good! - Steven Jones worked with getting OpenARC to build on FreeBSD and Debian - Juri Haberland contributed patches and pull requests to fix various issues in the OpenARC repo (working remotely) - Barry Lieba provided moral support and kept tabs on the overall work effort - Chris Newman worked on building an independent implementation for DKIM and ARC that can be used within the Oracle messaging suite (I'm sure it has some more official name) - Kurt Andersen worked on testing interoperability between Google, AOL, dkimpy, OpenARC, MailerQ, and Rspamd - Bron Gondwana and one of the other FastMail guys (sorry that I didn't catch the name) worked on adding ARC analysis to their PERL Mail::Milter::Authentication module ( https://github.com/fastmail/authentication_milter/). At the end of the hackathon, they had something that would evaluate the validity of ARC chains working! - Alexey Melnikov dropped by just before the hackathon presentations kicked off - he is building an independent C-based ARC implementation. You can see more details and various notes from the participants in the interop at https://bit.ly/arc-interop7 . My apologies to anyone that I've left out of the participation list. Please chime in with any other notable findings or questions. --Kurt Andersen --001a11c0436ae216e50554749f41 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We had 6-8 people through the weekend working on various i= nteroperability things:
  • Andreas Schulze was able to obtain openarc.org and has stood up a forwarder usi= ng OpenARC to process the mail both with verification on the way in and sea= ling on the way out, but the AMS which are generated fail signature validat= ion :-( but the ARC-Seal headers are good!
  • Steven Jones worked with= getting OpenARC to build on FreeBSD and Debian
  • Juri Haberland cont= ributed patches and pull requests to fix various issues in the OpenARC repo= (working remotely)
  • Barry Lieba provided moral support and kept tab= s on the overall work effort
  • Chris Newman worked on building an ind= ependent implementation for DKIM and ARC that can be used within the Oracle= messaging suite (I'm sure it has some more official name)
  • Kurt= Andersen worked on testing interoperability between Google, AOL, dkimpy, O= penARC, MailerQ, and Rspamd
  • Bron Gondwana and one of the other Fast= Mail guys (sorry that I didn't catch the name) worked on adding ARC ana= lysis to their PERL Mail::Milter::Authentication module (https://github.com/fastmail/au= thentication_milter/). At the end of the hackathon, they had something = that would evaluate the validity of ARC chains working!
  • Alexey Meln= ikov dropped by just before the hackathon presentations kicked off - he is = building an independent C-based ARC implementation.
You can s= ee more details and various notes from the participants in the interop at <= a href=3D"https://bit.ly/arc-interop7">https://bit.ly/arc-interop7 . My= apologies to anyone that I've left out of the participation list. Plea= se chime in with any other notable findings or questions.
<= br>
--Kurt Andersen
--001a11c0436ae216e50554749f41-- From nobody Sun Jul 16 14:12:33 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41EB8126BFD for ; Sun, 16 Jul 2017 14:12:32 -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=isdg.net header.b=dkWjdlHv; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=OZXEZzYA 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 m9tItJ9adSn7 for ; Sun, 16 Jul 2017 14:12:29 -0700 (PDT) Received: from mail.santronics.com (catinthebox.net [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 7AABD1200F3 for ; Sun, 16 Jul 2017 14:12:29 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=173; t=1500239544; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=orHppmLTeMWLeNYNtCWHHdRH628=; b=dkWjdlHvRYH4DiIQmVfRThqK3Ur9qfE7mBMY3nc17U9Vw7ZYenKgguDXWxoAw5 /7RKwxRUI0C7ytsTLKU/JBVv7O4e3GyEil9q9zWCLIZ5UVhgphCxWilGbm6+3pAe QVZaf/XV51ulTAerYu39H6eaeewkWW+Ld4jkn9m6hZqlM= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Sun, 16 Jul 2017 17:12:24 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 303431000.1.5312; Sun, 16 Jul 2017 17:12:24 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=173; t=1500239288; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=jLXLPL2 Cl4wYVHlLSWuruA99veadREol6N0hcpaMozU=; b=OZXEZzYA2oy8vXLRnCTypLG T89bJVlLiPkYZlf2uBny7aiix19xdckSFQ2s+e4iO/wY0rXQ/rQbzJWajXv3sImz DQBmrd36HeTq8LfG3e5xLV1Z4wNkLr3DIbmz6A5KbVJRq9QJm2/JRcx8XX7nNrD5 stXz/3W85H6lv/IgQraM= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.5) for dmarc@ietf.org; Sun, 16 Jul 2017 17:08:08 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.5) with ESMTP id 845959080.9.29260; Sun, 16 Jul 2017 17:08:07 -0400 Message-ID: <596BD6B2.20105@isdg.net> Date: Sun, 16 Jul 2017 17:12:18 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <8005ec7b-eb64-b542-3b74-539b7f42b1fb@andreasschulze.de> <1b50f7f0-36a1-a3f5-f6e1-5d03c0e4b779@andreasschulze.de> <76da3ccb-d147-3bb3-3442-0600d2466e08@andreasschulze.de> <15b6aa31-5986-8573-d2fe-4d5dda209597@sapienti-sat.org> <0fbf94e0-ab8d-e5c8-e4d0-e88ea83b10d7@sapienti-sat.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] [arc-discuss] openarc defer messages X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 21:12:32 -0000 On 7/15/2017 12:23 PM, Murray S. Kucherawy wrote: > > I don't think OpenARC development details are appropriate for the IETF > list, are they? > I agree. -- HLS From nobody Mon Jul 17 15:22:20 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7C9F131CDF for ; Mon, 17 Jul 2017 15:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eudaemon.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vm68Ly6ure0Z for ; Mon, 17 Jul 2017 15:22:17 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECF1B131CDE for ; Mon, 17 Jul 2017 15:22:16 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id a12so813546ywh.3 for ; Mon, 17 Jul 2017 15:22:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eudaemon.net; s=dkey; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=QMTddKjJIExrVO69xJbTi3pYNeOsDBdta//oVLPmMQo=; b=G+UNqYEVhiGbGfwqekqh3Al0+JaxrfiLyq4X+8m8ymesyB0NnNdagGkGy8+aXNDWMo pAbCVgzdvIZejV34Onyh4eX5NMMrnjmWBauezq2cj0QF7HKwyoZ+A90nVuu8KIK49Miy 8r3CsScqiyw7gK1IRpyHAHpQ/mxzD1xkrIwB8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=QMTddKjJIExrVO69xJbTi3pYNeOsDBdta//oVLPmMQo=; b=U50Q4LfVo+N6mpUT52aVA58byHijXEMhxP4X4zo4egoB8cBhIfGne7NCTCIBlufPMt JhQBqbkW6wl82cT42LtdWtuPSKbyLCaMz1/6TJiObzQHE/MSgIzqImylrxpBLQbe+HoD jffJXVFCz8B0d3TCHWG6AEifp6tA6rlI8K+4a14EsIi/3GH0tpe9APyVEazB8v6pqR9u PwHwul7mmb/EgDttox6tsxA0P25mY+UfahdWa1w5mcbynftJkjURJy2XfqSGqd/cWASy tG7GaAifSQqTERyOjrbs5IRrK6Go4MHiBMu6DfZ89odf8g8b1buFTS8QuoHmmQ/SXnQl OLjQ== X-Gm-Message-State: AIVw110Lc2m2IdGITAPhPrrSq+9eovpLmK0LXXNcfaNiaMxk4NyNJ3VV 2J2tBXoV7sUau5uWkN5EnA== X-Received: by 10.129.227.72 with SMTP id w8mr17131357ywl.165.1500330135826; Mon, 17 Jul 2017 15:22:15 -0700 (PDT) Received: from [192.168.0.30] (208-104-133-98.brvd.dsl.dyn.comporium.net. [208.104.133.98]) by smtp.gmail.com with ESMTPSA id p126sm174633ywg.61.2017.07.17.15.22.15 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Jul 2017 15:22:15 -0700 (PDT) From: Tim Draegen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Mon, 17 Jul 2017 18:22:14 -0400 To: dmarc X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [dmarc-ietf] current state of the DMARC Usage Guide X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 22:22:19 -0000 Hi all, in preparation for Thursday's in-person meeting, here's a = summary of where the DMARC Usage Guide is at: 1) Thread on "Do we really need to do this?". Thread ends with "let's = not do this unless there is missing documentation". = (https://mailarchive.ietf.org/arch/search/?email_list=3Ddmarc&gbt=3D1&inde= x=3Dii4ds1wcctfhUpbTmMeu8Nh0UHs) 2) Outline of approach to understanding if documentation is missing. = Approach: get some Domain Owners, third party senders, and receivers to = share operational experience: https://mailarchive.ietf.org/arch/msg/dmarc/9Pks0yVkpjtxtqKsfUf-gRY9gyE 1st ESP: = https://mailarchive.ietf.org/arch/msg/dmarc/76CoHb7KRYPOvRqrEuBn_KU1FZE 1st ISP: = https://mailarchive.ietf.org/arch/msg/dmarc/ptWY1dFS7IcmpcGGW5vICJpzF_s 3) Question of reputation being attached to selectors, and if BCP/Usage = Guide needs to fill a gap: = https://mailarchive.ietf.org/arch/search/?email_list=3Ddmarc&gbt=3D1&index= =3DLwQZxssf_aGqrh8VwXKoiGE0aKE An open question: https://mailarchive.ietf.org/arch/msg/dmarc/KKIATMeNnab8JA857XgMWOZPTOI In message = (https://mailarchive.ietf.org/arch/msg/dmarc/9Pks0yVkpjtxtqKsfUf-gRY9gyE) = I wrote: > I hope that by the next in person meeting, we can at least discuss if = there is > a "there there". If there isn't, it won't be for lack of trying. It's still my opinion that only the surface of real operational = experience has been scratched. Finding people, convincing them to be = interviewed, booking time, doing the thing, and then posting to this = list all takes time. My view on the Usage Guide is that the WG originally carved out time to = work on this to help future deployers avoid mistakes. It's not easy = reaching "beyond the choir", but IMO it's worth doing. HOWEVER, if I'm the one guy in the room that wants to work on this, No = Problem, I'll keep working this outside of the WG. =3D- Tim From nobody Mon Jul 17 23:51:16 2017 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9D7131D22; Mon, 17 Jul 2017 23:51:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dmarc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.56.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150036067527.11413.11603019466786916347@ietfa.amsl.com> Date: Mon, 17 Jul 2017 23:51:15 -0700 Archived-At: Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-06.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 06:51:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain-based Message Authentication, Reporting & Conformance of the IETF. Title : Authenticated Received Chain (ARC) Protocol Authors : Kurt Andersen Brandon Long Steven Jones Filename : draft-ietf-dmarc-arc-protocol-06.txt Pages : 46 Date : 2017-07-17 Abstract: Authenticated Received Chain (ARC) permits an organization which is creating or handling email to indicate its involvement with the handling process. It defines a set of cryptographically signed header fields in a manner analagous to that of DKIM. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Changes in the message that might break DKIM can be identified through the ARC set of header fields. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-protocol/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-06 https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-arc-protocol-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-arc-protocol-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 17 23:56:58 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8C9E131D3A for ; Mon, 17 Jul 2017 23:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNWokm-g-C_S for ; Mon, 17 Jul 2017 23:56:55 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C5A3131D3C for ; Mon, 17 Jul 2017 23:56:55 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id b64so13043600uab.0 for ; Mon, 17 Jul 2017 23:56:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=f/5TV8crWPd+pDVsyIpBTCn7NZPQFcHXrcE6CPDQ148=; b=aojHbonIfcms+tfzs1bBkMVN8z7mQ7s7bgnaN29ZfRU1y/JHJCusEuak8Z/h8JOdfc cQeygpWIPetHsfbyt9Pt9Wpvvgmo68BEuelCIY0h2e0HzFECe1T1KQaLdoeg5FJ1Dlfb F213fPoMmRXfauAR/Lz8uzfhZEPDhyeCYCRCI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=f/5TV8crWPd+pDVsyIpBTCn7NZPQFcHXrcE6CPDQ148=; b=MhKwLtsuKFQbgwtMHSuY4AMs0evbY89ljqwKbVlIn5tdohSIEGCNZVi3u6gkRLUZbL GZpkDkj74gfb8vSyFmmBdJcYZtGpDCj+Q/Vbbl2Un9dFcHLtYGqwwHP2+6ti1441DEob rsyGk78qQRjitN5fob3ZE3DvCjxzBtjqZ9g4aZ4chjLBL1guWvYf1etXs1z1djAxsj2e lGAkEaK76zWLfgDleK/3KT8I/Clk3QDv0Vi+20yZGlMCWVbySHIH6gprAmZLZER7nbwA wAjvLYWdpySJJXgcxHE1dLdOiWBH36Q8FJbD0xolUDdlv9nfxAHq1QVxmtqMf0ObEwZC NzuQ== X-Gm-Message-State: AIVw112GiSCcick4QIlBEutB+rNsotXiQqzAkxO7l3cgiPrIGmsx/rB9 lrG2zYXtqJ8k+QU4+AuI/M/W6e6GM0NkeNCztg== X-Received: by 10.31.220.199 with SMTP id t190mr98803vkg.132.1500361013932; Mon, 17 Jul 2017 23:56:53 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.176.26.39 with HTTP; Mon, 17 Jul 2017 23:56:53 -0700 (PDT) In-Reply-To: <150036067527.11413.11603019466786916347@ietfa.amsl.com> References: <150036067527.11413.11603019466786916347@ietfa.amsl.com> From: "Kurt Andersen (b)" Date: Tue, 18 Jul 2017 08:56:53 +0200 X-Google-Sender-Auth: 6nsRPQHmbDdKT8Ph3u6Sg4a4nSE Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c07cc7e4545b6055492052d" Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-06.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 06:56:57 -0000 --94eb2c07cc7e4545b6055492052d Content-Type: text/plain; charset="UTF-8" On Tue, Jul 18, 2017 at 8:51 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain-based Message Authentication, > Reporting & Conformance of the IETF. > > Title : Authenticated Received Chain (ARC) Protocol > Filename : draft-ietf-dmarc-arc-protocol-06.txt > Date : 2017-07-17 > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-protocol/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-06 > https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-arc-protocol-06 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-arc-protocol-06 Highlights of changes in this version: 1. Added rspamd as another existing implementation (section 9) 2. Clarified the sealing rules in the case of a failed chain (section 6.4.2) 3. Added parenthetical notes to two sections pertaining to the additional information desired for the AAR per list conversations (sections 5.1.3 and 6.4.6) --Kurt --94eb2c07cc7e4545b6055492052d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Jul 18, 2017 at 8:51 AM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Domain-based Message Authentication, Repor= ting & Conformance of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Authenticated Received Chain (ARC) Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0= Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-ietf-dmarc-arc-protocol-0= 6.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 : 2017-07-17

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

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

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

Highlights of changes in this version:
  1. Added rspa= md as another existing implementation (section 9)
  2. Clarified the sea= ling rules in the case of a failed chain (section 6.4.2)
  3. Added pare= nthetical notes to two sections pertaining to the additional information de= sired for the AAR per list conversations (sections 5.1.3 and 6.4.6)
    4. --Kurt=C2=A0
--94eb2c07cc7e4545b6055492052d-- From nobody Tue Jul 18 00:37:55 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C80C13155D for ; Tue, 18 Jul 2017 00:37: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, 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=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oie9134Xtxjd for ; Tue, 18 Jul 2017 00:37:51 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 0B79A12ECF0 for ; Tue, 18 Jul 2017 00:37:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1500363470; d=isode.com; s=june2016; i=@isode.com; bh=uMjgOD/fZqODHQDjjkkcvdhHDhOgIqEJNRyEpBo4B8Y=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=BssZ7RALHh2PwflpaOe6Ve35Oi2cN79i1+0y885tg0XwvpKTsXTJss97jP4UOQmRTcncpm BDokkH9dvWip6STVYrkYCyPen9+wTklEIYf9+uzJOUQr5sx5pzC7KNXYQVbGsY8rbXtrZG Q8aP0nIkVNSdRVB12YktDemGnz1Hlpw=; Received: from [172.16.18.185] (94.112.246.234.static.b2b.upcbusiness.cz [94.112.246.234]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 18 Jul 2017 08:37:50 +0100 From: Alexey Melnikov X-Mailer: iPad Mail (14F89) X-Identity-Key: id1 Date: Tue, 18 Jul 2017 10:02:22 +0200 X-Account-Key: account1 X-Mozilla-Draft-Info: internal/draft; vcard=0; receipt=0; DSN=0; uuencode=0; attachmentreminder=0; deliveryformat=4 Message-Id: <1BF07A5C-5591-4463-B99A-6C2A3BCEFF04@isode.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 To: dmarc@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [dmarc-ietf] Comments on ARC specification X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 07:37:54 -0000 I've started implementing ARC and have a few minor comments on the draft: 5.1.2.2. Computing the 'b' Tag Value for ARC-Message-Signature As with ARC-Seal and DKIM-Signature header fields, the order of header fields signed MUST be done in bottom-up order. Upon rereading this I am not sure this is very clear. Maybe give an example,= especially if multiple instances of a particular header field are included.= ARC-Authentication-Results needs ABNF (I know the document says in prose tha= t the syntax is effectively "i=3D; ...", but also specifying this wi= th ABNF would be much better, especially in order to avoid people inserting C= FWS in places they shouldn't.) Examples need updating. Some "Authentication-Results" in examples are supposed to be "ARC-Authentica= tion-Results" In A.3.2.2:=20 o gmail.com adds it's own ARC-Seal: header, contents of which are * version -- the version was removed? Auth-Results is used in several places -- Use non abbreviated version of Authentication-Results, in case people ar= e searching for occurrences of Authentication-Results in the document Best Regards, Alexey From nobody Tue Jul 18 00:59:15 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EFAB131A4F for ; Tue, 18 Jul 2017 00:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JyvpJpoxQ8tN for ; Tue, 18 Jul 2017 00:59:05 -0700 (PDT) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5931D12ECC0 for ; Tue, 18 Jul 2017 00:59:05 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id 64so14348584uae.2 for ; Tue, 18 Jul 2017 00:59:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=bI88j+aFb/qZUVpVYZ9AhBBRh/WOneO3A501Sckgmp4=; b=ep4S1ZXnL+dQVoLh42Qkw1lsOsqw1gW2AT1a97BKwAyNhUFBXWSCvnDaYsPXlWPMiB nbhS6/+Zkdl0VOIizgKwfc6Bq0/noIQq+FPKL5yy2kmoJfTb4sJmWFuZTkK/aBm/x7US 3CtXqQhRs9dqUHa1uOQAuA4xWUR3UhnPg2duA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=bI88j+aFb/qZUVpVYZ9AhBBRh/WOneO3A501Sckgmp4=; b=J5IBhvWzczvuMh+mLij2lXit5Lx0758EEMq+s45gV+UIJMe72yte4PxunrFyjRZhLb JiwMTzH6WLSX3Awf6hjmoww9X56W9rwjNN3L1m8zmLyjOyTIa4perrm+IkyD5Y+aAS3v pOYLrdBgzvfkTGuWD6Ts/ZMUyzemXRFWCs1prLdxT+lLY+CefyIhEcOoF/P8xlUlVVkp 8savIkwYxL16YH8H2Nmrq2mfroCnDaPEsvENSztZqOwTMEI1QlORPgdOwPkeBZ/W3FHe FaqWqH0J1COBFHMTIsprU5ePgOa+0YpggSFLkkzAFOp1jjvwXDcMCxPICS0vwTRTEe2T knlQ== X-Gm-Message-State: AIVw113aah4teVXnSjw7MgWLYrf12LdOG0/OwZDM9rV6HZJc3w32OjXd s/JVc0CtkIVZTPe+mt8WH13ErXhTHkP28eMlegq6 X-Received: by 10.176.75.28 with SMTP id h28mr156743uaf.133.1500364744370; Tue, 18 Jul 2017 00:59:04 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.176.26.39 with HTTP; Tue, 18 Jul 2017 00:59:03 -0700 (PDT) In-Reply-To: <1BF07A5C-5591-4463-B99A-6C2A3BCEFF04@isode.com> References: <1BF07A5C-5591-4463-B99A-6C2A3BCEFF04@isode.com> From: "Kurt Andersen (b)" Date: Tue, 18 Jul 2017 09:59:03 +0200 X-Google-Sender-Auth: 7_JHfvSYQNoUqCzXbzWYLAEgkog Message-ID: To: Alexey Melnikov Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="f403045e80aa9f4361055492e39f" Archived-At: Subject: Re: [dmarc-ietf] Comments on ARC specification X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 07:59:09 -0000 --f403045e80aa9f4361055492e39f Content-Type: text/plain; charset="UTF-8" On Tue, Jul 18, 2017 at 10:02 AM, Alexey Melnikov wrote: > I've started implementing ARC and have a few minor comments on the draft: > > 5.1.2.2. Computing the 'b' Tag Value for ARC-Message-Signature > > As with ARC-Seal and DKIM-Signature header fields, the order of > header fields signed MUST be done in bottom-up order. > > Upon rereading this I am not sure this is very clear. Maybe give an > example, especially if multiple instances of a particular header field are > included. > See section 5.1.1.3 of the document which specifies the way to build the header list for hashing. ARC-Authentication-Results needs ABNF (I know the document says in prose > that the syntax is effectively "i=; ...", but also specifying this > with ABNF would be much better, especially in order to avoid people > inserting CFWS in places they shouldn't.) > See the -06 version which I posted today with some extra notes regarding open questions related to AAR. Once we settle those questions, I'll also add details (and ABNF) for the AAR and handling multiple A-R headers (another open question on the list). For now, if your environment creates multiple A-R headers with the same authserv-id, they need to have the (not "none") resinfo sections concatenated to create the AAR. I've taken a note to update this in the next draft after we resolve the open questions regarding content in Thursday's session. Examples need updating. > Thanks - I'm sure that there's a lot more problems in the examples than just the ones you listed :-/ I suspect that we should just entirely remove the examples right now. If you want a real life example, you can find it (for the next week or so) at https://pastebin.com/HyMriMKe or other citations on the #ietf99 channel in the slack group. --Kurt --f403045e80aa9f4361055492e39f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Jul 18, 2017 at 10:02 AM, Alexey Melnikov <alexey.melnikov@iso= de.com> wrote:
I've started implementing ARC and have a few minor comments on t= he draft:

5.1.2.2.=C2=A0 Computing the 'b' Tag Value for ARC-Message-Signatur= e

=C2=A0 =C2=A0As with ARC-Seal and DKIM-Signature header fields, the order o= f
=C2=A0 =C2=A0header fields signed MUST be done in bottom-up order.

Upon rereading this I am not sure this is very clear. Maybe give an example= , especially if multiple instances of a particular header field are include= d.

See section 5.1.1.3 of the document = which specifies the way to build the header list for hashing.=C2=A0

ARC-Authentication-Results needs ABNF (I know the document says in prose th= at the syntax is effectively "i=3D<number>; ...", but also = specifying this with ABNF would be much better, especially in order to avoi= d people inserting CFWS in places they shouldn't.)

See the -06 version which I posted today with some extra no= tes regarding open questions related to AAR. Once we settle those questions= , I'll also add details (and ABNF) for the AAR and handling multiple A-= R headers (another open question on the list). For now, if your environment= creates multiple A-R headers with the same authserv-id, they need to have = the (not "none") resinfo sections concatenated to create the AAR.= I've taken a note to update this in the next draft after we resolve th= e open questions regarding content in Thursday's session.
Examples need updating.

Thanks - I'= m sure that there's a lot more problems in the examples than just the o= nes you listed :-/ I suspect that we should just entirely remove the exampl= es right now. If you want a real life example, you can find it (for the nex= t week or so) at https://pastebin= .com/HyMriMKe=C2=A0or other citations on the #ietf99 channel in the sla= ck group.

--Kurt

--f403045e80aa9f4361055492e39f-- From nobody Tue Jul 18 01:09:31 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF72412ECC0 for ; Tue, 18 Jul 2017 01:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=U23imSOE; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Cyn+OSCE 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 ZwFbjRVQpajE for ; Tue, 18 Jul 2017 01:09:28 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70700120227 for ; Tue, 18 Jul 2017 01:09:28 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id E0A072080E; Tue, 18 Jul 2017 04:09:27 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Tue, 18 Jul 2017 04:09:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=RTRx9PfZpnOlqJsLBN V0PN3hX3dYdI8VLIdErEvdVOk=; b=U23imSOE2tMnjlktdFQi0KgnBy/V2EOmhS 683kmz3+3pOAcCRjfHsNvYKltaSZ1vZItyDMe5QlCPjco4QZnqgrs9KqfiZDl73l JyqzZVV4eCxT4kde0ziG7xnLnLRyd+XqDz1qmTxU0QyGkshb+N1le00jERIMBMrn H37C0W489T7S4QJ2KqaouDuYCE6XlZEgn9Y+VQ2fAw1j6+PgExLcW8rhzGfwJLGy SHXtWxch2PbQzMMa83OhA38YIn25c6eW8hkLpirhRyt9V9gULtkqCQ3F1wA63plJ aYNUhZtMc9zG2KAkdBAs7igDQWErf7StSb56pzWifl83x4ub7A4Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=RTRx9PfZpnOlqJsLBNV0PN3hX3dYdI8VLIdErEvdVOk=; b=Cyn+OSCE JhF6pouC/T1r+APcgLnGvISOHp0xtZy9W+wi4fGd/5Ju8pBP4QDpxyIqYQFK7vX2 5H7sWyUjmP7khByTXn06DILO5t3TW3cdV3xthtFs++VSiRsQgYprStCYZt98I1ak XXWC0EUfBo7detOJlPR1ePKvYYm4roTH2ILWWVkCyIYjq7HUTySj39ESzPr8wLlm 6gUPZmzDeAbspGiV3noDo5yMZ2qQb4mf0q5Ng7ryy9CBD+czzAVWUlKQbM2RxINI 2KaWdnNNYLxoxzy2b1qSdnseUmgAaSqylpN5DkUaGr/veApa8TMNuklx5trcQ2Dd LKuvMwcm9pzM3w== X-ME-Sender: X-Sasl-enc: IQY4mrlzgvAwHFtTwySu7JoPtwsFD266T2gGsmd8Ax1U 1500365367 Received: from [172.16.18.183] (94.112.246.234.static.b2b.upcbusiness.cz [94.112.246.234]) by mail.messagingengine.com (Postfix) with ESMTPA id 7641E7E312; Tue, 18 Jul 2017 04:09:27 -0400 (EDT) Content-Type: multipart/alternative; boundary=Apple-Mail-F7C88292-7558-4C72-B56C-4EFF1A857CD5 Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPhone Mail (13G35) In-Reply-To: Date: Tue, 18 Jul 2017 10:30:04 +0200 Cc: Alexey Melnikov , "dmarc@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: <3A72407D-5B0A-44D9-A382-4DF21BCD3B1A@fastmail.fm> References: <1BF07A5C-5591-4463-B99A-6C2A3BCEFF04@isode.com> To: "Kurt Andersen (b)" Archived-At: Subject: Re: [dmarc-ietf] Comments on ARC specification X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 08:09:30 -0000 --Apple-Mail-F7C88292-7558-4C72-B56C-4EFF1A857CD5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Kurt, > On 18 Jul 2017, at 09:59, Kurt Andersen (b) wrote: >=20 >> On Tue, Jul 18, 2017 at 10:02 AM, Alexey Melnikov wrote: >> I've started implementing ARC and have a few minor comments on the draft:= >>=20 >> 5.1.2.2. Computing the 'b' Tag Value for ARC-Message-Signature >>=20 >> As with ARC-Seal and DKIM-Signature header fields, the order of >> header fields signed MUST be done in bottom-up order. >>=20 >> Upon rereading this I am not sure this is very clear. Maybe give an examp= le, especially if multiple instances of a particular header field are includ= ed. >=20 > See section 5.1.1.3 of the document which specifies the way to build the h= eader list for hashing.=20 Maybe add a cross reference then. Maybe it is just lack of coffee, but "bott= om-up" sounded confusing and the opposite of the DKIM order. --Apple-Mail-F7C88292-7558-4C72-B56C-4EFF1A857CD5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Hi Kurt,

On 18 Jul 2017, at 09:59, Kurt Andersen (b) <kboth@drkurt.com> wrote:

On Tue, Jul 18, 2017 at 10:02 AM, Alexey Melnikov <alexey.melnikov@isode.com> wrote:
I've started implementing ARC and have a few minor comments on the draft:

5.1.2.2.  Computing the 'b' Tag Value for ARC-Message-Signature

   As with ARC-Seal and DKIM-Signature header fields, the order of
   header fields signed MUST be done in bottom-up order.

Upon rereading this I am not sure this is very clear. Maybe give an example, especially if multiple instances of a particular header field are included.

See section 5.1.1.3 of the document which specifies the way to build the header list for hashing. 

Maybe add a cross reference then. Maybe it is just lack of coffee, but "bottom-up" sounded confusing and the opposite of the DKIM order.

--Apple-Mail-F7C88292-7558-4C72-B56C-4EFF1A857CD5-- From nobody Tue Jul 18 01:11:30 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5FE3131A57 for ; Tue, 18 Jul 2017 01:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=AfU8MHvv; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Vua8aUvd 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 L2LFjnEqgs9b for ; Tue, 18 Jul 2017 01:11:26 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B147212ECC0 for ; Tue, 18 Jul 2017 01:11:26 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 218972093C; Tue, 18 Jul 2017 04:11:26 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Tue, 18 Jul 2017 04:11:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=m7t415hOXlkbfLY9CG 4XAqoHWKzp5YZB2WuOFFBP6dk=; b=AfU8MHvv28I+C652/zGLnPJWl+2x+K6K4E BrGbw/40jv0N4Tz4LP85ri9h76r9XAZ2XgXhQQh7gw5E51/rak9eLVX+D2+7cxf2 53dp45B7ycpMlyZTrGp/CeNEb2ybpsgDc3EpWvbt850h573+BIFH6SY/7z9Rkava yWjH0QRYKM3WKDKiKlLPSZDyNs7afG0Kj1V+FxOyyaCPwYOW+eifKJnmYbQI1iQ9 wZlSvCCi1UZBWhytQ2Uu4knRS0VRWc+zPb/FL0Fn1lMNtOUFonxgyXuqRYzwnblI fe4dFcUslFbuy9UxXjZJDAVgcV1L9FFfS9IK7D+QszNLseXoMFnA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=m7t415hOXlkbfLY9CG4XAqoHWKzp5YZB2WuOFFBP6dk=; b=Vua8aUvd y3xPv7AQEWmUfTPQm2bXpWigFOjna58+aIHglbqEv5Ved6vSX1R6Hu4CIBDFCb0Q llhD6GvY4W515ZCJ7UojPmov/fBHaQCHvNlRPRtgufKla2oxLNqM2CQTLK1Mb5cj ncM7zJsuPihGz3j8UqLZ8HS20RPi6MrDo2/xlROUe3QZlWKpAwDGwb9e59uu4c/6 /fiFMG0QtJs1KhBU3KhfuhU0rzlpb6X+ftN4mBM/an/Bq2z4itWDo9M9KHkFKaV6 tp5/obkD7t4CXCF399A7QtrQa+OUafTos8gUZVpixQQSurGY5RFCPU/wi5hXAGaM NyEdc4NyU7Cq3A== X-ME-Sender: X-Sasl-enc: xpL2FbN48qVm4ghHILqDoGGjexfnZUPb+TEgxGwvGGgl 1500365485 Received: from [172.16.18.183] (94.112.246.234.static.b2b.upcbusiness.cz [94.112.246.234]) by mail.messagingengine.com (Postfix) with ESMTPA id B7BC37E312; Tue, 18 Jul 2017 04:11:25 -0400 (EDT) Content-Type: multipart/alternative; boundary=Apple-Mail-2B051E37-5BB2-46DE-9931-B9D4D24CAA13 Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPhone Mail (13G35) In-Reply-To: Date: Tue, 18 Jul 2017 10:32:03 +0200 Cc: "dmarc@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: <0D144909-B665-4D40-92E1-289AFD988294@fastmail.fm> References: <1BF07A5C-5591-4463-B99A-6C2A3BCEFF04@isode.com> To: "Kurt Andersen (b)" Archived-At: Subject: Re: [dmarc-ietf] Comments on ARC specification X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 08:11:29 -0000 --Apple-Mail-2B051E37-5BB2-46DE-9931-B9D4D24CAA13 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On 18 Jul 2017, at 09:59, Kurt Andersen (b) wrote: >=20 >> Examples need updating. >=20 > Thanks - I'm sure that there's a lot more problems in the examples than ju= st the ones you listed :-/ I suspect that we should just entirely remove the= examples right now. I think I like to see examples in the final version of the document when pub= lished as an RFC. They did help me to understand the document. > If you want a real life example, you can find it (for the next week or so)= at https://pastebin.com/HyMriMKe or other citations on the #ietf99 channel i= n the slack group. --Apple-Mail-2B051E37-5BB2-46DE-9931-B9D4D24CAA13 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

On 18 Jul 2017, at 09:59, Kurt Andersen (b) <kboth@drkurt.com> wrote:

Examples need updating.


Thanks - I'm sure that there's a lot more problems in the examples than just the ones you listed :-/ I suspect that we should just entirely remove the examples right now.

I think I like to see examples in the final version of the document when published as an RFC. They did help me to understand the document.

If you want a real life example, you can find it (for the next week or so) at https://pastebin.com/HyMriMKe or other citations on the #ietf99 channel in the slack group.
--Apple-Mail-2B051E37-5BB2-46DE-9931-B9D4D24CAA13-- From nobody Tue Jul 18 04:00:22 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D18D129B43 for ; Tue, 18 Jul 2017 04:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eo06TxG_Eg1g for ; Tue, 18 Jul 2017 04:00:18 -0700 (PDT) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9962C129459 for ; Tue, 18 Jul 2017 04:00:18 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id z22so18775237uah.1 for ; Tue, 18 Jul 2017 04:00:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:from:date:message-id:subject:to; bh=VVwV0/riWCNcBcLBgWOM3As43BrVCPT085Ym70AaJeE=; b=RVCYImcoewtATHKlYEwnPbHlDQG71uP6McU8kKx9yJ0q/LWDW4+CSI9srbT7ONh+A1 BcTMNoGUJ44dJAYTtfEJt9HDX8KhSGN9u5v+pg1XU3GzmjazEWHDHJbzZpTytcqCmuez K6dFRNg14doyI79nlz5TY9wvrJbD/5UDfTtiY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=VVwV0/riWCNcBcLBgWOM3As43BrVCPT085Ym70AaJeE=; b=Jb+JjhmZM8M1Cn1Kf1VX8hLxQSCR9TW6DtZqnrWE4/eKeUgGs3U5dB66d8GS91Zo2t N6CFym+0mHMkd5YU3kx69faDVTyV/XZvttuKn2e2I0/VFKIOGbGpo0ULOky6ZZpiUsmw GNnduIMPyu7aCAPrAEZE8DIPOiZkfyIKiBW9vR1hbVlqiYO4kX4z8wS/80ITm/jy9iUr YA+nMI6w2CcjA9jOANPagV5rSxSZVVCvc5i98nDdIatmjQm3/7S8krhXy5wMMbFEvHMh YsyftAsqcCXHE9zPYomx7MGSitPZZQWB6pSeo6zAr/IwyVbaf5o4/gJomWiS/CBC2Cuy 6/uw== X-Gm-Message-State: AIVw113admV2MzZk1PsG1xw48uSX4o1wvvzwSB7s63Eka0EUEYHUA9NB k9LE10Gebrt/7lA2SIYPoHq7FLpLXFTAcflR9w== X-Received: by 10.31.56.16 with SMTP id f16mr559625vka.86.1500375617475; Tue, 18 Jul 2017 04:00:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.26.39 with HTTP; Tue, 18 Jul 2017 04:00:17 -0700 (PDT) From: Kurt Andersen Date: Tue, 18 Jul 2017 13:00:17 +0200 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a1143185ab5abbb0554956b72" Archived-At: Subject: [dmarc-ietf] Question for Thursday's meeting consideration: extending DMARC DNS record to cover ARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 11:00:20 -0000 --001a1143185ab5abbb0554956b72 Content-Type: text/plain; charset="UTF-8" During today's lunch conversation, the question of how we can reasonably scale recipients being able to identify mediators came up. We've suggested (during M3AAWG sessions) that smaller recipients can build out a whitelist of "commonly seen" mediators, but might there be value in having a mediator publish some sort of DNS record that would indicate that they ARC seal mediated traffic? (We're deeming this not to be a problem for "big" receivers on the basis that they probably already know most of the major mediators within their traffic streams.) This might be an extension to the existing _dmarc record or perhaps a new _arc record type. How would recipients know to look for this record if the mediated traffic doesn't have a "from" in the mediator's domain space? Should they look at domain(s) information in the List- headers? I wanted to get this out to the list for consideration before Thursday's discussion so that we could possibly consider this during the AOB section of the agenda. --Kurt --001a1143185ab5abbb0554956b72 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
During today's lunch conversation, the question of how= we can reasonably scale recipients being able to identify mediators came u= p.

We've suggested (during M3AAWG sessions) that sma= ller recipients can build out a whitelist of "commonly seen" medi= ators, but might there be value in having a mediator publish some sort of D= NS record that would indicate that they ARC seal mediated traffic? (We'= re deeming this not to be a problem for "big" receivers on the ba= sis that they probably already know most of the major mediators within thei= r traffic streams.)

This might be an extension to = the existing _dmarc record or perhaps a new _arc record type.
How would recipients know to look for this record if the mediat= ed traffic doesn't have a "from" in the mediator's domain= space? Should they look at domain(s) information in the List- headers?

I wanted to get this out to the list for consideratio= n before Thursday's discussion so that we could possibly consider this = during the AOB section of the agenda.

--Kurt
=
--001a1143185ab5abbb0554956b72-- From nobody Tue Jul 18 04:30:31 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB306131B16 for ; Tue, 18 Jul 2017 04:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8nqRUSmDs7ze for ; Tue, 18 Jul 2017 04:30:28 -0700 (PDT) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A05C131B06 for ; Tue, 18 Jul 2017 04:30:28 -0700 (PDT) Received: by mail-ua0-x22d.google.com with SMTP id z22so19548987uah.1 for ; Tue, 18 Jul 2017 04:30:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UYdFaJ19Qcgt95kOgD2xZvPUEkA5L/tlVFh1zqiN6zQ=; b=K60omj9KIHFUp0NxkqWHF8wq+2klD60UKwX69gjzXbriY8hmLbMo3y2bSMjNPw1qy4 mziCzJq2SvQomdHekd9gMcTu5sa2CeXFNc0YF99TVb6749ttBjYII7bdvATHiHpwHHNe /uPW7NxRWu4coonDpymG/K2FRDqQLf5hXwqxF8Mhl/LjgwGzJ5OxXG2YBAjoYXo2t89W q2IQLhd2iwTvB2p00u0Zk/49GtT8d69hfXHL1qadm1zOh9lys4Ae3a3E0gvaz/Pg47yG VxpohWxmrLIEnyKZ3DN3bvfvtiFN3hrmbgE01RfUdfwcggyaFs8x2lJZHPZEc85Fsx1B eNqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UYdFaJ19Qcgt95kOgD2xZvPUEkA5L/tlVFh1zqiN6zQ=; b=rvh/tLfUJf/+F57Ag9iOrEaz+8/ZrbdRq+7lZr/V20DEy7aCv6Cx9aLjbP6GREnRpx vFnsloCBhujWGIqsTcl1h2/rl/wvkilWsvZ7xH0U7/AyaclMjZXKZXhVVRNzmB4OdE2m Nu8Fw2+i1+8hGwyQD4YbJBVGamAA8unEORqd99/jUmGnQNPA9GczEW84no8NmkDu6R+U H30YJ9mxgvYQE6W1kNGmNx2tuBipRakLJ/KZtyFQl9M/PTYvdBu7+enMBTdsdF+KrwEs oBGO9QZRzz6lE84S/aU8ZaDrZDF9RlVfboOeU4wBwUDAwTtwI0a3khruOoHRCtNKf72u rmUg== X-Gm-Message-State: AIVw112HYI/C3xJX6lpYPWTU5p5J8XgLUs5Kxc2BkO5e+5ZI0HzBmMg0 w328bB3/SwbF0894IfnFre9ZV7CS72ozZsc= X-Received: by 10.31.5.134 with SMTP id 128mr571168vkf.63.1500377427456; Tue, 18 Jul 2017 04:30:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.151.25 with HTTP; Tue, 18 Jul 2017 04:30:06 -0700 (PDT) In-Reply-To: References: From: Seth Blank Date: Tue, 18 Jul 2017 04:30:06 -0700 Message-ID: To: Kurt Andersen Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a114415f497cca2055495d714" Archived-At: Subject: Re: [dmarc-ietf] Question for Thursday's meeting consideration: extending DMARC DNS record to cover ARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 11:30:30 -0000 --001a114415f497cca2055495d714 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 18, 2017 at 4:00 AM, Kurt Andersen wrote: > During today's lunch conversation, the question of how we can reasonably > scale recipients being able to identify mediators came up. > I don't understand. Mediators ARC sign, the header is everything you need for this identification, is it not? > We've suggested (during M3AAWG sessions) that smaller recipients can build > out a whitelist of "commonly seen" mediators, but might there be value in > having a mediator publish some sort of DNS record that would indicate that > they ARC seal mediated traffic? (We're deeming this not to be a problem for > "big" receivers on the basis that they probably already know most of the > major mediators within their traffic streams.) > This is not why the white list exists. The white list exists as a short-term hack for people without internal reputation systems to determine trusted intermediaries (like the IETF, apache.org, etc.). Me publishing that I'm trusted on my own DNS doesn't help ;-) > This might be an extension to the existing _dmarc record or perhaps a new > _arc record type. > > How would recipients know to look for this record if the mediated traffic > doesn't have a "from" in the mediator's domain space? Should they look at > domain(s) information in the List- headers? > > I wanted to get this out to the list for consideration before Thursday's > discussion so that we could possibly consider this during the AOB section > of the agenda. > > --Kurt > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --001a114415f497cca2055495d714 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 18, 2017 at 4:00 AM, Kurt Andersen <kurta= @drkurt.com> wrote:
Durin= g today's lunch conversation, the question of how we can reasonably sca= le recipients being able to identify mediators came up.
<= div>
I don't understand. Mediators ARC sign, the header i= s everything you need for this identification, is it not?
=C2=A0<= /div>
We've suggest= ed (during M3AAWG sessions) that smaller recipients can build out a whiteli= st of "commonly seen" mediators, but might there be value in havi= ng a mediator publish some sort of DNS record that would indicate that they= ARC seal mediated traffic? (We're deeming this not to be a problem for= "big" receivers on the basis that they probably already know mos= t of the major mediators within their traffic streams.)

This is not why the white list exists. The white l= ist exists as a short-term hack for people without internal reputation syst= ems to determine trusted intermediaries (like the IETF, apache.org, etc.). Me publishing that I= 9;m trusted on my own DNS doesn't help ;-)
=C2=A0
This might be an extension t= o the existing _dmarc record or perhaps a new _arc record type.
<= br>
How would recipients know to look for this record if the medi= ated traffic doesn't have a "from" in the mediator's doma= in space? Should they look at domain(s) information in the List- headers?

I wanted to get this out to the list for considerat= ion before Thursday's discussion so that we could possibly consider thi= s during the AOB section of the agenda.

--Kurt

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


--001a114415f497cca2055495d714-- From nobody Tue Jul 18 04:34:49 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE7C2131DEF for ; Tue, 18 Jul 2017 04:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0GpVzdHL_Y3 for ; Tue, 18 Jul 2017 04:34:44 -0700 (PDT) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2F4C131838 for ; Tue, 18 Jul 2017 04:34:43 -0700 (PDT) Received: by mail-ua0-x234.google.com with SMTP id 35so19522537uax.3 for ; Tue, 18 Jul 2017 04:34:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Lbx/h/hm+kDgoksEWTVa2kMnSRuFsEZfjEq/o4fvLKw=; b=AXrOpaRVHnyWNdoM/9XhzVzZwhACdiEPjhYi5S89hHigvuEf8hDCJVQs76iZnAztbP BbBlmWM0Sb5Z2YgFs6pJEpjzy3cHJLa3uq3BmZmMUMAwnf2tN/ypGaYbrrz4fb9eQwqP ye/HNAXgf0HY9JzBbx/VmYLrm4cPMVi1c/tOY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Lbx/h/hm+kDgoksEWTVa2kMnSRuFsEZfjEq/o4fvLKw=; b=jT4juR6wRmEXxyJrJ94SV0XLkEyf1PHvdXVpWVNXxChhCHHFc3nQgbI0Ym+MvBPNaY dbwZ8EjmJVzSvb11FpyemzLajo75UVIBDhRt0yiZdh6IBwzv7fLZ3ovUZQCBBhi/HkRZ 7Cg3SeCVTiRps2OH08d7xMVIuj7CQHwrNnDz+tVzIR5cPn9hmOMA8kfgImt02PgkW1UQ sNSh+jBJYjU2ZwMe2FiqxsAii54VUX9G6qWSKlRHlvnOuZshlqzi5SSTEqhVEIeAwMMQ VlJqiX0SUNF1y/NXJU2po5dYpY07QqTa+uTR+5uCe/2FcFH04hav8TI2SKZ3mYkg8b7u lWyA== X-Gm-Message-State: AIVw113/m1wLZYWueAGDfh0qSyVMGdnNi0MlU1WTeiFnZUyPizyMlz/b VxPC17KJddwmqnt8YEG2YV4ESTIF+OLq X-Received: by 10.176.82.47 with SMTP id i44mr592536uaa.57.1500377682870; Tue, 18 Jul 2017 04:34:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.26.39 with HTTP; Tue, 18 Jul 2017 04:34:42 -0700 (PDT) In-Reply-To: References: From: Kurt Andersen Date: Tue, 18 Jul 2017 13:34:42 +0200 Message-ID: To: Seth Blank Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c18f6d8d1188c055495e6bc" Archived-At: Subject: Re: [dmarc-ietf] Question for Thursday's meeting consideration: extending DMARC DNS record to cover ARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 11:34:48 -0000 --94eb2c18f6d8d1188c055495e6bc Content-Type: text/plain; charset="UTF-8" On Tue, Jul 18, 2017 at 1:30 PM, Seth Blank wrote: > On Tue, Jul 18, 2017 at 4:00 AM, Kurt Andersen wrote: > >> During today's lunch conversation, the question of how we can reasonably >> scale recipients being able to identify mediators came up. >> > > I don't understand. Mediators ARC sign, the header is everything you need > for this identification, is it not? > Let's take ietf.org as an example. There are @ietf.org individuals and then there are all the mailing lists. If IETF wished to assert to receivers that all their mail was either mediated or came from designated internal servers, how would they do that? > We've suggested (during M3AAWG sessions) that smaller recipients can build >> out a whitelist of "commonly seen" mediators, but might there be value in >> having a mediator publish some sort of DNS record that would indicate that >> they ARC seal mediated traffic? (We're deeming this not to be a problem for >> "big" receivers on the basis that they probably already know most of the >> major mediators within their traffic streams.) >> > > This is not why the white list exists. The white list exists as a > short-term hack for people without internal reputation systems to determine > trusted intermediaries (like the IETF, apache.org, etc.). Me publishing > that I'm trusted on my own DNS doesn't help ;-) > I realize that you can not vouch for yourself, but you can say that you participate in ARC for mediated mail. --Kurt --94eb2c18f6d8d1188c055495e6bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Jul 18, 2017 at 1:30 PM, Seth Blank <seth@sethblank.com> wrote:
On Tue, Jul 18, 2017 at 4:00 AM, Kurt Andersen <= ;kurta@drkurt.com= > wrote:
During today's lunch conversation, the question of how we can reaso= nably scale recipients being able to identify mediators came up.

I don't understand. Mediators ARC si= gn, the header is everything you need for this identification, is it not?

Let's take ietf.org as an example. There are @ietf.org individuals and then there are all the mailing = lists. If IETF wished to assert to receivers that all their mail was either= mediated or came from designated internal servers, how would they do that?=
=C2=A0=C2=A0
We've suggested (dur= ing M3AAWG sessions) that smaller recipients can build out a whitelist of &= quot;commonly seen" mediators, but might there be value in having a me= diator publish some sort of DNS record that would indicate that they ARC se= al mediated traffic? (We're deeming this not to be a problem for "= big" receivers on the basis that they probably already know most of th= e major mediators within their traffic streams.)

This is not why the white list exists. The white l= ist exists as a short-term hack for people without internal reputation syst= ems to determine trusted intermediaries (like the IETF, apache.org, etc.). Me publishing that I= 9;m trusted on my own DNS doesn't help ;-)

I realize that you can not vouch for yourself, = but you can say that you participate in ARC for mediated mail.=C2=A0
<= div>
--Kurt
--94eb2c18f6d8d1188c055495e6bc-- From nobody Tue Jul 18 05:37:48 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDC8F131DE3 for ; Tue, 18 Jul 2017 05:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rI_jG9vv5dCT for ; Tue, 18 Jul 2017 05:37:44 -0700 (PDT) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B953131907 for ; Tue, 18 Jul 2017 05:37:44 -0700 (PDT) Received: by mail-ua0-x22c.google.com with SMTP id y47so6180739uag.0 for ; Tue, 18 Jul 2017 05:37:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=72jjkIjHchJjRF4x9ImE6hPcs2WCKOn3l0yxXLiApxU=; b=ipbgnF9duHhMX5BKGvhodErnzd8M3CkCDfsm9AnEz046T7H+K5rhdTX3EZVK3BgnCd X6DOusyD5gvjb02E1Cf0OQMrq4LKsQWFNNu4bnM3ppC+2mAU1RRivAMNdCoF3u7xCf5I c0vAERTH9Yu1NHShmej3n4thaBA2OP98GLkDdLkIjRrotHZopR3tIlYvyr45t2ISr1F3 J350poL1EmqI7zgJcKeyLFjM252Q3QzJfjPQlGRMyeEaEbqPR1NLjoFaQA7qCLMsAiSe DpmqpwlPXoGAxad85AQVG//JfXV0+GO4I7kKMz4yD/0RYt0YWoNsOvIHWo5txypxl2dd gDoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=72jjkIjHchJjRF4x9ImE6hPcs2WCKOn3l0yxXLiApxU=; b=j0xzzNTUizIhaCXZUiTXqD4HK9h/Oo2SMaVd5KapZ0kF7V13mw/g5uFRXhDaYBBJgs INUC6EHflvA1Q7ns3r3hK0x9ptr/NYuExwcyXe88FxrQS4Us4N/Z7W4x2VIBudB920Zx 1mZgmI8aqtzM+hTU/Cu8GuF9dyoN736sfE8MSUzRNDZ2wheAKD6vvaHRrqO1WRPdb+Qh jjFQjEmFzXGErHSt/zRftqkG4I5iNwIKJViJejHW2gffbiP7pExF2ceafJBoK5GwotMz csJJEKaf7/wp7jua8cR3UVvDfW/RPFdWjirfRsWuG3mVN/agsB7zcjq+U+IXuNSjww1K vODA== X-Gm-Message-State: AIVw113sRvaTHVftwR2ScvNinTGj1zjxIbFXXITbVBknQ21kbgSfTAwt APRrPqEzOpNmrPy00yUGd9sTlA+y3HeTp5U= X-Received: by 10.31.190.201 with SMTP id o192mr725999vkf.35.1500381463351; Tue, 18 Jul 2017 05:37:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.151.25 with HTTP; Tue, 18 Jul 2017 05:37:22 -0700 (PDT) In-Reply-To: References: From: Seth Blank Date: Tue, 18 Jul 2017 05:37:22 -0700 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a11439ce026ae6f055496c830" Archived-At: Subject: Re: [dmarc-ietf] Question for Thursday's meeting consideration: extending DMARC DNS record to cover ARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 12:37:47 -0000 --001a11439ce026ae6f055496c830 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 18, 2017 at 4:34 AM, Kurt Andersen wrote: > > Let's take ietf.org as an example. There are @ietf.org individuals and > then there are all the mailing lists. If IETF wished to assert to receivers > that all their mail was either mediated or came from designated internal > servers, how would they do that? > I don't understand why this distinction matters. Either you send email that authenticates and gets delivered, or that fails authentication but is ARC signed and gets delivered. Everything else gets rejected or heavily scrutinized. Where would this distinction add clarity or prevent abuse? (I'm not saying it doesn't, just that I don't see it.) > We've suggested (during M3AAWG sessions) that smaller recipients can build >>> out a whitelist of "commonly seen" mediators, but might there be value in >>> having a mediator publish some sort of DNS record that would indicate that >>> they ARC seal mediated traffic? (We're deeming this not to be a problem for >>> "big" receivers on the basis that they probably already know most of the >>> major mediators within their traffic streams.) >>> >> >> This is not why the white list exists. The white list exists as a >> short-term hack for people without internal reputation systems to determine >> trusted intermediaries (like the IETF, apache.org, etc.). Me publishing >> that I'm trusted on my own DNS doesn't help ;-) >> > > I realize that you can not vouch for yourself, but you can say that you > participate in ARC for mediated mail. > But isn't saying I participate in ARC done by ARC sealing a message? And conversely, what if I'm ARC signing but either a) don't properly update my DNS, or b) have a malformed DNS entry? Does this mean my good ARC signature is thrown away? This feels like an avenue for operational complexity that could slow ARC adoption. Upgrading your software to properly seal messages is a low bar and we shouldn't increase the complexity unless there's exceptional value to be gained. > --Kurt > --001a11439ce026ae6f055496c830 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Jul 18, 2017 at 4:34 AM, Kurt Andersen <kurta@drkurt.com>= wrote:
Let's take ietf.org as an example. There are @ietf.org individuals and then there = are all the mailing lists. If IETF wished to assert to receivers that all t= heir mail was either mediated or came from designated internal servers, how= would they do that?

I don't understand why this distinction matters. Either you send emai= l that authenticates and gets delivered, or that fails authentication but i= s ARC signed and gets delivered. Everything else gets rejected or heavily s= crutinized. Where would this distinction add clarity or prevent abuse? (I&#= 39;m not saying it doesn't, just that I don't see it.)
= =C2=A0 =C2=A0
We've suggested (during M3AAWG sessions) that smaller recipients can b= uild out a whitelist of "commonly seen" mediators, but might ther= e be value in having a mediator publish some sort of DNS record that would = indicate that they ARC seal mediated traffic? (We're deeming this not t= o be a problem for "big" receivers on the basis that they probabl= y already know most of the major mediators within their traffic streams.)

This is not why the white= list exists. The white list exists as a short-term hack for people without= internal reputation systems to determine trusted intermediaries (like the = IETF, apache.org, etc.)= . Me publishing that I'm trusted on my own DNS doesn't help ;-)

I realize that = you can not vouch for yourself, but you can say that you participate in ARC= for mediated mail.=C2=A0

But isn't saying I participate in ARC done by ARC sealing a mess= age?

And conversely, what if I'm ARC signing b= ut either a) don't properly update my DNS, or b) have a malformed DNS e= ntry? Does this mean my good ARC signature is thrown away? This feels like = an avenue for operational complexity that could slow ARC adoption. Upgradin= g your software to properly seal messages is a low bar and we shouldn't= increase the complexity unless there's exceptional value to be gained.=
=C2=A0
--Kurt

--001a11439ce026ae6f055496c830-- From nobody Tue Jul 18 06:43:02 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA10F131B01 for ; Tue, 18 Jul 2017 06:43:01 -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 tmlbe0HZ2QSM for ; Tue, 18 Jul 2017 06:42:57 -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 CCEDF131B62 for ; Tue, 18 Jul 2017 06:42:55 -0700 (PDT) Received: from [31.133.136.200] (dhcp-88c8.meeting.ietf.org [31.133.136.200]) (authenticated bits=0) by segv.crash.com (8.14.5/8.14.5/cci-colo-1.6) with ESMTP id v6IDgEPs048257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 18 Jul 2017 06:42:21 -0700 (PDT) (envelope-from smj@crash.com) X-SenderID: Sendmail Sender-ID Filter v1.0.0 segv.crash.com v6IDgEPs048257 Authentication-Results: segv.crash.com; sender-id=permerror header.from=smj@crash.com; auth=pass (PLAIN); spf=permerror smtp.mfrom=smj@crash.com X-DKIM: OpenDKIM Filter v2.4.3 segv.crash.com v6IDgEPs048257 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=201506-2k; t=1500385341; bh=lHg6yOlfFx43yj9wF9z/3IT+OSwf7JNGZpgrMyGdWOw=; h=Subject:To:References:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=RTiXCF36A+vVTycQ3N6qs+7b1xW8YKDWxqlD5fFrXJOwf5QIYr3+pobyryx4EZk5d XPkjNFF/mVayfJAxRU86HP1DcdmPaPIvsKheng2pB0D37zsbl7HAJYWXLAFy8n+DKF iolyp6tuQcH1U/U7gcQ7udY0nslz7V1Gn1ZY58PHvlIHmzVJRwPngoaHjh2uptj77M EZJzlgZLw6seuqS8kolBAt9fFn51RuOmUR4CzLztQzL0GgGAoheEe8z6yJquo6Rt2I lnVj6GHfxjZJjelHvF4+nvVsOZwfkAJC7VzHuhBR/qiz8fBl1fGIOM7mAp3euR1eJt oH2Rq1RU3+TcA== X-Authentication-Warning: segv.crash.com: Host dhcp-88c8.meeting.ietf.org [31.133.136.200] claimed to be [31.133.136.200] To: dmarc@ietf.org References: From: Steven M Jones Message-ID: Date: Tue, 18 Jul 2017 15:42:15 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (segv.crash.com [72.52.75.15]); Tue, 18 Jul 2017 06:42:21 -0700 (PDT) Archived-At: Subject: Re: [dmarc-ietf] Question for Thursday's meeting consideration: extending DMARC DNS record to cover ARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 13:43:02 -0000 On 07/18/2017 01:00 PM, Kurt Andersen wrote: > > We've suggested (during M3AAWG sessions) that smaller recipients can > build out a whitelist of "commonly seen" mediators, but might there be > value in having a mediator publish some sort of DNS record that would > indicate that they ARC seal mediated traffic? That whitelist - if I'm not confused - is used by the small/medium receiver to identify ARC intermediaries whose ARC-sealed authentication information they can take as accurate. In other words, that they can _trust_ ARC information from those intermediaries... It's the stand-in for the sophisticated reputation systems that the large receivers already have. The problems with self-identifying oneself as trustworthy are pretty clear... I'm missing what the other use for this information would be. What's the result of plugging this information into the small/medium receiver's filters? --S. From nobody Tue Jul 18 07:08:51 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28AB212FEE2 for ; Tue, 18 Jul 2017 07:08:50 -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 JzfMjnkQ7bxm for ; Tue, 18 Jul 2017 07:08:49 -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 ED8B81286B2 for ; Tue, 18 Jul 2017 07:08:47 -0700 (PDT) Received: from [31.133.136.200] (dhcp-88c8.meeting.ietf.org [31.133.136.200]) (authenticated bits=0) by segv.crash.com (8.14.5/8.14.5/cci-colo-1.6) with ESMTP id v6IE86dd048482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 18 Jul 2017 07:08:13 -0700 (PDT) (envelope-from smj@crash.com) X-SenderID: Sendmail Sender-ID Filter v1.0.0 segv.crash.com v6IE86dd048482 Authentication-Results: segv.crash.com; sender-id=permerror header.from=smj@crash.com; auth=pass (PLAIN); spf=permerror smtp.mfrom=smj@crash.com X-DKIM: OpenDKIM Filter v2.4.3 segv.crash.com v6IE86dd048482 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=201506-2k; t=1500386893; bh=lHg6yOlfFx43yj9wF9z/3IT+OSwf7JNGZpgrMyGdWOw=; h=Subject:To:References:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=VLAqhO6YisuLIrNXLls7EuarUJgsykudon34mwT0EXIphVplVSMelj1t+tljhLbLT qMWIFqBE5vAQTCwrJ9+13GjR5UTnE3i9ZBnOOrgLn5SSmwdkcok3Awom+3DwPiHEeA 1Xt1yY7yaeH4wRG9NzlKdYsJWaoK1qH1MUAsSTCvfOg26RbEneEapkFg4ynVcUafVz Vi98h7PM2EdenJ4OTazLVTaB/MObputT0/yqefWzcwn8CMbUcY5J4Zvf8jItuHH5tN +41m228mLw+x4uZUK/sbk7qhsfwNNhCJrb3n+6mWdKhSx5/EQ/WpCQZN2RB4Tryef9 Y1PSTjyWO/qUg== X-Authentication-Warning: segv.crash.com: Host dhcp-88c8.meeting.ietf.org [31.133.136.200] claimed to be [31.133.136.200] To: dmarc@ietf.org References: From: Steven M Jones Message-ID: <0946c69b-6706-44b4-55c8-327f8fe826e8@crash.com> Date: Tue, 18 Jul 2017 16:08:07 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (segv.crash.com [72.52.75.15]); Tue, 18 Jul 2017 07:08:13 -0700 (PDT) Archived-At: Subject: Re: [dmarc-ietf] Question for Thursday's meeting consideration: extending DMARC DNS record to cover ARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 14:08:50 -0000 On 07/18/2017 01:00 PM, Kurt Andersen wrote: > > We've suggested (during M3AAWG sessions) that smaller recipients can > build out a whitelist of "commonly seen" mediators, but might there be > value in having a mediator publish some sort of DNS record that would > indicate that they ARC seal mediated traffic? That whitelist - if I'm not confused - is used by the small/medium receiver to identify ARC intermediaries whose ARC-sealed authentication information they can take as accurate. In other words, that they can _trust_ ARC information from those intermediaries... It's the stand-in for the sophisticated reputation systems that the large receivers already have. The problems with self-identifying oneself as trustworthy are pretty clear... I'm missing what the other use for this information would be. What's the result of plugging this information into the small/medium receiver's filters? --S. From nobody Tue Jul 18 07:20:38 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCD9C12EC36 for ; Tue, 18 Jul 2017 07:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ft7ZeMDwzYWm for ; Tue, 18 Jul 2017 07:20:35 -0700 (PDT) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3977A12F280 for ; Tue, 18 Jul 2017 07:20:35 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id y47so9861253uag.0 for ; Tue, 18 Jul 2017 07:20:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=B/JUXs4XQ8JCpP8020E5BoN/kUH5q3rR7qGuhxTR7G8=; b=UyIkg38dQxwwDBtLfjzkeO6ChpTfp2krdj5D7rwF/vZ6UOTZLcpUMrvYp47K1EbMNq W/ZOc1ep9NEVTZSlXqmsF9pNdZDZ0L9POODTBO4rZFZ0STYXNX0p83/3Ya3Jb2r6Nm98 jsylGNBTlQJzBB989Xf80BYtbos+HcJMFu2gY+s+3SchvoJO10sRYVXzP8leBNn3Oi8V uxvoQzrAjDac5EwF+vYAm4p02F95Eh0gexbjMMtcuv6jsXYFyirLBe9RvQ6oXCA2OP3N h1yETKYpmppF2MAgK/3jbaq7THzwpamkQ7ZHc85CMIXs7jXIg3wZLbmJSo/tNTWICkZT Q3Jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=B/JUXs4XQ8JCpP8020E5BoN/kUH5q3rR7qGuhxTR7G8=; b=HRY2HQnsLuSfUdDD3eNu5y35NzJbDyvrazG2GzUHQIwowPMt9OZGe3iZ5Eldk3PiwV dylvYOgH8ISfVy63N6OEopnyK5w3ajBcRy3Szh68I9kAPo6fmSxEUpPEYIOYe8xapyqv 9h5eIPgc4bIW036L/IhwKYUDcQGfEJMB+6QSMefToofPoZROH65alwdQoECHENSH1f3O hskNmNzY7AfFdyZEw8glSPToZR/+AbIZyCcVz+0d5iQvNYB9q9rS/vb1+d3NU4Y4nO8Q LrROrSeq1hmH5LyQO+jPtq5idr7j4Du19UXkbBO9kIeMn4lDIDgReAdnble1QNbtJBpL CRjA== X-Gm-Message-State: AIVw113rPOzmP1qgIDC7yGG3+9x62YZLkYdEeoPqxzI1W90jEtH/+kqQ yvkPLyfNsmd2BD/ARTvclf+Bh2cegA== X-Received: by 10.176.81.93 with SMTP id f29mr954712uaa.113.1500387634387; Tue, 18 Jul 2017 07:20:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.126.196 with HTTP; Tue, 18 Jul 2017 07:20:33 -0700 (PDT) In-Reply-To: References: From: "Murray S. Kucherawy" Date: Tue, 18 Jul 2017 16:20:33 +0200 Message-ID: To: Kurt Andersen Cc: Seth Blank , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c190c2af91e3a05549837bb" Archived-At: Subject: Re: [dmarc-ietf] Question for Thursday's meeting consideration: extending DMARC DNS record to cover ARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 14:20:37 -0000 --94eb2c190c2af91e3a05549837bb Content-Type: text/plain; charset="UTF-8" On Tue, Jul 18, 2017 at 1:34 PM, Kurt Andersen wrote: > > I don't understand. Mediators ARC sign, the header is everything you need >> for this identification, is it not? >> > > Let's take ietf.org as an example. There are @ietf.org individuals and > then there are all the mailing lists. If IETF wished to assert to receivers > that all their mail was either mediated or came from designated internal > servers, how would they do that? > Why should receivers trust such an assertion by a domain they have not already decided to trust? Couldn't a bad actor make such a claim in an attempt to get preferential treatment? -MSK --94eb2c190c2af91e3a05549837bb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 18, 2017 at 1:34 PM, Kurt Andersen <kurta@dr= kurt.com> wrote:

I don't understand. Mediators ARC sign, the header is= everything you need for this identification, is it not?
<= /div>

=
Let's take ietf.org as an example. There are @ietf.org individuals and then there are all the mailing l= ists. If IETF wished to assert to receivers that all their mail was either = mediated or came from designated internal servers, how would they do that?<= /div>

Why should receiver= s trust such an assertion by a domain they have not already decided to trus= t?=C2=A0 Couldn't a bad actor make such a claim in an attempt to get pr= eferential treatment?

-MSK
--94eb2c190c2af91e3a05549837bb-- From nobody Tue Jul 18 07:57:08 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F735131A7D for ; Tue, 18 Jul 2017 07:57:07 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 d5Mg_sJwDwTE for ; Tue, 18 Jul 2017 07:57:06 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9CCD129482 for ; Tue, 18 Jul 2017 07:57:05 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id q4so19298021oif.1 for ; Tue, 18 Jul 2017 07:57:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=a+IxF7jhbOL/sJvvLnsG/LmSIE2yebHEnLhQ5RFQOQw=; b=eSJ6q0PftRhmjaDMLJRcAvhCO4n+LFASUm896NBo+xAdrfOtihIidWiPCKPwgcFtaO 3eMj5WvWKb6Ci4ZOgutriLx6GfJSBCoBvXzuAfZgxIinLx2jnu3iJOM6zWlMtgVie+oo KY2lmQTIHUAWnZZgbKTdPUK5MoZzlU+096v942b2ioqZ0rJTUBk44YwTGgNxxH/440lk DDmiyP4tGR3n0mYN1Rhpc75lFn8mYgv3KuPkJHRkKjTLLGoyM0NIMnvdLq1W+6nGapdl C3zMJukHF9aUK4mKk5N/7jFep4u8JY0J7UTdCqjtbnB1g5n1Mpl2DQX40vXdPmZbTVJA 0LXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=a+IxF7jhbOL/sJvvLnsG/LmSIE2yebHEnLhQ5RFQOQw=; b=lbHXe8mhV1YDZamAdUcTjmVdYVyts7SmkCB5fVd/AIDmVe5e6c3DN1lzyoQ+Yvf5+v Cjyrvh1UChKvFICLMaGe59gUGKJqoJSvp7ibohi8y20czluV7KecTwqMJzK6KuA8dzhn 6sS1EAkQxXxT6gwueuIgUoWeWSqxeLiCnWHJ5/ywoVjyu2t4bHrdj3EP2afCHXOhaDkI JdeYDq8SMipRugdwVPAPp5N78HT83rKL29d4zNa/B6h8CXLSUHsHV5Gjrxl3vn3BbRC6 Qni1ojfFe6/9qiufex5aVDRo25SlTOILfSeIN1/aZY0hlE+NC/dG6empkwAmsTz1VRHa jcrQ== X-Gm-Message-State: AIVw112CCaY2AxImz+iycllqnHfv6lvYS/dUPUHWRFjXul49HXhZ2ov+ 4k2SiO0CjuPngM+jXrQ= X-Received: by 10.202.48.5 with SMTP id w5mr1093980oiw.101.1500389823889; Tue, 18 Jul 2017 07:57:03 -0700 (PDT) Received: from ?IPv6:2602:304:cda0:8800:a0d1:e2cd:4698:7fa1? ([2602:304:cda0:8800:a0d1:e2cd:4698:7fa1]) by smtp.gmail.com with ESMTPSA id f10sm3150047oic.9.2017.07.18.07.57.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Jul 2017 07:57:02 -0700 (PDT) To: "Murray S. Kucherawy" , Kurt Andersen Cc: "dmarc@ietf.org" , Seth Blank References: From: Dave Crocker Message-ID: Date: Tue, 18 Jul 2017 07:57:00 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Question for Thursday's meeting consideration: extending DMARC DNS record to cover ARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 14:57:07 -0000 On 7/18/2017 7:20 AM, Murray S. Kucherawy wrote: > On Tue, Jul 18, 2017 at 1:34 PM, Kurt Andersen > wrote: > Let's take ietf.org as an example. There are > @ietf.org individuals and then there are all the > mailing lists. If IETF wished to assert to receivers that all their > mail was either mediated or came from designated internal servers, > how would they do that? > > Why should receivers trust such an assertion by a domain they have not > already decided to trust? Couldn't a bad actor make such a claim in an > attempt to get preferential treatment? Exactly. The concept of whitelisting seems to parallel use of that construct 15 or so years ago. It has some utility in simple cases, but does not scale well and does not deal well with the dynamics of today's world of email system compromise... ARC is an underlying authentication mechanism that calls for a new assessment mechanism, since the role of the authenticated entity is different than the entities currently being assessed by filtering engines -- intermediary rather than originator. It is possible that simply re-using current assessment mechanisms will suffice -- I can easily imagine that working well -- but it seems equally possible that different mechanisms will be needed. This open question about how ARC authentication will get used is one of the reasons I think the industry needs to deploy ARC experimentally for awhile, to develop some real-world operational experience with the dynamics of using it, beyond the early experience already being gained. That's why I've suggested that being able to write a stable "Using ARC" BCP would be a pragmatic milestone for deciding that ARC is appropriate for formal standardization. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Jul 18 08:52:27 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD55131B65 for ; Tue, 18 Jul 2017 08:52:26 -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 iXIvAE-9vquQ for ; Tue, 18 Jul 2017 08:52:25 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75F65131A54 for ; Tue, 18 Jul 2017 08:52:25 -0700 (PDT) Received: (qmail 36264 invoked from network); 18 Jul 2017 15:52:24 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 18 Jul 2017 15:52:24 -0000 Date: 18 Jul 2017 15:52:02 -0000 Message-ID: <20170718155202.14168.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org Cc: dcrocker@gmail.com In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Question for Thursday's meeting consideration: extending DMARC DNS record to cover ARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 15:52:26 -0000 In article you write: >ARC is an underlying authentication mechanism that calls for a new >assessment mechanism, since the role of the authenticated entity is >different than the entities currently being assessed by filtering >engines -- intermediary rather than originator. Well, yes, but for ARC you need a bottom turtle that tells you whether to mix the advice from the ARC chain into your message assessment. R's, John From nobody Tue Jul 18 09:04:27 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9EC91287A0 for ; Tue, 18 Jul 2017 09:04:25 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 BYsAZ_QU3KB5 for ; Tue, 18 Jul 2017 09:04:24 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F1611200FC for ; Tue, 18 Jul 2017 09:04:24 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id q4so21137322oif.1 for ; Tue, 18 Jul 2017 09:04:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=PzYitAqXUx+byi5xZxng//wBMyw/PTStd8HCdFfKj/Q=; b=buYIRnfIcei2sgniVh3h8qCUXl+sjEcFUIxmcv8ERITo6XfR8czi5tPXWCQQkGewtF d49qfJlSaH9JQLyjbjla3o3JcS6EV6WxnIl8rO50ITqjNmY9K9S9IpfW/tzQSlh5gYTb aywKWqe1yPZkwzqB3ZHjDJiuTOrt5Ib8xD5rf1PU8t++9XN/mOfVFXGG74saQDKz77Ct 19PSTewD1CzSHi1nQ/CxYiCJIO8dKDBAqxJ1m5TgFn8ReMTXtwu5DZQ+ndSTwT/s3Q9g MxtX0kRY972/v677xllh4kJ1SliK/I3D6fZteOMdc+MQz5480twKL7uTm32RnElSQpP9 CQyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=PzYitAqXUx+byi5xZxng//wBMyw/PTStd8HCdFfKj/Q=; b=UOxG3kDWE5JTgIHDPJi8/VHf/k0EHBguMzX8mxab/xRE/uUJ9aEF0xqINJ86V4Yje9 g62xRrmK4qKraISIVh2Vj59XgE2Syj8WUUV2LE7VymvZhkUe8uFcv9SazAItF1Dt3VdT 5JkcWIMgp8DyERBoPPUjCsszu6/pyq6Hp4jAarX+DrTHFItM+jLELS8V/FM1ZbWFtb+w LMW44NzW5Bl7sKw2rLl9w3vMhyufVZzHsQe9+TunFCMCfJB1a0NRwrossdW3my4bF4Ph dcVw+loJuMkrl2jbpDoTnMxGj5mGL9BAdIJZNsuRdzmfuY5Zuwu5ejGL6UagwujKLfPo 5Qzw== X-Gm-Message-State: AIVw110Ru9D4olKKMQK5NwYn1wLNixJZAZ5a4rLbSWRiQ4CxTiKUK4i9 dE4zFdyX+YUAKg3HcBE= X-Received: by 10.202.66.4 with SMTP id p4mr1655816oia.114.1500393863538; Tue, 18 Jul 2017 09:04:23 -0700 (PDT) Received: from ?IPv6:2602:304:cda0:8800:a0d1:e2cd:4698:7fa1? ([2602:304:cda0:8800:a0d1:e2cd:4698:7fa1]) by smtp.gmail.com with ESMTPSA id t77sm2891330oif.38.2017.07.18.09.04.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Jul 2017 09:04:22 -0700 (PDT) To: John Levine , dmarc@ietf.org References: <20170718155202.14168.qmail@ary.lan> From: Dave Crocker Message-ID: <65c96c82-f49a-4f41-1151-44c7a7181082@gmail.com> Date: Tue, 18 Jul 2017 09:04:21 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170718155202.14168.qmail@ary.lan> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Question for Thursday's meeting consideration: extending DMARC DNS record to cover ARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 16:04:26 -0000 On 7/18/2017 8:52 AM, John Levine wrote: > Well, yes, but for ARC you need a bottom turtle that tells you whether > to mix the advice from the ARC chain into your message assessment. Not sure what the 'but' is meant to contrast with. In claiming that figuring out how to add the assessment component, I'd expect the figuring to include such consiuderations and 'whether ]and how] to mix the advice' in... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Jul 18 15:57:56 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20D5213170E for ; Tue, 18 Jul 2017 15:57: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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 eJy83zr23NeO for ; Tue, 18 Jul 2017 15:57:52 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A208D128BA2 for ; Tue, 18 Jul 2017 15:57:52 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id p188so30037463oia.0 for ; Tue, 18 Jul 2017 15:57:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=cjNgYVOy5nTy30kLgLvQBtlkzzTen4zVekMVwa73JBQ=; b=jfR1yb8ydCtnOleKFCLaxwDFkdK8GdKhxL7ggb6lKgxOZWBo8dlv7P9jR3RFUDmaPR W07uAh3Q+4QWKynR25tMCqkjaVFwFdUEvDXFt4mTJJDdSNcx4SEt5KGSTeKnheQkDTut nNbB3gbTipXRl21JxQoZ4C0WEdtxjjW13Ko5tvLJKpcvTFGGK/fu++2dTgkbamJAJB+W lbberlXL5Tscu89NPtgxrEiDBsKrYof0dX4NBrvKBHM/Dgzki74l+Q2hi/j9o27PF9Ao tSuJvfbj5N7JNV1yOylJkjeGiiphjuxtmr6PjzQCJ8IH78Vy2ZGBORV9PIwSgXFfE5KJ lZng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=cjNgYVOy5nTy30kLgLvQBtlkzzTen4zVekMVwa73JBQ=; b=S1UN3KaCzUFIRckMYRZ/PWBEEQnRYiVGpstdwXLlzn1pmGaAEP+cRz30YUMwzLxr/6 3zGRVodB21+/4mLrnk2RkMCWIwiZ0C8lQvelnG2sv25nD7ipL6O+kriabeVfpj/kUZyT XJgCPNJKCmPLr5U2RW4jV2hy9I/uhDibQVkh+Qm1TngLFsOPqzxooIuzKsKX48QYjCnJ 7m5P9D7qlyT+gvu01SCsMt3tVrpmOGGj7cvJEW1R1dIxD5JJNQM/Ui5A/+rwkDQ16CLc OLHxHfzTGYhQg+DdIWCxNL/QJZG1cm95mVbWIiyhNuO+W5zMQlqJwW74IlZXuRDyJ9+1 YMpg== X-Gm-Message-State: AIVw110qxV3nfY4vMnfuP4BKbo00mbbnomXWlo1BwHNOABgJTayiejdX IEjq2/yLZKg4kWLFVYY= X-Received: by 10.202.198.199 with SMTP id w190mr2273258oif.93.1500418671833; Tue, 18 Jul 2017 15:57:51 -0700 (PDT) Received: from ?IPv6:2602:304:cda0:8800:d17e:7fe3:9cb7:7c98? ([2602:304:cda0:8800:d17e:7fe3:9cb7:7c98]) by smtp.gmail.com with ESMTPSA id u186sm3833717oie.34.2017.07.18.15.57.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Jul 2017 15:57:51 -0700 (PDT) To: Kurt Andersen , Seth Blank Cc: "dmarc@ietf.org" References: From: Dave Crocker Message-ID: <455759f1-f40d-c742-0788-cd179b53ed78@gmail.com> Date: Tue, 18 Jul 2017 15:57:48 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Question for Thursday's meeting consideration: extending DMARC DNS record to cover ARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 22:57:55 -0000 On 7/18/2017 4:34 AM, Kurt Andersen wrote: > I realize that you can not vouch for yourself, but you can say that you > participate in ARC for mediated mail. My concern is similar to what others already are expressing: I'm not clear what the security-related benefit would be. Publishing an 'I participate in ARC' record seems naturally reasonable, but I can't figure out how it would get used meaningfully. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Jul 19 04:28:59 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68791131CC3 for ; Wed, 19 Jul 2017 04:28:57 -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 rZm4AVonTGlP for ; Wed, 19 Jul 2017 04:28:55 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c: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 22E2F131CC4 for ; Wed, 19 Jul 2017 04:28:53 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id p193so6297262vkd.0 for ; Wed, 19 Jul 2017 04:28:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:from:date:message-id:subject:to; bh=9hDphOIRbuk8bh1fKKMQpwXfYrfV66tKmhoah6qUtXg=; b=OqqGjZZv48I9D7Zeen3+PD+va65MqpX/5dVjYcHnKRomwKmAsMnm/3Gxg9HVrtcIGt 8IKLh5qG3ib8T9Uds9/tX5QAlT60cgxcTadHP6g426dTxDT+ANggQVSz7YmpuuAcjQGX p//pD4r1xWSGjGLKxfF3V5yZoZSs0vgSmWsfU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=9hDphOIRbuk8bh1fKKMQpwXfYrfV66tKmhoah6qUtXg=; b=D5PuqsORbFgDw403vL4oL4XKB2v1YT+Atat5RNbyT+59P9+nlMSkgZRU/2+8rW/Z6q JhESvOM+0cvxhN3JKDNYa7pBBloohaGrsBnWGZBwU6muND51Hds5F50GpU42oTKa31N7 SASI1KTlBBKbY9Pe4SBAn8vyrzamOl1dDvrqRgdxfpTGYXS19VInP08Z6NviE6StfMZM gbzALWY7Mmo9iG9J+SMoor1Ol/PNGoB8SFewLL5hs+8IHNVzpDOS31m0d0fPM2kTXsD7 LuY/qeyYBAUV4aIlXHqwuNB0VUnVMddObW2Em1hzKbPfDYs+qFlIFDA2wmatpj/tmOHL iUAA== X-Gm-Message-State: AIVw112Sf6ufZmn/FplOx8uQhRUY84EeIAS0AFxsKBBSdSMMFBTGvSRl N7/sjPUwKTx/q7E1ecHgNTeiHo7oPmHQClE= X-Received: by 10.31.206.5 with SMTP id e5mr84665vkg.178.1500463732682; Wed, 19 Jul 2017 04:28:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.26.39 with HTTP; Wed, 19 Jul 2017 04:28:52 -0700 (PDT) From: Kurt Andersen Date: Wed, 19 Jul 2017 13:28:52 +0200 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a114e61d2c906380554a9effb" Archived-At: Subject: [dmarc-ietf] Open issue: mandatory signing of AAR[n] by AMS[n] X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 11:28:57 -0000 --001a114e61d2c906380554a9effb Content-Type: text/plain; charset="UTF-8" The spec currently calls for the n-th instance of AAR to be signed by the related AMS[n] header as well as the AS[n] header. There have been some offlist discussions about whether that is really necessary, and, generally the conclusion was that it is not really necessary to the integrity of the mechanism to have the AAR incorporated into the signed space for both AMS and AS. The question to the list (and one which we will also raise in the meeting on Thursday @ IETF) is whether to change the spec to make the signing of AAR[n] by AMS[n] optional. It won't break any current implementations and apparently will make some deployments easier (I'll have to let Seth and Gene chime in with details) so I'm inclined to make the change. Opinions? --Kurt --001a114e61d2c906380554a9effb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The spec currently calls for the n-th instance of AAR to b= e signed by the related AMS[n] header as well as the AS[n] header.

=
There have been some offlist discussions about whether that is r= eally necessary, and, generally the conclusion was that it is not really ne= cessary to the integrity of the mechanism to have the AAR incorporated into= the signed space for both AMS and AS.

The questio= n to the list (and one which we will also raise in the meeting on Thursday = @ IETF) is whether to change the spec to make the signing of AAR[n] by AMS[= n] optional.

It won't break any current implem= entations and apparently will make some deployments easier (I'll have t= o let Seth and Gene chime in with details) so I'm inclined to make the = change.

Opinions?

--Kurt<= /div>
--001a114e61d2c906380554a9effb-- From nobody Wed Jul 19 04:34:51 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFD48131CC6 for ; Wed, 19 Jul 2017 04:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXuFX1iURc4O for ; Wed, 19 Jul 2017 04:34:38 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E3C3131CC2 for ; Wed, 19 Jul 2017 04:34:32 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id i187so771508vke.4 for ; Wed, 19 Jul 2017 04:34:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=e97jyQTFbtZbRIcju40K57UMtDScapHblR9GFmMyE0M=; b=Lp2sLgcTmJkpLZ8de6zVCgBlCmrYhGsKLbiHD4YlvX36aMRe1bDnAo+DCJYmHipA4N T5D2+8gavLX/E7u0AnavQnhaeinoaeN8/buankfbKECrRQ61avJgtu+JIOlfHQO56F9k LkfTNAadIY+yZGVbwkNuXX6Z+t7whgy9vyQzpR9f19SNcxFPFuLaEOBLOaaiVgYprxuE 39V0tnNMiO9swrOljKaY3uRbn7uTfI0PU/S+QD7EL1ebK2t7bAbO7b3GQ48i56qsXf4t SbpDhxHGsqU0FDdIOul9xvmEwgOprB0KEjKsg6UgGe8zpEzZEn9JuY2Yz4M0PJIiB8OF uWzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=e97jyQTFbtZbRIcju40K57UMtDScapHblR9GFmMyE0M=; b=fJTU+MsXD60L6358uau9c/S7209dS9wAYsJPLt0D1FvwVaMfUn2Ja8b4i523IPFCib tOkHWKCDfnuVZLEJAKCwxwz79L7t7lmPMplbJVkZbHsChLpfIv45w//IUecfIZKmy6kc 1a/Ar37u5MyHI7w1S+dQsy/CNFNXF1DLWH1w5vxxv6B75sQs8xPB7HjMwPiCiucP8g1f gHvv9rrBEUf++8ttmB8q3rBXzCnXeqmmoZG7wddMCG9dFQ8lm4Oy97siHnTaJKr+7Znr BD3mkvzKw2cuogPSbLm0Yasrf4Wvjv1HV3kvRnFZ3M0Bkb0E5s/7dLse/HIeMrCyah7S j8Mg== X-Gm-Message-State: AIVw110gH7SE+2ZI0OlSNsf9oSFDYxWBZKSKzaQTIcclYSwKExGhkXVn b9FfcHb4LPkTBXq3vL0XHOxw53SuRr1SDBAfGA== X-Received: by 10.31.3.99 with SMTP id 96mr111772vkd.185.1500464070955; Wed, 19 Jul 2017 04:34:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.151.25 with HTTP; Wed, 19 Jul 2017 04:34:10 -0700 (PDT) In-Reply-To: References: From: Seth Blank Date: Wed, 19 Jul 2017 04:34:10 -0700 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a11426cd2f2ac030554aa0366" Archived-At: Subject: Re: [dmarc-ietf] Open issue: mandatory signing of AAR[n] by AMS[n] X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 11:34:49 -0000 --001a11426cd2f2ac030554aa0366 Content-Type: text/plain; charset="UTF-8" There has been an on-list discussion about this, but in it no consensus was reached: https://mailarchive.ietf.org/arch/msg/dmarc/KvpNpf_9ywZpK6oMcwJ1OJthiHM Off list the consensus from those I've spoken with (which is obviously not necessarily representative of the WG) is that we should drop the language suggesting coverage of the AAR by the AMS, as this adds no value when the AAR is required to be signed by the AS. Personally, I think removing this (so only the AS covers the AAR) simplifies the spec and implementations without removing value from the protocol. On Wed, Jul 19, 2017 at 4:28 AM, Kurt Andersen wrote: > The spec currently calls for the n-th instance of AAR to be signed by the > related AMS[n] header as well as the AS[n] header. > > There have been some offlist discussions about whether that is really > necessary, and, generally the conclusion was that it is not really > necessary to the integrity of the mechanism to have the AAR incorporated > into the signed space for both AMS and AS. > > The question to the list (and one which we will also raise in the meeting > on Thursday @ IETF) is whether to change the spec to make the signing of > AAR[n] by AMS[n] optional. > > It won't break any current implementations and apparently will make some > deployments easier (I'll have to let Seth and Gene chime in with details) > so I'm inclined to make the change. > > Opinions? > > --Kurt > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --001a11426cd2f2ac030554aa0366 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There has been an on-list discussion about this, but in it= no consensus was reached:=C2=A0https://mailarchive.ietf.org/arch/= msg/dmarc/KvpNpf_9ywZpK6oMcwJ1OJthiHM

Off list the c= onsensus from those I've spoken with (which is obviously not necessaril= y representative of the WG) is that we should drop the language suggesting = coverage of the AAR by the AMS, as this adds no value when the AAR is requi= red to be signed by the AS.

Personally, I think re= moving this (so only the AS covers the AAR) simplifies the spec and impleme= ntations without removing value from the protocol.

On Wed, Jul 19, 2017 at 4:28 A= M, Kurt Andersen <kurta@drkurt.com> wrote:
The spec currently calls for the n-th inst= ance of AAR to be signed by the related AMS[n] header as well as the AS[n] = header.

There have been some offlist discussions about w= hether that is really necessary, and, generally the conclusion was that it = is not really necessary to the integrity of the mechanism to have the AAR i= ncorporated into the signed space for both AMS and AS.

=
The question to the list (and one which we will also raise in the meet= ing on Thursday @ IETF) is whether to change the spec to make the signing o= f AAR[n] by AMS[n] optional.

It won't break an= y current implementations and apparently will make some deployments easier = (I'll have to let Seth and Gene chime in with details) so I'm incli= ned to make the change.

Opinions?

--Kurt
=

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


--001a11426cd2f2ac030554aa0366-- From nobody Wed Jul 19 05:07:28 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 402561317A9 for ; Wed, 19 Jul 2017 05:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HA8Glo3VqZUn for ; Wed, 19 Jul 2017 05:07:18 -0700 (PDT) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6157131CDA for ; Wed, 19 Jul 2017 05:07:17 -0700 (PDT) Received: by mail-ua0-x22a.google.com with SMTP id 64so47340764uae.2 for ; Wed, 19 Jul 2017 05:07:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aVTXrpUf8Cih3MSpWasVzAaILujle5wgqnsW68hW5CU=; b=tO/ZZvTPVxvpcAZkUXTzja4LNTGeUBLZKncmOLDVEJ2e63oBVm3Ipx65U7aiJukbgD exnkC1EiyLBPm0eiJrK7dqzdtscypewYd0hJ94zml71Qx4hXtIAzW/CaGL/jn89Z0yiB aEnCeHii0w9rmOAaV58dICSoNgNH0+mb/XrZzXEUTaLHC3i8r1VGbgXZlfqD84Yy4lA8 kNMbyC/ajfshWBa5BwphsSWqekhM1N6n1XvQcCikq7uQeiOw8J0hjPc8W+kH6gH4YUvg fJCXpmF1zS5Q+OmdblR07bdqU0lKVr4ze7KIwn9HEklNDckPTFl3Vr2fC7lTcfd6dNjC 6pzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aVTXrpUf8Cih3MSpWasVzAaILujle5wgqnsW68hW5CU=; b=njQcGpfh0Bo74BbEjZ0rJXYWnGu4aynRRZ5oVbaD0uFMtqk7LiXwKY3QfHrkg1Fkx/ qQDN8pCkW36dxLyZ39g/XGteNTlxJQiHpUX7cn2f9AFsGCkjD7a4OEmne7dgH1o9oFnf eAsa/9+/toBjk+VRIYV1NX3nx17dL6o/fo2ajdZEFdjyyEa/TjMqn1dJPXarOctwXpKg i0OQImjp20XfoSs2DEmhq/8X50sk/c5OFxUNFdjFABDpZB+T4AxIQ5qkANXxJuyKJYQR WziWFR10UgN8tCKSxFQd42Rp41z7iDMOS3f5c69gMu5QByf8z1ScmNQCfbvgIcGhizlt rGpg== X-Gm-Message-State: AIVw112i/TVAq178L/bEimIoSVoZRQkyukae2A84HhJr1NHWv9TqWT8d Gy/Va1PdIvDIN3cf/c9MSEt/MHFopg== X-Received: by 10.176.28.3 with SMTP id a3mr1192233uaj.24.1500466036684; Wed, 19 Jul 2017 05:07:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.126.196 with HTTP; Wed, 19 Jul 2017 05:07:16 -0700 (PDT) In-Reply-To: References: From: "Murray S. Kucherawy" Date: Wed, 19 Jul 2017 14:07:16 +0200 Message-ID: To: Seth Blank Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="089e08204f901d3e740554aa79a2" Archived-At: Subject: Re: [dmarc-ietf] Open issue: mandatory signing of AAR[n] by AMS[n] X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 12:07:22 -0000 --089e08204f901d3e740554aa79a2 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 19, 2017 at 1:34 PM, Seth Blank wrote: > There has been an on-list discussion about this, but in it no consensus > was reached: https://mailarchive.ietf.org/arch/msg/dmarc/ > KvpNpf_9ywZpK6oMcwJ1OJthiHM > > Off list the consensus from those I've spoken with (which is obviously not > necessarily representative of the WG) is that we should drop the language > suggesting coverage of the AAR by the AMS, as this adds no value when the > AAR is required to be signed by the AS. > > Personally, I think removing this (so only the AS covers the AAR) > simplifies the spec and implementations without removing value from the > protocol. > I concur. -MSK --089e08204f901d3e740554aa79a2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jul 19, 2017 at 1:34 PM, Seth Blank <seth@sethbl= ank.com> wrote:
There has been = an on-list discussion about this, but in it no consensus was reached:=C2=A0= https://mailarchive.ietf.org/arch/msg/dmarc= /KvpNpf_9ywZpK6oMcwJ1OJthiHM

Off list the conse= nsus from those I've spoken with (which is obviously not necessarily re= presentative of the WG) is that we should drop the language suggesting cove= rage of the AAR by the AMS, as this adds no value when the AAR is required = to be signed by the AS.

Personally, I think removi= ng this (so only the AS covers the AAR) simplifies the spec and implementat= ions without removing value from the protocol.

I concur.

-MSK
--089e08204f901d3e740554aa79a2-- From nobody Wed Jul 19 05:30:17 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF97131B13 for ; Wed, 19 Jul 2017 05:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 sbYVSCpMsKF5 for ; Wed, 19 Jul 2017 05:30:15 -0700 (PDT) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAF5D131CFA for ; Wed, 19 Jul 2017 05:30:08 -0700 (PDT) Received: by mail-ua0-x22a.google.com with SMTP id 35so47506650uax.3 for ; Wed, 19 Jul 2017 05:30:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:from:date:message-id:subject:to; bh=Am56/ajkjZdERmZY0oVlBD4O4G3IMe7JD9ZhjCZT8iI=; b=dWH5lUjgieTJsBL6jQdZqYHMEmbw+bW6gQcwpKP+4WOnse1YhJLgm7Vwb8OU20VMY5 ayKSZxkadq3bnAn1+TT7fNRsV7NMncRoB800HRy53JxCJHgFE9jE8pB8583Aibppdc7p HPg/CscJlEXi39t4xjR0wCFkTHGjRqiK9LYOo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Am56/ajkjZdERmZY0oVlBD4O4G3IMe7JD9ZhjCZT8iI=; b=jIl4TCRhhVOxbVtBlnFUCOK1dC6wDDwDKB5br2czG8vxo9toxfJcpKhI/Fq1yXC0Rj IySCAciBZpSKT4rqls2smw5W1q+gN2DqSdU1Io/a4ye4xxkce1v5IQxFZ3GQEm7fURD1 OIrTYZcgKOPqB6WNoJG2FrM/0ab28XizAq3UedHrS/enzmM+HygN+dyVgDg/s2pHkPLX aReZNTFbb14TAaiElUVCyF6Vaa+reCS0xoAUoAhUmQkJ4/6chrOsCJR/lwJoqimvzsqb RliwqFn+Q4bEwe3LvkUK7ThmskzwLVcXO8zC1Z/ATOv6JQuHuqmSWOiVEabaktYGbDEs pW1g== X-Gm-Message-State: AIVw112vMRgzEvbDdJKWahCLWOVSWMFhh04l3Q5V3Vb1sgt2kXau2qnT YVa+qWQb5jhwBoVPIxW7EtGsnJl0Jt/bi6I= X-Received: by 10.159.36.138 with SMTP id 10mr1277872uar.47.1500467407627; Wed, 19 Jul 2017 05:30:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.26.39 with HTTP; Wed, 19 Jul 2017 05:30:07 -0700 (PDT) From: Kurt Andersen Date: Wed, 19 Jul 2017 14:30:07 +0200 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a113cfbf4d440db0554aacab1" Archived-At: Subject: [dmarc-ietf] Another question for the group: A-R --> AAR, should we convert the authserv-id into a tag-spec? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 12:30:16 -0000 --001a113cfbf4d440db0554aacab1 Content-Type: text/plain; charset="UTF-8" When creating the AAR, would it be worth regularizing the authserv-id into tag-spec format? I know that most of the current implementations are taking the approach of stripping the leading "i=" tag-spec and then feeding the rest of the line to existing A-R parsers. If we changed to have the authserv-id tagged, the stripping would just have to go through the "authserv-id=" string too rather than the ";" that follows the "i=" tag-spec. --Kurt --001a113cfbf4d440db0554aacab1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
When creating the AAR, would it be worth regularizing the = authserv-id into tag-spec format? I know that most of the current implement= ations are taking the approach of stripping the leading "i=3D" ta= g-spec and then feeding the rest of the line to existing A-R parsers. If we= changed to have the authserv-id tagged, the stripping would just have to g= o through the "authserv-id=3D" string too rather than the ";= " that follows the "i=3D" tag-spec.

--Kur= t
--001a113cfbf4d440db0554aacab1-- From nobody Wed Jul 19 11:18:45 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E86BA131B4A for ; Wed, 19 Jul 2017 11:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxUk4JgCTg1o for ; Wed, 19 Jul 2017 11:18:41 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::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 1CAF1131B0A for ; Wed, 19 Jul 2017 11:18:41 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id a62so4893474itd.1 for ; Wed, 19 Jul 2017 11:18:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=d8mowjN+Nk+P4dFJ0x69DRgO0uCpPGV1xnzWnDCL/tY=; b=LqkacMpXbW048q3xteHG/3u3ljPbx+qxncHYs+7YFBT4h3uizrsBGzk//GUU1rXrq2 cJ7qfoGwOggbL7RzE66S419rlucEWR+WNApEp84h6rIejnbP41QEWVAa1wwRk4kpaoYh 2QQNpSeWQ1OZi+159pmHFnEzIouuVTdbW4DUn2Z1nmqs1rSJbeb8lDkAg1SaIDGg32Uy 7lnQOOWfMy87YYqNaBaxEN95wWDawbwGEn5nZ2aER9i37446eEK1PJXJ4IpJ8QqRET31 gSUwufmHygjL1dSfMIV+I8n8MhmKD+JUt79GA4e/DGinCEzv/TlAaO2Jn2xsDpN4MtLs NPKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=d8mowjN+Nk+P4dFJ0x69DRgO0uCpPGV1xnzWnDCL/tY=; b=PcoNLixgtsP31eUM4dh8RmsRIc9/BrTl5336sIfA1ezgMRx19DJVQPbVOw1hT4XJiW Ri1wzThWwfEKuhtd3DWfoReLlaGScNG616dUO4Alv1K5T7/VaJ4Zngc9xCQodDEHqV/D 4Vw7iw58AR/UcTSQlCMdLbcFLL+x3QEnIS6Bf4ollOyOHh6OgB7QX8JL9T3Rk7r74Nt2 O+zLB6oFX2WOmwXY16EymOooGwAy9Me32BAtgnNJGJUy0ORo8eY7ZcVLTT/MxpnB57IF Kf/Eh4aYCRPnclsjEbj6i8Buq3dzKvouFuS18Y8WNYtzPC2uV8ZWR12G4+47mmQ6b0nT F7DQ== X-Gm-Message-State: AIVw1137wYkOzL+CB7KCJUwOLvdgN8C5i79Oiw4VUOZx23DvP+tB3KD2 z0CDwY27ypeBWrbAGpelIlz+1q+Gng== X-Received: by 10.36.6.200 with SMTP id 191mr874649itv.44.1500488320461; Wed, 19 Jul 2017 11:18:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.106.130 with HTTP; Wed, 19 Jul 2017 11:18:39 -0700 (PDT) In-Reply-To: References: From: Gene Shuman Date: Wed, 19 Jul 2017 11:18:39 -0700 Message-ID: To: "Murray S. Kucherawy" Cc: Seth Blank , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a113f790454b0ba0554afa975" Archived-At: Subject: Re: [dmarc-ietf] Open issue: mandatory signing of AAR[n] by AMS[n] X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 18:18:44 -0000 --001a113f790454b0ba0554afa975 Content-Type: text/plain; charset="UTF-8" I also very much believe this language should be removed, as it's unnecessary complexity. On Wed, Jul 19, 2017 at 5:07 AM, Murray S. Kucherawy wrote: > On Wed, Jul 19, 2017 at 1:34 PM, Seth Blank wrote: > >> There has been an on-list discussion about this, but in it no consensus >> was reached: https://mailarchive.ietf.org/arch/msg/dmarc/KvpNpf_ >> 9ywZpK6oMcwJ1OJthiHM >> >> Off list the consensus from those I've spoken with (which is obviously >> not necessarily representative of the WG) is that we should drop the >> language suggesting coverage of the AAR by the AMS, as this adds no value >> when the AAR is required to be signed by the AS. >> >> Personally, I think removing this (so only the AS covers the AAR) >> simplifies the spec and implementations without removing value from the >> protocol. >> > > I concur. > > -MSK > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --001a113f790454b0ba0554afa975 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I also very much believe this language should be removed, = as it's unnecessary complexity.=C2=A0
<= br>
On Wed, Jul 19, 2017 at 5:07 AM, Murray S. Ku= cherawy <superuser@gmail.com> wrote:
On Wed, Jul 19, 2017 at 1:3= 4 PM, Seth Blank <seth@sethblank.com> wrote:
There has been an on-list discussio= n about this, but in it no consensus was reached:=C2=A0https://mailarchive.ietf.org/arch/msg/dmarc/KvpNpf_9ywZpK6= oMcwJ1OJthiHM

Off list the consensus from those I= 9;ve spoken with (which is obviously not necessarily representative of the = WG) is that we should drop the language suggesting coverage of the AAR by t= he AMS, as this adds no value when the AAR is required to be signed by the = AS.

Personally, I think removing this (so only the= AS covers the AAR) simplifies the spec and implementations without removin= g value from the protocol.

I concur.

<= /span>
-MSK

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


--001a113f790454b0ba0554afa975-- From nobody Wed Jul 19 18:28:15 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60CCD1272E1 for ; Wed, 19 Jul 2017 18:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIJd_20cKQK6 for ; Wed, 19 Jul 2017 18:28:13 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1635B126C2F for ; Wed, 19 Jul 2017 18:28:13 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id x187so15402448oig.3 for ; Wed, 19 Jul 2017 18:28:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=ooTKmr1uyAXvAHcvwtvsBzXH1ybV3r7fW2uD3PFRqD0=; b=mxLJjAjppyCmCuqxd7iujx17DNsXNtv0QN9SYRgqDpkRtiLSH9BtGRnCwGChLqXdij Q8bwoe1AhK4AVn43SlpqO5fpuFAIesc81zoDaWnQcbdI6g5TXTB55xvfBt30lgij5dNH CKVOSDlYsiYTalXiRs1UJGdi5xgo6Patq6Hdfzpo6pVf0ow3erlhYRt+yfGvhMLrRNyH QiUlUHF/1NkkkHpveJRRgmO/oepkwygtXu3DVaalCdKeeQEjNMp1/C39vfDviK0AHYW6 fURaHaRH18v3WmXLXcrcP+8pl/6HJGKEpJ3yQRo6kv8izPspSPzH1OO3A7zyYqCDi08e O9gA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ooTKmr1uyAXvAHcvwtvsBzXH1ybV3r7fW2uD3PFRqD0=; b=dBsE6m6WqjvvOEX/1L7/F1UNlWu0dmflvp13bOSSKtlp2sjDh50ZSiSE3U7qtdSWRc GLP2SeuCa3PJ9MScRF/hj2YI0dPDw2tuayTG9O6wQDToE6yMC0nnq0TTG+3PmVQMFdfV tRV7b3TaJvwlyXPVBdnJsoRTCZAvvakFcAfta8ZW7UZSLccouW5cAPjkIIj7AM9Oh+e1 fDxqiDDSIo0bHT3Y4KQHn4GowyuzYTJuNcHlzpICTxQZAzVApfmWFWLivwYnOIQfE91g hMrvtdUvurvrYkbXc8ltMhpWOdql+xDX3LxoNzFK/pANvGy2zmrSRz7Zrp6/Fl75lS0S Vqbw== X-Gm-Message-State: AIVw112V+L3yBMaUjk9ZP7GYQAa77gdfkGVT/Zs4pz97oyFO9YEysd07 KpvpvKDOk6dVBm/meYm9Al7D3mpSU6XPobA= X-Received: by 10.202.69.197 with SMTP id s188mr3500604oia.148.1500514091676; Wed, 19 Jul 2017 18:28:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.131.17 with HTTP; Wed, 19 Jul 2017 18:28:10 -0700 (PDT) Received: by 10.74.131.17 with HTTP; Wed, 19 Jul 2017 18:28:10 -0700 (PDT) From: Brandon Long Date: Wed, 19 Jul 2017 18:28:10 -0700 Message-ID: To: dmarc@ietf.org Content-Type: multipart/alternative; boundary="001a113dd3be6ae2f30554b5a95b" Archived-At: Subject: [dmarc-ietf] News piece on using arc... X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 01:28:14 -0000 --001a113dd3be6ae2f30554b5a95b Content-Type: text/plain; charset="UTF-8" https://www.propublica.org/nerds/item/authenticating-email-using-dkim-and-arc-how-we-analyzed-the-kasowitz-email --001a113dd3be6ae2f30554b5a95b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --001a113dd3be6ae2f30554b5a95b-- From nobody Wed Jul 19 21:58:33 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10318126DEE for ; Wed, 19 Jul 2017 21:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55Wp3Ap3tMQh for ; Wed, 19 Jul 2017 21:58:29 -0700 (PDT) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5554012EC51 for ; Wed, 19 Jul 2017 21:58:29 -0700 (PDT) Received: by mail-ua0-x22a.google.com with SMTP id 80so14782620uas.0 for ; Wed, 19 Jul 2017 21:58:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=J+GE9qxZobdc4F+kbrLu1a11mRkiq9pLNFjI2ipL0m0=; b=IMHxZ84A/SJHZVSAF0zW18dkXJIEDiNAXvFutY3LN+ggLj7TzRre/zS01jChZ1QkLB hod9GPD3Xjwqp4X5Teq4lekxQrQwfUOBoB1y/YL9NNyIWCkt68U+WVbQXKYC4TYI4Lm9 11pnGcIj50HiBAimGqGu8Yj9oOGtyTSvIl7O8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=J+GE9qxZobdc4F+kbrLu1a11mRkiq9pLNFjI2ipL0m0=; b=L1oqIzZsPqOCXlkm5RISSqkyVsQ0FCgDK2HKAbhMJaYwB6GpNbfrmxdfvM7ZBo/Yie IEztA0wKVqZo7wRP4mc1paXOzuFpcMRwAOlMdtxjfYpMQQqw0WRV02zJ9yzV4hMAdCGo LmS68++Yl+2zyw8zNmETCBins6qudNmLrLy61g8aEgNdQCNibySZcTiaWJIGqrz6IEh3 L/wjskDsKylVcmSXvHaqJySN6yZw0PerPnZGRWVm7uyKy3lnvbwSThEp2ica2wMmxy4Y ko4FTyP4EPRjHsO/Le007HLYVvQTwcLe+3h3bC5j0hossFBPY8y4csWQG3IVOnsqCVhQ SzTQ== X-Gm-Message-State: AIVw113osr944mVyzeX9T/cSzxFWTvC6o4XAef3EDgR9XDnvRYKZA0BY TC0CemSF0sVH4eiRb1lluBtuW2CF0A9nyEE= X-Received: by 10.176.93.41 with SMTP id u41mr1314210uaf.75.1500526708319; Wed, 19 Jul 2017 21:58:28 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.176.26.39 with HTTP; Wed, 19 Jul 2017 21:58:27 -0700 (PDT) In-Reply-To: References: From: "Kurt Andersen (b)" Date: Thu, 20 Jul 2017 06:58:27 +0200 X-Google-Sender-Auth: qFQbmyVXiC8B8d2DN2xHrNh5Pw8 Message-ID: To: Gene Shuman Cc: "Murray S. Kucherawy" , "dmarc@ietf.org" , Seth Blank Content-Type: multipart/alternative; boundary="f40304365cc06cfaac0554b899ee" Archived-At: Subject: Re: [dmarc-ietf] Open issue: mandatory signing of AAR[n] by AMS[n] X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 04:58:32 -0000 --f40304365cc06cfaac0554b899ee Content-Type: text/plain; charset="UTF-8" Ack - consider it done and I'll report as such in this morning's session. Thanks for weighing in. --Kurt On Wed, Jul 19, 2017 at 8:18 PM, Gene Shuman wrote: > I also very much believe this language should be removed, as it's > unnecessary complexity. > > On Wed, Jul 19, 2017 at 5:07 AM, Murray S. Kucherawy > wrote: > >> On Wed, Jul 19, 2017 at 1:34 PM, Seth Blank wrote: >> >>> There has been an on-list discussion about this, but in it no consensus >>> was reached: https://mailarchive.ietf.org/arch/msg/dmarc/KvpNpf_ >>> 9ywZpK6oMcwJ1OJthiHM >>> >>> Off list the consensus from those I've spoken with (which is obviously >>> not necessarily representative of the WG) is that we should drop the >>> language suggesting coverage of the AAR by the AMS, as this adds no value >>> when the AAR is required to be signed by the AS. >>> >>> Personally, I think removing this (so only the AS covers the AAR) >>> simplifies the spec and implementations without removing value from the >>> protocol. >>> >> >> I concur. >> >> -MSK >> >> _______________________________________________ >> 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 > > --f40304365cc06cfaac0554b899ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ack - consider it done and I= 9;ll report as such in this morning's session. Thanks for weighing in.<= /div>

--Kurt=

On Wed, Jul 19, 2017 at 8:18 PM, Gene Sh= uman <geneshuman@gmail.com> wrote:
I also very much believe this language shoul= d be removed, as it's unnecessary complexity.=C2=A0

On Wed, Jul 19, 2017 at 5:07 AM, Murray S. Kucherawy <= span dir=3D"ltr"><superuser@gmail.com> wrote:
On Wed, Jul 19, 2017 at 1:34 PM, Seth Blank <seth@sethbla= nk.com> wrote:
The= re has been an on-list discussion about this, but in it no consensus was re= ached:=C2=A0https://mailarchive.ietf.org/ar= ch/msg/dmarc/KvpNpf_9ywZpK6oMcwJ1OJthiHM

Off li= st the consensus from those I've spoken with (which is obviously not ne= cessarily representative of the WG) is that we should drop the language sug= gesting coverage of the AAR by the AMS, as this adds no value when the AAR = is required to be signed by the AS.

Personally, I = think removing this (so only the AS covers the AAR) simplifies the spec and= implementations without removing value from the protocol.

I concur.

-MSK
<= /div>

_____________________________________= __________
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


--f40304365cc06cfaac0554b899ee-- From nobody Wed Jul 19 22:00:47 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13FD312EC51 for ; Wed, 19 Jul 2017 22:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eqkwR7PLbjNW for ; Wed, 19 Jul 2017 22:00:43 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1194126DEE for ; Wed, 19 Jul 2017 22:00:42 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id p185so4625069iof.2 for ; Wed, 19 Jul 2017 22:00:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fT21YRaGTiq/t1Xdv5r+bxbNDEgL5mQGPhUxOXo9lnA=; b=MUiz6rR4l7oGAQJB9szQekBEQVisQXTiLWF09nAwg9efKy/b33c98RDlIFhV10wUd/ mj6VYyTz14BBAqzDYZ7FtY0zg6oPMJWU3W5sXYPHZXmioSGgXFdNMssbi7II2/ALGB26 ThbLHR/rUtv03erXaxosk97Nkts7kFGqXrrOI/bY+eKbHCnVqiZHlRbspD0j5VTQfF4x loCrmm6h0jD5vXN8ePS8o8bGwTIyY/oCJ+wOjgo4cwiXuPP+97FGy0bFRWOUQGTDs/yE qufd6qDylWCKTdd8xJXkHUc/WuvMO8OaXsx2EtJ8yKfv9e9AWkEH2b0jTnmQ+2VIiELu VLVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fT21YRaGTiq/t1Xdv5r+bxbNDEgL5mQGPhUxOXo9lnA=; b=ZpbVlL+IYmCEolblpW/ZZuv4R74CTdyJeWihUCL99dWklfWc4PHhGcFCABU0snj1k3 U7yvKj6jy4FjrCUyIX+dS6mAvx3X/dy+5p0Ovwe2ZiqSmArvFa8JBQL4C10y4IvZItoY v2O46aZZkc2Z9JRzdN+aliBcTqkvsovBAvEOTb6O2ntC+6pZyuBkiznfE30sT22jGHtT gvA0rJ4nIZD/8c5Cjk+FVs0Pwtb26qJyvLELvjLWno2X/k8lMPMuhtPPD+8g+2FL01Z+ dHLGDnTochzMlgu7o0HZe+CuAksWkEPDsgvDNVRPQyURoL7c3qlyuWNad+zzCn293+9H XSnw== X-Gm-Message-State: AIVw113l4DSWAuCfZbySLxCq5Uv9kdC7yrAj+VLseBjlPSWgGOhrFpFR R3XDJNmtYEsneI9p4LBDfGcrJfOSQg== X-Received: by 10.107.184.6 with SMTP id i6mr2312452iof.288.1500526842247; Wed, 19 Jul 2017 22:00:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.106.130 with HTTP; Wed, 19 Jul 2017 22:00:41 -0700 (PDT) In-Reply-To: References: From: Gene Shuman Date: Wed, 19 Jul 2017 22:00:41 -0700 Message-ID: To: "Kurt Andersen (b)" Cc: "Murray S. Kucherawy" , "dmarc@ietf.org" , Seth Blank Content-Type: multipart/alternative; boundary="94eb2c0769fa6887be0554b8a1bc" Archived-At: Subject: Re: [dmarc-ietf] Open issue: mandatory signing of AAR[n] by AMS[n] X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 05:00:45 -0000 --94eb2c0769fa6887be0554b8a1bc Content-Type: text/plain; charset="UTF-8" Great. AFAIK, this was the last remaining technical issue in the spec. I'm very happy to see things reach this point. On Wed, Jul 19, 2017 at 9:58 PM, Kurt Andersen (b) wrote: > Ack - consider it done and I'll report as such in this morning's session. > Thanks for weighing in. > > --Kurt > > > On Wed, Jul 19, 2017 at 8:18 PM, Gene Shuman wrote: > >> I also very much believe this language should be removed, as it's >> unnecessary complexity. >> >> On Wed, Jul 19, 2017 at 5:07 AM, Murray S. Kucherawy > > wrote: >> >>> On Wed, Jul 19, 2017 at 1:34 PM, Seth Blank wrote: >>> >>>> There has been an on-list discussion about this, but in it no consensus >>>> was reached: https://mailarchive.ietf.org/arch/msg/dmarc/KvpNpf_ >>>> 9ywZpK6oMcwJ1OJthiHM >>>> >>>> Off list the consensus from those I've spoken with (which is obviously >>>> not necessarily representative of the WG) is that we should drop the >>>> language suggesting coverage of the AAR by the AMS, as this adds no value >>>> when the AAR is required to be signed by the AS. >>>> >>>> Personally, I think removing this (so only the AS covers the AAR) >>>> simplifies the spec and implementations without removing value from the >>>> protocol. >>>> >>> >>> I concur. >>> >>> -MSK >>> >>> _______________________________________________ >>> 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 >> >> > --94eb2c0769fa6887be0554b8a1bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Great.=C2=A0 AFAIK, this was the last remaining technical = issue in the spec.=C2=A0 I'm very happy to see things reach this point.= =C2=A0

On W= ed, Jul 19, 2017 at 9:58 PM, Kurt Andersen (b) <kboth@drkurt.com> wrote:
Ack - consider it done and I'll report as such in this= morning's session. Thanks for weighing in.

= --Kurt


On Wed, Jul 19, 2017 at 8:18 PM, Gene Shuman <geneshuman@gmail.com> wrote:
I a= lso very much believe this language should be removed, as it's unnecess= ary complexity.=C2=A0

On Wed, Jul 19, 2017 at 1:34 PM, Set= h Blank <seth@sethblank.com> wrote:
There has been an on-list discussion about this, but= in it no consensus was reached:=C2=A0https://ma= ilarchive.ietf.org/arch/msg/dmarc/KvpNpf_9ywZpK6oMcwJ1OJthiHM=

Off list the consensus from those I've spoken with = (which is obviously not necessarily representative of the WG) is that we sh= ould drop the language suggesting coverage of the AAR by the AMS, as this a= dds no value when the AAR is required to be signed by the AS.
Personally, I think removing this (so only the AS covers the AA= R) simplifies the spec and implementations without removing value from the = protocol.

I concur.

-MSK

_______________________________________________<= br> 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



--94eb2c0769fa6887be0554b8a1bc-- From nobody Wed Jul 19 22:17:25 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3275213180C for ; Wed, 19 Jul 2017 22:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o42leZrI8hNv for ; Wed, 19 Jul 2017 22:17:22 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52239131748 for ; Wed, 19 Jul 2017 22:17:22 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id 191so18206571oii.2 for ; Wed, 19 Jul 2017 22:17:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=N/guTgWLkUWXINgtw/UD/Vf7xLJpdwnbU8RrodGM+HE=; b=kkcTK7D9bFHKoo3BstZVe2tqNitz9l/JXqmjARtAqsq78Sd34HSixKeHmRU5gz4nD+ ROfGSmAiHV2xnzi46nVVg4DlG1OqbOcjFe/X8ucqEkJFhzmnG/Urplqjy6iRB7nnV0PU MDrsiV20zCF/NrG5TuCPMT+ojtusfBzd75dLVfdn7RKu8q1l8lyrHEbfn+2vQ8FdgudU DAN3iVZElurY2pZiKTbESrEEZZ1Lyh90y2RA02EbzHPIl8psewCMvnbbSCKb+ONpdTjb ltvQIEiK6ptZzJIWl93DiL8LGEbSGCeM0fyeVUIqacO2vUXhFgKlqM6PR4Rlz1Tx2UZj dfUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=N/guTgWLkUWXINgtw/UD/Vf7xLJpdwnbU8RrodGM+HE=; b=ioXFS3j3A6VThdOVa1QgAAeQceGeE7+vrVWOskNYtRkbE33xYTyyJO/ivSMpQe13Ic 8AvbiPXVS1cHfZihSUGYv0TUiXr52pAjDKdM/br6HjS1Su/l3fTmKbmhYZNLZmORPGKE fw8bIDUp+k5LkXwlTe2MDVjaWBdGP5Q/rrL/O6eD5CdG36SnUuYGmy56DsNaKMRnpGX+ qkCY/IWyKjLOPJ/7c9UA/ViNCvBLUQ/rRQJhEe8e1ZtHtxxRiuyARmFFuqT7tcAVpQV9 QNZ8CFnL4puV62M+Ws5aci9R+k2syYH8202HhTkWfqb2ORlZeGeM/eqd7h9Qi5AWPDdJ CZkQ== X-Gm-Message-State: AIVw111fDL/KNUsJ1CsEdx/a8Ivp2FOlcLrETY+T5JBDw9qpvuOhmTN4 tY2R6AFb6PnEzFrXvK1cNus0aNJuOECOmRY= X-Received: by 10.202.199.74 with SMTP id x71mr4258241oif.94.1500527841219; Wed, 19 Jul 2017 22:17:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.131.17 with HTTP; Wed, 19 Jul 2017 22:17:18 -0700 (PDT) Received: by 10.74.131.17 with HTTP; Wed, 19 Jul 2017 22:17:18 -0700 (PDT) In-Reply-To: References: From: Brandon Long Date: Wed, 19 Jul 2017 22:17:18 -0700 Message-ID: To: Kurt Andersen Cc: dmarc@ietf.org Content-Type: multipart/alternative; boundary="001a1140bae0f442770554b8dc58" Archived-At: Subject: Re: [dmarc-ietf] Another question for the group: A-R --> AAR, should we convert the authserv-id into a tag-spec? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 05:17:24 -0000 --001a1140bae0f442770554b8dc58 Content-Type: text/plain; charset="UTF-8" That would also raise the question of where the semicolon would be. Arc-Authentication-Result: i=1 authserv-id=mx.google.com; Or Arc-Authentication-Result: i=1; authserv-id=mx.google.com; Anyways, how does this help things? You can't use a simple parser anyways because of the multiple tag-specs per semicolon delimited list and the overly permissive cfws in the authres spec. Brandon On Jul 19, 2017 5:30 AM, "Kurt Andersen" wrote: When creating the AAR, would it be worth regularizing the authserv-id into tag-spec format? I know that most of the current implementations are taking the approach of stripping the leading "i=" tag-spec and then feeding the rest of the line to existing A-R parsers. If we changed to have the authserv-id tagged, the stripping would just have to go through the "authserv-id=" string too rather than the ";" that follows the "i=" tag-spec. --Kurt _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc --001a1140bae0f442770554b8dc58 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That would also raise the question of where the semi= colon would be.

Arc-Authentica= tion-Result: i=3D1 authserv-id=3Dmx.google= .com;=C2=A0

Or=C2=A0=

Ar= c-Authentication-Result: i=3D1; authserv-id=3Dmx.google.com;=C2=A0

Anyw= ays, how does this help things?=C2=A0 You can't use a simple parser any= ways because of the multiple tag-specs per semicolon delimited list and the= overly permissive cfws in the authres spec.
=
Brandon

<= div class=3D"gmail_quote">On Jul 19, 2017 5:30 AM, "Kurt Andersen"= ; <kurta@drkurt.com> wrote:
When creat= ing the AAR, would it be worth regularizing the authserv-id into tag-spec f= ormat? I know that most of the current implementations are taking the appro= ach of stripping the leading "i=3D" tag-spec and then feeding the= rest of the line to existing A-R parsers. If we changed to have the authse= rv-id tagged, the stripping would just have to go through the "authser= v-id=3D" string too rather than the ";" that follows the &qu= ot;i=3D" tag-spec.

--Kurt

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


--001a1140bae0f442770554b8dc58-- From nobody Wed Jul 19 22:29:58 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 159AC12783A for ; Wed, 19 Jul 2017 22:29:57 -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 csMOapmC5rAI for ; Wed, 19 Jul 2017 22:29:55 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04C9B126B6E for ; Wed, 19 Jul 2017 22:29:55 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id g13so7803202ioj.5 for ; Wed, 19 Jul 2017 22:29:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WjGKzMDJ5KGillnX1lO04QOSZ2Kq9SvG3qC0CUTaGCA=; b=dJKNpBkXlHS+1ZknkRm9bJcp/oq+4//bSd3PHMAp9Fk4ACOuBYcwxuIxY8/Aj5Z3vV W7EgfRUSOu36AD3w0eUJorznbUiv9NNB0IgqNN8KiJY445Znz0cKHRixEo5X3qLJMvuS kSKE0qS6/niE6Xtd+IPDC941kq90PPxpQf5FrrVCPZGhSnp8ipP3SwcDghibpOmE1DW5 Ps/qMkqHfImcm78zL3HsDBjqXjUr+IecZqRkzkXZAvG/YqQjKOdUvUzQS748XQWf12p5 ZqHlo5W8+kXLW43ejoODG8tlqhzHTuLTPo2ivTM56RImfHt4NcAu97tfg6sFtRdJIZcn Ibvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WjGKzMDJ5KGillnX1lO04QOSZ2Kq9SvG3qC0CUTaGCA=; b=ApmqepFIiMP35W6X3i5smFS+I1Rn7cfI4F6wgWLBJBk79ETmbUeAfYZH1O1ITUMtqm 8cXaURga+iFNKDn4hi5o3V9CuL95e2a7neUHChih0rjkWLNmWfjgitbexmJt4hvZnu+D T70fzxjKpfjr0t9fs3u1c2sDzPO+ZIFIBgUZJyMPw7h3IIFi5BqhIxC0K7yu+Ubgk+x7 akPGjqtt6Qox3cU/xXWvVm28UMlIbHTiOOPluRB/w3i4OcDlgWFs8SkWBDvzYCE7SwRv nopKU7PoqrMAzjwD5f6XJ92ur87LSsHVSh+uHJ6ldiemyMGjBcQsxc9dgvzzUIrmxcEB b1Rg== X-Gm-Message-State: AIVw110L5cFfqRAcohe7ZQ8+Hr8cKFKyRoTkX3SjTVUcq7TBprqyw8ko E3AM9uOPpMtbllgJEcft/6vF42p6DA== X-Received: by 10.107.192.135 with SMTP id q129mr2320520iof.63.1500528594364; Wed, 19 Jul 2017 22:29:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.106.130 with HTTP; Wed, 19 Jul 2017 22:29:53 -0700 (PDT) In-Reply-To: References: From: Gene Shuman Date: Wed, 19 Jul 2017 22:29:53 -0700 Message-ID: To: "Kurt Andersen (b)" Cc: "Murray S. Kucherawy" , "dmarc@ietf.org" , Seth Blank Content-Type: multipart/alternative; boundary="001a114f1d2ed7aed10554b90945" Archived-At: Subject: Re: [dmarc-ietf] Open issue: mandatory signing of AAR[n] by AMS[n] X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 05:29:57 -0000 --001a114f1d2ed7aed10554b90945 Content-Type: text/plain; charset="UTF-8" Accept, after checking my email further, these new ideas about the AAR. But I expect/hope this is something we can resolve quickly. On Wed, Jul 19, 2017 at 10:00 PM, Gene Shuman wrote: > Great. AFAIK, this was the last remaining technical issue in the spec. > I'm very happy to see things reach this point. > > On Wed, Jul 19, 2017 at 9:58 PM, Kurt Andersen (b) > wrote: > >> Ack - consider it done and I'll report as such in this morning's session. >> Thanks for weighing in. >> >> --Kurt >> >> >> On Wed, Jul 19, 2017 at 8:18 PM, Gene Shuman >> wrote: >> >>> I also very much believe this language should be removed, as it's >>> unnecessary complexity. >>> >>> On Wed, Jul 19, 2017 at 5:07 AM, Murray S. Kucherawy < >>> superuser@gmail.com> wrote: >>> >>>> On Wed, Jul 19, 2017 at 1:34 PM, Seth Blank wrote: >>>> >>>>> There has been an on-list discussion about this, but in it no >>>>> consensus was reached: https://mailarchive.i >>>>> etf.org/arch/msg/dmarc/KvpNpf_9ywZpK6oMcwJ1OJthiHM >>>>> >>>>> Off list the consensus from those I've spoken with (which is obviously >>>>> not necessarily representative of the WG) is that we should drop the >>>>> language suggesting coverage of the AAR by the AMS, as this adds no value >>>>> when the AAR is required to be signed by the AS. >>>>> >>>>> Personally, I think removing this (so only the AS covers the AAR) >>>>> simplifies the spec and implementations without removing value from the >>>>> protocol. >>>>> >>>> >>>> I concur. >>>> >>>> -MSK >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >> > --001a114f1d2ed7aed10554b90945 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Accept, after checking my email further, these new ideas a= bout the AAR.=C2=A0 But I expect/hope this is something we can resolve quic= kly. =C2=A0

= On Wed, Jul 19, 2017 at 10:00 PM, Gene Shuman <geneshuman@gmail.com= > wrote:
Great= .=C2=A0 AFAIK, this was the last remaining technical issue in the spec.=C2= =A0 I'm very happy to see things reach this point. =C2=A0

On Wed, Jul 19, 2017 at 9:58 PM, Kurt Andersen (b) <kboth@= drkurt.com> wrote:
Ack - consider it done and I'll rep= ort as such in this morning's session. Thanks for weighing in.

--Kurt


On Wed, Jul 19, 2017 at 8:18 PM, Gene Shuman <geneshuman@g= mail.com> wrote:
I also very much believe this language should be removed, as it= 9;s unnecessary complexity.=C2=A0

On Wed, Jul 19, 201= 7 at 5:07 AM, Murray S. Kucherawy <superuser@gmail.com> wr= ote:
On Wed, Jul 19, 2017 at 1:34 PM, Seth Blan= k <seth@sethblank.com> wrote:
There has been an on-list discussion about this, but in it no= consensus was reached:=C2=A0https://mailarchive= .ietf.org/arch/msg/dmarc/KvpNpf_9ywZpK6oMcwJ1OJthiHM

=
Off list the consensus from those I've spoken with (which is= obviously not necessarily representative of the WG) is that we should drop= the language suggesting coverage of the AAR by the AMS, as this adds no va= lue when the AAR is required to be signed by the AS.

Personally, I think removing this (so only the AS covers the AAR) simpli= fies the spec and implementations without removing value from the protocol.=

I concur.=

-MSK

_______________________________________________<= br> 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




--001a114f1d2ed7aed10554b90945-- From nobody Thu Jul 20 00:16:05 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E45D2127735 for ; Thu, 20 Jul 2017 00:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.718 X-Spam-Level: X-Spam-Status: No, score=-2.718 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=QMHXtaWo; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=YYSPobmS 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 L3xCnEWVhvq2 for ; Thu, 20 Jul 2017 00:16:03 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 363AD131CF4 for ; Thu, 20 Jul 2017 00:15:53 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id A56A1206E9; Thu, 20 Jul 2017 03:15:52 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Thu, 20 Jul 2017 03:15:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=J22kf/yN2qxrGJpqvK cdEUkTL8fSbjG8XfuZVX9icdc=; b=QMHXtaWotALdANOBg2XwxYtWFHzbE0MI+T G32/uXGHiw32bWgRF9kohRTt868TEsb9wGLVFrYED4tUceDjO9v/DxJGBzFBK/3D b24Oipn2S3yejAST0dE4/ZZe84a4o5XiZJQFOxW1dnHliMrvdkt92ezNN/2+h+WB mMdvCNy5jeOsstKtl6/o2qI+wS79061Xmw+vF+/LlaWu9Kp8SHkwZx7r6ZvmREcp eQ7hyIfGyiT5ku0n8FrRclYan8fwfEoL5j0hVC7LKuvkW0WQw6ieAMRh1TXtvQTa 5gDLHdLgNsgJ+IqFaRkEZg5Y5IR2g6iZefjSVtcXqHwzCeY4Jybg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=J22kf/yN2qxrGJpqvKcdEUkTL8fSbjG8XfuZVX9icdc=; b=YYSPobmS nd+E7dwVdpaf5PeUlVdyW27v/al76jHMia6Cb4kRASjVZunLZv3guM707y0Qqpi8 uBLB6qU9BFRz/i6IHywR1+FNDibemNgJaVHT2ytFEIN5h9H0kAqt9Nn0kENn7UFn XZd+O8xiz2SbawAcgFxTBUddRI1P5tuW1Ndg5kPOJ4Xvv5JUIvOpRkbMfqNH+9Hu IyGJnkg9lLuxLQWZT6kuKLOS00QrWCi44uwhqjydM05JYbUoIdSVPW9FxItRW4sO Q/JYO/YBA2sBYcORo+dPoMj/ylRUsjEYtB5JcuAUX2Aii9NM4ECwaxAN89co9tgm EKeCCZK9rz/qBw== X-ME-Sender: X-Sasl-enc: gfKFOJMxLkVScn5suxGfyAfUPabehmaUX/SMoKRvDnEV 1500534952 Received: from [31.133.156.90] (dhcp-9c5a.meeting.ietf.org [31.133.156.90]) by mail.messagingengine.com (Postfix) with ESMTPA id 0E32224250; Thu, 20 Jul 2017 03:15:51 -0400 (EDT) Content-Type: multipart/alternative; boundary=Apple-Mail-0928026A-9D90-4C0B-9EF3-C0B8EFFCB8F7 Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPad Mail (14F89) In-Reply-To: Date: Thu, 20 Jul 2017 09:16:23 +0200 Cc: Kurt Andersen , dmarc@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <20C45C15-B271-4B6E-80CD-868D21AAB0A8@fastmail.fm> References: To: Brandon Long Archived-At: Subject: Re: [dmarc-ietf] Another question for the group: A-R --> AAR, should we convert the authserv-id into a tag-spec? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 07:16:05 -0000 --Apple-Mail-0928026A-9D90-4C0B-9EF3-C0B8EFFCB8F7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On 20 Jul 2017, at 07:17, Brandon Long wrote: >=20 > That would also raise the question of where the semicolon would be. >=20 > Arc-Authentication-Result: i=3D1 authserv-id=3Dmx.google.com;=20 >=20 > Or=20 >=20 > Arc-Authentication-Result: i=3D1; authserv-id=3Dmx.google.com;=20 I think the idea was to use the latter. >=20 > Anyways, how does this help things? You can't use a simple parser anyways= because of the multiple tag-specs per semicolon delimited list and the over= ly permissive cfws in the authres spec. Good point. It would be better to leave AAR as is then. >=20 > Brandon >=20 > On Jul 19, 2017 5:30 AM, "Kurt Andersen" wrote: > When creating the AAR, would it be worth regularizing the authserv-id into= tag-spec format? I know that most of the current implementations are taking= the approach of stripping the leading "i=3D" tag-spec and then feeding the r= est of the line to existing A-R parsers. If we changed to have the authserv-= id tagged, the stripping would just have to go through the "authserv-id=3D" s= tring too rather than the ";" that follows the "i=3D" tag-spec. >=20 > --Kurt >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >=20 >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc --Apple-Mail-0928026A-9D90-4C0B-9EF3-C0B8EFFCB8F7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On 20 Jul 20= 17, at 07:17, Brandon Long <blong@goo= gle.com> wrote:

That would also raise the question of where the semicolon would b= e.

Arc-Authentication-Result: i= =3D1 authserv-id=3Dmx.google.com; =

Or 

Arc-Authentication-R= esult: i=3D1; authserv-id=3Dmx.google.com; 

I think the id= ea was to use the latter.

Anyways, how does this help things?  You= can't use a simple parser anyways because of the multiple tag-specs per sem= icolon delimited list and the overly permissive cfws in the authres spec.

Good point. It would be be= tter to leave AAR as is then.

Brandon

On Jul 19, 2017 5:30 AM, "Kurt= Andersen" <kurta@drkurt.com> w= rote:
When c= reating the AAR, would it be worth regularizing the authserv-id into tag-spe= c format? I know that most of the current implementations are taking the app= roach of stripping the leading "i=3D" tag-spec and then feeding the rest of t= he line to existing A-R parsers. If we changed to have the authserv-id tagge= d, the stripping would just have to go through the "authserv-id=3D" string t= oo rather than the ";" that follows the "i=3D" tag-spec.

--Kurt

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


____________________= ___________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mai= lman/listinfo/dmarc
= --Apple-Mail-0928026A-9D90-4C0B-9EF3-C0B8EFFCB8F7-- From nobody Thu Jul 20 02:56:08 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA2E131C03 for ; Thu, 20 Jul 2017 02:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxpEvf9hjxzh for ; Thu, 20 Jul 2017 02:55:57 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51095131C05 for ; Thu, 20 Jul 2017 02:55:57 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id v205so3759028itf.1 for ; Thu, 20 Jul 2017 02:55:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=NQNHNVfuQzCeQHryGwlKoHU0KIKCGObRbSBWeAfk+zE=; b=iBy5g9NoQmRM5DgrW+w3nP7NJAslKJDHixHVWSUrpdJ8EbKgItveZ3QDfKyWzZliJo Xd0gPBCO704bR5kwnosXyNVxYxAeiW4tAsOwJz/DCGMIkZrx8pJqsCkFHM5J31Ix0tIX ulemZJBSAqI9M0NzR/1KrKe0BaoXLe8kbVSdlijWoY7va/hRyRVF1FXiEbxcldoQqR0r d2jiO+oYZxEPcCFdCthz7oGfMmQLmrGTMcFUpMK9L7jWMDE8np2rDBBIO4IPKOEJ2QX8 IH0wAJa3McwW3/hqNBjycckeVFL5lz4mvd8RWwCny2IdMtpfJqYXUKJIqkx8QvI9d4AO UX1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=NQNHNVfuQzCeQHryGwlKoHU0KIKCGObRbSBWeAfk+zE=; b=RXaAwOyqlj3mv0AgzC2ZgdPLwX50QJaEOkM1NdaTiLHUk6FR4bCT+RXOlLPbSxuENS U5QW5hY6wYyydKKraLQrfjqtF0b9nLEF68Q8szJjqh6yTsEKrt/yCs08dnRlxUQ9qcjA 8KGY8oDCxrUOWwNd8/c94NvIjiURmuXpe025PkzjfDgPgalIW5Q0aOp2s5WK1YVeIN80 CfLMMqdryJh59RzwDadtb+P+fzm7dSrfbW3rlt+YIjKUsAZykhjch+YhZopq924onO5W 7yhq/w7sO9bknJQsqYK81wwpddybTWZ68cG3pQo5yCRWGX+lIQIvM8giZcjx8VgBlSc8 I+rQ== X-Gm-Message-State: AIVw1105/86s+QxJDtdItLdmFegzWbPlNOf0VR03jicdOYAlsacVxz9z bgaX2OxOGewljMjt20zm0CeZm5sSq1YE X-Received: by 10.36.252.69 with SMTP id b66mr2548886ith.171.1500544556165; Thu, 20 Jul 2017 02:55:56 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 10.107.152.80 with HTTP; Thu, 20 Jul 2017 02:55:55 -0700 (PDT) From: Barry Leiba Date: Thu, 20 Jul 2017 11:55:55 +0200 X-Google-Sender-Auth: 0Jh8oL_qNPDFckSuhGyJHq3y-B8 Message-ID: To: "dmarc@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [dmarc-ietf] Draft minutes from DMARC session at IETF 99 (Prague) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 09:56:06 -0000 The minutes are uploaded to the meeting materials manager, here: https://www.ietf.org/proceedings/99/minutes/minutes-99-dmarc-02.txt Please review and post any corrections. Barry, as chair From nobody Thu Jul 20 03:06:51 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A64131A4C for ; Thu, 20 Jul 2017 03:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGLWXDTp6sf7 for ; Thu, 20 Jul 2017 03:06:47 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::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 04F7F127735 for ; Thu, 20 Jul 2017 03:06:47 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id f9so19281777uaf.4 for ; Thu, 20 Jul 2017 03:06:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ib7+1A4Untp6l0cvTYusf9cFUeG5zPxUdpN5fQwkb0k=; b=1v/jjbRTSJGTvo5CzZLJ9VJ6av4Uq1QRMAHit1+WVJApBPoJak1bhEIZp5GJnMipXz p6kDUXvk50NYtR9okbbTL1vgIGamF6eYvfcs/DSr2fnrCFspCnBXV4kRJ/aTp9kpyE1M PcE77Bgopr1hgdTh6T5uMRLmj4AhMr8SdC+DeceiUQlFVn1m/iWrwdJRUvwHmtcoBXME Ja1/0pM9KVsHMZlmNRsLsio1HGOTkfJtNjylNnL0BoFmeiCbvqs3PldGPmM5yXdbeFbt cThIDXl/I90XgU2VuKBtwQyeszZyT7KFiImTNAhqrj+xl25l+5lT/eCQbPdQX0QAUBuy Ccmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ib7+1A4Untp6l0cvTYusf9cFUeG5zPxUdpN5fQwkb0k=; b=cMbm/H6YW9UqAh07Prn+vQxgbFHwp8aYxdYubzLH3VH42p7xeXG9H9EB+L6eauUvnW 6FMPBnTyxdybkNNM+ebsCU47Suqt8JRpdvnIKpisM90wM9jdbqMHok4pIPDsmaXg0kqD 4jzy2PIAehL7aFr8hilqOVw2kfkG1W4lQp+GI5pA+sB59JsIpm6g6UQIKGchRPrmfl0U QGBQeUpRDO9Qk4Jrh9Sq2sSjMjQgfmnIc+ewrJIfG8InU6cepdaTqV8oZgxW1K6bRPgL 557kAtxWJ9eJHIF6smfH+WeogcTccIfCWjkQvDnmw1VFbK05PTi0TWGbjvw5EV7Ua9yF SJVA== X-Gm-Message-State: AIVw111dyUulMw7hSwNiDMzpr/eqmLRPwYswLs0KnQ5d23brcpQjvwnS 9sYZk/FChDKV2uMEocR1wAPPxY9PADcd X-Received: by 10.176.74.71 with SMTP id r7mr1587246uae.180.1500545206113; Thu, 20 Jul 2017 03:06:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.151.25 with HTTP; Thu, 20 Jul 2017 03:06:25 -0700 (PDT) In-Reply-To: References: From: Seth Blank Date: Thu, 20 Jul 2017 03:06:25 -0700 Message-ID: To: Barry Leiba Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="f403045f8f0efaf21e0554bce7c8" Archived-At: Subject: Re: [dmarc-ietf] Draft minutes from DMARC session at IETF 99 (Prague) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 10:06:49 -0000 --f403045f8f0efaf21e0554bce7c8 Content-Type: text/plain; charset="UTF-8" One correction: Point 4, settled issues: - AAR need not be signed *by AMS* On Thu, Jul 20, 2017 at 2:55 AM, Barry Leiba wrote: > The minutes are uploaded to the meeting materials manager, here: > https://www.ietf.org/proceedings/99/minutes/minutes-99-dmarc-02.txt > > Please review and post any corrections. > > Barry, as chair > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --f403045f8f0efaf21e0554bce7c8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
One correction:

Point 4, settled issues= :
- AAR need not be signed *by AMS*


On Thu, Jul 20, 2017= at 2:55 AM, Barry Leiba <barryleiba@computer.org> wro= te:
The minutes are uploaded to the meeti= ng materials manager, here:
https://www.ietf.org/proceed= ings/99/minutes/minutes-99-dmarc-02.txt

Please review and post any corrections.

Barry, as chair

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

--f403045f8f0efaf21e0554bce7c8-- From nobody Thu Jul 20 03:08:22 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1E50131BFC for ; Thu, 20 Jul 2017 03:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTAwHHK-pcRp for ; Thu, 20 Jul 2017 03:08:19 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C183D131BF4 for ; Thu, 20 Jul 2017 03:08:19 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id g13so9797802ioj.5 for ; Thu, 20 Jul 2017 03:08:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=F6IluFYGau5jEVy+aamxFzGZsJ/FjJQp6AVjjBlY25I=; b=DASVZlGAaAxW7YCDHSiCFKu4L69W+vRMAO4R6JBdWhAlJD9iBYMNnYB7i5KAxkCSBc +emoavYHi+C5mgMBEIWMH+YEA/94cub1ED43hpxrlU17/t5YFKfeZZGs0howm599AmMl U4f8MGq9xtLn852I9Zi4CiBnh7M8R+5q0VGN7ljR/XJoNDBqJ8XgEklFBKM2NSR6fZh0 FfLMSDxlrryDhxM9YKaOoB9wR4pmWkPXZoYL+SRstAf6AvF/faGlWfmJqnH+uVp6OZec biFn9ZvPAw2TcZg1ZRga/dR0bBVjQ5Jxgoh2XT6nB4n0lP94rWgFshou54lhpJkIQYBV nWAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=F6IluFYGau5jEVy+aamxFzGZsJ/FjJQp6AVjjBlY25I=; b=CITTW+ESWa+y8StdDQc28Siierlx2MRlJ5dMIpZTVeEn266gc+R4MSlhNLJFI2EssY h9pLpNXxH1p/QdWfn062L/CnDgyg+BH99bs+zgbhLNFpMLKUVqLp1yX6zmOsKHvLfpr3 7pqHp0D8/VsVc3SGWqF0gFNYmXpIRxp9+QZ6D27xNGeweNVp2yn5rE2fItH7Y18qnXBh X+VwLy+2xEngE/AsYI90QxI2ZIt/xxSoroakARu9xQ1Sa6pgC2pvsyl723WuWHVAcdVT zMCsKoWi5jrKXhCEsvKL/eyc4COp0SLKSnGKdcoThu9LKkz+MmM3H8cGRCiuxdC/vOYY 9WCQ== X-Gm-Message-State: AIVw1113T+p3kwtJUhSs8oulvC2DL/xPcTWRmzXZS2rnAXrlqE8/e5ve +o1QsgcBkMQVMq5MMirS/OzPAhdxzK+Y X-Received: by 10.107.182.132 with SMTP id g126mr2849334iof.216.1500545298835; Thu, 20 Jul 2017 03:08:18 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 10.107.152.80 with HTTP; Thu, 20 Jul 2017 03:08:18 -0700 (PDT) From: Barry Leiba Date: Thu, 20 Jul 2017 12:08:18 +0200 X-Google-Sender-Auth: hepuVyAykJH_yaHpiqL-rcW7hwU Message-ID: To: "dmarc@ietf.org" , Brandon Long Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [dmarc-ietf] DMARC mailing list policy with respect to DMARC bounces causing subscription suspensions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 10:08:21 -0000 As noted in the IETF 99 minutes, we have announced a new policy for the DMARC mailing list, at least until the list is under some DMARC damage-mitigation: If you post with an email address in a domain with a DMARC "reject" policy, and that policy causes other subscribers to have their subscriptions disabled due to the DMARC-related bounces, then: 1. You will be asked to post from a different address, in a domain that does not have a "reject" policy. 2. If you continue to post from the problematic address, that address will be blocked from posting on the grounds that it is disrupting the operation of the working group. Brandon, you are on notice that your address has been causing problems for some time, and you have not responded to my off-list notes. I got a new batch of disabled subscriptions this morning. If it happens again, will not be allowed to post. I want to stress that your participation is valuable and we *do* want you here. It's just that the DMARC policy at is inconsistent with posting to mailing lists, and we can't continue to accept the disruption that causes. Barry, as chair From nobody Thu Jul 20 04:07:24 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C0B8129AD1 for ; Thu, 20 Jul 2017 04:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TIfU4aZAlzUf for ; Thu, 20 Jul 2017 04:07:21 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEFCC12EAF0 for ; Thu, 20 Jul 2017 04:07:21 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id g13so10236074ioj.5 for ; Thu, 20 Jul 2017 04:07:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=i8BPJWq2wau7FMc0j+IdtqEdohuyuqAQrOFp799OO9w=; b=ocKB/ZEl4lVk19La1riKIQmHVPggHJ+AuA23OZgegvjUwLnw71fIJfcVxY32dtTkey Uk8OOcwLXS84erXoygTFbhXbLBTWp96s4/A22ZeVnRHnn37Y9+ixuv3c651kxcq//zIN qLxYpRiAwdogdxFc6C4t5xud80g9cFBIDvyVmrGb2VQcDFUS6DZERv52bOn7YAg0EQQr jOjVz6OcaUtkdoBeTaMX+r522sSiadaHsphv0wSwNvRy6z/w9Fo+rTXazo3yQhWBE8ut mKsJdPtR4tczc3M0jzhl9LZVEl9HE2bRioPpRyJ00ZJwhGIgKrDAyYrUPNG1Z8P9y2jL YFGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=i8BPJWq2wau7FMc0j+IdtqEdohuyuqAQrOFp799OO9w=; b=thNjBH5c8GSf574tzK8f8PwtGYZt53yeXsRTL4Q9NVr1WcqqJkHIH+tTCtwWfa40w6 GPA3RSTWDJPp3StKv7kkHG2iZVjyKJ3T0CaT9NuANNzQqFYORzh/2+xQrX6rg0vEkuVy QGMgh8L9vs/SXOL5hIZoOp7gGPQdjnJfbPtTPa9HbcbM17Ta/35J0o3rFXsoTDOLCKuW xg8LnpWUdbKh4TuIZQ7oxX5zGZw2BDxeND+olgOpDNzRJPvlOnLky9xn7fYeesXKd7h6 4AjcqkPfIwSDyCPUAexb1CyyyO/HBd7yKpwtIuu0Av4CAcpfzQqtSDQPf483dKIMTayi GdYw== X-Gm-Message-State: AIVw110ztJz9DPrYdGvg1kAg+TZM9ftb4XH+f8zP2qWoEf1Xe+yPaE58 uQzpInMmERhx91FbZ+gGLzmxa9gY2w== X-Received: by 10.107.182.132 with SMTP id g126mr2985770iof.216.1500548841075; Thu, 20 Jul 2017 04:07:21 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 10.107.152.80 with HTTP; Thu, 20 Jul 2017 04:07:20 -0700 (PDT) In-Reply-To: References: From: Barry Leiba Date: Thu, 20 Jul 2017 13:07:20 +0200 X-Google-Sender-Auth: jCnvmMfNj2kCTCrBgWBclILMv0M Message-ID: To: Seth Blank Cc: "dmarc@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [dmarc-ietf] Draft minutes from DMARC session at IETF 99 (Prague) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 11:07:23 -0000 > One correction: > > Point 4, settled issues: > - AAR need not be signed *by AMS* Ack; changed in my version. I'll post it after seeing if there are other corrections. b From nobody Thu Jul 20 04:24:00 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9B91270B4 for ; Thu, 20 Jul 2017 04:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZTi7xJ5CLQF for ; Thu, 20 Jul 2017 04:23:57 -0700 (PDT) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E28512969E for ; Thu, 20 Jul 2017 04:23:57 -0700 (PDT) Received: by mail-ua0-x234.google.com with SMTP id q25so1730142uah.1 for ; Thu, 20 Jul 2017 04:23:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:from:date:message-id:subject:to; bh=pzCR57wT8FUORW9umqpohKdexOCLcZgVnWzeUWFPpDU=; b=OUDMxfyFo+sCCLBuowiXfKDrRhVojjhWhakbE8kGB80r0h4bb8shTu8UsYj8BZ3wKB OcnQfAZAYjf8mTRKpdyHNyMcSP0rW24lOakeH2RkAUMMF0jU1hI8KWVF+H+4L1q7XCAE lYBZdH2+2T9dB/kLt8Z+AnZcZqdt/4yG24VE0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=pzCR57wT8FUORW9umqpohKdexOCLcZgVnWzeUWFPpDU=; b=k+ls3P7vasld3SiKaF2hHB/h9e6hxXCIXjG5NoBcvT45uryuYjZtMBIwErG42VKAYC pMd8Tq3pEaFlUyB+hyIWQBjbHfOmBITfoFWs7PVAzR9TU4F9t80xTar4/shz8zTA++fz QxE+IMXaoe2/bpD+3vmJb6Th93LuoxlXaef7/yflOv1VghshH7QYwoUBNFvX07RDtDsN DiSuDsHwtQF03gA3Sg5JrUgmKzEfTCN6BqkRu7X/gOLwLVQlEwEivJNpmhxWCy8gyJS5 /p1DpHhBB+QQMF/Kzw4Ob0KdOyZRax8SY6OkqRFQElx26gF1HJ+AEIpoB2UJko8gh52i oMEA== X-Gm-Message-State: AIVw111m5LDUCu4NVpjMVUbqmyJLM8jaamfVuaklhph5pQxnRx4c8BZP vdPQLnTZ/gLFRn99YrQdUDkBYG5xfGyLP68Yfw== X-Received: by 10.159.48.8 with SMTP id h8mr1834669uab.196.1500549836303; Thu, 20 Jul 2017 04:23:56 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.176.26.39 with HTTP; Thu, 20 Jul 2017 04:23:55 -0700 (PDT) From: "Kurt Andersen (b)" Date: Thu, 20 Jul 2017 13:23:55 +0200 X-Google-Sender-Auth: tQOgVVuZ3AxVJ_PxTyCDoQepc0w Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="f403045dce5ef60bea0554bdfb8d" Archived-At: Subject: [dmarc-ietf] Speaking notes for IETF99 DMARC meeting (Kurt) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 11:23:59 -0000 --f403045dce5ef60bea0554bdfb8d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable *Herewith are my notes that I was referring to when speaking today - apologies for the weird line spacing that pasted itself in with the text...= * *3. Report about handling IETF Mailman* We (Steve, Seth, Kurt) met with Henrik and Robert who support the IETF mailman (2.x) on Tuesday. They are looking for two things before implementing: 1. on the wire stability =E2=80=93 spec locked (Kurt) 2. OpenSUSE packaging for an ARC implementation that can plug into postfix before and after mailman (Seth) *4. Open issues in the ARC specs* *2. **Settled issues:* a. Signing AAR within AMS =E2=80=93 optional b. cv=3Dinvalid collapsed into cv=3Dfail (reasons for chain failure can b= e structural, environmental (DNS failures), or invalid sigs) c. A-R arc=3Dpolicy added to pass|fail d. Dealing with multiple A-R headers when ARC sealing 3. Language cleanup =E2=80=93 in progress a. Some challenges in describing how to handle algorithm evolution, but working on it b. Clarifying conveyance of ingress status to egress sealing 4. Signaling ARC participation =E2=80=93 list discussion 5. Helping small receivers bootstrap =E2=80=9Ctrust=E2=80=9D =E2=80=93 n= ot a spec issue 6. AAR content and format (see below) 1. Standards status: Standards Track vs Experimental a. If Experimental, what is the experiment and what constitutes success? *5. Handling enhanced reporting* - What should be reported in a DMARC report when ARC is involved? Adding in connecting IPs and all selectors to help senders troubleshoot problems =E2=80=93 want to be able to provide the same level of detail that= is currently provided with DMARC first-receiver reports - Where/when to report with ARC? Each step should be reporting back to the 5322.MFrom domain =E2=80=93 will = generate multiple reports for a message that goes through mediation steps; but that=E2=80=99s an issue for the report consumers to reconcile - Structuring ARC data info? Package as a single line JSON in the comment? --> Fork to a separate spec *6. Deployment discussion -- issues? Concerns? Nothing?* 1. We now have a couple of new implementations (rspamd + Mail::Authentication =E2=80=93 reflected in the next draft of the spec) and= two pending (Chris + Alexey) *9*. *AOB Points* 1. Do we need to revisit the DMARC reporting to formalize how to report local policy extensions like ARC? 2. What do we need in order to put DMARC onto standards track? --f403045dce5ef60bea0554bdfb8d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Herewith are my note= s that I was referring to when speaking today - apologies for the weird lin= e spacing that pasted itself in with the text...


3. Report about handling IETF Mailman

We (S= teve, Seth, Kurt) met with Henrik and Robert who support the IETF mailman (2.x) on Tuesday. They are looking for = two things before implementing:

1.=C2=A0=C2=A0=C2=A0 on the wire stability =E2=80=93 spec locked (Kurt)

2.=C2=A0=C2=A0=C2=A0 OpenSUSE packaging for an ARC implementation that can plug into postfix before and a= fter mailman (Seth)=C2=A0

4. Open issues in the ARC specs

2.=C2=A0=C2=A0=C2=A0 Settled issues:

a.=C2=A0=C2=A0=C2=A0 Signing AAR within AMS =E2=80=93 optional

b.=C2=A0=C2=A0 cv=3Dinvalid collapsed into cv=3Dfail (reasons for chain failure can be structural, environmental (DNS failures), or invalid sigs)

c.=C2=A0=C2=A0=C2=A0 A-R arc=3Dpolicy added to pass|fail

d.=C2=A0=C2=A0 Dealing with multiple A-R headers when ARC sealing

3.=C2=A0=C2=A0=C2=A0 Language cleanup =E2=80=93 in progress

a.=C2=A0=C2=A0=C2=A0 Some challenges in describing how to handle algorithm evolution, but working on = it

b.=C2=A0=C2=A0 Clarifying conveyance of ingress status to egress sealing

4.=C2=A0=C2=A0=C2=A0 Signaling ARC participation =E2=80=93 list discussion

5.=C2=A0=C2=A0=C2=A0 Helping small receivers bootstrap =E2=80=9Ctrust=E2=80=9D =E2=80=93 not a spec issue

6.=C2=A0=C2=A0=C2=A0 AAR content and format (see below)

1.= =C2=A0=C2=A0=C2=A0=C2=A0Standards status: Standards Track vs Experimental

a.=C2=A0=C2=A0=C2=A0=C2=A0If Experimental, what is the experim= ent and what constitutes success?

5. Handling enhanced reporting

=C2=A0=C2=A0 - What should be reported in a DMARC report when ARC is involved?

Addin= g in connecting IPs and all selectors to help senders troubleshoot problems =E2=80=93 want to be able to provide = the same level of detail that is currently provided with DMARC first-receiver report= s

=C2=A0=C2=A0=C2=A0 - Where/when to report with ARC?

Each = step should be reporting back to the 5322.MFrom domain =E2=80=93 will generate multiple reports for a message th= at goes through mediation steps; but that=E2=80=99s an issue for the report consume= rs to reconcile

=C2=A0=C2=A0=C2=A0 - Structuring ARC data info?

Packa= ge as a single line JSON in the comment? --> Fork to a separate spec


6. Deployment discussion -- issues?=C2=A0 Concerns?=C2=A0 Nothing?

1.=C2=A0=C2= =A0=C2=A0 We now have a couple of new implementations (rspamd + Mail::Authentication =E2=80=93 refl= ected in the next draft of the spec) and two pending (Chris + Alexey)

<= /blockquote>

9. AOB Points=

1.= =C2=A0=C2=A0=C2=A0 Do we need to revisit the DMARC reporting to formalize how to report local policy extensi= ons like ARC?

2.=C2=A0=C2=A0=C2=A0 What do we need in order to put DMARC onto standards track?

--f403045dce5ef60bea0554bdfb8d-- From nobody Thu Jul 20 04:43:50 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9946E12EC30 for ; Thu, 20 Jul 2017 04:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.908 X-Spam-Level: X-Spam-Status: No, score=-0.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_16=1.092, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 3GKQSOO4fNcY for ; Thu, 20 Jul 2017 04:43:47 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E50C12EA7C for ; Thu, 20 Jul 2017 04:43:47 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id d29so11363109uai.2 for ; Thu, 20 Jul 2017 04:43:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=9ADqLMy9on0zG56m6Tbxem6Y+0OIXCY4N7HQYGxHSuw=; b=eoA85nOJD6vW0shK36I1D6jErMLtDyZpPBJy1tPhnBkZhytnrc7i5zdfr/ma1vLsLi Zy0IwUCWEvYvIAzML8QgR6l+cW1WIxnGOq/Yj/QKFMg0QLCLSjAtwOfQ7mJJBXnyFFZs k8acbN0EwERBGcU/WHiViuzXMwc8otSmdnyuk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=9ADqLMy9on0zG56m6Tbxem6Y+0OIXCY4N7HQYGxHSuw=; b=AocRBUnncSQ5lPQ2LsPZB6AKxXKu8N55iz9Xp68xIOfH6rNLpwyBoQSMus6Wwo5Bhv Kzu91OQ0piH5+3XesAM7M4hBdX25jagAiiP13xfVR0/WGZ5U2WQir+q3WOiqhO+tkYlk 2fN6/c3FlyG6kjicLBpUKSs9VyHBS9pxTn3bZGpCtewo6qBIVBhs8UQkxmPSt9MEV334 xoHk5DZmvgWOxiMlR5ZdURXMEyZD/YY+kjkS9LonIFG/uT22xd9DH0MgXdnazFJLPapE SfksPQD8yQFbzSYdD/XUPptwm0sjnCZRvn1fZLFOUk0jtos+Zn+gg7IU8nWlV89inuyF w7xw== X-Gm-Message-State: AIVw111CkWN0gus5Xoz8Arkc/Nt1ARpy2wOkGJj+y1sOQh3ZjXgd4GQr GPQ5Pb4gK8C9LlPg1Ao4A51uNqq2KsM/ X-Received: by 10.176.80.139 with SMTP id c11mr1925675uaa.159.1500551026075; Thu, 20 Jul 2017 04:43:46 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.176.26.39 with HTTP; Thu, 20 Jul 2017 04:43:45 -0700 (PDT) In-Reply-To: References: From: "Kurt Andersen (b)" Date: Thu, 20 Jul 2017 13:43:45 +0200 X-Google-Sender-Auth: IJIDy_XJSscOiESvEbwcM-P0Ek0 Message-ID: To: Brandon Long Cc: "dmarc@ietf.org" Content-Type: multipart/related; boundary="94eb2c0cc3f4e0af2d0554be428e" Archived-At: Subject: Re: [dmarc-ietf] News piece on using arc... X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 11:43:50 -0000 --94eb2c0cc3f4e0af2d0554be428e Content-Type: multipart/alternative; boundary="94eb2c0cc3f4e0af2a0554be428d" --94eb2c0cc3f4e0af2a0554be428d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jul 20, 2017 at 3:28 AM, Brandon Long wrote: > https://www.propublica.org/nerds/item/authenticating- > email-using-dkim-and-arc-how-we-analyzed-the-kasowitz-email > Interesting way of looking at a solo ARC set: ...a validated DKIM signature guarantees that you have the same email that > was *sent*; a validated ARC signature can guarantee that you have the > same email that was received by the receiving server. Essentially functioning as an electronic version of the old paper-pusher's date stamp: or one of our original mental constructs: --Kurt =E2=80=8B =E2=80=8B --94eb2c0cc3f4e0af2a0554be428d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Jul 20, 2017 at 3:28 AM, Brandon Long <blong@google.com> = wrote:

Interesting way of looking at a solo ARC set:
...a validated DKI= M signature guarantees that you have the same email that was sent;= a validated ARC signature can guarantee that you have the same email that = was received by the receiving server.

Essen= tially functioning as an electronic version of the old paper-pusher's d= ate stamp:
or one of o= ur original mental constructs:

--Kurt
=E2=80=8B
=E2=80=8B=C2=A0

--94eb2c0cc3f4e0af2a0554be428d-- --94eb2c0cc3f4e0af2d0554be428e Content-Type: image/jpeg; name="rcvd-image-1.jpeg" Content-Disposition: inline; filename="rcvd-image-1.jpeg" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: ii_j5cda1980_15d5fce056068773 /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCAUUBRQDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3+iii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKAEorC8Ya+/hjwxd6vHbC4aDYBEz7Q25wvXB9a8z/4 Xjf/APQAtv8AwLb/AOIranh6lVXiiJTjHc9pzRmvFv8AheN//wBAC2/8C2/+Io/4Xjf/APQAtv8A wLb/AOIrT6lW7fiL2sO57TmjNeLf8Lxv/wDoAW3/AIFt/wDEUf8AC8b/AP6AFt/4Ft/8RS+pVu34 h7WHc9pzRmvFv+F43/8A0ALb/wAC2/8AiKP+F43/AP0ALb/wLb/4in9SrdvxD2sO57TmjNeLf8Lx v/8AoAW3/gW3/wATR/wvG/8A+gBbf+Bbf/EUvqVbt+Ie1h3Pac0Zrxb/AIXjf/8AQAtv/Atv/iKP +F43/wD0ALb/AMC2/wDiKf1Kv2/EPaw7ntOaM14t/wALxv8A/oAW3/gW3/xFH/C8b/8A6AFt/wCB bf8AxFH1Kt2/EPaw7ntOaM14t/wvG/8A+gBbf+Bbf/EUf8Lxv/8AoAW3/gW3/wARR9SrdvxD2sO5 7TmjNeLf8Lxv/wDoAW3/AIFt/wDEUf8AC8b/AP6AFt/4Ft/8RR9SrdvxD2sO57TmjNeLf8Lxv/8A oAW3/gW3/wARR/wvG/8A+gBbf+Bbf/EUfUq/b8Q9rDue05ozXi3/AAvG/wD+gBbf+Bbf/EUf8Lxv /wDoAW3/AIFt/wDEUfUq3b8Q9rDue05ozXi3/C8b/wD6AFt/4Ft/8RR/wvG//wCgBbf+Bbf/ABNH 1Kt2/EPaw7ntOaM14t/wvG//AOgBbf8AgW3/AMTR/wALxv8A/oAW3/gW3/xFL6lW7fiHtYdz2nNG a8W/4Xjf/wDQAtv/AALb/wCIo/4Xjf8A/QAtv/Atv/iKf1Kv2/EPaw7ntOaM14t/wvG//wCgBbf+ Bbf/ABFH/C8b/wD6AFt/4Ft/8RR9SrdvxD2sO57TmjNeLf8AC8b/AP6AFt/4Ft/8RR/wvG//AOgB bf8AgW3/AMRS+pVu34h7WHc9pzRmvFv+F43/AP0ALb/wLb/4mj/heN9/0L9t/wCBbf8AxFH1Kt2/ EPaw7ntOaM14t/wvG/8A+gBbf+Bbf/EUf8Lxv/8AoAW3/gW3/wART+pV+34h7WHc9pzRmvFv+F43 /wD0ALb/AMC2/wDiKP8AheN//wBAC2/8C2/+Jo+pV+34h7WHc9pzRmvFv+F43/8A0ALb/wAC2/8A iKP+F43/AP0ALb/wLb/4ij6lW7fiHtYdz2nNGa8W/wCF43//AEALb/wLb/4ij/heN/8A9AC2/wDA tv8A4ml9SrdvxD2sO57TmjNeLf8AC8b/ALaBbf8AgW3/AMRR/wALxv8A/oAW3/gW3/xFH1Kt2/EP aw7ntOaM14t/wvC//wCgBbf+Bbf/ABFH/C8b/wD6AFt/4Ft/8RT+pV+34h7WHc9pzRmvFv8AheN/ /wBAC2/8C2/+Io/4Xjf/APQAtv8AwLb/AOIpfUq3b8Q9rDue05ozXi3/AAvG/wD+gBbf+Bbf/EUf 8Lxv/wDoAW3/AIFt/wDEU/qVft+Ie1h3Pac0Zrxb/heN/wD9AC2/8C2/+Io/4Xjff9AC2/8AAtv/ AImj6lW7fiHtYdz2nNGa8W/4Xjf/APQAtv8AwLb/AOIo/wCF43//AEALb/wLb/4ij6lW7fiHtYdz 2nNGa8W/4Xjf/wDQAtv/AALb/wCIo/4Xjf8A/QAtv/Atv/iKPqVft+Ie1h3Pac0Zrxb/AIXjf/8A QAtv/Atv/iKP+F43/wD0ALb/AMC2/wDiKPqVbt+Ie1h3Pac0Zrxb/heF/wD9AC2/8C2/+Io/4Xjf /wDQAtv/AALb/wCIo+pVu34h7WHc9pzRmvFv+F43/wD0ALb/AMC2/wDiKP8AheN//wBAC2/8C2/+ Io+pV+34h7WHc9pzRmvFv+F43/8A0ALb/wAC2/8AiKP+F43/AP0ALb/wLb/4mj6lX7fiHtYdz2nN Ga8W/wCF43//AEALb/wLb/4ij/heN/8A9AC2/wDAtv8A4ij6lX7fiHtYdz2nNGa8W/4Xjf8A/QAt v/Atv/iKP+F43/8A0ALb/wAC2/8AiKPqVft+Ie1h3Pac0Zrxb/heN/8A9AC2/wDAtv8A4ij/AIXh f/8AQAtv/Atv/iKPqVbt+Ie1h3Pac0Zrxb/heF//ANAC2/8AAtv/AIij/heN/wD9AC2/8C2/+Ipf Uq3b8Q9rDue05ozXi3/C8b//AKAFt/4Ft/8AEUf8Lxv/APoAW3/gW3/xFP6lX7fiHtYdz2nNGa8W /wCF43//AEALb/wLb/4ij/heF/8A9AC2/wDAtv8A4ij6lW7fiHtYdz2nNGa8W/4Xhf8A/QAtv/At v/iKP+F43/8A0ALb/wAC2/8AiKX1Kt2/EPaw7ntOaM14t/wvG/8A+gBbf+Bbf/EUf8Lxv/8AoAW3 /gW3/wART+pVu34h7WHc9pzRmvFv+F43/wD0ALb/AMC2/wDiKP8AheN//wBAC2/8C2/+IpfUq3b8 Q9rDue05ozXi3/C8b/8A6AFt/wCBbf8AxFH/AAvG/wD+gBbf+Bbf/EU/qVft+Ie1h3Pac0Zrxb/h eN//ANAC2/8AAtv/AIij/heN/wD9AC2/8C2/+Io+pVu34h7WHc9pzRmvFv8AheF//wBAC2/8C2/+ Io/4Xjf/APQAtv8AwLb/AOIo+pV+34h7WHc9pzRmvFv+F43/AP0ALb/wLb/4ij/heN//ANAC2/8A Atv/AIij6lX7fiHtYdz2nNGa8W/4Xjf/APQAtv8AwLb/AOIo/wCF43//AEALb/wLb/4ij6lW7fiH tYdz2nNGa8W/4Xjf/wDQAtv/AALb/wCIo/4Xjf8A/QAtv/Atv/iKPqVbt+Ie1h3Pac0Zrxb/AIXj f/8AQAtv/Atv/iKP+F43/wD0ALb/AMC2/wDiKPqVft+Ie1h3Pac0Zrxb/heN/wD9AC2/8C2/+Io/ 4Xjf/wDQAtv/AALb/wCIo+pV+34h7WHc9pzRmvFv+F43/wD0ALb/AMC2/wDiKP8AheN//wBAC2/8 C2/+Io+pV+34h7WHc9pzRmvFv+F43/8A0ALb/wAC2/8AiKP+F43/AP0ALb/wLb/4ij6lX7fiHtYd z2nNGa8W/wCF4X//AEALb/wLb/4ij/heN/8A9AC2/wDAtv8A4ij6lX7fiHtYdz2nNGa8W/4Xjf8A /QAtv/Atv/iKP+F43/8A0ALb/wAC2/8AiKPqVbt+Ie1h3Pac0Zrxb/heN/8A9AC2/wDAtv8A4ij/ AIXjf/8AQAtv/Atv/iaX1Kt2/EPaw7ntOaM14t/wvG//AOgBbf8AgW3/AMRR/wALwv8A/oAW3/gW 3/xFH1Kt2/EPaw7ntOaM14t/wvG//wCgBbf+Bbf/ABFH/C8b/wD6AFt/4Ft/8RR9SrdvxD2sO57T mjNeLf8AC8b/AP6AFt/4Ft/8RR/wvG//AOgBbf8AgW3/AMRT+pV+34h7WHc9pzRmvFv+F43/AP0A Lb/wLb/4ik/4Xjf/APQAtv8AwLb/AOIpfUq3b8Q9rDue1ZozXi3/AAvG/wD+gBbf+Bbf/EUf8Lxv /wDoAW3/AIFt/wDEUfUq3b8Q9rDue05ozXi3/C8b/wD6AFt/4Ft/8RR/wvG//wCgBbf+Bbf/ABFP 6lW7fiHtYdz2nNGa8W/4Xjf/APQAtv8AwLb/AOIo/wCF43//AEALb/wLb/4ij6lX7fiHtYdz2nNG a8W/4Xjf/wDQAtv/AALb/wCIo/4Xjf8A/QAtv/Atv/iKPqVft+Ie1h3Pac0Zrxb/AIXjf/8AQAtv /Atv/iKP+F4X/wD0ALb/AMC2/wDiKX1Kt2/EPaw7ntOaM14t/wALxv8A/oAW3/gW3/xFH/C8b/8A 6AFt/wCBbf8AxFP6lW7fiHtYdz2nNGa8W/4Xjf8A/QAtv/Atv/iKP+F43/8A0ALb/wAC2/8AiKX1 Kt2/EPaw7ntOaM14t/wvG/8A+gBbf+Bbf/EUf8Lxv/8AoAW3/gW3/wARR9SrdvxD2sO57TmjNeLf 8Lxv/wDoAW3/AIFt/wDEUf8AC8b/AP6AFt/4Ft/8RT+pV+34h7WHc9pzRmvFv+F43/8A0ALb/wAC 2/8AiKP+F43/AP0ALb/wLb/4ml9SrdvxD2sO57TmjNeLf8Lxv/8AoAW3/gW3/wARR/wvG/8A+gBb f+Bbf/EU/qVbt+Ie1h3Pac0Zrxb/AIXjf/8AQAtv/Atv/iKP+F43/wD0ALb/AMC2/wDiKPqVft+I e1h3Pac0Zrxb/heN/wD9AC2/8C2/+Io/4Xhf/wDQAtv/AALb/wCIpfUq3b8Q9rDue05ozXi3/C8b /wD6AFt/4Ft/8RR/wvG//wCgBbf+Bbf/ABFP6lX7fiHtYdz2nNGa8W/4Xjf/APQAtv8AwLb/AOIo /wCF43//AEALb/wLb/4il9SrdvxD2sO57TmjNeLf8Lxv/wDoAW3/AIFt/wDEUf8AC8b/AP6AFt/4 Ft/8RT+pVu34h7WHc9pzRmvFv+F43/bQLX/wLb/4itjwn8VbvxH4ms9Im0eG3W535lS4LFdqFum0 elTLCVoxcmhqpF7HqVFFFc5YUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBxXxY/wCScan/AL0P/o1K +f8AT7N9R1G2so3VHuJViVm6Ak4r6A+K/wDyTjU/96H/ANGpXhfhn/ka9Ix/z+R/+hV62Bly0JNe ZhUV5JHYj4MeIDn/AImGn8HH8f8AhS/8KX1//oIaf/4//hXuRAJORRtX+7XJ9er9zT2UTw3/AIUv r/8A0ENP/wDH/wDCj/hS+v8A/QQ0/wD8f/wr3LaPSjav92j69X7h7KJ4b/wpfxB/0ELD/wAf/wAK P+FL6/8A9BDT/wDx/wDwr3Lav92jYPSj69X7i9nE8N/4Uv4g/wCghp//AI//AIUf8KX8Qf8AQQ0/ /wAf/wAK9y2r6UbR6UfXq/cfs4nhv/Cl/EH/AEENP/8AH/8ACj/hS+v/APQQ0/8A8f8A8K9y2r6U bR6UfXq/cPZxPDf+FL+IP+ghp/8A4/8A4Uf8KY1//oIaf/4//hXuW1f7tG1fSj67X7h7KJ4b/wAK X1//AKCGn/8Aj/8AhR/wpfX/APoIaf8A+P8A+Fe5bV/u0bV/u0fXq/cPZRPDf+FL+IP+ghYf+P8A +FH/AApfX/8AoIaf/wCP/wCFe5bV/u0bR6UfXq/cXs4nhv8AwpfX/wDoIaf/AOP/AOFH/Cl/EH/Q QsP/AB//AAr3Lav92jav92j69X7h7OJ4b/wpfX/+ghp//j/+FH/Cl9f/AOghp/8A4/8A4V7ltX0o 2r/do+vV+4/ZRPDf+FL6/wD9BDT/APx//Cj/AIUvr/8A0ENP/wDH/wDCvctq/wB2jav92j69X7h7 OJ4b/wAKX1//AKCGn/8Aj/8AhR/wpfxB/wBBDT//AB//AAr3LavpRtX+7R9er9w9lE8N/wCFMa// ANBDT/8Ax/8Awo/4Uxr/AP0ENP8A/H/8K9y2r6UbV/u0vr1fuHsonhv/AApfxB/0ENP/APH/APCj /hS/iD/oIaf/AOP/AOFe5bV9KNq/3af17Edw9lE8N/4Uvr//AEENP/8AH/8ACj/hS+v/APQQ0/8A 8f8A8K9y2r6UbV9KPr1fuHsonhv/AApfxB/0ENP/APH/APCj/hS+v/8AQQ0//wAf/wAK9y2r/do2 j+7R9er9w9nE8N/4Uvr/AP0ENP8A/H/8KP8AhS/iD/oIWH/j/wDhXuW1f7tG1f7tH16v3D2UTw3/ AIUv4g/6CFh/4/8A4Uf8KY1//oIaf/4//hXuW1fSjavpR9er9w9lE8N/4Uvr/wD0ENP/APH/APCj /hS+v/8AQQ0//wAf/wAK9y2r/do2r/do+vV+4eyieG/8KX1//oIaf/4//hR/wpfX/wDoIaf/AOP/ AOFe5bV/u0bV/u0fXq/cPZRPDf8AhS+v/wDQQ0//AMf/AMKP+FL6/wD9BDT/APx//Cvctq/3aNq/ 3aPr1fuHsonhv/Cl/EH/AEENP/8AH/8ACj/hS+v/APQQsP8Ax/8Awr3Lav8Ado2r/do+vV+4eyie G/8ACl9f/wCghp//AI//AIUf8KX1/wD6CGn/APj/APhXuW1f7tG1f7tH16v3D2UTw3/hS+v/APQQ 0/8A8f8A8KP+FL+IP+ghp/8A4/8A4V7ltX+7RtX0o+vV+4eyieG/8KY1/wD6CGn/APj/APhR/wAK X1//AKCGn/8Aj/8AhXuW1f7tG1f7tH17Edw9lE8N/wCFL6//ANBDT/8Ax/8Awo/4Uvr/AP0ENP8A /H/8K9y2r/do2r/do+vV+4eyieG/8KY1/wD6CGn/APj/APhQfgvr/wD0ENP/APH/APCvctq+lGwe lL67X7h7KJ4b/wAKX1//AKCGn/8Aj/8AhR/wpfX/APoIaf8A+P8A+Fe5bV/u0bV/u0/r1fuHsonh v/Cl/EH/AEENP/8AH/8ACj/hS+v/APQQ0/8A8f8A8K9y2r/do2j+7R9er9w9nE8N/wCFL6//ANBD T/8Ax/8Awo/4Uv4g/wCghYf+P/4V7ltX0o2r/do+vV+4eyieG/8ACl/EH/QQsP8Ax/8Awo/4Uxr/ AP0ENP8A/H/8K9y2r/do2r6UfXq/cPZRPDf+FL+IP+f+w/8AH/8ACk/4Uv4g/wCghp//AI//AIV7 nhf7tG0HtS+u1+4eyieG/wDCl/EH/QQ0/wD8f/wo/wCFL6//ANBDT/8Ax/8Awr3LYPSjavpT+u1+ 4eyieG/8KX1//oIaf/4//hR/wpfX/wDoIaf/AOP/AOFe5bB6UbV/u0fXq/cPZRPDf+FL6/8A9BDT /wDx/wDwo/4Uvr//AEENP/8AH/8ACvctq/3aNq/3aPr1fuHsonhv/Cl/EH/QQ0//AMf/AMKP+FL+ IP8AoIWH/j/+Fe5bV/u0bV/u0fXsR3D2cTw3/hS+v/8AQQ0//wAf/wAKP+FL+IP+ghp//j/+Fe5b V/u0bV/u0fXq/cPZRPDf+FL6/wD9BDT/APx//Cj/AIUvr/8A0ENP/wDH/wDCvctq/wB2jav92j69 X7h7KJ4b/wAKY1//AKCGn/8Aj/8AhR/wpfX/APoIaf8A+P8A+Fe5bV9KNq/3aPrtfuHsonhv/Cl9 f/6CGn/+P/4Uf8KX1/8A6CGn/wDj/wDhXuW1fSjavpR9er9xezieG/8ACl9f/wCghYf+P/4Uf8KX 1/8A6CGn/wDj/wDhXuW0elG1fSj69X7j9lE8N/4Uvr//AEENP/8AH/8ACj/hS+v/APQQ0/8A8f8A 8K9y2r/do2r/AHaPr1fuHsonhv8AwpfxB/0ENP8A/H/8KP8AhS+v/wDQQsP/AB//AAr3Lav92jav 92j69iO4eyieG/8ACl/EH/QQsP8Ax/8Awo/4Uv4g/wCghp//AI//AIV7ltX+7RtX0o+vYjuHs4nh v/Cl9f8A+ghp/wD4/wD4Uf8ACl9f/wCghp//AI//AIV7ltHpRtX0o+vV+4eyieG/8KX1/wD6CGn/ APj/APhR/wAKX1//AKCGn/8Aj/8AhXuW1f7tGwelH16v3D2UTw3/AIUxr/8A0ENP/wDH/wDCj/hS +v8A/QQ0/wD8f/wr3LavpRtX+7R9er9w9lE8N/4Uvr//AEENP/8AH/8ACj/hS+v/APQQ0/8A8f8A 8K9y2r6UbV/u0fXa/cPZRPDf+FL6/wD9BCw/8f8A8KT/AIUv4g/6CGn/APj/APhXue1f7tG1f7tH 17Edw9nE8N/4Uv4g/wCghp//AI//AIUf8KX8Qf8AQQ0//wAf/wAK9y2r/do2r/do+vYjuHs4nhv/ AApfxB/0ENP/APH/APCk/wCFL+IP+ghp/wD4/wD4V7ntX+7RtHpR9exHcPZRPDf+FL+IP+ghp/8A 4/8A4Uf8KX1//oIaf/4//hXuW1f7tG1f7tH16v3D2UTw3/hS+v8A/QQ0/wD8f/wo/wCFL6//ANBD T/8Ax/8Awr3LavpRtX0o+vV+4eyieG/8KX1//oIaf/4//hR/wpfxB/0ENP8A/H/8K9y2r/do2r/d o+vV+4eyieG/8KX1/wD6CGn/APj/APhR/wAKX1//AKCGn/8Aj/8AhXuW1f7tG1f7tH16v3D2UTw3 /hS+v/8AQQ0//wAf/wAKP+FL6/8A9BDT/wDx/wDwr3Lav92jav8Ado+vV+4eyieG/wDCl9f/AOgh p/8A4/8A4Uf8KX1//oIaf/4//hXuW1f7tG1fSj69X7h7KJ4b/wAKX1//AKCGn/8Aj/8AhR/wpfX/ APoIaf8A+P8A+Fe5bV/u0bV9KPr1fuHsonhv/Cl9f/6CGn/+P/4Uf8KX1/8A6CGn/wDj/wDhXuW1 f7tG1f7tH16v3D2UTw3/AIUv4g/6CFh/4/8A4Uf8KX8Qf9BDT/8Ax/8Awr3Lav8Ado2j0o+vYjuH s4nhn/Cl/EH/AEENP/8AH/8ACl/4Uvr/AP0ELD/x/wDwr3Lav92jav8Ado+vYjuHs4nhv/Cl9f8A +ghp/wD4/wD4Uf8ACl9f/wCghp//AI//AIV7ltX+7SbV/u0fXq/cPZRPDv8AhS+v/wDQQ0//AMf/ AMKP+FL+IP8AoIWH/j/+Fe5bVx92jav92j69X7i9nE8N/wCFL6//ANBDT/8Ax/8Awo/4Uvr/AP0E NP8A/H/8K9y2r/do2r/do+vV+4/ZRPDf+FL6/wD9BDT/APx//Cj/AIUvr/8A0ENP/wDH/wDCvctq +lG1f7tH16v3D2UTw3/hS+v/APQQ0/8A8f8A8KP+FL+IP+ghp/8A4/8A4V7ltX+7RtX0o+vV+4ey ieG/8KX8Qf8AQQ0//wAf/wAKP+FL+IP+ghp//j/+Fe5bV9KNq/3aPr1fuHs4nhv/AApfX/8AoIaf /wCP/wCFH/Cl/EH/AEELD/x//Cvctq/3aNg9KPr1fuL2cTw3/hTGv/8AQQ0//wAf/wAKP+FL+IP+ ghp//j/+Fe5bV9KNq+lH17Edx+yieG/8KX1//oIaf/4//hR/wpfX/wDoIaf/AOP/AOFe5bV/u0bV 9KPr1fuHsonhv/Cl9f8A+ghp/wD4/wD4Un/Cl/EH/QQ0/wD8f/wr3Pav92jav92j69X7h7KJ4b/w pfX/APoIaf8A+P8A+FH/AApfX/8AoIaf/wCP/wCFe5bV/u0bV/u0fXq/cPZRPDf+FL6//wBBDT// AB//AAo/4Uv4g/6CFh/4/wD4V7ltX+7Rheyij69X7h7KJ85eJfh/qfhbSv7Qvrq1kjMqxBYt2ST9 RS/DH/kpGj/Wb/0S9ek/GQf8UXEQoz9sj/rXm3ww/wCSkaP9Zv8A0S9d1OpKphpSlvqZWUaisfSN FFFeMdAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBxXxX/AOScan/vQ/8Ao1K8M8L/API2aR/1+R/+ hV7n8WP+Scan/vQ/+jUrwzwx/wAjXpH/AF+R/wDoQr1cH/u0/mYz+NH1KO/1paQd/rS15Rqwooop hcKKKKAuFFFFAXCiiigEFFFFAMKKKKAuFFFFAwooooEFFFFILhRRRTBBRRRSAKKKKYXCiiigLhRR RSC4UUUUwuFFFFAXCiiigLhRRRQFwooooC4UUUUBcKKKKAuFFFFAIKKKKAYUUUUBcKKKKAQUUUUA wooooC4UUUUAgooooAKKKKAuFFFFAXCiiigLhRRRQFwooooC4UUUUBcKKKKQXCiiimFwooopDYUU UUCuFFFFMLhRRRQDCiiigLhRRRQFwooopBcKKKKYXCiiigEFFFFABRRRSC4UUUUBcKKKKYXCiiig LhRRRQFwooooGFFFFArhRRRQFwooooC4UUUUBcKKKKQXCiiimDCiiigLhRRRQFwooooBBRRRQFwo oooC4UUUUBcKKKKAuFFFFAXCiiigYUUUUCuFFFFIaCiiimAU1un406mnp+NISPO/jN/yJcP/AF9x /wBa82+GP/JSNH+s3/ol69J+M3/Ilw/9fcf9a82+GP8AyUjR/wDem/8ARL16uH/3SXzMZfxEfSNF FFeUbhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHFfFf8A5Jxqf+9D/wCjUrwzwv8A8jZo/wD1+R/+ hCvc/ix/yTjU/wDeh/8ARqV4X4Y/5GzSP+vyP/0IV6uD/wB2n8zGfxo+ph3+tLSDv9aWvLNWFQ3d zFZ2stzO+yGJC7tjooGSamrK8Tf8ivqv/XpL/wCgmhK7SAwR8U/BhXP9tpz/ANMZP/iad/wtLwX/ ANBtf+/Mn/xNfOaZ8tck9KsixvWAItLjB6ERNz9OK9d5fSW8mc/tn0PoP/haXgv/AKDaf9+ZP/ia P+FpeC/+g2v/AH5k/wDia+fP7Pv/APnyuv8Av01L/Z9//wA+V3/36el9Qo/zP8A9qz6C/wCFp+C/ +g0n/fmT/wCJo/4Wn4L/AOg0n/fmT/4mvnz+z7//AJ8rr/v01L/Z9/8A8+V1/wB+m/wo+o0f5n+A /as+gv8Ahafgz/oNp/35k/8AiaT/AIWn4M/6Daf9+ZP/AImvn7+z7/8A58rr/v09H2C//wCfK6/G J/8ACj6jR/mf4C9qz6Ei+J3g2V9qa3Hn1Mbj+a1u6fruk6qu6w1G2uAeySgn8utfLklndxpvltZ0 X1ZDiq8ThJPOgcrIp4kjOCPxHIqXl8H8Ehqq76o+uywHJ6Uu4V8/eGfilrOjOkOpO+o2Q4Yv/rVH s3f8a9r0PX9N8Q6at7ptwJYTww/iQ+jDsa4a2HnRfvbGsZqWxr0Ug/pS1iUwooooEFFFIehpDRHP NHbwyTSttjjUsx9AOSa5IfFPwWf+Y2n/AH5k/wDia6PVv+QNf/8AXtJ/6Ca+Ugx256Y967cJho17 8z2M6k3G1j6L/wCFpeCzyNbT/vzJ/wDE0f8AC0vBf/QbX/vzJ/8AE189rY3rKCtpcspGQVibBB/C nf2ff/8APldf9+n/AMK6vqND+Z/gZ+1l1PoL/hafgv8A6Da/9+ZP/iaP+Fp+C/8AoNr/AN+ZP/ia +ff7Pvv+fK7/AO/T/wCFH9n33/Pld/8Afp/8KPqNH+Z/gHtWfQX/AAtPwZ/0G0/78yf/ABNH/C0/ Bn/QbT/vzJ/8TXz7/Z9//wA+V3/36ej+z7//AJ8rv/v09H1Cj/M/wH7Rn0F/wtLwX/0Gk/78yf8A xNH/AAtLwZ/0G0/78yf/ABNfPv8AZ9//AM+V3/36emSWl1Au+W2njXpukjZRn0yaPqFH+Z/gJ1Wj 6MsfiL4V1O+gsrPVlluJ22RoInG4+mStdTXzF4JJ/wCE20U5P/H0tfToHNcWKoRoySizWnJyTuLR RRXMUFFFFABRRRQAUZxRTW4GTwKQ0LuGM9qTcvqK5jxV430vwtCBdv5t2wzHbR8s319B7143r3xI 8Q67uRLo6fasf9TbcN+L9TXRRwtSrqtETKcY7nvl9rmlaYjNe6jawBeu+UAj8KwpfiZ4PgbD65D/ AMBjdv5LXzhKULmWchnP8chyT+JqaG1uZ1Bgtp5B6xxsRXbHLoL45GXtX0R9ER/E/wAGyttTW0z7 xSAf+g1r2PijQtS/49NWtJT/AHRKAfyNfMUljeRruktblVHdo2FVQYnYcozj1xkUPAU/syBVWfXg kUqGDAg9COc07PNfL+j+L9f0J0+w6lMI1/5YSsXjP4GvWvCPxU03WHjs9UVbC9Y4Uk/upD7HsfY1 y1sHUp67o0jUjLQ9HopivyQeuafXIaMKKKKZIUUUUAFFFFABRRRSAK53WPHHhzQNRNhqepLb3IRZ DGY3PynODkAjsa6Fug+tfPvxdz/wsKYA/wDLpB/N66MLRVWpyyFNuKuj1L/hafgv/oNp/wB+ZP8A 4mj/AIWn4M/6Daf9+ZP/AImvnmK3mnBMMUspHXy0LY+uKf8AYL//AJ8rr/v0/wDhXe8BRTs5P8DH 2r6n0H/wtLwX/wBBtf8AvzJ/8TR/wtLwX/0G0/78yf8AxNfPv9n3/wDz5XX/AH6f/Cj+z7//AJ8r v/v09H1Gj/M/wH7Vn0F/wtLwX/0G0/78yf8AxNH/AAtLwX/0G1/78yf/ABNfPv8AZ9//AM+V3/36 ej+z7/8A58rv/v09H1Gj/M/wD2rPoL/haXgv/oNr/wB+ZP8A4mj/AIWn4L/6Da/9+ZP/AImvn3+z 7/8A58rv/v0/+FJ/Z9/nH2K7/wC/T/4UfUaH834oPas+gj8U/BeONbTP/XGT/wCJrptL1O01jT4r +xmE1tKMo4BGR9CM18nHIOCehwR6V9I/DX/kn2k/9c2/9CNc+KwsaMVKL3KhNyZ1lFFFcJoFFFFA BRRRQAU05p1Hekxo44/FHwYCVOtJuHBHkycf+O0f8LS8F/8AQcT/AL8yf/E186nhnBJxuP8AOpks rySMPHaXDIejLGxB/EV6/wBQpWu5M51Vkz6E/wCFpeC/+g2v/fmT/wCJo/4Wn4L/AOg2n/fmT/4m vn3+z7//AJ8rr/v0/wDhR9gvzz9iusdz5TcfpR9RofzfkP2sj6B/4Wn4L/6Daf8AfmT/AOJre0TX 9M8R2TXmk3QubdZDEXCsuGABIwQD3FfLLo8TlHVkccFWBBFe5fBQ/wDFG3f/AGEZP/QI6wxOFhSp 88X2KpzcnZnpFFFFcBoFFFFIAooooAKz9X1mw0LTnv8AUpxb2qFQ0hBOCTgcAE9avscKT7Vzfjqw /tDwRq8GCWFu0g+q/MP5U4pOSTHsrlL/AIWn4L/6Daf9+ZP/AImj/hafgv8A6Dif9+ZP/ia+c1bK 5J7CrQsb4gFbS5ZSMgiJiCPyr13l9GO8n+Bz+1l2PoP/AIWl4M/6Daf9+ZP/AImj/haXgv8A6Daf 9+ZP/ia+ff7Pv/8Anyuv+/T/AOFA0+/zxZXWf+uLf4VP1Kh/N+Qe1fQ+gf8Ahafgv/oOJ/35k/8A ia6iwv7fUrKG9tJPMt5lDxuBjINfJzKVkKuGDKcMCCMGvor4Z3H2j4e6UzHLorxtz0w7AfpiufFY WNKClB3uXTm5Ox2NZ2sa1YaBYNf6nci3tVZVaQqTyTgDArQrzf4zXTR+FLa1H/LxdKDz2X5q5aMP aVIw7mknZXNcfFPwWf8AmNp/35k/+Jpf+FpeC/8AoNp/35k/+Jr53jjkmfy40Z37KoyTx2FTf2ff /wDPldf9+nr0/qFFbyf4GPtZH0F/wtLwX31tP+/Mn/xNIPil4LIyNcXH/XGT/wCJr59+wX//AD43 ZP8A1yf/AAqGSGWB/LmjeOQdVcEEfgaFgKL0Un+AOrLsfS2k+O/Deu6ilhpuprcXThmWMRuMgDk5 IArpK8M+C9h5/iW+vm6WkARfq55/Ra9yrz8TTjSqOEWaxd43FooorEYUUUUAFYWu+MNC8N3EMGrX 4tpJkLxgozbgDg9Aa3T0rxH42nGv6P8A9esn/oYrbD0lVqKDFN8qud5/wtPwX/0G0/78yf8AxNL/ AMLT8F/9BtP+/Mn/AMTXzxDDNcMyxRPIR1CKWP6VL9gvj/y5XX/flv8ACvQeAoreT/AxVWT6H0F/ wtPwX/0G1/78yf8AxNH/AAtLwX/0G1/78yf/ABNfPv8AZ9//AM+V1/36ej+z7/8A58rr/v0/+FH1 Gj/M/wAB+1Z9Bf8AC0vBf/QbX/vzJ/8AE0f8LS8F/wDQbX/vzJ/8TXz7/Z9//wA+V1/36f8Awo/s +/8A+fK6/wC/T/4UfUKP8z/APas+gv8AhaXgv/oNL/35k/8AiaP+FpeDP+g2v/fmT/4mvn3+z7// AJ8rv/v0/wDhR/Z9/kAWVzk+sLf4UfUKP8z/AAD2rPoH/hafgvtriZ/64yf/ABNdDouuad4gsPt2 mXIuLYsV3hSOR1GCBXysyPG5VwyOpwVKkEfWve/g/wA+BQf+nmT+dc+JwkKUOaLZUJuTs0d/RSDp S1wGrCo55o7e3knlbbHGpZjjOAKkqhq//IEv/wDrg/8A6CafUa1Oc/4Wn4LP/MbT/vzJ/wDE0v8A wtLwZj/kNp/35k/+Jr5zUnaMZqytjeuoZLS4ZWG5SImwR7V639n0lvJnNGq3rY+g/wDhaXgv/oNr /wB+ZP8A4mj/AIWl4L/6DSf9+ZP/AImvn3+z77/nyu/+/T/4Uf2ff/8APld/9+no+o0f5n+A/as+ gv8AhaXgv/oNr/35k/8AiaP+FpeC/wDoNr/35k/+Jr59/s+//wCfK7/79PR/Z9//AM+V3/36ej6j R/mf4B7Vn0F/wtLwX/0G1/78yf8AxNH/AAtLwZn/AJDaf9+ZP/ia+ff7Pv8A/nyu/wDv09H9n33/ AD5XX/flv8KPqNH+Z/gHtWfQi/E/wa7BRrceTxzFIP5rW7puvaVq6b9P1G2uR0xHICfy618uNZXk Y3PaXCqOpMTAfqKghlaOcT20hjlU8PE21l/Ec1Ly+D+CQKs1ufXW9fWlDA9DXhfhT4sXunOlrr7P d2nA+0AZlj9z/eFe1WN7b31rHcWkscsEo3I8ZyCK8+tRnSdpG0ZKSui3RSZ9qWshsKKKKYgpp6fj Tqaen40ho87+Mv8AyJUX/X5H/WvNvhj/AMlI0f8A3pv/AES9ek/Gb/kS4f8Ar8j/AK15t8MR/wAX K0f/AHpv/RL16uH/AN0l8zB/xUfSNFFFeUdAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBxXxY/wCS can/AL0P/o1K8L8Mf8jZpH/X5H/6EK90+LH/ACTjU/8Aeh/9GpXhfhj/AJG7R/8Ar8j/APQhXq4P /dp/Mxn8aPqYd/rS0DvRXlGrCsrxN/yK+q/9ekv/AKAa1ayvE3/Isar/ANekv/oJqo/EvUOh8qj/ AFI/3a+rNEA/sHTuB/x7Rf8AoAr5TH+p/wCAivq7Q/8AkX9O/wCvWL/0AV6eZbR+f6GOH6/13L4A 9B+VLtX+7SjpRXlG1xNq/wB2jav92looC4m1f7tJtH90flTqKAuNwDwVGPpXN674L0HXw5vbCMTs OLiH5ZF98/4101NwRTUpRd4sLX3PnXxf8P8AUfCzNdRk3enZ/wBeo+ZP98f1rE8P+INQ8Naol/Yv g8eZET8sq+hH8jX1BcwJcQtFKiSROCHRxkMDXz/8RPBP/CLaiLqzVv7KuWyn/TF/7pPp6V6uGxSq /uqpjUp8vvRPbfDfiGz8S6RFqNm3yt8rxn70TDqprYU5B5zXzd4E8VP4Y8QI0rv/AGfdEJcrnhef v49q+jkZWXIIIPIxXDiaHsZ26PY0hPmRLRSbqWucqwUdqKKARR1f/kD6h/17Sf8AoJr5PToB6ivq /WP+QPqH/XtJ/wCgmvlBOgr1ct2kY1t0fU3hYZ8KaSx5Js4s5/3RWvgf3R+VZPhX/kUtI/684v8A 0AVr9q8uXxM2T0GlR6CkwP8AZ/Kh8iP6CvLD8bNLycaPqBGT3j/xq6dKdT4FewOSW7PU8D/ZpcD/ AGa8r/4Xbpn/AEBtQ/76j/8AiqP+F26Z/wBAbUP++o//AIqr+qV/5Re1j3PVMD/Zrzv4x8eC4jnJ F4n/AKC9UP8Ahdml/wDQGv8A84//AIqua8b/ABFsvFmgrp8FhdW8izrLul2bSACMcEnvWtDC1o1I uUdLkyqRcWkzmvBY/wCK40X/AK+V/rX0/wClfMHgr/keNG/6+V/rX0+OlaZj/EXoTR+F/wBdgooo rgNAooopAFFFFADST1xxXFePvHEfhaxEMBSTU51/cxnog/vt+uK6vUr6HTdPubyckRW8bSPjrgDN fMGuaxc+INZutTu2zJM3yjpsQdF9sD+tdeEw/tZ3lsiak+VablS5ubm8u5Lq6lea5mbLOxyXJ/z0 r0Hwv8KL7U1S61qV7K2PKwp/rmHbJOQv5ZrX+FngaP7PH4j1SJXlkGbSJxwi/wB8j34xXrYU7cGu jFY2zdOlpYinTW8jn9E8GeH9FXNnpkAfGPMkXc7Y7kmugCJ2UflRkLxmqOp67pei24n1K+htYz0a RsZ+lea3Kb11ZvtsXyikcqPyrM1TQNI1iPy9R022ulPHzxjP59ayoPiP4QuZxBFrtsZGOFDblB/E jFdIsyOoZCGUjII5BFDUovqg3PLPEHwdtZUebQJmt5cfLbSndG3sD1X868l1HT7zTL2Wzv7Z4LmM 4ZG/mD3HuK+rz8zYHp+dcv418G2nirSmRgkV9EMwXIHIPofUGu7D42UHy1HdGU6Sexwfw1+IDwzx aDrE+6FsJaXEh+528sn06YNezIwboc18lXVpPaXctpco0c8EhikXOCrA4OP6V9AfDTxQ3iHw4FuW BvbMiGXJ5cY+V8e/T8KeNw6j+9hsxUpv4ZHb0U3dTq4LGtgooooEFFFFABRRRQA1u1fP3xc/5KJN /wBekH83r6BboPrXz98XP+Shzf8AXpB/N67MB/GfoTV+E3/gj/rtZGOAsX9a9iCj0H5V478EP9dr X+7F/wCzV7H0qMZ/HkFJ+6JtH90flSYHoB9RS9GzXF+LviFZ+EdTgsrmwubiSaHzgYiuAM4wckel c8ISm+WKuzRu2rZ2mB/s0YH+zXln/C7dM/6A1/8A99R//FUn/C7NM/6A1/8A99R//FVt9Tr/AMpP tY9z1PA/2aUAZ/hryz/hdul/9Aa//wC+o/8A4qhfjbpe4Z0a/Az6x/8AxVH1Ov8Ayi9rHueOXP8A x+XP/XeX/wBDavo34a/8k90n/cb/ANCNfN8r+ZcSyAYDyO4Hf5mJ/rX0f8Nf+SfaT/1zb/0I16GY /wAOK8zGlrJs6yiiivHNwooooAKKKKYBR3oo70mNHyI3+sb/AHj/ADr6R+HIz8P9HJ5Pkd/qa+bj /rW/3j/OvpL4c/8AIg6T/wBcv6mvXzD+FH1Oej8Xy/yOnwvoPyphUE4I4PFS0zuv1/pXjs6Uz5j8 aEt441sk5/0tv6V6v8FP+RNu/wDsIyf+gR15P40/5HjW/wDr7b+lesfBT/kTLv8A7CMn/oEdevi/ 91XyOan8bPSKKKK8k3CiiimAUUUUgEYZGDVe6hW5tJ7ZxlZkZD9CMVYPIpuCMfXNBSZ8kTwmCae3 IIMcrx8/7LEf0r6Q+Ht8b/wLo8jNuZIBE5/2l+X+leF+N7H+z/HGr2wA2i48wEf7YD/+zV6p8F7w TeFLm0JO62unP4P8w/rXrY5KdGM/Q56d1Jo9IwP7oppx6CpKYeDzXkM6NT5l8cWptPHOsxngG5aR c9g3IxXqXwYuRL4UvIOcw3jcHsCoNcP8XbbyPH0kq8Ce1if6sCwJ/ICt74JXTCfWLPPyFY5lHvna f5CvXre/hE/QwjpUPZM15B8brkbtEtlPKmWRh+AA/rXr5PGa8H+MtwX8ZW9vk4is1Pt8zN/hXJgV esiqrtAqfCW2a58extjK29vJKT6dF/rX0EAD1UV4p8E7fdrmqXOP9XbLFn6tn+le2injnes/IdJN RSIwBnHAP0r5o8dX51Hxzq827KLP5K89k+X+YNfSN9P9ls7i4b7sUTufwBNfJ8tx9omlunIJldpW J9WOa1y6N5yl2Qqz0R7Z8FrDyvDl7fnG65uSg+iDj+Zr04dK5T4d2I0/wJpEG3DtAsr+7Nkmurrj ry5qsn5lQVopBRRRWYwooooAQ9K8S+Nv/If0f/r1k/8AQxXtrdK8S+Nv/If0b/r1k/8AQxXVgf46 +ZNX4CD4L8+Kr9f4fsmcf8Cr3MKvoPyrwz4L/wDI13v/AF5f+z17oDRjl+/Y6V+UTaP7o/KjC/3f 0pSK5Lxh42tfBxsxdWlxcfai+zydvG3Gc5I9a5owcnyx3Kbtqzq8D/ZpcD/Yryv/AIXbpn/QH1D8 TH/8VS/8Lt0z/oDX/wCcf/xVa/VK/wDKT7SPc9TwP9ik+XPQfUCvLP8Ahdml/wDQGv8A84//AIql Hxt0rPOj6j+Bj/8Aiqf1Sv8Ayj9rDueY+MOPGuuAdBfSAD2yK9j+D3/Iij/r5k/nXiOuXyarr2o6 jEjIl1cNMiN1UHsccV7d8H8jwMvHW5k/nXfjE1h4p+RhT1nc78dKWgdKK8hHQwPSqGr/APIEv/8A rg//AKCav1Q1f/kCX/8A1wf/ANBNNbjjufJ4A8sn2r6i8IKD4M0MkAk2EJJP+4K+Xh/qj9K+ovB/ /IlaF/2D4P8A0AV6mZfDE58P+htbR/dH5Uu1f7tL3oryrG9xNq/3aNq/3aWiiwXE2r/dpNo/u/pT qKAuNKj0rlfEngLQ/EUUhmtVgvGHy3UA2uD79jXWdqbtxmqjKUXeLsG+58w+J/CupeFNQ+zXiBom 5huUHyyD+h9RWr4B8bTeFtRFvcMz6VOw8xB/yyP94e3rXuuu6JZ6/pc1hfRq0UgwrY+ZG7MD6ivm vXtEufDutXGmXa5aLlHHSRD0YV61CrHEwdOpuc8k4PmifUcMqTRxzRyCRHUMrKchge9TjkZryT4Q +K3nhfw7dyEvCu61ZjyUHVPw4xXrKElRkYPpXmVaTpTcGbxkpK6HUUUVmAU1ug+tOprdB9aQ0ed/ Gb/kS4f+vuP+tebfDH/kpGj/AFm/9EvXpPxl/wCRLh/6/I/615t8Mf8AkpGj/wC9N/6JevVw/wDu kvmYP+Kj6RoooryjoCiiigAooooAKKKKACiiigAooooAKKKKAOK+LH/JONT/AN6H/wBGpXhfhn/k bdI/6/I//QhXunxY/wCScan/AL0P/o1K8M8MY/4SzSP+vyP/ANCFerg/92n8zGfxo+ph1P1ooHei vLNWFZXib/kWNV/69Jf/AEE1q1leJv8AkWNV/wCvSX/0E04/EvUOh8qj/Uj6V9XaH/yL+m/9esX/ AKAK+UR/qR/uivq7Q/8AkX9N/wCvWL/0AV6eZbR+ZhQ2f9dzRFFFFeWbsKKKKBBRRRQAUUUUDGsK zNZ0a013SbjTbxQ0M6491PYj3BrVpCBjpSu07oe6sfJ2p6ZPpGqXemXq5mt2MTZ/i9G+hFe3/Cfx G2reG/7PuZN13p5Ee49WjP3Sf1H4Vznxm0Hy5rTXoU4fFtPgd/4D/MVyfw81r+w/Glm7cQXZ+zTY PZs7T/31j869irbE4bn6o54+5O3Q+kFIYA06mAYbr0p9eOjdhRRSHoabBFLWP+QPqH/XtJ/6Ca+T 06D6V9Yat/yBr/8A69pP/QTXyenQfSvUyzaRjW6H1P4V/wCRS0j/AK84v/QBWvWR4V/5FLSP+vOL /wBAFa9eW92bLYa/3T9K+RB3+p/nX12/3D9DXyGP4vqf516WW7z+RjX6HUWHw98TanYQX1nZRSQT qGjJmCkj3zVr/hV3jD/oGQ/+BK17L8Px/wAUHop7/Zh/M10+KiePqKTSSGqUWlqfOf8Awq7xh/0D If8AwJWj/hV3jDvpkX/gStfRlGBU/wBoVfIPYxPB/DHw88T6b4p0y8utPRIIJ1eRhOpwOe1e7joK MCiuetWlWalIuMVFWQtFFFYjCiiimAUhpaDQB5p8ZNTNp4Zi09SQ9/MAcH+FPmIP6V5H4a0n+3fE 2n6ZkbZpcyEnHyKCzfopH412/wAablpPEVha/wAENuXH1Zsf+y1B8G7RbjxZeTkcwWfy8dCzY/kK 9aj+5wnN1Zi1zVdT3GKNIYkiiQJGihUVegA6AVNTcc9KXtXkHR0Of8YeI4fC2gTajIoklGEgi/vy HoP61826rql5rN9JqGpXJmuXJO4/wD+6B2Fen/G67Y3ej2P8ASSc+5zt/qa5n4ZaRBrHjSI3K70t YmnCHozAgLn25r1cJCNKi6r3MKjcpctzkJYJY0QzxuqSD5S6Ebh+PWvQvhV4tuNP1qLRLqRjY3eR AD0jk6jHsea734q2cMnw/vWMaboWjZDtHy/OBxXhWkErrmnsDjbcxkEdvmFaxnHFUZNqxNnTnufV i4yRS4BU4pT1NGBXi9DpPFPjF4fW11G216BMR3P7m4wOkgxsJ+oyPwrn/hnrJ0fxtbxuxEF6Ps0g 9+qH8/517D8Q9NOp+B9UjAJeKEzx/wC8nIr5xhna1mhukOHhdZAR6g5/pXr4WXtsO6b6aHPU92XM fWw6EehpwqrY3Au9PtboYPnxo/HuAat15Gx0BRRRTJCiiigAooooAa3QfWvn34un/i4c3/XnB/N6 +gm6D618/fFzH/CxJs/8+cH83rswH8b5E1PhOg+CH+u1r/di/wDZq9izXjvwQ/12tf7sX/s1exVO M/jSCl8IjdD9K8N+NI/4q3Tv+vD/ANqNXuTdDXhnxq/5GzTv+vA/+jDRgf46+Y6nwnGaH4d1PxHP NDpcCzPCAzguFwD3rc/4Vb4w/wCgZD9ftK1vfBID+39U/wCvZP8A0I17aK6sTjKlOo4JLQxp01KK bPnT/hV3jD/oGQ/+BK0f8Ku8Yf8AQMh/8CVr6MorD6/U7Iv2K7s+cv8AhV/jA5A0yLOf+fla9r8D 6bd6P4QsNPvo1juYEIdVbcOST1roeAelArGtiZ1klIuMFHYWiiisBhRRRQAUUUUAFHeijvSY0fIh /wBa3+8f519I/Dj/AJEDSf8Arl/U183N/rG/3j/OvpH4cf8AIgaR/wBcv6mvXzD+FH1/Q56S975f 5HVUzuv1p/WmDqPrXjyOlHzF40/5HjW/+vt/6V6x8FP+RMu/+wjJ/wCgR15P4z/5HfW/+vt/6V6x 8FP+RMu/+wjJ/wCgR16+L/3ZfI5qXxM9IoooryjcKKKKACiiigApDzS0GkM8C+MNp9n8bRzgcXVq r8eqnb/hWl8Erzy9W1eyJP76GOVf+Akg/wDoQq78b7I+To+oDtI8DD6qWH8q5L4XXhsvH9mO1xHL Bj0JwR/6DXrx/eYP0/Qw+GofRdNPJoPPFKK8g6Dxf43WWzVNHvBjMscsR/4CVI/9CNZXwfu/s3jV oef9KtWT/vkhq7D412nmeHtPugP9TdbT/wADGP6CvNvh9dC08f6PIzbVaVoyfXcpAH54r1qPv4Nx OeWlS59JkkAYr5x+JF0br4gamWJxGyxD2wo/qa+jWGAeelfLfiO7F94p1a7HSa7kcfngfyrHLY/v G/Iqtsl/X9anqfwSttuj6tdHGZLoICPQIP6mvVugrgvhHbeT4Ctpe880sv8A4+V/9lrva5sTLmrS fmaRVoo5T4i350/wJqsqEh3jWIEd97BTj8Ca+cIIDcTQ2qDmWRIwMepGK9q+Nd75Xh/T7IH/AI+b rLDPZRn+eK818BWYvvHWkREZVJvNYY7KCR+uK9DBe5QlIxq6ySPpS1gS3tooYwAkaBAB6AYFTVGn A9qkryDcKKKKYgooooARuleJfG3/AJD+jf8AXrJ/6GK9tbpXiXxt/wCQ/o3/AF6yf+hiurBfx18y avwEHwX58V3w/wCnL/2evcx1rwv4Mf8AI133/Xl/7NXui9TTx38dhS+Eca8d+OI+bQv96b+Qr2Kv Hvjj97Qv96b/ANBWowf8eP8AXQdT4WeaaNol/r98bLTYkluNhfYzheB15Nb4+F/i/wD6BkX/AIEL V34QD/ivOn/LnJ/Na99Hau3FYqdKryxtYyhTUo3bPnb/AIVd4w/6BkP/AIErS/8ACrvGH/QMh/8A Ala+i8UVz/X6vZFexifOR+FvjDHOmRYz/wA/K1638N9Fv/D/AIVWx1KJY7jz3barbuCeK7LFIAPS sq2KqVo8srFQpxjqgHIzS0UVzIthVDV/+QJf/wDXB/8A0E1fPSqGr/8AIEv/APr3f/0E0+o4nygP 9WfpX1F4P/5ErQv+wfB/6AK+XR/qz9K+ovB//IlaF/2D4P8A0AV6uZfDE5qH+RuUUUV5R0hRRRQS FFFFABRRRQUhjfeHP4eteffFXwyNX0H+0rZAb2wG7A6tH3X+v4V6JgelMkQSI6MAVZdpHsaqnN05 KSE1dWPlHS9Rn0nVLbUrVsTW8qyJ7gHkfiK+o9J1CDVdKtb62YNDPGHU/wCffNfNPivRD4f8TX2m YIjjk3wk942yV6e1epfBvWmu9FudIkY77OXfGP8Apm3p/wACzXpY6CnTVaP9IwpO0nFnqVFNXOPS nV5RuFNPT8adTT0/GgEed/Gb/kS4f+vuP+tebfDH/kpGj/Wb/wBEvXpXxm/5EqL/AK+4/wCtea/D H/kpGj/703/ol69XD/7pL5mMv4iPpGiiivKNwooooAKKKKACiiigAooooAKKKKACiiigDivix/yT jU/96H/0aleF+Gf+Rt0j/r8j/wDQhXunxY/5Jxqf+9D/AOjUrwvwz/yNukf9fkf/AKEK9XB/7tP5 mM/jR9TjvRSDv9aWvKNWFZXib/kWNV/69Jf/AEE1q1leJv8AkWNV/wCvSX/0E1UfiXqHQ+VR/qR/ u19XaH/yL2m/9esX/oAr5RH+oH+6K+rtD/5F7Tf+vWL/ANAFenmW0fmYUNn8v1NGiiivLN2FFFFA WCik3UA5oCwtFFFAgooooGjn/GGkDW/CmoWO3dI8RaLHUSDlcfjXzGGZGDJlXU5HswOR+or63xwR +NfMXi7ThpHi7VLNQfLWctHn+6wyP516WXT1cGY11sz6I8M6p/bHhvTb/O5poEL/AO+Bhv1Brarz P4Mai1x4aurButlOdv8AuyZb+ea9LHSuCrDkqOPY1TukxaDyKKKgaKOr8aNfj/p2k/8AQTXyenQf SvrDWP8AkD6h/wBe0n/oJr5PToPpXqZZtIxrdD6n8K/8ilpH/XnF/wCgCtesjwr/AMilpH/XnF/6 AK168t7s2Ww1/uH6V8ij+L6n+dfXLkFDg9jXyL0LfU/zr08s3l8jGvuj6V+H5P8Awgei8H/j3H8z XT59q+ZLHx14l06xhtLTVXhghXaiBFOB+Iqf/hZPi7/oNS/9+0/wrOWBquTaaGqqtsfSmfY0Zr5r /wCFk+Lv+g1L/wB+0/wpf+Fj+Lu2tS/jGn+FT/Z9Xuh+1XY+kQx5z0HpTq8E8K+O/E9/4q0u0utX eSCWcK6GNfmH4CvexXPWoyotKRcZKQtFFFZAFFFFABSGlpD0oGjwb4x5/wCEzgH/AE5p/wChNWh8 ER/xN9Y/64R/+hGs/wCMf/I6W/8A15p/6G1aHwR/5C+sf9cI/wD0I160v9y+S/M51/E/rse0kZ70 tA6UV5B0XPEPjd/yMekf9ecn/oYqH4MAf8JXd8f8uh/9CFTfG7/kY9I/685P/QxUXwY/5Gq8/wCv Q/8AoQr1o/7n8v1MJfxEeg/FH/knWp/9s/8A0Na8B0rnWLHH/PzH/wChCvfvijz8OtT/AO2f/oa1 8+2Uy219bTsCVilRyB1IBzRgdaMvV/kOo7TR9Z98npRvHpXl5+Nej5OdKvvzX/Gj/hdWj/8AQJvv zX/GuBYWt/Kae0h3PTJo1nSSFwCjqVYeoI5r5KaIxPJE38DFD+BxXtP/AAuvR+CNKvgT7r/jXjd7 Olzf3E0QISWZnUHqATmvQwFKpTcuZWuZVZRlazPo74f3DXXgTSJWcswg2En2JH9K6gdK4j4UOX+H OnZPIeYflI1duOleZVVqkl5m62QUUUVmIKKKKYBRRRQA1ug+tfPvxdH/ABcOb/rzg/m9fQTdB9a+ fvi5/wAlEm/69IP5vXZgP43yJq/CdB8EP9drX+7F/WvY81458EP9drf+7F/Nq9jqMZ/GkFL4RrdK 8M+NX/I2ab/14f8AtQ17m5G014Z8aefFem+n2D/2oaeB/jL5jq/ATfBTjX9UPpbp/wChGvbQ2exr 5W0fX9T0CeWbS7o28koCuwUHIH1rX/4WT4uz/wAhqX/v2n+FdeJwdSpUcosyhNRikz6S3exo3exr 5t/4WR4uP/Mal/79p/hR/wALH8W/9ByX/v2n+Fc/9n1e6K9sux9JbsUoINfNo+JHi4n/AJDcvHrG n+Fe4eBdRutW8G6ffXs3nXEyEu+MZwxFY1cNOkryLU1LRHR0UUVzjCiiimAUUUUAFHeijvSY0fIj f6xv94/zr6R+HH/IgaR/1x/qa+bm/wBY3+8f519I/Dj/AJEDSP8Arl/U16+Yfwo+v6HPS+L5f5HV UzuPqafTPT6mvHkdKPmLxp/yO+t/9fbf0r1j4Kf8ibd/9hGT/wBAjryfxp/yO+tf9fbf0r1j4Kf8 ibd/9hGT/wBAjr18X/uq+RzUviZ6RRRRXlHQgooooBhRRRQIKKKKQ0cD8XbQ3XgWeYdbSZJcY6jO 0/8AoVeJaBeDT/E+lXnQQ3UbHntuGa+j/Fth/aXhTVbQDLSW77R7gZ/pXy1lnti65DeXkexxmvWw D5qUoMxq/EmfXozuJ7ZqQcgVn6ReDUdGsrxSMTwrJwfUZq/nP0ryTc4v4rWv2n4f37YJMDRzDH+y wNeCaVObTWtPuB/yzuYm/wDHxmvpbxZbfbfCWsWwG4y2UwUe+w4/WvlosVQEHkDIP05r1sv1pyic 9bdH1tcSpDBLKzAIiMzE9sDNfJZlL75mPLEuT+JNfRus6h/xaq41Hd8zaUHz6lkH+NfOXlGRPKHV vkH1PFGWx5eZhX6H0x4Dtms/AujQkYP2cOR/vEt/WujJ4qrpsQt9Ls4f+ecCJj0woqyx+UkcnsK8 qUrts3XY8N+M179o8V2dmDlba1DkA9GZm/oBS/BiyM3iq+vADtt7bZkjgFmB/PCmua8e3hvvHmsS qwZEm8pCD1CqB/PNek/BWxMPh+/viOLq4wp9Qgx/MmvWqXpYNLuc8feqs9O2nbj2xS9qWivIOhsK KKKBBRRRQAh6V4l8bf8AkP6P/wBesn/oYr249K8R+N3/ACMGj/8AXrJ/6GK68F/HXzJq/AV/gx/y Nl9/15f+zV7ovU14X8F/+Rtvv+vP/wBmr3RaeO/jsKXwjq8e+OP3tC/3pv8A0Fa9hNeO/HA5bQ8H +KYn8hUYP+PEc/hZgfCAhfHmSf8Alzkx+a176P4c9a+VdJ1i/wBEvftenXJt5yhTcFB4PXrW0fiP 4uDY/tuX/v2n+FduKwlSrU50zKFRRjZn0lu9qN3sa+bP+FkeLv8AoNy/9+0/wpf+Fj+Le+ty4/65 p/hXP/Z1XuivbLsfSW8Ubh3r5u/4WP4v/wCg1L+Maf4V7B8NNXv9c8KLd6nO1xOZ3XeQBwDx0rKt hZ0o80rFRqRk7I7OikHAFLXMi2B6VQ1f/kCX3/Xu/wD6CavnpVDVv+QJf/8AXu//AKCafUcT5Q/5 Zt9K+ovB/wDyJWhf9g+D/wBAFfLo/wBWfpX1F4P/AORK0L/sHwf+gCvVzL4YnNhzcoo70V5R03Ci iigkKKKKACiiigAprjKkZp1I1AHjfxp0lUk0zVkTGd1vMw79Cn/s1cv8MtUOl+OrIM+2G7DW789S Rlf1Ar174kaZ/afgXUkA3Pbx/aVHumW/lmvna2uHs7uC5jYhoJVlUj/ZYH+lethP3tB02Y1fdnc+ tUyetPqtZXKXdpBcpjbNGsi49CM1ZryDoYU09Pxp1NPT8aBI87+Mv/Ilw/8AX5H/AFrzb4Y/8lI0 f/em/wDRL16V8Zf+RLi/6+4/615r8Mf+SkaP/vTf+iXr1cP/ALpL5mD/AIqPpGiiivKOgKKKKACi iigAooooAKKKKACiiigAooooA4r4r/8AJONT/wB6H/0aleGeFx/xVmkf9fkf/oVe5/Fj/knGp/70 P/o1K8M8Mf8AI16R/wBfkf8A6EK9XB/7tP5mM/jR9TetFIO/1pa8s1YVleJv+RY1X/r0l/8AQTWr WV4m/wCRY1X/AK9Jf/QTTj8S9Q6HyqP9QPoK+rtD/wCRf03/AK9Yv/QBXyiP9QP90V9XaH/yL+m/ 9esX/oAr08y2j8zChs/l+po0UUV5RuxCcConmii5d1QdcswFSnoa+cfiZPPL451KCW4mkhjZVWNn JUDYp6dO9b4ej7afLewpy5Vc+iI7mCfPlTRyY67HBqRSGOTwa+SrS4m0+VZbKaS2kU5BgYoQfwNe reBfihObmLTPEUgcOQkN6eME9n/xretgZwXNF3RMaqejPYs0VGp3c54x19aeO1cJYtFFFMEMPBBr wr4yWIg8VWlygAE9qAT6srNn9CPyr3fFeV/Gu13aZpN0FH7q4dGPsy8fqK6cHLlrxJq6xZh/Be+e HxJqFkT8lxbeZj/aRgP5NXuA7ivm/wCHF59k+IGlc481ng+u4H/AV9HjsKvHxtWv3RNLWI6igdKK 4jUo6x/yB9Q/69pP/QTXyenQV9Yax/yB9Q/69pP/AEE18np0Ferlm0jCt0Pqfwr/AMilpH/XnF/6 AK16yPCv/IpaR/15xf8AoArX9a8t7s2WxCybkKk4zkEivND8FNIbkarfrkngBCP1FemnIAIPWqq6 pp+P+P62/wC/q/41VOpODfI7BJJ7nnn/AApLSf8AoMX/AP3zH/hR/wAKS0n/AKDGof8AfKf4V6J/ amn/APP9a/8Af5f8aX+1NP8A+f8Atf8Av8v+Na/Wq/8AMyeSB51/wpLSf+gvqH/fKf4VzPjn4c2P hTQU1C2vru4dp1i2yhQoBDHPA9hXtf8Aamn/APP/AGv/AH+X/GuB+L15az+DY1huYZWF2h2pIGP3 W9K0oYitKpFOTJnGKi2jyrwX/wAjtox9bpK+n+9fMHgwf8Vto3P/AC9JX0/3rXMfjj6E0Vo/X9EF FFFeeahRRRQAUHpRQaAPBfjJ/wAjlb/9eSf+hNV/4JEf2zq655+zocf8CNVPjOMeLrQ+tmvP/AjU /wAED/xUWrD1tEP/AI+a9aX+5fL9TBfxP67Ht9FHeivINzxD43/8jFpH/XnJ/wChiofgv/yNV5/1 6H/0IVN8b/8AkY9I/wCvOT/0MVD8GP8Akarz/r0P/oQr1o/7l8v1MJfxEem+PtMu9X8F32n2EPnX EuwKmQM4YHqfpXin/Ct/GPT+xJf+/sf/AMVX0iVBFLtH1+tcVHFTorlibSgpbnzb/wAK38Y/9ASX /v7H/wDFUn/Ct/GP/QEl/wC/sf8A8VX0ntX0FG1fQVt/aNXsifYxPm0/Dfxj/wBASX/v7H/8VQPh x4wB/wCQHN/39j/+Kr6S2r6CjaPSj+0avZB7GJyXw50q+0TwTZ2Go27QXMbylkYgkZckdCR0NdcO lJtFLXFOTlJyfU1WmgUUUUiQooopAFFFFADW6D618+/Fz/kok3/XnB/N6+gm6D618/fFz/koc3/X pB/N67cB/G+RNX4ToPgh/rta/wB2L/2avY68b+CB/fa1/uxfzavY+9RjP40gpfAIeciuN8V/D2x8 WajDeXV7cQPFF5QWIL0znPINdk3HSq819a27qlxcRROwyA7hcj8a5oTlCV47lu1rM83/AOFJaSP+ YvqP5R/4Uf8ACktJ/wCgxqH/AHyn+Fejf2pp/wDz/Wv/AH+X/Gj+09P/AOf+1/7/AC/41t9Zr/zM nkiec/8ACktJ/wCgvqH/AHyn+FKPglpOf+QvqB/4Cn+Feif2pp//AD/Wv/f5f8aUapYZ4vbb/v8A L/jR9Zr/AMzDkgfKMqiO4mjBJCSOgJ7hWIH8q+jvhr/yT7Sf+ubf+hGvnK45u7jHTz5Px+dq+jfh r/yT7Sf+ubf+hGvQzD+HH1/QxpfEzrKKKK8g3CiiigAooopjCjvRR3pMEfIjf6xv94/zr6R+HH/I gaR/1y/qa+bm/wBY3+8f519I/Dj/AJEDSP8Arl/U16+Yfwo+pz0vi+X+R1RpndfqafUZ6r9TXkM6 UfMfjT/kd9b/AOvt/wClesfBT/kTLv8A7CMn/oEdeT+NP+R41v8A6+2/pXrHwU/5Ey7/AOwjJ/6B HXrYv/dV8jmpfEz0iiiivKNwooooAKKKKACiiikNEUsYkjZD0ZSv5ivlC/tWsNTu7NvvW8zxH8CR X1mScjFfNXxBsv7P8eatF0EsgnGPRxmvRy5+/KPdGVZaJnsfwvvBefD/AE0dWtw0DH3U/wCBFdkO leW/BW936DqdkW+aG78wD2ZV/qDXqS/dFcmIjy1ZLzNI6xGSxiWN4m6OpU/QivkmeEwXM8DjmOSR MfRiK+uDngj1r5g8YWn2LxprNtjGy5JA9mAYf+hV2ZbK05IzrL3T0DUtVaX4B2p3DdIsdmfcK2P5 LXmeiW323xDplt2lvIVP0LjP6VuT6ksnwjs9O3/vE1Zzj/ZALD+dRfD21+1+P9HiIJCSNKcf7K5H 611U4+zp1H5szeslbyPpJQAAB0xUV1cJaQSXDnEUSM7n2HNTEHnn8a5f4hX/APZ/gPVpQ21pIGhT /ebgfzrxIx5pJI6r21Z84z3D3M8tw/LyyM5PuTX0d8OrA6b4G0yJgAXj84/8DO7+tfOUMJuLqK3U f62RYx+Jx/Wvq6wtRZ2NvbL0hjSIf8BUD+lepmMklGBhRWty12oooryzUKKKKACiiigAPSvEfjd/ yMGj/wDXrJ/6GK9tPSvEvjb/AMh/R/8Ar1k/9DFdWC/jr5k1fgK/wY/5Gu+/68v/AGavdB1/CvC/ gx/yNd9/15f+zV7qvf8ACnjv47Cl8IprkvF3ga08YNatd3txb/Zt23yQvOfXINdbVaW5gtQPPmji DdN7Bc/nXLGUou8dy7J7nm3/AApLSf8AoMah+Kx/4Uf8KS0n/oL6h/3zH/hXo39p6f8A8/1sP+2y /wCNJ/amn/8AP9a/9/l/xrb61X/mYuWJ53/wpLSf+gxqH/fKf4Uf8KS0jodX1H8o/wDCvRP7U0// AJ/rX/v8v+NB1LTiP+P61z/11X/Gl9Zr/wAzDlgfL+u2CaXr+o6dEzPHa3DQqzgZIH0r234O/wDI ij/r5k/nXjni5g/jTXHVgyNeuykdCK9k+Dv/ACIi/wDXzJ/OvQxjvh4t76GNP43Y78dKKB0oryEb sD0qhq3/ACBL/wD693/9BNXz0qhq3/IEv/8Ar3f/ANBNPqOJ8oD/AFZ+lfUXg/8A5ErQv+wfB/6A K+XR/qz9K+ovB/8AyJWhf9g+D/0AV6uZfDE5sObneijvRXlHQwopCcCuE134raJod/caf5V1dXkD bHjjTaAf941UISm7RVxPTc7yjNeTD44W+7nQZtv+zcAn8ttdBovxV8OavOlu88tjO5AC3SbVJ9A2 cVpLD1oq7iLmj3O5oqNXyBgg554qSsCrBSNS0jdKYIrXMCXlrNbSD93MjRt9CMf1r5OkhaGSW3k4 KO0ZB7YJFfW752/L1r5k8aWi2PjnW7dAQq3JZc+jKrfzY16OWytOUTOtsme7/Dy//tHwLpMxwWSH yWx/sHb/AErqK83+DF15vg6a2/59rpwM/wC1839a9Irirx5akl5lR+FBTW6D606mt0H1rIpHnfxl /wCRLh/6+4/615t8Mf8AkpGj/wC9N/6JevSfjN/yJcP/AF9x/wBa82+GP/JSNH/3pv8A0S9erh/9 0l8zF/xUfSNFFFeUbhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHFfFj/knGp/70P/AKNSvDPDH/I1 6R/1+R/+hCvc/ix/yTjU/wDeh/8ARqV4Z4YP/FWaR/1+R/8AoQr1cH/u0/mYz+NH1L6/Wlo9aK8o 1YVleJv+RY1X/r0l/wDQTWrWV4m/5FjVf+vSX/0E1UfiXqHQ+VR/qB9BX1dof/Iv6b/16xf+gCvl Ef6kfSvq7Qz/AMU/pv8A16xf+gCvTzLaPzMKGz+X6mjRRRXlG7EPQ183fEj/AJKBq3++n/oC19In oa+bviT/AMlA1b/fT/0Wtd2X/wAZ+hlW+A1/A3guy8WeFdS8wtFfQ3O23nB4X5M4YdxmuH1CwuNM v7nT7xDHPC5jkXORkdx7elexfBUj/hHdTyM/6UB/46Ko/GTQFVLPXoIwGDeRckdwfuE/rXTGu1iZ U5PRkyj7iaNv4V+KW1rQ2065fdeWPAJPMkZ6Mf5fhXoY5FfNPgDWDofjKwnLkW8zfZ5ueCG4H5Hb X0sK4sZS9nV02ZpTlzRFooormLCuD+Llqs/gOeUg7oJ4nX8XCn9Ca7yuV+IsHn+AtXUgHbDvH4EG tKLtVi/NCl8LPn/w5dfYfE2lXQ/5ZXSH8zg/zr6nXhR696+R45TC6TL1Rgw/A19br0B9a7cyXvRl 5GdDZokHSikHSlrzTYo6x/yBtQ/69pP/AEE18np0FfWGsf8AIH1D/r2k/wDQTXyenQfSvVyzaRhW 6H1P4V/5FLSP+vOL/wBAFa9ZHhX/AJFLSP8Arzi/9AFa9eW92bLYicHy2BHGDXyOUUs3G7LHk/Wv rt/uH6V8h9yfc/zr0stSbl8jGtuhpEanB2A+5ozD6p+dfRHgjQdJvPBekz3Ok2EszwDc8lujE8nq cV0P/CL6F/0A9L/8BE/wq5ZhFNrlEqTa3PlbMPqn50B4h0dRn/ar6o/4RfQv+gJpf/gIn+FJ/wAI xoXfRNM/8BY/8KX9ox/lH7BvqfO/gp0PjjRQHX/j7Tv9a+oByM1lx+HtHt5Flg0mxilU5V0t0BB9 iBWovSuPE11WkmlaxcIcqFooornKCiiigApD0paQ0AeG/Ggf8VTY+9p/7MaX4JH/AIqfVP8AryX/ ANDqT41gDX9MbHP2dsn2yKg+CzY8V6kPWwH/AKMFeq/9y+RjH+Iz3QHNLTO+afXknQeIfG7/AJGP SP8Arzk/9DFQfBj/AJGq8/69D/6EKn+N/wDyMWkf9ecn/oYqH4Mc+Krz/r0P/oQr1o/7l8jnl/ER 7p2FLSA8ClzXkm4UUUn4UCFooz7UUwCiiigeoUUUUhBRRRTGgooooENboPrXz98XP+Shzf8AXpB/ N6+gW6D618/fF3/koc3/AF6QfzeuzAfxfkTV+E6D4ID99rX+7F/7NXsdeOfBD/Xa1/uxf+zV7EKn GfxpBS+AQnA4rwv41Kv/AAlWnAj/AJcc4/7aNXujdK8N+NX/ACNum/8AXgf/AEYaWC/jr5jqfAea ERrywVfqaTMPqn/fVekfB+ws9Q1zU47y0guEW3QqJolcA7j0yK9fHhjQucaJpn42qf4V6FbGxpTc HG5jGm5Rvc+WMw+qfnRmH1X/AL6r6o/4RfQv+gJpf/gIn+FL/wAIvoX/AEA9L/8AARP8Ky/tGP8A KV7F9z5X3xj+Nf8AvoV9J/DRg3w+0kggjY3Q/wC0a0x4Y0IZ/wCJJpuPa1j/APia0bS1gs4RDbQR wRKfljjUKo+gFc2JxSrRUUrWKjT5XcsUUUVyFhRRRSAKKKKYBR3oo70ho+RG/wBY3+8f519I/Dj/ AJEDSP8Arl/U183N/rG/3j/OvpH4cf8AIgaR/wBcv6mvXzD+FH1Oel8Xy/yOqpnp+NPNM7r9f6V5 DOlHzF40/wCR41v/AK+2/pXrHwU/5E27/wCwjJ/6BHXk/jT/AJHjW/8Ar7b+lesfBT/kTLv/ALCM n/oEdeti/wDdY/I5qXxM9IoooryjcKKKKACiiigAooooGhhNeGfGWy8jxTZ3uABdW23j1Q//AGQr 3PivLPjXYM+j6XfgDEE5iJ9N4/8Asa6cFLlrrzIq/AYXwWvfK8S6jZswAntVZR6lWOf0Ne4qcrXz d8Ob0WHj7SpGOElLwn/gSsB+uK+kh/nFXj4cta/dBSfuiH0r56+K9qbbx9cuRgXMMcwPr8uz/wBl r6Fbp+NeKfGy2C65pV3j/W2zRHH+y27+tLAStWS7hV+E81Nw/wBkFsT8gk8wD3xiu4+EFsZ/HXng Ai3tZGPtu4FcFXqnwStv9O1q76kQxRD2OXJ/pXp4t8tCTMKes0eylsLXmXxpvhF4dsLAEbri5Dke yDn9WFemDBOD+NeH/GXUBP4msbFTxa25dh6FyP6KK8jBw5q0fvOmq7QZzPgSwGo+OdJgIzGJvNbP oilv5gV9LrnvXhnwasBP4ou7t8/6Na4TPYs2P6GvcwDuNbZhK9a3Yij8Nx9FFFcRYUUUUAFFFFAC HpXiXxt/5D+jf9esn/oYr249K8R+Nv8AyMGj/wDXrJ/6GK6sD/HXzJq/AQfBf/kbL7/ry/8AZ69z WvDPgv8A8jZff9eX/s9e5qP5U8d/HYUvhHV458cEBbQyQRlpgcd+BXsdePfHH72h/wC9N/6CtRg/ 48Rz+FnkJWNFyRgf7RpMxf7H513HwrtLa+8a+Rd28NxD9lkbZLGHGcj1r3D/AIRjQTg/2Jpufe1j /wAK9Kvi40p8nLcxjTcle58r5h9U/OjMH95Pzr6o/wCEX0L/AKAel/8AgIn+FH/CMaCP+YFpn/gK n+FY/wBox/lK9i+58sB4xnDpn13Cvfvg6wPgRcHP+kSfzrqj4Y0LH/ID00f9uqf4VdtbK1sY/KtL aG3iznZCgQZ+grDE4tVocqVioU+V3LI6UtA6UVwmjCqOr/8AIFv/APr3f/0E1eqhq/8AyBL/AP64 P/6CafUcT5QH+rP0r6i8H/8AIlaF/wBg+D/0AV8uj/Vn6V9ReD/+RK0L/sHwf+gCvVzL4YnNhzc7 0Ud6K8o6GMbpXzL4758e67nJxdHp/urX043Q/SvmPx3/AMj7r3/X0f8A0Fa78u/iv0M63who3gnX tf0w3+l2sU8O8pjzVVgR7HFZF9p13plyba/tJbaYfwSrjP8AjXtvwdP/ABRkvr9rkrofGPhe18Ta DPayIDdRqz20n8SyY459M9a2ljnCs4SWhCp80eY8x+Gfjm4069g0LU5zJYzHbbyOeYG7KT/dNe5Z PevkV1aN3QhkljYr7qynH8xX054N1c674T06/ZsytEEl93Xg/qKxx9GMWqkdmVSlfRnQZo70i9KW vPNWIfWvnj4rQeR8QbpsY86CKX68bf6V9EV4P8Z4wvjO0cfx6ev6SPXZgHat8mZ1NYm38D5iYNag Y9JYnUexUg167XiXwUlI13VIc8NbK2Po1e20sarVmOm7xQU09Pxp1NPT8a5C0eefGX/kS4v+vuP+ tea/DD/kpGj/AO9P/wCiXr0r4y/8iXD/ANfkf9a81+GP/JSNH/3pv/RL16uH/wB0l8zF/wAVH0jR RRXlG4UUUUAFFFFABRRRQAUUUUAFFFFABRRRQBxXxY/5Jxqf+9D/AOjUrwvwx/yNmkf9fkf/AKEK 90+K/wDyTnU/96H/ANGpXhXhj/kbNI/6/I//AEKvVwf+7z+ZjP40fVHrRR3NFeUasKyvE3/Isar/ ANekv/oJrVrK8Tf8ixqv/XpL/wCgmqj8S9Q6HyqP9T/wGvq3Q/8AkX9N/wCvWL/0AV8pD/Uj/dFf V2if8i/pv/XrF/6AK9PMto/MwobP5fqaApaB0oryzdiHoa+bviT/AMlC1b/fT/0Ba+kT0NfN3xJ/ 5KDq3++n/oC125f/ABn6Gdb4Ueg/BL/kAal/19j/ANAFdj400tdW8H6pabcubdnj9nUZH61x3wT/ AOQBqX/X2P8A0AV6dIoZSpGVPBB7issS3HESa7lR+A+RgxSRXXIKkEexBr6p0K//ALS8P6dfEnNz bRyHJzyVBNfMOq2psdYvrU4Pk3MiHHfk17z8LLlrrwDY7skwu8PPorHH867cwSlTjMzpfE0duD2p fWkHc+9LXkmwVjeKUWXwtqyMMg2U3/oBNbNZniBPM8PamnQtaTD/AMcIprR3Dc+UhzCM90zX1nps v2jS7SfOd8KNn1yM18ndIsf7P9K+p/DZLeF9LPrax/8AoIr1MyXuxMKDu38jXoo7UV5R0FHWP+QP qH/XtJ/6Ca+T06D6V9Yax/yB9Q/69pP/AEE18np0H0r1cs2kYVuh9T+Ff+RS0j/rzi/9AFa9ZHhX /kUtI/684v8A0AVr15b3Zsthr/cP0r5D/vfU/wA6+vH+4fpXyGOjfU/zr08t3l8jGv0Ppj4f/wDI h6Mf+ncfzNdNXM/D/wD5EPRf+vYfzNdMK86p8b9TZbIKTApaKgLhiiiigLhRRRTEFFFFABSGloNA HjHxvUDUNEIGCY5gT64K4rM+DTEeMrsetkc/99itb44/6/QeOon/APZKxPg/n/hOHAON1o2fzFet DXBP0ZjtV+Z74KfTc5WneleQdB4h8b/+Ri0j/rzk/wDQxUXwY48VXn/Xof8A0IVL8bv+Ri0j/rzk /wDQxUXwY/5Gq8/69D/6EK9aP+5fI5pfxEeseJ9c/wCEd0C61UwmdYNv7tW2k5IHX8a8+/4XfFj/ AJAE/wD4Er/hXVfFDA+Hep9efL/9DWvnmGJ7iaKCMDfI4RcnHJOKyweHp1INzXUurKSdonrg+OEX /QAn/wDAlf8ACj/heEX/AEAJ/wDwJX/CuUPwp8WhsfZLYj1FytH/AAqjxb/z52//AIErWvs8F3/E i9Y6v/hd8X/QAn/8CV/wpV+N8TMq/wBgzDJAz9oB/pXE6l8OfEmlabdahd20C29rE0shWcE7RyeK 5ZRtlQA/xD+dXHDYWabhr8wcqkX7x9axSGWKN+RvUNg9s1MOar2oP2SA9vLXj8KsCvGOkKKKKZIU UUUAFFFFADW6D618/fFz/koc3/XnB/N6+gW7V8/fFz/koc3/AF6QfzeuzAfxvkTU+E6D4If6/Wv9 2L/2avY68c+CH+u1r/di/wDZq9jqMZ/GkFL4RrdK8M+NX/I2ad/14H/0Ya9zbpXhvxq/5GzTv+vA /wDoxqMF/HXzHU+Ak+Cf/Iwan/17J/6Ea9uHTp3rxL4J/wDIwan/ANeyf+hGvbR0/Gnjf47+RNH4 F/XUdRRRXIaXExS0UUwuFFFFAgooooAKKKKACjvRR3pDR8iN/rG/3j/OvpH4cf8AIgaR/wBcf6mv m5v9Y3+8f519I/Dj/kQNJ/65f1NexmH8KPr+hz0vi+X+R1VM/u/U0+md1+teOzpR8xeNP+R51v8A 6+2/pXrHwU/5Ey7/AOwjJ/6BHXk/jT/kd9b/AOvt/wClesfBT/kTLv8A7CMn/oEdeti/91XyOal8 TPSKKKK8o3CiiigAooooAKKKKAEIBri/inZG88BXzKuWtmScewU8n8ia7WszxDY/2n4e1CyABM9u 8YB9SOP1qqcuWal2Bq8bHzBpd0bLWLG5B4huoXPsA4z+ma+sEIZQw+6eQfWvkLJMRxwwXqfWvqfw xfC/8LaVc5LmS0iLH1baAf1Br0Mxj8MjOi+hrP8Ad/GvLfjZa79C0u5VRmG7IY+gZG/rivUiQQPz rh/izb/aPh/fOB81vJFIP++gD+hriw8uWtF+ZpPWLPn2vbfgrahfDN9c45lvWTPqFVf6k14l7V9D fCi2Nv8AD+ykP/LyzzgexOP6V6mYStSt3Zz0fiOyIHPrXzX4/v2v/HWry5yI5fIH0jyuPzBr6Qup PJtJpScBEZjn0AzXyhc3DXl5PdyH5riRpmP+8ST/ADrmy6F5uRpWfu2PZfgtYCHQdQvivzT3O1T/ ALKqP6k16iPWuU+G9j9h8BaWhRRJJGZXIHUsxOfyxXVAEd65K8uerKRpBWgkOooorIAooooAKKKK AA9K8R+N3/IwaP8A9esn/oYr209K8S+N3/If0f8A69ZP/QxXVgv46+ZNX4GV/gv/AMjZff8AXl/7 PXui14X8GP8Aka77/ry/9mr3QdaeO/jsKXwjq8e+OP3tC/3pv5LXsPevHvjj97Qv96b/ANBWpwX8 eP8AXQc/hZz/AMH/APkff+3OT+a178O1eBfB/wD5H72+xyfzWvfR/DV4/wDjfJE0fhH0UUVxGlwp MClooC4UUUUwCqGr/wDIEv8A/rg//oJq/VDV/wDkC33/AF7v/wCgmjqOJ8oD/Vn6V9ReD/8AkStC /wCwfB/6AK+XR/qz9K+ovB//ACJWhf8AYPg/9AFermXwxObDm5RRRXlHSI3SvmPx3/yPmvf9fZ/9 BWvpw9D9K+Y/Hf8AyPmvf9fR/wDQVrvy7+K/T9TGt8J6t8G/+RNm/wCvt69CYHgg4Nee/Bv/AJE2 b/r7evROo/GuXFfxZeppT+FHzH42tFsfHGtWyAbVudw/4Eqt/wCzV6v8G7jzvB80H/PC8fH4815l 8RuPiLrf/XWP/wBFJXovwU/5F7Uh/wBPYI/75FejiXzYWLfkZQ0qHpyDAp1IKWvINmFeI/Gxca/p j+tqV/8AHzXtx6V4p8bf+QxpX/Xs/wD6FXXgf46+f5EVPgf9dSp8F2x4uvF7tZn9HFe7V4N8Gv8A kdrr0+wt/wChrXvA6VWP/jfJCpfCLTT0/GnU09PxriNEeefGX/kS4f8Ar8j/AK15r8Mf+SkaN9Zv /RL16V8Zf+RLi/6+4/615r8MP+SkaP8A70//AKJevVw/+6S+ZjL+Ij6RoooryjcKKKKACiiigAoo ooAKKKKACiiigAooooA4r4r/APJONT/3of8A0aleF+GP+Rs0j/r8j/8AQq90+LH/ACTjU/8Aeh/9 GpXhXhn/AJG3R/8Ar8j/APQq9XB/7tP5mM/jR9Udz9aKO9FeUasKyvE3/Isar/16S/8AoJrVrK8T f8ixqv8A16S/+gmqj8S9Q6HyqP8AUj6V9XaH/wAi/pv/AF6xf+gCvlEf6kf7or6u0P8A5F7Tf+vW L/0AV6eZbR+ZhQ2fy/U0aKKK8s3Yh6Gvm74kf8lB1b/fT/0Ba+kT0NfN3xJ/5KDq3++n/oC12Zf/ ABn6Gdb4Ueg/BP8A5AGpf9fY/wDQBXp7HGK8w+Cf/IA1L/r7H/oAr09+lZYv+NIuHwo+aPH8ItvH usxqML56sPxjUn9c16b8F5zJ4ZvoCeIbs4HpkA1wHxVQJ8Qb044aONv/AB2ux+CEmbXW4v7kkLH8 Q3+Fd+I1wkX6GUdKh6wv3adSDpmlryDZiGqOtDdol+vc20g/8dNXzWfrR26FqJ7i1kI/75NNbjR8 onhPwr6l8LNu8K6UfW1j/wDQRXy0eYzn+7X1L4VTZ4U0oelrGP0r1cy+GPqc2G6/I2aKKQ9K8k6S lq/Oj3//AF7Sf+gmvk9Og+lfV+r/APIGv/8Ar2k/9BNfKCdB9K9XLNpfIwrdD6n8K/8AIpaR/wBe cX/oArXrI8K/8ilpH/XnF/6AK168t7s2Ww1/uH6GvkP+8Pc/zr68f/Vt9DXyIf4j7nj8a9LLN5fI wr9P67H0v8Pv+RC0X/r3H8zXTfjXMeAM/wDCB6Nx/wAu4/ma6T5vQfnXn1Pjl6m62Q+imfN6D86X 5v7v5moCw6imZI/+tT+tAWCiiimIKKKKACjrRRQB478chiTQT/13/wDZK574Rts8eRgfxW0gP6Gu h+OX3tB/7b/ySuc+E3/I+w/9e8n8hXrU/wDcn6Mxl/EPoEdPxNSUzsPrT68g6DxD43f8jFpH/XnJ /wChiovgx/yNV3/16H/0IVL8b/8AkY9I/wCvOT/0MVB8GD/xVl2M/wDLof8A0IV60f8Acvl+pzy/ iI9D+KP/ACTrVP8Atn/6GteA6Sf+JzY8f8vEf/oQr3/4pf8AJO9TH/XP/wBDWvANK/5DNj/18R/+ hCjA/wAGXq/yCr8aPq5h83T9aMfX86djmlryEdBzPj3/AJJ94gPP/HjL1/3a+alH75R/tj+dfS3j 3/knuv8A/XjL/wCg181L/rV/3x/OvXy7+HL+uhz1+h9aWvFnB/1zX+VTVXtf+PO3/wCuS/yFTjpX knQLRRRTJCiiigAooooAa3QfWvn74uf8lDm/684P5vX0C3QfWvn74u/8lDm/684P5vXZl/8AF+RN X4ToPgh/rtb/AN2L+bV7F3rx34If67Wv92L/ANmr2Ooxn8aQUvhGt0rwz41f8jZpv/Xh/wC1Gr3N uleGfGr/AJG3Tf8ArwP/AKMNGC/jL5jqfATfBP8A5GDU/wDr2T/0I17cOnXvXiHwU/5D+qf9e6f+ hGvbRnsOPrTxv8d/Imj8C/rqPopnzeg/Oly3oPzrkNLDqKjXG4g54pykHOO1ADqKKKYgooopAFFF FMAo70Ud6TGj5Eb/AFjf7x/nX0j8OP8AkQNI/wCuX9TXzc3+sb/eP86+kfhx/wAiBpH/AFy/qa9f MP4UfX9DCl8Xy/yOqpncfWn0zuPrXjs6EfMXjT/keNb/AOvtv6V6x8FP+RNu/wDsIyf+gR15P40/ 5HfW/wDr7f8ApXrHwU/5E27/AOwjJ/6BHXr4v/dV8jmpfEz0iiiivKNwooooAKKKKACiiikAU1hk AHpmnU1qGNHynrVmbDXtQsyu0w3Lpj0GeK9z+E179r8B2yEkvayyRHP++SP0Iryv4mWRs/H2okjC 3G2dSO4K4P6iuz+CV6GtNXsWY7kkSVQfQrgn88V6+K9/DKfoYw0m0esjkVi+MLE6h4R1a1Ay0lux UepAyP5Vtrgj6HFKQCMGvJi7NM2avdHyULG98tW+w3PKg/6pv8K+lvBdp9h8HaRbFSpjtUBVhggk ZP8AOt3AB+6KUgYrpxGJdZJNWIhBROZ+IF8bDwPq0ynB8jYD/vEL/U183RwNPIlrGPmkIjUe5OBX tfxmvRD4asrXPNxdDK+qqpP88V5j4EszfeONHiAJCXCzMMdAnzHP5V2YK0KEqj8zOrrOyPpSxgW2 sbeBFCrFEqADtgVYpq9vWnV5RuFFFFAgooooAKKKKAEbpXiXxt/5D+jf9esn/oYr21uleJfG3/kP 6N/16yf+hiurBfx18yavwFf4Mf8AI133/Xl/7NXui14X8F/+Rtvv+vP/ANmr3UU8d/HYUvhFrx74 4/e0L/em/wDQVr2HvXj3xx+9oX+9N/6CtTgv48f66Dn8LMD4P/8AI+EetlJ/6Ete+jnBrwH4QHHj z62cn81r31QQOmTirx/8b5Imj8JJRTPmPYfnR83oPzriNR/HrRTDnuOPrSg84FArDqKQdKWmDCqO r/8AIFv/APr3f/0E1eqjq/8AyBL/AP693/8AQTSHE+Tx/qz9K+ovB/8AyJWhf9g+D/0AV8uj/Vn6 V9ReD/8AkStC/wCwfB/6AK9bMvhj6nNhzc70Ud6K8o6GIeh+lfMnjv8A5H3Xv+vo/wDoK19Nnofp XzJ48/5H3Xv+vs/+grXdl38V+n6mVf4T1b4N/wDImzf9fb16GvQV558G/wDkTZv+vt69DWubFfxZ eppT+FHzb8R/+Sja3/10j/8ARSV6L8FP+Rf1L/r6H/oIrzr4j/8AJRtb/wCusf8A6KSvRfgn/wAi /qX/AF8j/wBBFejiP90XyMo/xD08UtIKWvINmFeKfG//AJDOlf8AXs//AKFXtdeKfG7/AJDGlf8A Xs//AKFXXgv46+ZnU+B/L8yl8GT/AMVpd/8AXkx/8fWvdx0rwj4Mf8jnd/8AXk3/AKGte7joKeP/ AI3yQUvh+8Wmnp+NOprdB9a4zRHnfxl/5EuH/r7j/rXm3wx/5KTo/wDvTf8Aol69J+M3/Ilw/wDX 3H/WvNvhj/yUnR/96b/0S9erh/8AdJfMwf8AFR9I0UUV5R0BRRRQAUUUUAFFFFABRRRQAUUUUAFF FFAHFfFj/knGp/70P/o1K8L8M/8AI26P/wBfkf8A6EK90+K//JONT/3of/RqV4Z4YH/FWaR/1+R/ +hCvVwf+7T+ZjP40fU3eigd6K8s1YVleJv8AkWNV/wCvSX/0E1q1leJv+RY1X/r0l/8AQTTj8S9Q 6HyqP9QP90V9XaH/AMi/pv8A16xf+gCvlEf6gf7tfV2h8+HtN/69Yv8A0AV6eZbR+ZhQ2fy/U0aK KK8o3Yh6Gvm74k/8lB1b/fT/ANAWvpE9DXzd8Sf+Sg6t/vp/6AtduX/xn6Gdb4Ueg/BP/kAal/19 j/0AV6e4yMGvMPgn/wAgDUv+vsf+gCvUDWWL/jSLh8KPn34uLt8eSkfxW0ZP6iuj+BxwNfOe9vx+ Elc98XsHx5Jg9LWMfzroPgePl18D+9b/AMpK7an+5r5fmYw/iM9gAwMUtIORmlryjdhWZ4gbb4c1 Q+lnKf8Axxq06w/GFx9m8IavITgfZJBn6qQP51UVeSQN2Vz5cUgw5PUrX1R4d+Xwzpg9LWP/ANBF fK/SP6LivrSwgFvYW8H/ADziVPyGK9PMdo/MwoKzZaHSlooNeUdBR1j/AJA+of8AXtJ/6Ca+T06C vq/V/wDkDX//AF7Sf+gmvlFeFzXq5ZtIwrdD6m8K/wDIpaR/15xf+gCtftWR4W/5FPSOf+XOL/0A Vr9jXlvdmyWxGxLI3pg818j85bv8x/nX1synbg9G9BXBf8Kd8LMS2dRXJyQLogc/hXXg8RGi3zdS KkHK1jxu38Ta9aW6QW2r3kMMa7UjSTAUe1Sf8Jd4l/6Dt/8A9/jXsH/CmvCv97Uv/As/4Uf8Kb8K /wB7Uv8AwLP+Fdf1vDfy/giPZ1O54/8A8Jd4l/6Dt/8A9/jR/wAJf4l/6D1//wB/jXsH/Cm/C397 Uv8AwLP+Fcr4/wDh7onhjw+l9pxu/Pa4WI+dOXG0hieD9BVQxGGnJRUdX5ImUJpXv+ZheE/E2vXf jDSYLjWL2WGS4VHR5cqwPqK+iQMcV8weC8/8Jro3/X2lfT561y5hCMZrlXQuk207v+tBaKKK4TQK KKKACiig0AeRfHCEmDRLj+FZZU/FguP5VyPwtuVg+INirEDzo5I8/wDAGI/lXqfxT0ltU8F3LRx7 5bRluFAHOF+9j8K8D02+k0zU7TUIP9ZbSrIvvg8j8s162G/eYZw9UY1NJpn1euQBmpetZ+l6jb6t pkGoWzh4bhA6kHOM9vqKv5FeRsdDPJfjZpUklvpmroCyQs1vIQPuhuQfzXH41534R8Sv4U8Rx6kI fPhKmOWMHBKnGSPcY719J6jp1tqlhNZXcfm28ybHU+leHeIfhRrem3DPpSnULL+BcgSr7Ed/zr08 LXpun7GoYVIu/Mi947+Jdh4i8PHStMtrhROytNJOoXYFOcDBOTkVxXhWwl1XxbplpEDlp1diB0Cn JP6VctPAPiq9mES6JcxknkzgRqPfOTXrvgTwDF4Ujkubl1m1KUbWdfuxr/dX/GtJ1KOHpOFN3YRU pyTZ3IOSR2p1NGN2aXNeQbnM+P3A+H2vgkD/AEGXH5V82KR5w/3gB9c16/8AF/xXELVfDtpIrSyN vuyhztQfwn6nt7V5v4R0l9b8WabaKm5RKskvHARCGJP6V6+Di6dGU5dTnqtSkkj6btMi2gB7RqD+ QqxUQGMj0qUV5B0NWCiiigkKKKKYBRRRQOw1ug+tfP3xd/5KHN/16QfzevoFug+tfP3xd/5KHN/1 6QfzeuzAfxfkRV+E3/gf/r9a/wB2L/2avZK8b+B5xca19Iv/AGavY81GM/jyCl8Ijc5xXhvxpH/F Wadn/nw/9qNXuJB3ZGB+Fcv4i8B6P4q1CK71EXfmxReWpim2ALnNRh6ip1FKWxU4uUbI+ebDVNQ0 uR3sLye1dwAzRNtLAdBV7/hLfEoHGu3/AP3+Newf8Ka8K/39S/8AAs/4Uf8ACm/Cv97Uv/As/wCF eg8Zh5O7j+CMlTn3PIB4u8S/9B2//wC/xpP+Eu8S/wDQdv8A/v8AGvYP+FN+Fv72pf8AgWf8KUfB rwsf4tS/8Cz/AIUvreG/l/BB7Ofc8e/4S/xKf+Y7qH182vfPh7cz3ngfTbm6mead0O+Rzlm+Y9a+ bJlCXU6L91JXRc8nAYgc/TFfR3w1/wCSfaT/ANc2/wDQjRmEIqEXFWFTk27NnWUUUV5RuFFFFIQU UUUxhSdxS0dxSYI+RX/1rf75/nX0h8OP+RB0j/rif5mvm9v9a3++f519H/Dg/wDFAaR/1x/9mNex mH8KPr+hhR+L5f5HV0z+IfWnZphOCD7mvHZ0I+Y/Gn/I8a3/ANfbf0r1j4Kf8iZd/wDYRk/9Ajry jxoMeONb/wCvtv6V6v8ABT/kTLv/ALCMn/oEdeti/wDdY/I5qXxs9IoooryjcKKKKB2CiiikIKKK KYBTW7mnU1ulIpHifxqszFrum3oBKzW5iJ9CrE/+zVU+Dl6IPGE9uSAtxaMAD3ZWUj9M11fxntDN 4asbsKx+z3OGIHChhjn8cV5n4CvPsXjrR5NyqGnMTlj/AAspH88V69L38I12uYPSofTA606mKcsR 6U+vIWxswpjdKfTG7UDR4f8AGe+83xDYWQIIgti7D0Zm/wAAKi+DtibjxZc3mDi1tipIHQucD/0E 1g/EC+Go+OdUlU5RJBCp/wB1QD+ua9E+Cth5WialqJGDc3AiX3EYP9XNevUtTwfKc8XzVbnqK4A/ rS01adXkm7CiiigQUUUUAFFFFIAPSvEfjb/yMGj/APXrJ/6GK9uPSvEfjb/yH9H/AOvWT/0MV14L +OvmTV+Ar/Bf/kbL7/rz/wDZ690HWvDPgwMeLL73sv8A2evcxjJ9fSnjv47HS+Ed3zXjvxvPz6EP eb+Qr2HOelc34l8F6V4ra3bU/tGbfds8mUp165rHD1FTqqb2HOLcWkfOFlf3umzGayuJbaUjb5kR w2PrWifF3iU/8x2//wC/tewf8Kb8KnvqQ/7ez/hR/wAKb8K/3tS/8Cz/AIV6LxuHk7uP4Iy9lNaJ nj//AAl3iT/oO3//AH+NH/CYeJB116/H/bWvYP8AhTXhX+9qX/gWf8KQfBzwqG66l073Z/wpfW8N /L+CD2c+/wCZ5APF3iXn/ie3+O/7417X8K7671HwaLi9upbmbz3XfK2WwDxzXhniCyg03xJqlhbK whtrpoo9zbjgY6mva/g6f+KEX/r5k/nRjIw9ipRSQU2+azZ346UtIOlLXkmzCqOr/wDIEv8A/r3f /wBBNXqo6v8A8gW//wCvd/8A0E0DifJ4/wBWfpX1F4P/AORK0L/sHwf+gCvl0f6s/SvqLwf/AMiV oX/YPg/9AFetmXwxObDm53oooryjosIeh+lfMnjz/kfde/6+z/6CtfTZ6H6V8yeO/wDkfde/6+j/ AOgrXdl38V+n6mVf4T1b4N/8ibN/19vXoa1558G/+RNm/wCvt69DWubFfxZepdP4UfNvxG/5KLrf /XSP/wBFJXovwU/5F/Uv+vof+givOviN/wAlF1v/AK6R/wDopK9F+Cn/ACANS/6+R/6CK9HEf7rH 5Gcf4h6eKWkFLXkGz3CvFPjd/wAhjSv+vZ//AEKva68U+N//ACGdK/69n/8AQq68F/HXz/Iip8D+ X5lL4Mf8jndf9eTf+hrXu46CvCPgwf8Ais7v/ryb/wBDWvdx0FVj/wCN8kTS+H7xaaen406mnp+N cRqjzv4y/wDIlw/9fcf9a82+GP8AyUjR/wDem/8ARL16T8Zf+RLh/wCvyP8ArXm3wx/5KRo/+9N/ 6JevVw/+6S+Zi/4qPpGiiivKNwooooAKKKKACiiigAooooAKKKKACiiigDiviv8A8k41P/eh/wDR qV4X4Y/5GzSP+vyP/wBCFe6fFf8A5Jxqf+9D/wCjUrwvwx/yNmkf9fkf/oQr1cH/ALtP5mM/jR9T jvRQO9FeWasKyvE3/Isar/16S/8AoJrVrK8Tf8ivqp/6dJf/AEE04/EvUOh8qj/Uj/dFfV2h/wDI v6b/ANesX/oAr5R/5Y/8BFfVuh/8i/pv/XrF/wCgCvTzLaPzMKGz+X6mlRRRXlm7EPQ183fEn/ko Wrf76f8AoC19Inoa+bviT/yUHVv99P8A0Ba7cv8A4z9DOt8KPQfgn/yANS/6+x/6AK9Pbsa8w+Cf /IA1L/r7H/oAr09+n41ji/40i4fCj55+K53fEK8x/DDH/wCg11fwPQrFrrn+J4B+j/41xHxGmM3x C1gsdwjlRF9h5a/1Jr0P4KQldB1KYjl7kAH12r/9eu6urYNL0Mo61D1BeBilpo+8adXlG9wNcf8A E64Fv4A1Nj/GqR/99OB/Wuwrzj4yXfk+EYbXdj7VcqpHqF+b+YFa0FerFeZE37rPELOD7TfW1v8A 89ZVT8yBX1mvSvmLwZa/a/G+iwsu5TdKzD2GT/hX04gIXmuzMpJyil2IoL3WSDpSH7tA6UHpXmmx S1b/AJAt/wD9e0n/AKCa+T15XHr619Z30D3VjcW6MFMsbICRnGQRXjw+COo4AOt2v/fpv8a78DXp 0lLne5lVg5WsZVn8W/EOnWMFnb2el+VBGsa70fJCjH96rH/C6PE//PppP/fEn/xVXv8AhSOo/wDQ atf+/TUf8KR1H/oNWv8A36at+bBbk2qFE/GfxP8A8+mk/wDfEn/xVJ/wufxR/wA+ek/98Sf/ABVX /wDhSOo/9Bq1/wC/TUf8KR1H/oNWv/fpqObA+QWqFH/hc/if/nz0j/viT/4qj/hc/if/AJ89I/74 k/8Aiqvf8KR1H/oNWv8A36aj/hSOo/8AQatf+/TUc2B7ILVO5Q/4XP4n/wCfPSf++JP/AIqsjxH8 QtZ8U6alhfwWSQrKJQbdGDZAIAOSfWum/wCFI6j/ANBq1/79NSf8KR1L/oNWn/fpqqNTBxd1uJxq NWOL8FjHjXRh/wBPaV9QV5HoXwkv9H8Q2GpSatbSR20okZBE2Wx6GvWx0rjxtaFWacOxdOLincWi iiuQsKKKKQBRRRTAgljSaJ45FDI4Ksp6MD1FfNvjXwvL4V16W3KsbOZjJayY4K/3fqK+mNorG8Re HNP8SaY9hfREqxyki/eRuxBrow2IdGd+jCcVJHiHgTx5L4VnNrdh5dKlO5h3hJ/iX+te96dqdlqt mt1Y3Mc8DYwyHOPr6V86eKfBWq+E5z9oi+0WJb5LuPp7bh2NZOm6zqGiXX2nTbyW1lJBOxvlb6jo fxrvr4aGIXtKbMYzcPdZ9WKevNO4rw3TPjLrVsgS/srW99XU+W35AYrooPjZpJQG50nUEfuIwjKP x3D+VcEsHWjpy3NfaRPUOKQkdeK83f40aAApWw1Ik9cRpx/49WNqPxskbcumaOAP4XunwfrtXP8A OksJWk/hD2ke5668oRSzsqKBkljjFeZeM/ipbWcclh4fdbm7J2vc/wDLOL6H+I/pXmet+MNe8Qgr qF+5iP8Aywh/dx49wOv41n6TpF/rl79i0y0e4m7hOAnux7D3rso4GMPfrMh1bu0SvJJcXV20jtLP czOSXIy8rE/zzXvHw18FN4a0xry/H/Ezu1HmL/zyTqE/xpngj4b2vhwpf6iY7vU8fKwyY4f90Hqf eu/RcVji8V7RezhsOnT5dWH8WMc08dKTHOaWuE1bCiiimSFFFFABRRRQO41ugr59+Lv/ACUOb/rz g/m9fQD7iDg89q828Z/DO98V+J5dUh1KC3jaCOII8ZJyu70+tdOEqRp1OaW1iZptaHmHhjxjqXhE XR063tZGudu4zhjgLn0I9a6L/hc/icdLTSf++JP/AIqr/wDwpHUf+g1a/wDfpqP+FI6j/wBBm0/7 9NXdKrg5y5pbmUYzSsih/wALo8Uf8+ek/wDfEn/xVH/C5/E//PnpP/fEn/xVX/8AhSOo/wDQatf+ /TUf8KR1H/oNWv8A36ap5sD5DtUKA+M/if8A589I/wC+JP8A4ql/4XP4n/589I/74k/+Kq9/wpHU f+g1a/8AfpqP+FI6j/0GrX/v01HNgeyC1Qo/8Ln8T/8APnpH/fEn/wAVR/wufxP/AM+ek/8AfEn/ AMVV7/hSOo/9Bq1/79NR/wAKR1H/AKDVr/36ajmwPkFqh5e7mSWSQgBpHZyB2LEkj8zX0f8ADT/k n2k/7jf+hGvPv+FJ6lkga3a5HrC3+Nep+E9Hk0Dw1Z6XNMs0lupVnVcA8k9KzxmIp1IJQfUcINO7 NqiiivONUFFFFAgooooHcKKKTHOaTBHyKc73/wB4/wA67/Qvird6DodppcOlQzR2ybQ7ysCefpUr fBjxMWJF7pHU9Zpf/jdIfgv4n73mjj/tvL/8br251cNUilNnNGE1si7/AMLt1D/oCWv/AH+b/Cj/ AIXZqBxnRLbj1mb/AAqj/wAKW8T/APP5pH/f+X/43S/8KX8T/wDP5pH/AH+l/wDjdZKOCK/enE6z qR1nWrzUmiERuZDIUBztJ969m+Cn/Im3f/YRk/8AQI647/hTHidf+XvSD/23k/8Ajdej/Dvw3f8A hTQJdP1F7ZppLt5gYHLAgqoHUA/w1GLrUpUuSDvqh04yUrs7KiiivNNgooooC4UUUUCCiiigApDS 000ikcn8R7L7b4C1RAuTGgmA/wBxg39DXzrb3EltcRXMWPMicOuemQcivqvUrMX+m3Vm5ws8TRE+ zAg/zryhfgc+0A+IDwP+fYcfrXoYLEQpwlGo7GU4SbTiYn/C4PFI526f+MLf/FUf8Li8U/3NN/79 N/8AFVuf8KOf/oYP/JYf40f8KOf/AKGE/wDgKP8AGtvaYLsvuJUaiMP/AIXF4q/u6d/35b/4qj/h cHirIO2w9wIT/jW5/wAKPk/6GH/yVH+NH/Cjnx/yMH/ksP8AGj2mC7L7gcah5XcTyXd1NczHMk0h kfHHJOTxX0P8NtP+w+AdMBGHnj+0Hju/zfyIrjP+FHuOR4g/D7MB+ua9X060Sw061sozmO3jWNc+ ijArHGYinUiowZVOm4ttlodqdSLjFLXnmgUUUUwuFFFFAgooooAD0rxH42/8jBo//XrJ/wChivbW zt4ODXAePvAV54v1Oxube/htxbxNGwkjLZywPb6VvhakadVSlsKcXKNkeO+GfFF/4Uv5rywjt5JZ YvLxOCQBnPYiuoHxm8TZz9j0nd/uSf8AxVX/APhSOo/9Bq0/79NR/wAKR1H/AKDVp/36avQnVwc5 XkZKNRaIof8AC6PFGf8Aj00n/viT/wCKo/4XR4o/589J/wC+JP8A4qr/APwpHUv+g1a/9+Wo/wCF Iaj/ANBm1/79NS5sD5fiO1Qof8Ln8Uf8+ek/98Sf/FUf8Ln8T/8APnpH/fEn/wAVV/8A4UjqP/Qa tf8Av01H/CkdR/6DVr/36alzYLyC1Qof8Lo8T/8APnpP/fEn/wAVR/wufxPnmz0n/v3J/wDFVf8A +FI6j/0GrX/v01KPglqQ/wCY1a/9+Wo5sF5Baoeb6lfyarqt5qEyIkt1KZnCZwCcdM17n8HhjwIv /XzJ/OuSPwS1IDI1m0z2/dNXovgbw3P4V8PjTLi5juHEjOXjUqOTnoazxeIpTpKEGEINSuzpx0oo HSivNRswqhq//IEv/wDrg/8A6Cav1Q1f/kCX/wD1wf8A9BNNbjifKA/1Z+lfUXg//kStC/7B8H/o Ar5dH+qP0r6i8H/8iVoX/YPg/wDQBXq5l8MTmw5uUUd6K8o6LiHoa+Y/Hn/I+a9/19H/ANBWvpw9 D9K+ZPHn/I+69/19n/0Fa78u/iv0/Uyr/Ceq/Bv/AJE6b/r7evRFrzz4N/8AImzf9fb16GvQVy4r +LL1Lp/Cj5t+I3/JRdb/AOukf/opK9F+Cn/IA1L/AK+R/wCgivOviN/yUXW/+ukf/opK9F+CY/4p 7Uve6H/oIr0cR/ui+RnH+IeniloAxRXkG7CvFPjd/wAhnSv+vZ//AEKva68U+N3/ACGNK/69n/8A Qq68D/HXzM6nwP5fmUvgx/yOl1/15N/6Ete7joK8I+DA/wCK0uv+vJv/AEJa93HQVWP/AI3yRNL4 fvFpp6fjTqaen41xGqPPPjL/AMiXD/19x/1rzX4Y/wDJSNH/AN6b/wBEvXpPxl/5EqH/AK+4/wCt ebfDH/kpGj/703/ol69XD/7pL5mMv4iPpGiiivKNwooooAKKKKACiiigAooooAKKKKACiiigDivi x/yTjU/96H/0aleF+GP+Rs0j/r8j/wDQhXunxX/5Jxqf+9D/AOjUrwrwx/yNmkf9fkf/AKEK9XB/ 7vP5mM/jR9UetFHeivLNWFZXib/kV9VH/TpL/wCgmtWsrxN/yLGq/wDXpL/6CacfiXqHQ+VR/qB/ uivq7Q/+Rf03/r1i/wDQBXyiP9QPoK+rtE/5F/Tf+vWL/wBAFenmW0fn+hhQ2f8AXc0aKB0oryzd iHoa+bviT/yUHVv99P8A0Ba+kT0NfN3xJ/5KDq3++n/oC125f/GfoZVvhR6D8E/+QBqX/X2P/QBX p7dvrXmHwT/5AGpf9fY/9AFd34l1BdL8NajfFgpht3ZT/tbTj9ayxSvXkl3Lh8KPmnX7v7d4i1K5 ByJLpyCfrj+le4fCWAweA7ZmGDNNJIPcbsD+VfP3LHnlicn3J619ReFdP/szwppFmQFeK1jDgf3t oLfqTXdj/cpRh/WiM6S965sgHNOpB3+tLXkG43PXFeN/Gu9Ml5pNgMYRWnb2zwP5GvYmOBn8q+dv ibqP9oeO7wZylqFt1x2xkn9WNdmAjzVk+xlV0jYt/CSyF148jmYHbb20so4/iyqj/wBCP5V9AY5r yP4JWH7rVdRYHLOkCH2GS364r10c5pY2XNWfkFNWghaQ9KWiuQ0QwjoKNtPooGNxRinUUANxRinU UANxRinUUANxRinUUANA556UtLRQJhRRRTEFFFFIAooopgFNYE8U6ikMhlgSeNo5YldGGGRuQfqK 4TW/hJoOqFpbMSaZOf8An3wYz9UPH5Yr0GirhOUHeLsJpM8G1H4N6/bufsVxaXqHoSfJb8QSRWJc fDfxbb8PozOR3ilV6+k/0NNOe+PyrqjmFZLWzI9lE+aB4D8Vu2BoV0PqAP61qWfwo8WXJHm21vbI f4pZwSOe4FfQW3PTI98U8DAxnPuabzCq1bQPZRvc8r0j4LWMJD6xqEl5jkxQr5Sn2JySR+Vej6dp NjpNqtrYWsNtCvSOJdo+vvV6iuWdWdT4maJJDQgHalAGaWisxhRRRQJhRRRTEFFFFIAooooAaAd1 BXmnUUFDcUYp1FADMUuKdRQA3FGKdRTAbijFOopANAIOTSjvmlooEwooopiCiiigAooooAKKKKQD ee1LgEcilooKG7F9KNo9KdRQJsYF+bkcUoXHPP0p1FFh30CiiimSFFFFABRRRSAKKKKYBSNnt1pa KQ0IRxSYPpTqKBjefQ0YPpTqKYDce2aTB9KfRSC43FAUYp1FABjFFFFAmFFFFMQUUUUAFFFFIAPN NIPoadRQVcZtpcU6igBm2jb6AU+igBuKMU6igBuKMU6igBmDS4Oc4xTqKAAcAUUUUCYVQ1f/AJAt /wD9e7/+gmr56VQ1f/kC3/8A17v/AOgmn1HE+UB/qz9K+ovB/wDyJWhf9g+D/wBAFfLo/wBWfpX1 F4P/AORK0L/sHwf+gCvVzL4YnNhzc70Ud6K8o6GIeh+lfMnjz/kfde/6+z/6CtfTZ6H6V8yePP8A kfde/wCvs/8AoK13Zd/Ffp+plW+E9W+Df/Imzf8AX29ehr0H1rzz4N/8ibN/19vXoa1zYr+LL1Lp /Cj5t+I3/JRdb/66R/8AopK9G+Cn/Ival/19D/0EV5z8Rv8Akout/wDXSP8A9FJXovwU/wCRf1L/ AK+h/wCgivRxH+6L5GcfjPTwc0tItLXkG7CvFPjf/wAhjSv+vZ//AEKva68U+N3/ACGNK/69n/8A Qq68F/HXz/IzqfA/l+ZS+DH/ACOd3/14t/6Gte7jpXhHwY/5HO7/AOvFv/Q1r3cdKeP/AI3yQqfw i009Pxp1NboPrXGaI87+Mv8AyJUP/X3H/WvNvhj/AMlI0f8A3pv/AES9ek/Gb/kTIf8Ar7j/AK15 t8Mf+Sk6P/vTf+iXr1cP/ukvmYy/iI+kaKKK8o3CiiigAooooAKKKKACiiigAooooAKKKKAOK+LH /JONT/3of/RqV4X4Y/5G3SP+vyP/ANCFe6fFj/knGp/70P8A6NSvC/DH/I26R/1+R/8AoQr1cH/u 0/mYz+NH1PmikHelryzVhWV4m/5FjVf+vSX/ANBNatZXib/kWNV/69Jf/QTTj8S9Q6HyqP8AUj/d r6u0P/kX9N/69Yv/AEAV8oj/AFI/3a+rdD/5F/Tf+vWL/wBAFenmW0fmYUNn8v1NKiiivLN2Iehr 5u+JP/JQdW/30/8AQFr6RPQ183fEjn4hav7On/oC125ev3z9DOt8J6B8FD/xTupD/p8H/oApnxi1 5YNNtdFif97dMJZgD91F6fmT+lc34C8b6b4S8NailwJJrySfzIrdFxuG0DJboBXEapql3rep3Go3 8haeVtxJ6KOygewrojh5SxMqjWhLklBIv+EdHbXfFmnafg7GkEspHaNPmP6gD8a+n1HAOMe1eZfC Pwu+nabNrN3FtnvAFhUjlYhyPzOT9MV6cOgrlxtXnq2WyLpxtG4tFFFcZZTvruKw0+4vJziK3RpG +gGa+U7q6kvLme8mJMkzmVs+pOa9y+L2t/YfCa2EcmJb9wh29fLH3v6V41oemPrWvWWmoCWuJlU4 7KOWP/fINerl8VCnKozGq7yUUe+fDfSv7L8D6dGyhZJ1+0vjqd53DP4EV11RwRRwRJHGAERQigeg GB+lS15kpOUnJm1rKwUUUUgQUUUUCCiiikAUUUUx2CiiigQUUUUAFFFFA7BRRRQIKKKKQBRRRQAU UUUwCiiikAUYoooHYKKKKAYUUUUxBRRRQOwUUUUgCiiimIKKKKBhRRRQIKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigdgooooBhRRRSEFFFFMAooooGFFFFAgooooAKKKKACiiigAooooAKK KKACiiigAooooAKKKKQBRRRTAKKKKACiiigdgooopCCiiigdgooophYKKKKBBRRRQAUUUUDCiiik IKKKKYBRRRQMD0qhq3/IEv8A/r3f/wBBNXz0qhq3/IEv/wDr3f8A9BNIcdz5QH+rP0r6i8H/APIl aF/2D4P/AEAV8uj/AFZ+lfUXg/8A5ErQv+wfB/6AK9bMvhj6nNhzc70Ud6K8o6GIeh+lfMnjz/kf de/6+z/6CtfTZ6H6V8yePP8Akfde/wCvs/8AoK13Zd/Ffp+plW+E9W+Df/Imzf8AX29ehr2rzz4N /wDImzf9fb16GvQVzYr+LL1Lp/Cj5t+I3/JRdb/66R/+ikr0b4Kf8i9qX/X0P/QRXnPxH/5KNrf/ AF1j/wDRSV6N8E/+Re1H/r6H/oIr0cR/usfkZx/iHp4GKKKK8g2YV4p8bv8AkM6V/wBez/8AoVe1 14p8bv8AkM6V/wBez/8AoVdeC/jr5/kRU+B/L8yl8GP+Rzu/+vJv/Q1r3cdBXhHwZ/5HS7/68W/9 DWvdx0FPH/xvkiaXw/eLTT0/GnU09PxrjNUed/GX/kS4v+vuP+tebfDH/kpGj/703/ol69J+Mv8A yJcP/X3H/WvNvhj/AMlI0f8A3pv/AES9erh/90l8zF/xUfSNFFFeUbhRRRQAUUUUAFFFFABRRRQA UUUUAFFFFAHFfFj/AJJxqf8AvQ/+jUrwvwz/AMjbpH/X5H/6EK90+K//ACTjU/8Aeh/9GpXhfhj/ AJG3SP8Ar8j/APQq9XB/7tP5mM/jR9Tev1paQd/rS15RqwrK8Tf8ivqv/XpL/wCgmtWsnxN/yK+r H/p0l/8AQTVR+JeodD5WH+pH0r6u0P8A5F/Tf+vWL/0AV8o/8sB9BX1dof8AyL+m/wDXrF/6AK9P Mto/MwobP5GjRRRXlG73GuSEJHYV4H8SfDWtf8JZfammmTSWc5UrLEN3RQDkDkdK9+pMc1tQrujL mSFOPMrHyfbaZqN3MIrbTruZycBRA39cV6T4O+FNy11Ff+JUWONSGSyzkse28jj8K9n/ABNGPSt6 uOqTVo6ERpJasjRdihVUKqj5QOgqQZIBNGKWuI1YU0nA5of/AD7VwfxO8VDQNBNlbyf8TG9UpEV6 ovd/6VcIOclFCdoq7PKviF4gHiLxdcyxPutLT/R4Dng4PzN+Jrqvg5oRkvrvXpUysQ+z25I/iIy5 H4ECvMrSznvr2GztEMlxO4iiUep9a+oPDmjQeH9CtdMt/uwJhm7s3cn6mvTxclSoqlHqYU05S5zT AwB6dqf6UYoryUdDCiiimIKKKKBBRRRQAUUUUDuFFFFAgooooAKKKKB3CiiigQUUUUgCiiimAUUU UAFFFFABRRRQO4UUUUhBRRRQAUUUUx3CiiigQUUUUAFFFFAwooooEFFFFABRRRQAUUUUAFFFFIAo oooAKKKKYBRRRQAUUUUDuFFFFABRRRQIKKKKACiiigYUUUUCCiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooHcKKKKBBRRRSHcKKKKYXCiiikIKKKKYBRRRQMKKKKBBRRR QAUUUUDCqGr/APIEv/8Ar3f/ANBNXz0qhq3/ACBL/wD693/9BNLqOO58oD/Vn6V9ReD/APkStC/7 B8H/AKAK+XR/qz9K+ovB/wDyJWhf9g+D/wBAFetmXwx9Tmw5ud6KO9FeUdDEPQ/SvmTx5/yPuvf9 fZ/9BWvps9D9K+ZPHn/I+69/19n/ANBWu7Lv4r9P1Mq3wnqvwb/5E6b/AK+3r0Regrzv4Of8idN/ 19vXoi9BXNiv4svUun8KPm34j/8AJRtb/wCusf8A6KSvRvgmf+Ke1L/r6H/oIrzn4jf8lF1v/rpH /wCikr0X4Kf8i/qX/X0P/QRXo4j/AHWPyM4/xD1CikWlryDZhXinxu/5DOlf9ez/APoVe114p8bv +QzpX/Xs/wD6FXXgv46+f5EVPgfy/MpfBg/8Vpd/9eTf+hrXu46CvCPgyP8AitLv/rxb/wBDWvdx 0FPH/wAb5Iml8P3i009Pxp1NboPrXGao87+M3/Ilw/8AX3H/AFrzb4Yj/i5Wj/703/ol69J+M3/I lw/9fcf9a82+GP8AyUnR/wDem/8ARL16uH/3SXzMX/FR9I0UUV5RuFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAcV8V/8AknGp/wC9D/6NSvC/DH/I2aR/1+R/+hCvdPix/wAk41P/AHof/RqV4X4Y/wCR s0j/AK/I/wD0IV6uD/3afzMZ/Gj6mHf60tA70V5RqwrK8Tf8ivqv/XpL/wCgmtWsrxN/yLGq/wDX pL/6CaqPxL1DofKo/wBSPpX1dof/ACL2m/8AXrF/6AK+UR/qB/u19XaH/wAi9pv/AF6xf+gCvTzL aPz/AEMKGz+X6mjRRRXlm7CiiigQUUUUAFMLHOMU+mMPlI7UikYviXxHZeG9Ikvr6VUwMRxj70jd lAr5x1zWrvX9Yn1C8b95IflQdI07KK1PH91qsvi+/t9UuGlNvIVhTPyqh5GB9KqeFINGuPENtHrt x5NiGBYEcMeysewr2cLRjRp+0erOabcnZbHo3wk8IGFD4kv4sNKpWzRh91e749T2r1lQRnjrUUPl iNRCFEYA8sLjbt7YxxipgeK8qrUdSTkzoUVFWQ6iiioEFFFFABRRRSAKKKKACiiimAUUUUAFFFFI AooopgFFFFABRRRSAKKKKYBRRRSAKKKKACiiimAUUUUAFFFFABRRRQAUUUUAFFFFIAooopgFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRSAKKKKACiiimAUUUUgCiiimAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFIAo oopgFFFFABRRRQAUUUUAFFFFABVDVv8AkC3/AP17v/6Cav1Q1f8A5At//wBe7/8AoJpdSonygP8A Vn/PavqLwd/yJOg/9g+D/wBAFfLo/wBWfpX1F4P/AORK0L/sHwf+gCvWzL4Y+pzUP8jc70Ud6K8o 6GI3Q18yeO/+R917/r6P/oK19Nt0NfMnjv8A5HzXv+vo/wDoK13Zd/Ffp+plX+E9W+DmP+EOm/6+ 3r0Negrzv4Of8idN/wBfb16IvaubFfxZepdP4UfNvxG/5KLrf/XSP/0Ulei/BT/kXtS/6+h/6CK8 6+I3/JRdb/66R/8AopK9G+Cf/Ivaj/19D/0EV6OI/wB0XyM4/GenAYpaKK8g2YV4p8bv+QxpX/Xs /wD6FXtdeKfG4/8AE50r/r2f/wBCrrwX8dfMip8D+X5lL4M/8jpd/wDXi3/oa17uOgrwj4M/8jpe H/pxb/0Na94HSnj/AON8kTS+H7wpp6fjTqaen41xmqPO/jL/AMiXD/19x/1rzb4Y/wDJSNH/AN6b /wBEvXpPxl/5EuH/AK+4/wCtebfDH/kpOj/703/ol69XD/7pL5mL/io+kaKKK8o3CiiigAooooAK KKKACiiigAooooAKKKKAOK+LH/JONT/3of8A0aleF+GP+Rt0j/r8j/8AQhXunxX/AOScan/vQ/8A o1K8K8Mf8jZpH/X5H/6EK9XB/wC7T+ZjP40fVA70Udz9aK8o2aCsrxN/yLGq/wDXpL/6Ca1ayvE3 /Isar/16S/8AoJqo/EvUT2PlUf6kf7or6u0P/kXtN/69Yv8A0AV8oj/U/hX1bof/ACL+m/8AXrF/ 6AK9PMto/MwobP5fqaVFFFeWb2CiiigLBRRRQIKYwPOOtPpMc5pFI898cfDYeKL4albXq294IhHt ZMq+CSMnqOteLazomoaDfvYalAYpsHB5KuPUHuK+qSvHTNcz408KweKtFktiqpeR5e3mPVW64z6G u3DYuVO0ZfCZTpKWx5x8LvHL6feReH9Sl3Wcx22krH/VP/cPse3pXty18jyRyQSvFMrRSxMVcfxI 49PpX0b8PvEZ8R+Fbe4mbN5ATBcD1YDhvxBBq8dQUbVY7MVKbfus62imqc8mnV56NbBRRRTBBRRR QIKKKKQBRRRTHYKKKKQgooooAKKKKYBRRRSAKKKKYBRRRQOwUUUUgCiiigQUUUUxhRRRQAUUUUCC iiigYUUUUAFFFFAgooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKB2CiiigQUUUUAFFFFAB RRRSAKKKKYBRRRQMKKKKBBRRRQMKKKKACiiigLBRRRQIKKKKACiiigAooooAKKKKQ7BRRRQIKKKK YBRRRQAUUUUAFFFFIAooopjsFFFFAgooooAKKKKBhRRRQIKKKKACiiigaCqOr/8AIEv/APr3f/0E 1e7VQ1b/AJAt/wD9e7/+gml1KjufKA/1Z+lfUXg//kStC/7B8H/oAr5dH+rP0r6i8H/8iVoX/YPg /wDQBXrZl8MfU5cObneiiivKOiwh6H6V8yePP+R917/r7P8A6CtfTZ6H6V8yeOv+R917/r6P/oK1 35d/Ffp+plX+E9V+Df8AyJ03/X29eiLXnnwc/wCROm/6+3r0NegrlxX8WXqXT+FHzb8Rv+Si63/1 0j/9FJXo3wT/AORe1H/r7/8AZRXnPxG/5KLrf/XSP/0Ulei/BT/kX9S/6+R/6CK9HEf7ovkZx/iH qFFIOlLXkGzCvFPjf/yGdK/69n/9Cr2uvFPjf/yGdK/69n/9CrqwX8dEVPgfy/MpfBn/AJHO7/68 W/8AQ1r3gdK8H+DI/wCK0u/+vFv/AENa94HSqx/8b5Iml8P3hTT0/GnU09PxrjNUed/Gb/kS4f8A r7j/AK15t8MT/wAXK0f/AHpv/RL16T8Zf+RLh/6+4/615t8Mf+SkaP8A703/AKJevVw/+6S+Zi/4 qPpGiiivKNwooooAKKKKACiiigAooooAKKKKACiiigDivix/yTjU/wDeh/8ARqV4X4Y/5GzSP+vy P/0IV7p8WP8AknGp/wC9D/6NSvC/DH/I2aR/1+R/+hCvVwf+7T+ZjP40fU/c0UDv9aK8s1YVleJv +RY1X/r0l/8AQTWrWV4m/wCRY1X/AK9Jf/QTTj8S9Qex8qj/AFI+lfV2h8eH9N/69Yv/AEAV8oj/ AFA+gr6u0P8A5AGnf9esX/oAr08y2j8/0MKGz+X6mjRRRXlm7CiiigQUUUUAFFFFAxCM0mOPpTqP akM8E+LmhLp3iSLU4UCw6kuXx2kXGT+II/Km/CPWDYeK2052xFfxkAdvMUE/yGK9D+K2l/2j4JuJ 0QGWydbgHH8I+9+h/SvCNNvW03VLO9jJzb3CS8cEgMM/pmvXoP22GcOu3+RzS9ypzf15n1cvUU+o bedLm3iuIzlJVDqfYjIqavIOhhRRRTEFFFFABRRRSAKKKKYwooooEFFFFABRRRQAUUUUgCiiigAo oopjCiiigQUUUUgCiiimAUUUUAFFFFIAooopgFFFFABRRRQAUUUUAFFFFIAooopgFFFFABRRRQAU UUUAFFFFABRRRQAUUUUAFFFFIAooopgFFFFIAooopgFFFFABRRRQAUUUUgCiiimAUUUUDCiiigQU UUUAFFFFIAooooAKKKKYwooooEFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAVQ1f/kCX/8A17v/AOgmr5qhq3/IEv8A/r3f/wBBNHUqJ8oD/Vn6V9ReD/8AkStC/wCw fB/6AK+XR/qz9K+ovB//ACJWhf8AYPg/9AFermXwxObDm53oo70V5R0CHoa+ZPHX/I+69/19H/0F a+mz0P0r5k8d/wDI+69/19H/ANBWu/Lv4r9P1Mq/wnq3wc/5E6b/AK+3r0Na88+Df/InTf8AX29e hr2+tcuK/iy9S6fwo+bfiN/yUXW/+ukf/opK9F+Cn/Iv6l/19D/0EV518Rv+Si63/wBdI/8A0Ule i/BT/kX9S/6+h/6CK9HEf7ovkZx/iHp4paQUteQbMK8U+N3/ACGNK/69n/8AQq9rrxT43f8AIZ0r /r2f/wBCrrwX8dfMip8D+X5lL4M/8jnd/wDXi3/oa17uOleE/Bj/AJHO7/68m/8AQ1r3YdKrH/xv uFS+H7xaaen406mnp+NcRojzv4y/8iVF/wBfcf8AWvNvhj/yUjR/rN/6JevSvjL/AMiXF/19x/1r zX4Y/wDJSNH/AN6b/wBEvXrYf/dJfMwl/FPpGiiivJOgKKKKACiiigAooooAKKKKACiiigAooooA 4r4r/wDJONT/AN6H/wBGpXhfhg/8VZpH/X5H/wChCvdPiv8A8k41P/eh/wDRqV4Z4YH/ABVmj/8A X5H/AOhCvVwf+7T+ZjP40fUo7/WloHeivLNWFZXib/kWNV/69Jf/AEE1q1leJv8AkWNV/wCvSX/0 E04/EvUOh8qj/UD6A19XaH/yL+m/9esX/oAr5RH+p/4CK+rtD/5F/Tf+vWL/ANAFenmW0fn+hhQ2 fy/U0BS0UV5Rv1Eboa8v+JPjXWvC+s2drpjwiOWAyN5ke7J3Yr1BvumvD/jWf+Kl03/r0P8A6Ea6 cJCM6qjJXJqNqDaKlr8YvEkEhNxDZXK/3ShjP5iu98MfFLR9dlitLtW0+9fokhBRj6Bv8a8c8OeG L3xTcXNvYPEs0EPnBZTgONwGM/jWXd2dzY3UtlewvDPExV0YYIPt/jXoywlCbcI6MxjUnu9j6zDB uM9uKcAcDP415l8KfGM2q2r6Nfyb7q2XdFI7cyJ6fUV6aDkA15FSm6cnFm6d1cWiiioGinqFot/p 1xaOPknjaNvoRivlGWJopJYH4ZGZD+BIr63IyODivmPxraLYeN9Yt41wguC6j2YBv616WWy96UTG utme7+AdQOpeBtJnY5ZYRCT7plP6V04rzb4MXnneFbi0P/LtdHAz0DfN/jXpI71xVo8tWSXc0i7x TFooorMYUUUUAFFFFIAooopgFFFFABRRRQAUUUUAFFFFIAooopgFFFFABRRRSAKKKKACiiimAUUU UDCiiikIKKKKACiiimAUUUUAFFFFABRRRSAKKKKACiiimAUUUUAFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQNBRRRQDCiiigQUUUUAFFFFABRRRSAKKKKYBRRRQAUUU UgCiiimAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFIAooopgFFFFAAelUNW/5Al//wBe 7/8AoJq+elUNW/5Al/8A9e7/APoJpdSonygP9WfpX1F4P/5ErQv+wfB/6AK+XR/qz9K+ovB//Ila F/2D4P8A0AV62ZfDH1ObDm53oo70V5R0MQ9D9K+ZPHf/ACPuvf8AX0f/AEFa+mz0P0r5k8d/8j7r 3/X0f/QVrvy7+K/T9TKv8J6t8G/+ROm/6+3r0Ne1eefBv/kTpv8Ar7evQ1rlxX8WXqXT+FHzb8Rv +Si63/10j/8ARSV6N8FP+Re1L/r6H/oIrzn4j/8AJRtb/wCusf8A6KSvRvgn/wAi9qP/AF9D/wBB FejiP90XyM4/GenAUtFFeQbMK8U+N3/IZ0r/AK9n/wDQq9rrxT43f8hjSv8Ar2f/ANCrrwP8dfMi p8D+X5lL4Mf8jnd/9eTf+hrXu46CvCPgx/yOd3/15N/6Gte7joKrH/xvkiaXw/eLTW6D606mt0H1 riNUed/Gb/kS4f8Ar8j/AK15t8MT/wAXJ0f6zf8Aol69J+Mv/Ilw/wDX3H/WvNvhj/yUnRz/ALU3 /ol69XD/AO6S+Zi/4qPpGiiivKNwooooAKKKKACiiigAooooAKKKKACiiigDivix/wAk41P/AHof /RqV4X4Y/wCRs0j/AK/I/wD0IV7p8WP+Scan/vQ/+jUrwvwwP+Ks0j/r8j/9CFerg/8Adp/Mxn8a PqfuaKO5+tFeUasKyvE3/Isar/16S/8AoJrVrK8Tf8ixqv8A16S/+gmqj8S9Q6HyqP8AVfhX1boX /Ivab/16xf8AoAr5SH+pH0r6u0P/AJF/Tf8Ar1i/9AFenmW0fmYUNn8v1NGiiivKN+oh6GvD/jX/ AMjJp3/Xmf8A0M17gehrw/41/wDIyab/ANeh/wDQzXZgf4yIq/A/66ifBbP/AAkuo8nJsuP++1ro vi94eiuNEi1qGIC4tHCSED70ZOMn6Guf+Cv/ACMuof8AXl/7Oteq+LbUXng/WICOHs5R+O04q8RN wxfMvIUdYWPnTwxqr6J4o06/Q48uZUb3VjtbP519SjHbp2r5EJOzI4PFfVuhz/atB06f/npbRv8A moNaZjHWMhUdrF+iiivNNUNPSvn34tWn2bx5JIP+Xm2jmPtyV/8AZa+hK8P+NUQTxNp8+Pv2m3P+ 6xP9a7MA7V7GdbWJd+CFxtm1q1PVvKlH4Bga9iFeG/BabHiq8i/56WRb/vl1/wDiq9zFRjVavIKb vBBRRRXMWFFFFABRRRSAKKKKACiiimAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAwoo ooBhRRRQIKKKKBoKKKKACiiikIKKKKYBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUgCiiimAUUUUAFFF FIAooooAKKKKY7BRRRQIKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAPSqGrf8gS/wD+ vd//AEE1fqhq/wDyBL//AK93/wDQTS6lRPlAf6s/SvqLwf8A8iVoX/YPg/8AQBXy6P8AVn6V9ReD /wDkStC/7B8H/oAr1sy+GPqc2HNzvRRRXlHSIehr5k8ef8j7r3/X2f8A0Fa+mz0P0r5k8ef8j7r3 /X2f/QVruy7+K/T9TGt8J6t8G/8AkTZv+vt69DWvPPg3/wAibN/19vXoa1zYr+LL1Lp/Cj5t+I// ACUbW/8ArrH/AOikr0b4KH/in9R/6+h/6CK85+I//JRtb/66x/8AopK9F+Cn/IA1L/r5H/oIr0cR /ui+RnH+IeoUUg6UteQbMDXinxu/5DOlf9ez/wDoVe114p8bv+QxpX/Xs/8A6FXXgv46+f5EVPgf y/Mp/Bn/AJHS7/68m/8AQ1r3YdBXhPwZ/wCRzu/+vJv/AENa92HQVWP/AI3yRNL4fvFprdB9adTW 6D61xGqPPPjL/wAiXF/19x/1rzX4Yf8AJSNH/wB6f/0S9ek/Gb/kS4f+vuP+tebfDH/kpGj/AO9N /wCiXr1cP/ukvmYv+Kj6RoooryjcKKKKACiiigAooooAKKKKACiiigAooooA4r4r/wDJONT/AN6H /wBGpXhnhc/8VZpH/X5H/wChV7n8WP8AknGp/wC9D/6NSvC/DH/I2aR/1+R/+hCvVwf+7T+ZjP40 fU470UDvRXlGrCsrxN/yLGq/9ekv/oJrVrK8Tf8AIsar/wBekv8A6CaqPxL1DofKo/1A+gr6u0T/ AJF/Tf8Ar1i/9AFfKI/1A+gr6t0T/kX9N/69Yv8A0AV6eZbR+ZhQ2fy/U0hRSClryzdiHoa8P+Nf /Iyad/15n/0M17gehrw/41/8jJp3/Xmf/QjXXgf4yJq/A/66h8Ff+Rk1D/ry/wDZ1r2LWAG0O/BH H2aT/wBBNeO/BX/kZNQ/68v/AGda9j1f/kCX/wD17Sf+gmljf94+4VP4T5P6LX1J4QYt4M0Jick6 fAT/AN8Cvlv+H8K+o/B3/Ik6D/2D4P8A0WK7Mx+CPqZ0tzboooryTdBXjvxvgAn0a4weRInH0Br2 KvJvjjj7DoZ7/aJB/wCOCunBu1eJFX4Gc18HZAnjth/esZVH/fSH+le+jpXzx8KGCfEG0y2N8Mqg evT/AAr6HFaY9fvvkTS+EWiiiuI0CiiigAooopAFFFFMAooooAKKKKACiiigAooooAKKaWAGT0pQ wOMHr0pDsLRTQwPQ06mAUUUmRQIWim7hRuAoAdRSZpaACiiigAopCQO9JvXOM80gHUUgYEZBpc0x hRRRQIKKTIo3DOM0DsLRSZFLQAUUUUhBRRRTAKKKKACiiigAooooAKKKKACiiigbCiikyKBC0UmR 17UoOaBhRRRQIKKKKACiiigYUUUUAwooooEFFFFABRSE460Z5xQAtFJmjIoAWikyPWlpAFFFFMAo pMijIPQ0DFopNwoyD3oAWiiigQUUUUAFFISB1oDA0h2FopM0tMAooyM4pMikAtFGaTIpgLRSZFG4 ZxQNoWikzmloJCiiigAooooAKKKKQBRRRTAKKKKACqGr/wDIEv8A/r3f/wBBNXz0qhq3/IEv/wDr 3f8A9BNHUqJ8oD/Vn6V9ReD/APkStC/7B8H/AKAK+XR/qz9K+ovB/wDyJWhf9g+D/wBAFermXwxO bDm53oo70V5R0MQ9DXzJ48/5H3Xv+vs/+grX023Q18yeO/8Akfde/wCvo/8AoK13Zd/Ffp+plX+E 9W+Df/Imzf8AX29ehrXnnwb/AORNm/6+3r0NegrmxX8WXqXT+FHzb8R/+Sja3/11j/8ARSV6N8FP +Re1L/r6H/oIrzn4j/8AJRtb/wCusf8A6KSvRvgmf+Ke1L/r6H/oIr0cR/ukfkZx+M9OFLRnNFeQ bMK8U+N3/IY0r/r2f/0Kva68U+N3/IZ0r/r2f/0KuvBfx18/yIqfA/l+ZR+DP/I6Xf8A14t/6Gte 8DoK8I+DP/I6Xn/Xi3/oa17uOgp4/wDjfJE0vh+8Wmnp+NOpp6fjXGao87+Mv/Ilw/8AX3H/AFrz b4Y/8lI0f/em/wDRL16T8Zv+RLh/6/I/615t8Mf+Sk6P/vTf+iXr1cP/ALpL5mL/AIqPpGiiivKN wooooAKKKKACiiigAooooAKKKKACiiigDivix/yTjU/96H/0aleF+GP+Rs0j/r8j/wDQhXunxX/5 Jxqf+9D/AOjUrwvwx/yNmkf9fkf/AKEK9XB/7tP5mM/jR9TjvRQO9FeWasKyvE3/ACK2qn/p0l/9 BNatZXib/kV9V/69Jf8A0E04/EvUOh8qj/Uj/dFfV2h/8i/pv/XrF/6AK+UR/qf+A19XaH/yL+m/ 9esX/oAr08y2j8/0MKGz+X6mjRRRXlG/UQ9DXh/xr/5GTTf+vQ/+hGvcD0NeH/Gv/kZNN/68z/6G a7MD/GRFX4H/AF1D4K/8jJqH/Xl/7Otex6v/AMgS/wD+vaT/ANBNeOfBX/kZNQ/68v8A2da9j1f/ AJAt/wD9e0n/AKCaWN/3h/IKfwnyf/D+FfUfg7/kSdB/7B8H/osV8ufwD6V9R+Dv+RI0H/sHwf8A osV2Zj8EfUzpb/I26KKK8k2CvJvjl/x4aH/18S/+gV6zXk/xxVjp2isOguJM/wDfFb4X+PEmp8DO K+GHHxD07/dk/wDQa+jRXzj8MiB8QtNPqJB/47X0aOlbY/8Air0Jo/C/X9ELRRRXEaBRRRSAKKKK ACiiimAUUUUgCiiigAooopgFNbkEU6kNIaMTxF4itvD2mm6uBuPREB5Y1x1h8UfMv44r3T/JgdsB w+ce/QVn/Fi4cavY25ZvL+z79nbO5hmvPMk5B6elcdWvKM+WJ9blmTUa2FVSpvL8D6ahkSZI5FYM rDcrD0qaub8CSPN4K0qSRy7mI5Y/7xFdJXXF3SZ8viKfsqkqfZtfcwpjdMmn1XvZlt7WSdvuxIzn 8BmmzJLXQ5zxP40sfDarC4Mtw/IjU4wPf865ex+K7NcKL/S0hhJwZFnLbfqNorgdY1R9T1i6vS7M XclCey54qjkgnPO771cMsRPm0PtsNkOH9ivaq8n+B9K2V5Ff20dxbsHikAKsO9Wq8v8AhXq5b7Xp jyM20CSNT0VeAQPxNemrmuunPmjc+TxuFeGrypPoPooorQ5SKaQRoXYhVXkk9AO9ec6v8Uktb5rf TrFbpEbBdpdoP6Guj8f3TWfhK6kVipbEfHvxXhBBAUE5BywrkxFWUGlE+jyTK6WKhKrW1S0R7x4W 8XW3iW3bYnk3Mf34ic4+nrXSqO5r510LWJdE1m3vlLbUbEgX+Je9fQtrMk9vHNG2UdQwPrWlGrzr Xc5M3y/6nVXJ8L2J6KKK3PHZh+I9et/D1g13cYYdETP3mzjFcfpfxRW81GO3vNPFvE+MSb84+owK g+Lc7CbT4M5XBfHvnFeZnDEs4yDkn8646taUZ2R9VleUUMRhfaVN3c+mkcMMqc5GRUo6Vk+Hnafw /Yys253hBLEda1RXWtdT5iceWTj2FooooIYUUUUCCiiimAUUxiQ3DY+tNJYjqf8AgNA7EtFVp7mG 3TM06Rj1dwv865XWPiFpGlh0ima7nU42RHI+u7pUOcVuzWlh6tZ8tNXZ2dFeHap8Rdevpi8MrWUP 8KRH5vxJz/KvV/Ct3Pe+FNNubiVpZpbdWd26sfWphVjN2R2YvK6+FpxqVeuhtUUUVqedYQ9KYxwu cZqQ9K5nx1cm18IX8sblJcKEZTgg7h0/DNTJ2VzSjB1JqmursdAkqNwGBPpUuOa+crTxHrdimy11 a7ijPJAYHJPU8irY8Z+Isf8AIavT/wACH+Fc/wBaj1Pflw5ib+7JH0HRXz5/wmniP/oM3n/fY/wp P+Ez8R/9Bi8/77H+FH1qBP8Aq1iv5kfQlFfPn/CaeI/+gxef99j/AAoPjPxH21m8/wC+x/hR9agH +rWK/mR9B0V5j8NNd1bVtUvkv724uIo4FK+YwIDljnt6V6aK3hPnV0eNi8NLDVXRm9ULRRRVHMFF FFMAooqMtxn3xSGkK5wAT17Vzer+N9F0iYwzXBkn/wCecI3EfyrjvHnjaaa5k0jTJdiocTSqep/u ivOAMMSc+5z1/GuariOXSJ9Jl2ROtFVK7sn06nrbfFnSQ/Fpecf7I/xrQsPiToF7MsbyS27n/nso UfnmvFOP/wBdIQRjIOD1461ksTNbnqz4ewjjo2mfTEM6ToskTI6N0Ydx7VYrwbwl4rudA1BUd2ey kYKUJ4Qeor3GGdbiJJYnBRwCCD+tddOopq58tmGXVMHU5Zap7MsVHIwVSc9KC2D1PT6CvJ/H/jCa e6k0mwmdIYv9ZKh+8392ipNQV2Z4LB1MXVVOB1eq/EPQ9MkaJZftMw/hhAP65rIi+LVgZcPp06Ln k5Bx+FeUIW2PtOAetG4BhjaTXE8TK+x9ZT4ewqjaTbZ75ovjDR9bZltLkiTjKuMEZ9K38kqM4z61 8zxSywzCeN2jlU5V1PT6V7J4D8W/27am0uzi8gHUn/WD1roo1+d2Z42a5M8LH2tN3j18juKKBRXS fPhRTWOBmopZhDE8jkKqjJJPSlcpIyPEPiWy8PQLNdlmLnCIvUmofDni2w8R7xbho54/vxt1x6j1 ryTxhrza7r0kyljDEdkQbsP/ANZNWPh/cPF4xtQjFfMyjY7g9q5FiG58q2Ppf7DUMC6s9J2ue6jm nUxRjoeBT66z5oQ479axdU8S6XoZ23tysbf3RycfStaZ1RCzHAA61846neyajqlzeSOW8x8gsein pisatXkR62VZd9dnJSdkj2QfEjw0f+XuT/v2aP8AhY/hr/n8k/74NeHEDPWjPYVz/WZHvf6uYf8A mZ7j/wALH8M/8/sn/fBq1Y+OPD+pTCG3vl8w8AONufpXgilt3QHNSL5iMrIQShBU5waPrUiZcN0b Plk7n0yhyin1FPrJ8NXEl14a02ebPmPArNnrnFa1d0XdXPjqkeWTj2CiiimQFFFFABRRRQAUUUUA FFFFIAPSqGrf8gS//wCvd/8A0E1fqhq//IEv/wDr3f8A9BNNblRPlAf6s/SvqLwf/wAiVoX/AGD4 P/QBXy6P9WfpX1F4P/5ErQv+wfB/6AK9XMvhic2HNzvRR3oryjoYjdDXzH48/wCR817/AK+j/wCg rX043Q18yeO/+R817/r6P/oK13Zd/Ffp+plX+E9W+Df/ACJs3/X29ehr0FeefBv/AJE6b/r7evQ1 rmxX8WXqXT+FHzb8R/8Ako2t/wDXWP8A9FJXovwT/wCRe1L/AK+h/wCgivOviP8A8lG1v/rrH/6K SvRvgp/yL2pf9fQ/9BFejiP91j8jOPxnpwpaQUteQbMK8U+N3/IZ0r/r2f8A9Cr2uvFPjd/yGNK/ 69n/APQq6sF/HX9dCKnwP5fmUvgyf+K0u/8Arxb/ANDWvdx0FeEfBj/kdLv/AK8m/wDQlr3cdBVY /wDjfJE0vh+8Wmt0H1p1NPT8a4zVHnfxm/5EuH/r8j/rXm3wxP8AxcrRx/tTf+iXr0n4y/8AIlw/ 9fcf9a82+GP/ACUjR/8Aem/9EvXq4f8A3SXzMX/FR9I0UUV5RuFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAcV8WP+Scan/vQ/+jUrwvwx/wAjbo4/6fI//QhXunxX/wCScan/AL0P/o1K8L8MD/irNIPf 7ZH/AOhCvVwf+7T+ZjP40fU470UDvRXlmrCsrxN/yK+qn/p0l/8AQTWrWV4n/wCRW1b/AK9Jf/QT Tj8S9Q6HyqP9SP8Adr6u0Mf8U/pv/XrF/wCgCvlL/liP90V9W6H/AMi/pv8A16xf+gCvTzLaPzMK Gz+X6mjRRRXlm7EPQ14f8a/+Rk07/rzP/oRr3A9DXh/xr/5GTTf+vQ/+hmuvA/xkRV+B/wBdQ+Cv /Iy6h/15f+zrXsmqgto96o6m3kH/AI6a8b+Cv/Iyah/15f8As617Pf8A/INuv+uL/wAjSxv+8P5B T+E+Sx9z8K+ovBx/4onQh6afB/6LWvl4/wA819QeD+PBeif9g+D/ANFrXZmPwR9SKO5u0Ug6UteQ bMK8r+N3Oj6R/wBfL/8AoFeqV5X8bf8AkD6R/wBfL/8AoNdGF/jR9SJ/Czg/hnx8QNM/3n/9Br6P FfOHw0/5KBpf1f8A9Br6PFb5h/FXoTR+B+v6IWiiiuE0CiiigAooooAKKKKBoKKKKQgooooAKKKK YBQelFB6UgPHfi3geIrAf9Oh/wDQzXA7eQBXffFz/kZNP/68z/6Ga4P+IV5tf+Iz9Iyn/caXp+rP dvh7/wAiLpP/AFyb/wBCauorl/h7/wAiLpH/AFyb/wBCauor0Kfwo+Dx3+9Vf8T/ADYhOO1cp8Qd VOn+F7hYyRLPiND+I3fpmuqPf6V5J8VdQ86+s9NBOIgZj+ORU1pcsGzXK8P7fFwj03+488XC/KRn 5cKKcFO0Ekc54+lMYnaXHUCur8ZaAdE/skgAB7QRMfVgST+jCvOUW02ff1cTCFWFJ7yv+BS8Fah/ ZfiqymztjkbypMf3cZ/nivf0Jwc9c18yhjGRIp2srAg/Svofw9qI1PQ7S8yC0ka7vY9xXVhZbo+Z 4loWnCsuqszXooorrR8szjfid/yJsg9Z4/514jk/l0r274nf8ic//XeP+deIetcGK+M+54c/3R/4 n+SFDYIJGfXNeu/DHXTcae+kzlmktgDEx7oe31HNeRDB4rS0HVpdF1q3v4+RG2HXPVTwf0rOlPkl c7s0waxWGcOq1R9GBgcEdKdVazniu7aK4iOUkUMv41Zr00z85as7M8n+Ln/IR07/AK5n+debvnGP rXpHxc/5COnf9cz/ADrzd+n4mvOrfxD9AyT/AHKPzPobwuf+KZ04/wDTAVsL0zWN4W/5FjTf+vcV sr90V6Edj4Sv/Fl6v8x1FFFUYsKKKKQgooopgc94yv7rTfDt1c2cpjnRcqwUN39DXjlz4t8RXKKJ 9UnQY52KE/kK9+lVXyrjKsMEEcVCbS2C48qP/vmsalNze9j1cDjqWGg1OmpPufOlxd3t2N9zd3cy /wDTSVyPyzVfCI21cMBntivou60uwuITDLbRMDntXztMFE7hBhQTge1cdWk4Wbd7n1eVZjHF80Yw 5bDWYk5Jz9a9/wDBZ/4onR/U2qV8/n7tfQHgz/kSdG/69VrTC7s5OJf4EPX9DoKKKK7j4xiHkEVw XxQn2eGIohnM1yFGPZSefyrvT0NeXfFq5Ij0y3H3S7SfkpH9ayrO1NnoZRT58bTXn+Wp5ioJxnAH TNKQMdD9a7DwL4Rg8QNNc3wb7HC21QOjN35/KvQ0+H/hraANPU46HPWuOFCUlc+uxeeUMPVdJptr ex4XgDvSYHrXvH/CAeHP+gcn50f8K/8ADn/QOT86r6tPucn+smH/AJX+B4P+P6UMQoJJ6ckD0r2b XPC/hnQ9Jnv309QY1woz1J4H86898IaONd8TQxlALeNvNkHqM8D+dZyoyjJRvudtDNqdajOsotKJ 6b4D0Q6ToaPJGq3Ex3tjrjHANdcuckelMQBUAHAHAp6nNejGKirI+Er1pVqkqkt2OoooqjAKKKKA Cud8X6w2jeG7y6XIkI2RkdmI4roq85+LUrro9jCnSW4+YeuB/wDXrKrLlg2duAoqtiYU31Z5OSXf fJhixLMT1JNdJ4Q8Jy+Jbxw7iOzhOJCDy2egFcz1wByB6fWve/BGlrpXhezjIHmOvmO2OSWORn8C K4qEOeep9nnWNeFw/wC73ei8isnw58OpD5f2Mn/aMjE/zrzzxj4Nfw1Ik9q5kspPl+bJKHP8ule4 isHxZZre+Hb+FlGBCXB9CvP9K66lKMo7HyuBzKvSrpyk2nvfU+fiDypPByOlexfDTV5L3QTaylmk tTgMf7p6f1rxtciNeegFejfCSTbqmpRnO3y0x+Zrkw7amkfUZ7RjPBOXVWO+8U6p/ZHh26u1Pzhc Lz1J4/rXz80jStI7MWLsWYnqc16p8WLxk0+ytEJBeUyPjuoBH868q2lS6nr0JqsTK8rdjHh2go4Z 1OsmdV4J8JjxDdSyzki1hOGH944zgfmK9Hm8A+H5LcxpYpG2APMBOR70vw/s/sfhGzLcS3GZW+vT +QFdTjg56GuilTioK/U8HMsxrVMTJxk0k9PkfPvibQpfD+rvYkgxY3xO2eRzxn8qraLqsukaxb38 RJaNwMeoPB/SvSvixYB9Gtb5QM28mwnvhiP8K8lZeMjuePyrkqR5J6H1OXV1jcGvaat6M+mLW4W5 to5kBCSKGXPoalLe3euY8B3rXvhCydyS0eYiT/snFbOp6laaXaPc3swhiUZJJ6/T1rvjK8bnwlWg 4VZUktU7Fx5AFyR9favLviD4ySZG0jTZDkkieRWx+AP51meJviJdaskltpoe2tDx5nR2H9K4okbS uQM8lj1Nc1avf3Yn02VZLKMlWxC22X+YhPbGK6HwKf8AistPz/frnfeui8Df8jlp3+/XPT+NHv49 f7NUXkz3vHP1pelJ3FOr1D8zMbxRdfYvDeoXIzmOBmGK+eAu1dvJx+te5/Eac2/g+7Az+9/dnHuC f6V4aeSc881wYp3kkfZ8NU7UJzfV/l/w50Xh/wAE6l4ismu7SS2EasVIlYg5/Ktf/hVOuf8APay/ 7+H/AArtvhzCIfCFs2MGV3J/76IrrV6VtChBxTZ5+LzvF08ROEGrJtbHjZ+FOu44msv+/h/wq7pn wrv/ALUv9pTWwgVgcQsST9eK9ZwKMVaoU10OSee4ya5XJfcRW0CW1vHDGAEjUKo9hU1JS1seO3d6 hRRRQIKKKKYBRRRQAUUUUAFFFFABVDV/+QJf/wDXu/8A6Cav1Q1f/kCX/wD17v8A+gml1KifKA/1 Z+lfUXg//kStC/7B8H/oAr5dH+rP0r6i8H/8iVoX/YPg/wDQBXrZl8MfU5sObneijvRXlHQxG6Gv mTx3/wAj7r3/AF9H/wBBWvptuhr5j8ef8j5r3/X0f/QVruy7+K/T9TKv8J6v8G/+ROm/6+3r0Na8 8+Df/Imzf9fb16GvQVzYr+LL1Lp/Cj5t+I//ACUbW/8ArrH/AOikr0b4J/8AIvaj/wBff/sorzn4 jf8AJRtb/wCusf8A6KSvRvgn/wAi9qP/AF9/+yivRxH+6R+RnH+Ien0UUV5BswrxT43f8hjSv+vZ /wD0Kva68U+N3/IY0r/r2f8A9CrrwX8dfP8AIip8D+X5lL4M/wDI6Xf/AF4t/wChrXvA6V4P8Gf+ R0u/+vFv/Q1r3cdBTx/8b7iaXw/eLTT0/GnU09PxrjNUed/Gb/kS4f8Ar7j/AK15t8Mf+Sk6P/vT f+iXr0n4zf8AIlw/9fcf9a82+GP/ACUnR/8Aem/9EvXq4f8A3SXzMZfxEfSNFFFeUbhRRRQAUUUU AFFFFABRRRQAUUUUAFFFFAHFfFf/AJJxqf8AvQ/+jUrwvwv/AMjZpH/X5H/6FXunxY/5Jxqf+9D/ AOjUrwzwwP8AirNI/wCvyP8A9CFerg/92n8zGfxo+ph3ooHeivLNWFZXib/kWNV/69Jf/QTWrWV4 m/5FjVf+vSX/ANBNOPxL1DofKo/1A+gr6u0P/kX9N/69Yv8A0AV8oj/UD/dr6u0P/kXtN/69Yv8A 0AV6eZbR+ZhQ2fy/U0aKKK8s3Yh6GvD/AI1/8jJpv/Xof/QzXuB6GvD/AI1/8jJpv/Xof/QjXXgf 4yIq/A/66h8Ff+Rl1D/ry/8AZ1r2i9/5B9z/ANcm/ka8X+Cv/Iy6h/15f+zivaL3/kH3P/XJv5Gl jf8AeH8gp/CfJZ6H6mvp/wAHf8iXof8A2D4P/Ra18wHoT6Zr6f8AB/HgvQz/ANQ+D/0WtdmY/BH1 Io/E/Q3V+7S0i/dFLXkGzCvK/jb/AMgfSP8Ar5f/ANBr1SvK/jb/AMgfSP8Ar5f/ANBrowv8aPqR P4WcH8NP+R/0v6v/AOg19HivnD4af8j/AKX9X/8AQa+jx3+tb5h/FXoTQ+B+v6IWiiiuE0CiiigA ooooAKKKKBoKKKKBBRRRQAUUUUDuFB6UUHpSYjx34uf8jJp//Xmf/QzXB/xCu8+Ln/Iyaf8A9eZ/ 9DNcH/EK82v/ABGfpGU/7jS9P1Z7t8Pf+RF0j/rk3/oTV05rmPh7/wAiLpH/AFyb/wBCauoNehD4 UfB47/eqv+KX5siYhSSfunrXzz4l1BtS8QXt0Pus/H0HH9K9s8W6gdM8NX1xkBxGVj56sRxXgAJb jOTnJ9+5rlxUtOU+g4aoazrP0NbwvY/2l4nsLVlJQyKzgf3RjP8AOvTfibp5uvDK3CjL2sqnp2JU H9K5v4VWHnarfagfuwRiNcjru5/9lr03VrRb7S7u1fpLE6DjocHBq6ML0n5mOa4xwzGLX2Lf8E+c QNpr1r4U6is2lXGnk/NbvvHuG5/pXlM0XkyyRPkOjsjA9iGNdL8P9RGneLYAT8lxmEgngk4wa5qM +Woe7m9BYjByt01R7vRTQcnAp1elc/PTjfid/wAic/8A13j/AJ14h2r2/wCJ3/Inv/13j/nXiHY1 wYn4z7nhz/c36v8AJGjDpztok2qxAkW8yo/sCCc/pVPGCNoG3BGD7ivSPhzYw6l4c1ewmHySlVbj pkHmvPr6wuNO1CeynXEsLEEevoazlC0VM7cNi/aYirQlvF3Xp/wD074Xa99psZNImP723JaLJ6oe v616MK+cNE1abRtWtb+L/lk2GH95e4r6GtLyK8tYbiBg8Uqhlb2Irrw07xs+h8tnuC9jiPaRXuz1 +Z5j8XP+Qhp3/XM/zrzd+n4mvR/i4f8AiYad/uH+decP0H1Nctb+Iz6PJP8Acon0L4X/AORY07/r 3H9a2V+6KxvCw/4pjTf+uArZX7or0IbHwtf+LP1Y6iiirMWFFFFAgooooAKRvu0tI33aGUmRkZDV 8zycTP8AWvpns1fM0nMz/WuPF7I+p4Z+Kp8v1GN0r6A8Gf8AIk6N/wBeq14Afu17/wCDP+RJ0b/r 1Wowu7OriX+BD1/Q6Ciiiu8+LYHoa8c+KMrzeJLRERz5UGDtU4yT/wDXr2I8gioHs4ZG3PGjN6sg JrOrDnjynZl+L+qVlWte1zC8B6d/ZvhCyjIw8q+c49GYDNdLgUyKNYowigBR0AGMU4kgcCqirKxh WqurUlUe7dxaiY5JwM1Jk9cVzfjDXf7B0SedGAnkBSFf9o9/5UpNJXYUqcqs1CO7PPPiNr/9oasu mwMTDatliOjSY/wNdb8NNHFjoAvXA8y8w/I/h/h/Q15PpttLqerQWwJL3EwJbqf7xP5Aivoq1to7 W3igjAEcShEA7ADArno+/NzZ9FnHLhMNDBw9X5liloorrPmGwooooEFFFFABXJeO/D0viDR/LtgP tMDb0z346V1tNKZ7n8KiUeZWN6FaVGoqkN0eIaF4G1a+1iAXtk1vaowMrN/Fjnjmva4UEUKRgYVQ FA+lSbT/AHjigryDnp2qadJU1ZHTjcfUxklKfTsL2rnvGeoLp/hi9lJGWj8sD13EL/Wt7fg44x3J 7V4/8SvEq6jfR6XbMGgtzuldT1f+7+WDTqyUYtseWYWWJxMYrZav0OCUYVU9OK9G+EkTm+1OXadg hjUH33HP8688xj5scDmvbvh7pD6T4dTzlxPcOZGGOgwOP0riw0bzTPrM+rRhg3DrJ/8ABOP+LUmd csYx2tif/H688flHPsa7f4nSF/Fixn+CAAfic1xTDCY9Vqavxs6soXLgqfofSGjWwttKs4QP9XEB WgajRdsa4PYfyqTrXpdD86lq2zk/iPEZvBV4AM7SjH8DXhhYivoDxpH5nhDVB6W7t+QNeAbs/Ljt jNcOK+JH2fDT/wBnkuz/AEPWvhNP5ui3cJ/5Zyg4+uTWV8WJZhqNhEx/cBCw5/i4z/SrHwhbA1Yf 7UR+nBrs/Enhe18T2iRXDmJ4yTHIq5Kk9a1jFyo2R5letDC5tKpNaX/NHz+eI1JTr0IPJOa7/wAG +BWvZY9T1eJ0twf3cDjBc+re1dXonw20vSLgXM8j306nKtKuAD9BxXX7NuAD06e1TTw1vekbZjnv tIulhtE93/kfOWrgLrd8oUKBMwAHYdq1vA3/ACOOn/79ZOsf8hy//wCu7VreBv8AkcdP/wB+sI/x Pme/W/3B/wCH9D3vuKdTe4pcmvSPzo8/+LE4XQLe2yQ0k4fjuArD+oryFu+Bk84B+lekfFy5BvNM gB48uRm+uRj+debdT16152Il+8Pvchp8mCi+7b/r7j2m18RaL4X8NadBc3ALfZ1YRR/MxJGT09zW U/xbslf5NKuih/2lz/OvLWdz85f5gNuc4OKaDngEccnnrVfWJbRMqWQYfV1ryb87HuGj/ELRdYlS Dz3tbhjhY5R/XpXWBg/C88ZyO9fMoYhc5x7Dg16b8PPGUssy6TqM24sP3ErHBOP4a2pYjmdpHl5n kfsIOrQ1S3TPUAcjNLTVztGRzTq6j5kKKKKACiiigbCiiigQUUUUAFFFFABVDV/+QJf/APXB/wD0 E1fqhq//ACBb/wD693/9BNHUqJ8oD/Vn6V9ReD/+RK0L/sHwf+gCvl0f6s/SvqLwf/yJWhf9g+D/ ANAFermXwxObDm5RR3oryjpEPQ/SvmTx5/yPuvf9fZ/9BWvps9DXzJ47/wCR817/AK+j/wCgrXfl 38V+n6mNf4T1b4N/8ibN/wBfb16Gv9a87+DnHg6b/r7evRF7Vy4r+LL1NKfwo+bfiN/yUbW/+usf /opK9G+Cf/Ival/19D/0EV5z8Rv+Sja3/wBdY/8A0UlejfBP/kXtS/6+h/6CK9HEf7pH5GUfjPT6 KKK8g2YV4p8bv+QxpX/Xs/8A6FXtdeKfG7/kMaV/17P/AOhV14L+Ovn+RFT4H8vzKXwZ/wCRzu/+ vFv/AENa93HQV4R8GT/xWl3/ANeLf+hrXu46Cqx/8b5Iml8P3i009Pxp1Nbp+NcRqjzv4y/8iXD/ ANfkf9a82+GP/JSNH/3pv/RL16V8Zv8AkS4va8j/AK15r8Mf+SkaP9Zv/RL16uH/AN0l8zGX8VH0 jRRRXlG4UUUUAFFFFABRRRQAUUUUAFFFFABRRRQBxXxX/wCScan/AL0P/o1K8M8L/wDI2aR/1+R/ +hCvc/iv/wAk41P/AHof/RqV4X4YH/FWaR/1+R/+hCvVwf8Au0/mYz+NH1MO/wBaWgd6K8s1YVle Jv8AkWNV/wCvSX/0E1q1leJv+RY1X/r0l/8AQTTj8S9Q6HyqP9QP92vq7Q/+Rf03/r1i/wDQBXyi P9QPoK+rtD/5F/Tf+vWL/wBAFenmW0fmYUNn/Xc0aKKK8o36iHoa8P8AjX/yMmm/9eh/9CNe4N90 14f8bP8AkZNN/wCvQ/8AoZrswP8AGRFX4H/XUPgr/wAjLqH/AF5f+zrXtN0u+0nX1jYfpXi3wV/5 GTUP+vL/ANnWvbZP9S/+6aWO/jv5BT+E+R2HBHuR+tfTngxg/gvRD2+wwj/xwCvmNv4/95v5mvpr wT/yJGif9ekX/oIrszH4I+v6GdH4mdCKWkHf60teQbsK8r+Nv/IH0j/r5f8A9Br1SvK/jb/yBtI/ 6+X/APQa6ML/ABo+pE/hZwfw0/5KBpf1f/0Gvo8V84fDT/kf9L+r/wDoNfR471vmH8VehND4H6/o haKKK4TQKKKKACiiikAUUUUwCiiikAUmQO9LTG4AJxxQNIduAGSRRkeorC8R+I7Pw5aie6JLMcRx p1Y1haD8RLHWb5LOe3ktZZD+7J6H9al1Ip8rep1QwVedJ1Ywbiup3dB6U1e/NKelUcp498XP+Rk0 /wD68z/6Ga4P+IV3nxc/5GTT/wDrzP8A6Ga4P+IV5tf+Iz9Hyn/caXp+rPdvh9/yIuk/9cm/9Cau orlvh+P+KD0n/rk3/obV0xOFFehT+FHweO/3qr/if5s82+LGpBbez05H5kYysAegXGM/rXlanaQR 79K6bx1qX9peLLvulufKXHtXNxYDguCUBG7HXFefVlzTZ9zlND2GDiravU9o+G+nCz8JRyMu2S5Y yMSMZGfl/Q12JYADIzjj8686sfibo1jYwWyWF+RFGF+QJjgAd2qyfi1o2cHT7/8AKP8A+LrshUpx ilc+TxGX42tWlU9m9WzgvHWnDT/F12qoRHMRInGAQQM4/EmsGCZrS4iuI8+ZC4kXHXIOa6fxr4ks fEk9tPaQTRNFGYyJduTk57E1yobDe+a4alufQ+yy/wBo8LGNZWdrM+jtLvVvdOguo3VlliDhlOR+ daIOQK4L4YamLzw29m2N1pIUA/2cAj9Sa7tPu16UHzRTPz7F0HQrzpvozj/id/yJ7/8AXeP+deId jXt/xO/5E9/+u8f868Q7GuLE/H8j7Dhz/dH6v8kerfCfP2DUcdfMTn/vqoPijoWWg1m3UhgPLmwu cjsSfqasfCX/AJBmoj/pov8A7NXd6lYxajp89pMMpKu0+xxwa3jBTopHiYrEvC5rKqujX3WR83em Oh616t8L9eEtpJo88qmSH5ocnqnoPpxXmupWEulahcafOuHhkIz6+n6VJpOpy6NqlvqEI5gI3Afx DuK5KcnCep9PmGGjjMK1HXqjt/i3/wAhDTf+uZ/nXnL9PxNd98TbqK9fSLmE5SWIsD+NcA3T86db +I7EZKmsFFPzPoXwt/yLOnf9cBWyv3RWN4X48M6b/wBcBWyv3RXo09j4Ov8AxZerHUUUVRiwoooo EFFFFABSN900tIfu0mNDOzV8zS/65/rX0z2avmaX/XN9a5cX0PquGfiqfL9Rp6V7/wCDP+RI0b/r 1Wvn8/dNe/8Agz/kSdG/69VrPC7s6uJf4EPV/kdDRRRXefF3CiiigQUh6UtIelIaI5X8tCx7V4Z4 519tc1+VY5M2dsxSIq2VYj+L0x05r0nx9rp0bw/IsTYurg+Untnv+leIY2kL2GFNcmJqfYR9Xw9g rt4ma20X+Z2HwzsPtXiZriRWK2sJdQB/Efl/9mr2oAgAV538JLTbYahdkfM8wRT7bVP869IrXDxt TR5WeVnUxsvLQO1FFFbnkBRRRQAUUUUgCiiigYZppYYzuGPrSN0zXDePPFy6Pbmws2DX0o+YD+AV M5KKuzow2HniKipU92VPHHjhLGN9N02T/SWyHkU/c7dfWvJ33PISeWJ5p7O8jMWJd3O5natbw74f ufEOofZ4BiDO6WbsAOw9686c5VZWR95hcNRy6g3977l3wT4bk13V45HRvsls4aQlflb2z0r3NECD aBtGMD2qno+lWmjafFZ2cQSNABnuxA6mtE13UqSgj4zM8fLGVubZLZHiPxL/AORzfP8AzxWuNboP p/Su1+KMbL4vVuzwDH4GuKk+VCfSuCrpJn2+Vf7nT9D6eX7q/Sn1HEcordigqSvUPzgxPFpH/CJa tkgf6JL17/Ka+ee5I9a9+8cv5fg/Uif+eLD9DXgXTcPxrhxXxo+y4a/gTfmel/CL72rYHGY/5NXq a9BXmHwfH7vVyf78X8mr1Ada6KH8NHg52/8Abqny/JAaYeop5ph7Vszyz5x1j/kOX/8A13atXwN/ yOOn/wC/WVrH/Icv/wDru1angb/kctO/3682P8T5n6LW/wBwf+H9D3w0jZx06Gl7inV6R+dI8f8A itZyx6tZ3ZLeS8TKCV+VTkdT05/pXDWVlPqFzHa20TSTSEBVVc9TjJ9vU19GX+n22pReRdwpLEeq OMj61S0rw7peisz2FosLtwWyWJH1JOK5amHcp3voz6LB579Xwio8t5Lbsc/4c+H1jplqsl/bpd3h HzeYMqvsK1tQ8G6Hf2xhk0yCLOcSRKAyn8q6MdTTXGa35IpWseNPGV51Paym7+p89eJNAuPDmpva yfNC3+qkx94VmQyvBLBNC+2WJgyEHpXqvxVsRJottfY+aGTGfY8V5KK8+rDknofd5ZiXi8Ipz32Z 9G6DqiavolnfKy5miVmAPQ46H3rTrg/hfOZfCRiPSK5YD6fLXdJ9wGvRhK8Uz4PGUfY150+zY6ii irOUKKKKACiiikAUUUUAFFFFMAqhq/8AyBb/AP693/8AQTV+s/V/+QLfH/p3f/0E0dSonyiP9Wfp X1F4P/5ErQv+wfB/6AK+XR/qz9K+ovB//IlaF/2D4P8A0AV6uZfDE5sP+iNzvRR3oryjoYh6H6V8 yeO/+R917/r6P/oK19NnofpXzJ48/wCR917/AK+z/wCgrXfl38V+n6mVf4T1b4N/8ibN/wBfb16G vavPPg3/AMibN/19vXoa1y4r+LL1Lp/Cj5t+I3/JRdb/AOukf/opK9G+Cf8AyL2o/wDX0P8A0EV5 z8Rv+Si63/10j/8ARSV6L8FP+QBqX/XyP/QRXo4j/dF8jOP8Q9QopBS15BswrxT43f8AIY0r/r2f /wBCr2uvFPjd/wAhjSv+vZ//AEKuvBfx18/yIqfA/l+ZS+DP/I6Xn/Xi3/oa17uOgrwj4Mf8jndj /pyb/wBDWvdx0qsf/G+SFS+H7xaaen406mnp+NcRojzz4y/8iXF/19x/1rzX4Y/8lI0f/em/9EvX pPxm/wCRLh/6+4/615t8Mf8AkpGj/wC9N/6JevVw/wDukvmYy/iI+kaKKK8o3CiiigAooooAKKKK ACiiigAooooAKKKKAOK+K/8AyTjU/wDeh/8ARqV4X4YP/FWaR/1+R/8AoQr3T4sf8k41P/eh/wDR qV4X4Y/5G7R/+vyP/wBCFerg/wDdp/Mxn8aPqcdT9aKB1P1oryjVhWV4m/5FjVf+vSX/ANBNatZX ib/kWNV/69Jf/QTVR+JeodD5VH+oH+7X1doY/wCKe03/AK9Yv/QBXyiP9SP92vq7Q/8AkXtN/wCv WL/0AV6eZbR+ZhQ2fy/U0aKBRXlG7Eboa8P+Nf8AyMum/wDXof8A0I17gehrw/41/wDIyab/ANeZ /wDQzXXgf4yJqfA/66h8Ff8AkZNQ/wCvL/2da9tk/wBS/wDumvEvgr/yMmof9eX/ALOte2y/6l/9 00Y7+OxUvgPkdv4/95v5mvprwT/yJGif9ekX/oIr5lbguD2Zv5mvpnwR/wAiPontaR/+giuzMvgj 6/oZ0N2dEO/1paQd6WvIN2Bryv42/wDIH0j/AK+X/wDQa9TNeWfG3/kD6R/18v8A+g104X+NH1In 8LOD+Gn/ACUDS/q//oNfR6184fDX/koGl/V//Qa+jx1NbZh/FXoTQ+B+v6IWiiiuE0CiiigAoooo AKKKKBoKKKKBBTWwVOelOpr/AOrP0pDR4z8Up5f+EogjJ+SOBWQe5Jz/ACFcZDcvBcwTofnidWBP bkZrvPizblNWsbjHEkRQH1wR/jXnzAFSPVecV5tb+K2fomUKM8DBeR9K6fMLmxguFORLEr/mM1ZJ 4Ncx4B1JL7wraqZN0kCiJuOgHA/QV0xYcV6MHzRTPgK9N0qsoPo/1PH/AIs/N4jsc9rMj8d5rgyc c98V03j/AFKPUvFdx5Th44sIpH0BP65rmDghjngV5lV3mz9DyuDp4OnGXb/gnvHgAY8DaUvcRsP/ AB9q19YvI9P0q6u5G2rDGWNU/Ctu9p4Z063kUrIkXzKe2STXOfFLUxb6BHYo2JLt9pH+wOSfzxXf zcsL+R8R7L6zjnBfak/zPIWleXfLKcvIxZz7mkYDqefb0pSAxUg/xc/Su18GeB7bxLp811dz3ESp LsTyiBngeo968+MHN6H3uJxNLCU+ep8K0OHBA6LQSD/D+Vevf8Ki0j/oI6j/AN9J/hR/wqLSP+gj qP8A30n+Fa/V6nY8/wD1gwHRv7meRgjbgYHOeaOCeTXrf/CpNJXpf6gfbcn+FeYavYDTdXvLLDEQ SFF3kZIzx0qJ0pQs2dOEzLD4ubjRe3kdN8NNS+x+JxasQqXke3n1XJ/pXtaZ281812V41jqFvex8 G3kV+OwBGf619HWlyl1aQTqciaMOMehAP9a6cLK8Wux83xHQca8aqXxL8jlfid/yJz/9d4/514h2 Ne3fE4/8Uc//AF3j/nXiPrWWJ+M9bhz/AHR+r/JHq/wm/wCQbqP/AF0X/wBmr0U9a86+E3/IN1H/ AK6L/wCzV6KQc8DNddH+Gj5rN/8AfqnqvyR5n8UdDLLDrMK7ivyT49Ox/lXmJ/h5yMV9I6hYRX1h cWssYaOVCCD6/wD66+etU02TSdSuLCQHdExH1rmxFPlfMup9Bw/jPaUnh57x29Bs19Ncafb2szhl tifK45APOCe/NVCc0AD8RSY+RgeuOK5btn0MYKCtE+h/C4/4pjTf+uArYX7tY3hfP/CMad/1xH8z Wyv3RXrQ2PzCv/Fn6v8AMdRRRVGLCiiigQUUUUgCkb7tLSHpQNDP4Wr5ml/1zfWvpkjCNmvmaTiZ wfWuTFdD6rhj4qny/UYfumvoDwZ/yJOjf9eq18/n7tfQHgv/AJEvRx3FqtRhfiZ1cS/wIev6HQUU UV3nxbCiiigQU1/unnHvS5ArL8Ramuk6BeXrHGyM7f8AePC/qRUt2Vy4Rc5KK3Z474/1f+1fEkqL IGgt1MaAdmBGc/iDXLFjhh2apHYyTM8hy7sXc+55qJwdvsFNeXKXNJtn6dhqEaFGNJdF/wAOe4fD WBY/B9vMPvTMzt6cEr/Suxrn/BURh8IabGRg+WW/Nif610FelT0gj84xsufETl5v8woooqzlCiii mAUUUUAFMLMM9OtPqpf3sNhZz3M7bYoULscZ4FK9i0m3ZGN4u8TReHdLaXcv2h8rCmM/N6kV4Td3 Ut9dSXNw2+aVtzMf5VoeI9dn8Qao95MxCZxHH2UetZ0FvNd3EUEMRkkkYKoA5zXn1ajnKy2Pvcqy +OCo88/ie/kXtE0W713Uo7O2Vst/rH7Kv+c17voOh2mh2CW1quB1Zs/ePeqXhbw1B4c0xYEUNcMA Zpf77VvpwMEY9q6aNLkV3ufM5tmcsXPkj8C/HzHBQABk/jS0bh/kUgYHvW542p5H8WISutWU5Hym 3IJ991edyDKSfQ17B8VLL7RodvdRxlmilwxHZcH+teRdmHqcV5uIjabP0DIqqngoeWn4n0Zot39s 0Wzucg+ZGDx/n2rSFcZ8OtQW78JwxlsvbsYyB1AGCP512IcBck/WvQg7xTPh8VSdKtKm+jZynxIm 8nwXecgb2VOfc14e3yuQ34/lXqPxa1JBaWOnK4JlcvIo6gLtx/X8q8t++xJ7/wAq4cQ71LH2XD9L kwXM/tNv9D1j4SwY0q+uMENJKo/AZAr0YVyvgKxex8J2isu15cynPcHkfpXVL0rspK0UfJ5jUVXF VJrv+QGmHtUhqM9RWjOI+cdY/wCQ5f8A/Xdq1PA3/I5af/v1l6x/yHL/AP67tWp4G/5HLT/+uleb H+J8z9Frf7g/8P6HvhpoL7jnGKd3FNY4Xk16J+d7I5jxJ44sPDc6wSq1xOeTHHwQPWtDQPEll4it DcWb8qcPEfvL9a8a8ZtJ/wAJhqSzFt2/AHXAxxVz4f60uk+JkSZmW3u1EbHrhudvHuSK5VXftLPY +lqZLTWBVWndztc9zFNbOfYYoDrjOaNwJPPSutnzKOP+JJA8E3Yc/MXj2/8AfYrxMV6l8WNQQWNn p6OC8khZ1B6DHGfxry0dcZHXvXn4mV5n3XD8HDB3l1bZ6/8AClf+KYnY/wDP0w/Ra75MbRiuU+Hl k1n4Os8ptaf9+f8AgQH+FdWo2jFdtJWgj5HMainiqkl3Y6iiitDhCiiigAooooAKKKKACiiigAPS qGr/APIEv/8Ar3f/ANBNX6oat/yBb/8A693/APQTR1KifKA/1Z+lfUXg/wD5ErQv+wfB/wCgCvl0 f6s/SvqLwf8A8iVoX/YPg/8AQBXq5l8MTmw/+Rud6KO9FeUdDEPQ/SvmTx3/AMj7r3/X0f8A0Fa+ mz0NfMnjv/kfde/6+j/6Ctd+XfxX6fqZV/hPVvg3/wAidN/19vXoY7V538G/+ROm/wCvt69DOQMd +1cuK/iy9S6fwo+b/iP/AMlF1v8A66x/+ikr0X4KY/4R3UT3+1D/ANBFeXeNLxL/AMcazcxkGNrj ap9dqqv/ALKa9W+DUBh8JXE7Die8fafXbx/OvRxOmFin5GcP4jPSRS0gpa8g2YV4p8bedZ0v/r2b /wBCr2snArw741yg+JdNizyLMt+bn/CuvA/x18yKnwP+upB8GB/xWd0f+nJv/Q1r3cdK8M+CyZ8V X7n+G0x+bD/CvcxVY/8AjP5CpfCLTW6fjTqaen41xGiPPPjN/wAiZF/1+R/1rzX4Y/8AJSNH+s3/ AKJevSfjN/yJcX/X3H/WvNvhj/yUjR/96b/0S9erh/8AdJfMxl/ER9I0UUV5RuFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAcV8WP+Scan/vQ/+jUrwvwx/wAjZpH/AF+R/wDoQr3T4sf8k41P/eh/9GpX hfhj/kbdI/6/I/8A0IV6uD/3afzMZ/Gj6nHeigd6K8s1YVleJv8AkWNV/wCvSX/0E1q1leJv+RY1 X/r0l/8AQTTj8S9Q6HyqP9QPoK+rtD48P6b/ANesX/oAr5RH+oH0FfV2h/8AIv6b/wBesX/oAr08 y2j8zChs/l+po0UUV5Ru9xD0NeH/ABr/AORk03/r0P8A6Ga9wPQ14f8AGv8A5GTTv+vM/wDoRrsw P8ZEVfgf9dQ+Cv8AyMl//wBeX/s4r28jK49a8Q+Cv/Iy6h/15f8As4r2/uKnH/xn8gp/CfI8o/fS j/po/wD6Ea+k/h+xfwHo+f8An2X/AAr5sl/18v8A10b/ANCNfSPw+/5ELRv+vdf612Zh/Dj6/oZ0 d2dQPSlpP4jS15R0BXlfxt/5A+kf9fL/APoNeqV5X8bf+QNpH/Xy/wD6DW+F/jR9TOp8LOD+Gn/J QNL+r/8AoNfR6184fDT/AJKBpf1f/wBBr6PWt8w/ir0JofA/X9ELRRRXCaBRRRQAUUUUAFFFFA0F FFFAgpD6UtFIZxPxK0ltR8NvNEgaW1YSD12/xfyrxYjBJz3wa+mpoIp4nilQPG6lWVhkEHqK8N8Y eEJ/D1800Ebyac+SrgZ2ZOea5MTTfxI+r4ezCMU8PN21ujP0HxPqHhu6aS0Ikik5khYkBsdK39Q+ J2q3lk0FvZw2u8ENIshc8+mRxXDg84B5Hp3pTkcFSufWuZVZRXKj36mXYWtU9rOF2PeRmkaSQl3Y 5JPWtDw7pkuta5bWaLujaRTL7IDzVG2t57y4WC2iMsrHGyMFj+ley+CfCA0C3a6utrX0g7D7g9Kq jTc5X6HNmmPhhaLSfvPRI61VEcaovAVQox7V4z8TL83Xiv7KCRHaRhR9WAbNe0HgDjPqa8N8e2T2 ni24acP5c4DK56HpXViX7mh85w+ovGXluk7epyxyOnFe/eCtOOmeGbOFlw7KZH+pJ/pivFdA0w61 rlpZBFZWkBmI7Jnn9K+h4EVF2qMKoCgfQVGFjvI7uJMQrQoJ+bJqKKK7D5MY2Qwrxn4n6YLTxDFe KAqXUeSf9of/AK69nYZIrifiNpP9oeHmuETdJaMZeOu3qcfkKxrR5oHqZPiPYYuLb0ejPGONrL2I xXt/w61I33hC2R23S25aJs9gGOP0xXh6kcHOc+tex/DGxltvDTTyKR58rEA9cZx/SuXC/G0fScRx g8Km976Fn4nc+Dn/AOu8X868S7GvefHthJf+FLqOFSzIRKAO+3JrwnavfGMkH5uhoxOkkxcOTTw0 o9b/AOR6p8Jf+QXqP/XRf/Zq9IXqa4D4V2csOgTTyrtE8vy+4Gef1rv1I9K66OkEfM5tNTxtRx7/ AKIU9K8v+J+gtth1q2T51Iilx+h/DnNeoGqeo2UWoWE1rMoMcqlTntTqR5o2McFiZYavGqum/ofN pILcDikPStHWdJl0PVZbC4QjbzGxONy+v86opE87JDCu+aT5UAPU+leZa0uU/SI1oTp+0T0PoPwu ceGNNH/TEf1rYX7oqjpdr9j0q3tuhijAq8v3RXqwVkfmNZp1JNdWx1FFFUZMKKKKBBRRRQAUHGKY 5weprx/UvidrlrqNzbxtaBYpGUExZyAfrWcqkY7nbg8FVxcnGl0PXnwoIJ6jnntXzPMQ0zlTkEnF dRefEnX72AxNc20Qb+OJMN/OuS3RjgSKfxrjr1FO1j63Jcuq4NydVrW3UU8qa+gfBTBvBmkY6m1X g18/Bk5BdeR610ej+O9a0WzWytri3aBBhBKudo9BzU0KihJ3Ns5wVTF0oxpWunfc99zmlrxQ/FPX xuIexwO3l8/zr1DwpqdxrHh+2v7op5soyQgwBg12wqxm7I+PxeW18LBSq2s/M26KKK1PPGn71cH8 UrxofC8cCnH2iYKR67ef6V3h+9+FcB8UbKWbw9DdJ922mLNjsCMVjWvyOx6OV8v1ynzbX/4b8TyD kH3NJJny2HfaR+YqQcrwpPqOpq9ommvq+tWtlCjEySDeCfupkZJ/DNeclzOx+hVaip05Tlsj37RI xDpNpGBjbCvHpwK0aht0WONUHRFC/lxU1estj8um+aTYUUUUxXCiiigGFFFFIQVwPxR1J7Xw/Hax tte5lwcd1HX+Yrvq4P4maPPqOix3NtG0j2rMxVRklT1/kKzq35HY9DLXTWLpuptc8bz1AHOeKu6b qNzpN+l3Ysq3CAgFgDjP1qk5RW67T6NTdyDo6/8AfVeZZn6LJQqRcZapnU/8LF8V/wDQQT/vwtH/ AAsXxSRzqKf9+F/wrltyf31/76o3J/fX86v2lTuc31DB/wDPuP3I6pfiH4pLAHUIyPeFRn9K7fwP 43m1u6fTtQCi4xlHUYDetePZT++v5123w3sJrnxQLuNG8iBGy+OCSCBWlKpPmSPPzTA4SOFnNQUW traHrWrWEeraXcWUyjbKhH49v1xXzzeWdzp15LaTqVlhcqcj0719KbAfzyK4Txz4LOs5v9PCrejC sMffX3966K9PmV1ueFkmYxwtR06jtGX4M888L+JZ/DepmaMGS3lG2WPPX0Ir0OX4oaKLTeiSvLj5 UK8ZryOaF7eZ4ZwY5UOCjDaaYcE8HH1auWNaUFyn0mKyrC4yftpLXy6l7WdWuNb1SS/udoeT5QAc gAHI/nUvh/R59a1qCyjTKlw0p9FHJqpZWdxqFwLexgM8zEDaOevevafB/hSLw9Y75sPfTDMkmOns KKVKVSd3sZ5jjqWBoeyp/FayXY6a3gSCJIogBGi7VA7Cpl6YoAAGAOKXFelY+CvcKY3UU49KY4JU 4PODigD5x1j/AJDt/wD9d2rV8Df8jjp/+/VbxXZ/YPFOoxNkDzsqD3BAOa0/hxZteeLYpFBKQI0h YdjxgV50V+9sfoNapH+zXPpynuVMYgKc0AkDJ55p2Ae1eifn55B8UNHe31WHUo0LRToVlbGMMAMf 1rglYrjaSsgPytnpX0XrWkWut2D2V0oKOOvcH/JrwzX/AA1feHLlkukZrfP7udQcH61w4inZ8yPs 8jzGFSisPN2ktvNHbeF/iNaJaRWWrs0MsY2rPj5W+tbWpfELQbG2MkF0t3Lg7FiHBPvXiwUspIdM HqA1Ko+bqAcd+lSsRJKxrUyDDTq86uk+hd1bU7rWdRlv7s/O54APCjsKfoWky67q9tYRA7ZHzKcf dUdTUGm6fdarci3soTLI5x8q5H4kdK9p8H+EofDlnvlYPfSj94/p7CilTlUlzM0zHHU8FQ9nT+K1 kux01rDHbW0UEKhY41CqB2AqakQALgdKWvQR8C227sKKKKYgooooAKKKKACiiigYUUUUAwPSqGrf 8gS//wCvd/8A0E1fPSqGrf8AIEv/APr3f/0E0dRxPlAf6s/SvqLwf/yJWhf9g+D/ANAFfLo/1Z+l fUXg/wD5ErQv+wfB/wCgCvVzL4YnNhzcoo70V5R0iHofpXzJ47/5H3Xv+vo/+grX02ehr5k8d/8A I+67/wBfR/8AQVrvy3+K/QxrfCerfB3/AJE6X/r6etTx74wg8M6K6o4bUbhTHbxg5IJH3z7CvJdA +IN54Z8NnS9OtozcSTM5uZjkKD6Ljk/jXLXt/c391JeX1xJPPJ9+WQ5JrX6nKdZzntcSnaFkQhJJ XCoGeeQ4QDks7HH8zX0/4V0UaB4YsNOwA8UYMmP755b9c15x8MfAc8dxFr+rwtHt+a0t3HOT/Gwx xx0FexYrHHV1NqEdkVSjZXYCloxiiuA1uIeleBfGK4E3jiOMf8sLNEP1LM39a98J4xXzb8RbkXXx B1cg7gkqRg/RF/rmu7L1et8jKt8J13wRtt19rN0f4FjiHHrk/wBK9lry74J25XQ9TudpHm3IUE99 q4/rXqVZYyV68h0/hQU1ug+tOpp6fjXMWjzv4zf8iXD/ANfcf9a82+GP/JSdH/3pv/RL16T8Zv8A kS4f+vuP+tebfDH/AJKRo/8AvTf+iXr1cP8A7pL5mMv4iPpGiiivKNwooooAKKKKACiiigAooooA KKKKACiiigDiviv/AMk51P8A3of/AEaleGeFz/xVmkf9fkf/AKFXufxX/wCScan/AL0P/o1K8L8M f8jZpH/X5H/6EK9XB/7tP5mM/jR9TjvRQO9FeWasKyvE3/Isar/16S/+gmtWsrxN/wAixqv/AF6S /wDoJpx+JeodD5VH+pH+7X1dof8AyL+m/wDXrF/6AK+UR/qB/u19XaH/AMi/pv8A16xf+gCvTzLa Pz/QwobP5fqaNFFFeUbvcQ9DXh/xr/5GTTf+vQ/+hmvcD0NeH/Gv/kZNN/68z/6Ga7MD/GRFX4H/ AF1D4Lf8jLqH/Xl/7Ote3nt9a8Q+C3/IyX//AF5f+zivb/T61OP/AI79EFL4T5Gl/wCPib/rq/8A 6Ea+k/h9/wAiFo3/AF7r/Wvm2X/Xzf8AXR//AEI19I/D4/8AFA6P/wBcAP1NdmP/AIUfX9DOluzq OrGlHSkH3jS15Juwryv42/8AIG0j/r5f/wBBr1SvLPjaD/YmlEdBcv8A+g10YX+NH1In8LOC+Gn/ ACUDS/q//oNfR4r5v+GzBfH+lZ7sw/8AHa+kB3rfMP4q9CaPwfP9ELRRRXCaBRRRQAUUUUAFFFFA BRRRQAUUUUAIRUMtus0ZSQBlPVSMg1PRQNNrY5S9+Hug3srObQRMe8bEf1qnF8LdBjfLefJ7PIa7 eiodOL6HVHHYmKsqj+8ytN0Cw0iMrY2kMPPUZJP1J5rRCsvQjJOTxUlFUlbY5pTlJ3k7sYVOD6ms rWfDtjrtusN7GGC/dcfeH0NbFFFk1ZjhUlB80XZnPaF4P03w/I8tohMjLt3ucnFdAo28dqWihJLY dSrOpLmm7sKKKKZmJjmo5IVkRkZQysMEHvUtFIdzjm+G2gtfm6MThS24whvkJzn611cMAgiWNFVU UYAXgAdqmopKKWqNamIq1be0k3Yjkj8xSpAIIwQfSuSn+G2gz3xujC6ZbcY1c7SfpXY0U3FPcVKv Upfw5WK1raR2lukEMaRxRqAiL0GKsAEZzS0UWM229wphQnPNPophcxtZ8M6dr0e2+t1dgMLICQy/ jWfpHgLRtGuhcwQmSdfuySsSV+ldTRU8kb3sbRxNaMORSduw3ZgUoGKWiqMbhRRRQIKKKKACiiig BjKT0rMfw3pMjl5NPt2Zjkkr1Oa1qKTinuXGco/C7GP/AMIvonfS7b8Fpf8AhF9E/wCgXbf981r0 UuVFe2qfzP7zHPhfRP8AoF2/4Ck/4RbRO2mW4/CtmijlQe3q/wAz+8xl8L6ODn+zLX67a0rS0isb cQQIEiX7qjtU9FHKlqhSqzkrSdwoooqjMaQSwNRXFrHdQtDKivEwwVYdanopDTa2OFuvhbotxO0s clxb7uqRN8v65rd0Lwrp3h5GFnF87DDSMcsa3aKlU4p3SOipjMRUhySm2hqrtp1FFUc4UUUUCCii igAooopgBqNog2cnqMY7VJRSHcyZPDmkTSeZLp0DOepxSf8ACL6J/wBAu2/75rXopcsexp7ap/M/ vMj/AIRfRP8AoF2//fNH/CL6J/0C7f8A75rXoo5Y9g9tU/mf3mR/wi+idtMtv++at29hDZp5drDF DHx8qLjNXKKFFIUqs5K0ncYFOcmjYT7U+iqIuzG1bwzpeshftlnFIw/i5BH4isZfhn4fEocwSED+ EyNj+ddlRUuEX0N6eLr01ywm0jM03QrDSAVsbSGJTjJXOfzNaDJkYz+NPop2tsZSnKTvJ3YlLRRQ QIaTBxTqKY7mBrnhHTfEBD3kbCUDAkjOGxU+i+HbHQLcw2MQUNy7tyzfU1sUVPKk72NXiKrh7Nyf L2EIyuBS9qKKoyuNIJbPtUFzZQ3ULRTRJJGwwQ3Oas0Umrgm1qjkL34beHbxtwtmgP8A0ycj+dQQ fC/QISS6TTjssj8D8Rg121FTyR7HUsdiUrKo/vM/T9Is9LhWGzt44UHZR/XrV3YScnFPoqrWOZyb d27sao2jGadRRQJhRRRTEFFFFABRRRSAKKKKYBRRRQAVQ1f/AJAl/wD9e7/+gmr9UNX/AOQJf/8A Xu//AKCaOpUT5QH+rP0r6i8H/wDIlaF/2D4P/QBXy6P9WfpX1F4P/wCRK0L/ALB8H/oAr1cy+GJz Yc3O9FHeivKOhjSQOvfivnLxho2q33jnWpLXS7yVHuCwZISRjaOh/Cvo5hlTTAp6jr3961oVnRk5 JXFKKmrM+d9M+GPinU2QyWK2UR6vcOOB67VJNemeF/hXpWhSx3V451C+TkNKP3cZ/wBlf6nNd5t+ v508dauri6lRWvZCjTjHYbtYDt+FP7UUVzFNhSN0paRulMERsRtyTgAHJPavlLU7tr/Vr67JJM1x I+T3y1fSPjPUf7L8G6tc5wy2zKpH95gQP1Ir5jWN3VY0GXYhFA9ScD+deplsLKU/kZV3pY+h/hVa G18AWGR/rmklPqcucfpXbd6zdEtBpujWNgBgwwJGceqqAf1rSrzakuabl3ZolaKQU09Pxp1NPT8a gaPPPjL/AMiXF/19x/1rzX4Y/wDJSNH+s3/ol69J+M3/ACJcP/X3H/WvNvhj/wAlI0f/AHpv/RL1 6uH/AN0l8zGX8RH0jRRRXlG4UUUUAFFFFABRRRQAUUUUAFFFFABRRRQBxXxY/wCScan/AL0P/o1K 8L8Mf8jbpH/X5H/6EK90+K//ACTjU/8Aeh/9GpXhfhj/AJGzSP8Ar8j/APQhXq4P/dp/Mxn8aPqf 1ooHU/WivKNWFZXib/kWNV/69Jf/AEE1q1leJv8AkWNV/wCvSX/0E1UfiXqHQ+VR/qB9BX1dof8A yL+m/wDXrF/6AK+UR/qB/uivq7Q/+Rf03/r1i/8AQBXp5ltH5mFDZ/L9TRoooryzdiHoa8P+Nf8A yMmm/wDXof8A0M17gehrw/41/wDIyab/ANeh/wDQzXXgf4yIq/A/66h8Ff8AkZdQ/wCvL/2da9wH UV4f8Ff+Rkv/APry/wDZ1r3AdRU4/wDjv+ug6Wx8iv8A66X/AK6v/wChGvoz4a/8k90f/cP/AKEa +c3/ANdL/wBdX/8AQjX0Z8Nf+Se6P/uH/wBCNduY/wANeplR+JnXL0paRelLXkm7CvL/AI2g/wDC Paccf8vRH/jpr1CvNfjQufDFkcdLsf8AoJrbC/xokT+Fnmnw7YDx/pGe8hA/75NfStfMXgV9nj3Q yO90q/oa+nM4rpzD+IvQmj8PzFooorgNAooooAKKKKACiiigYUUUUCCiiikAUUUUxhRRRQIKKKKQ BRRRTAKKKKACiiikAUUUUwCiiigAooooAKKKKACiiigAooopAFFFFMAooooAKKKKQBRRRTAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKQ7BRRRTEFFFFA BRRRQAUUUUgCiiimAUUUUAFFFFABRRRSAKKKKYBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQM KKKKBBRRRQOwVQ1f/kC3/wD17v8A+gmr9UNXP/Elvv8Ar3f/ANBNHUcT5QH+rP0r6i8H/wDIlaF/ 2D4P/QBXy6P9W30r6i8H/wDIlaF/2D4P/QBXq5l8MTmw5ud6KO9FeUdDCiiikAUUUUxBRRRQMKQ0 tMfI6UgSPL/jRqog0Wx0pT811MZX/wB1Mf1YflXmvgnSv7Y8Z6ZaMP3fm+dJx2Qbv5gVd+I+sDWP Gl20bBobTFshHPKk7j+ddZ8F9IJk1DWnXpi2hP4gsf5CvYivYYW/X/Mwl79Sx7GMdaWmjjinV46O hhTT0/GnU09PxoEjzz4y/wDIlxf9fcf9a81+GH/JSNH/AN6f/wBEvXpPxm/5EuH/AK+4/wCtebfD H/kpGj/703/ol69XD/7pL5mL/iI+kaKKK8o3CiiigAooooAKKKKACiiigAooooAKKKKAOK+K/wDy TjU/96H/ANGpXhfhj/kbNI/6/I//AEIV7p8WP+Scan/vQ/8Ao1K8L8MD/irNI/6/I/8A0IV6uD/3 afzMZ/Gj6nHeigd6K8s1YVleJv8AkWNV/wCvSX/0E1q1leJv+RY1X/r0l/8AQTTj8S9Q6HyqP9SP 92vq3Q/+Rf03/r1i/wDQBXykP9T+FfV2hn/intN/69Yv/QBXp5ltH5mFDZ/L9TRoooryjd7iHoa8 P+Nf/Iyab/16H/0I17gehrw/41/8jJpv/Xof/QzXZgP4yIq/A/66h8Ff+Rkv/wDry/8AZxXuA6iv D/gr/wAjJqH/AF5f+zrXuA6ipx/8d/10Cl8J8iv/AK6X/rq//oRr6M+Gv/JPdH/3D/6Ea+c3/wBd L/11f/0I19GfDX/knuj/AO43/oRrtzH+GvUzo/Ezrl6UtIvSlryTdiGvP/jFDv8ABQk/55XMbfTJ x/WvQTXFfFWMy/D+/UAfK8Lc+0i1rQdqsX5kz+Fnifgxlj8c6G7HAF4mf1r6dH3eeor5V0ab7Pru nz5A8u5jbJ/3hX1SOp/OuvMl78X5EUHdMlooorzkasKKKKYgooooAKKKKB3CiiigQUUUUAFFFFA7 hRRRQIKKKKACiiigAooooAKKKKACiiigYUUUUAFFFFAgooopAFFFFMAooooAKKKKBhRRRQIKKKKA CiiigdwooooC4UUUUhBRRRTAKKKKB3CiiigQUUUUAFFFFA7hRRRQIKKKKACiiigYUUUUCCiiigYU UUUBcKKKKBBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUDuFFFFIQUUUUwCiiigAooopA FFFFABRRRTGFFFFAXCiiigAooooC4H7tUNX/AOQLff8AXu//AKCav1Q1f/kC3/8A17v/AOgmhbjW 58oD/Vn6V9ReD/8AkStC/wCwfB/6AK+XR/qz9K+ovB//ACJWhf8AYPg/9AFermXwxObDm53oo70V 5R0MKKKKQXCiiimIKPSijPagdxuTuxXOeNPEK+HfDV3e5HnbfLgU/wAcjcAD6cn8K6FiO5x7mvn3 4meKR4g1/wCy2sm6wsSUQjo8n8Tf0rbDUnVqW6ImcuWPmcUN8jADLyM3QdWYn+pNfTfhHRB4e8LW OncGSNN0rY+855P6nH4V498K/Dh1nxQb+ZM2mnYc+jSH7o/DBP5V9AL0rqzCreSproTSjZczEHpT qKK840uFNPT8adTW6D60Ajzv4zf8iZD/ANfkf9a82+GP/JSNG+s3/ol69J+M3/Ilw/8AX5H/AFrz b4Y/8lK0f/em/wDRL16uH/3SXzMZfxEfSNFFFeUbhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHFfF j/knGp/70P8A6NSvC/DB/wCKs0f/AK/I/wD0IV7p8WP+Scan/vQ/+jUrwvwx/wAjZpH/AF+R/wDo Qr1cH/u0/mYz+NH1OOp+tFJ60teUasKyvE3/ACK2qn/p0l/9BNatZXib/kV9V/69Jf8A0E1UfiXq HQ+Vf+WI/wB0V9W6H/yL+m/9esX/AKAK+Uh/qev8Ir6t0TjQNNHf7LF/6AK9PMto/P8AQww/X5Gk KKQUV5RswPQ14f8AGv8A5GTTf+vQ/wDoZr3BjhSa8O+NZz4l03AP/Hof/QzXXgf4yFU+Bi/BX/kZ dQ/68v8A2da9vzgivEPgr/yMt/8A9eX/ALOte3HHH1pY/wDjP5CpfCfJNwhiu7iNvvLM4P8A30a+ iPhkQ3w/0nBzhWB/76NeH+MNPfTfGOrWzLtxcGReOqsAwx+den/CDX7Q+Hn0me4jjuLeZmVXcDKN yCM124336EZIinZTZ6iv3aWoFu7YLzcw/wDfwUfa7b/n5h/7+CvJsbMmNc746s2vfBerxKRu+zsw z/s/N/Stz7Xbf8/MP/fwVXvntruxuLczwlZYmjP7wdwRTV00+wrX0Z8o7yq+YhwQNw+tfWVnOl3Z Q3KHKTIHX6EZFfKdxAbW7mtnXDQyNGQOR8px/Svoj4damupeBtNfdukgTyJMnoy8fyxXp5irxjJG NBu7OvopB0pa8pG7CiiimIKKKKACiiigAooopAFFFFMAooooAKKKKACiiigAooopAFFFFABRRRTA KKKKQBRRRTAKKKKQBRRRTAKKKKQBRRRTAKKKKACiiigAooooAKKKKQBRRRTAKKKKQBRRRTAKKKKQ BRRRTAKKKKACiiigAooopAFFFFABRRRTAKKKKACiiikAUUUUwCiiigAooooAKKKKACiiikAUUUUw CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooopAFFFFABRRRTAKKKKACiiikAUUUUwA9Koat /wAgS/8A+vd//QTV+qGr/wDIEv8A/rg//oJoW5UT5QH+rP0r6i8H/wDIlaF/2D4P/QBXy5/yzP0r 6j8H/wDIlaF/14Qf+gCvVzL4YnNh/wDI3KKKK8k6QoooxQAUUYpDmi4mLTCxzxzVHUtb0zSIjLqN 9b2ygZxJIFJ+gzk15R4s+LTXEUtl4bDIrcPevlWPsi9R9TWtKjOq7RQnKMVqa/xM8erp1vJoemSq 17KpW4lXnyVPGB/tH9K8d0/TrnU7+Cws4zJPM4RB/U+3rUUUU93dLFBG9xczN8qLks7Gvefh34EX wzbfbr4K+qzr82eREv8AdHv0zXptwwdOy+JmFnUdzovCvh+38N6DBp8ABK/PK/d3I+Y/nW4ORQBy KWvIbbd2dC00CiiigQU1ug+tOprdB9aQ0ed/Gb/kS4f+vuP+tebfDH/kpGj/AO9N/wCiXr0n4y/8 iXD/ANfcf9a82+GP/JSNH/3pv/RL16uH/wB0l8zF/wAVH0jRRRXlG4UUUUAFFFFABRRRQAUUUUAF FFFABRRRQBxXxY/5Jxqf+9D/AOjUrwzwwf8AirNI/wCvyP8A9CFe5/Fj/knGp/70P/o1K8L8Mf8A I26R/wBfkf8A6EK9XB/7tP5mM/jR9TDv9aWkHf60teUasKyfE3/Ir6oP+nSX/wBBNa1Vb60S/spr Sbd5UyFH2nBwRjinF2aY+h8lrjygD3FdAnjfxTEixxa5dJGqhVVQnygDAHSvVl+DXhoDbv1AAd/O /wDrUv8Awpnw1/z11D/v/wD/AFq9iWNw8viX4HNGnNI8q/4TvxZ/0H7z8k/+Jo/4Tvxb/wBDBefl H/8AE16t/wAKa8Nf89dQ/wC//wD9aj/hTPhr/nrqH/f/AP8ArVP1rDfy/gVyTPKf+E78VkYOv3n5 J/8AE1m6nrOo61MkupXcly6DarPjIGc44xXtH/CmvDX/AD11D/v/AP8A1qT/AIU14a/566h/3/8A /rU1jMMtUvwE6c3uzlfgqc+Jr/8A68v/AGda9u6rXLeGvAeleFL2a60+S6Z5U8siWTcAM5rqQMP1 zx0rzsVUVWq5R2Nqa5Y2Z5j8U/BdxqqJremRGS6iTZPCo5kQZII9SK8VYlWKvujcE5U5Uj2NfXOA eorMvvDWialKZb3SLK4lPV5YFYn8SK3w2NdKPLJXRE4X1W58rhh/fP8A30f8aTP+0f8Avo/419Pf 8IT4Z7+HtL/8BU/wo/4Qnwv/ANC/pf8A4Cr/AIV0f2hT/lZHsn1Z8w5H94/99n/Gl346O3/fZ/xr 6d/4Qrwv/wBC/pf/AICr/hR/whXhf/oXtL/8BV/wp/2hT/lY/ZPufMe4ZyWye+WzXbfDTxevh7Wx ZXUgFhesFYk8Rv8Awt+PevZv+EK8L/8AQvaX/wCAq/4Uh8EeFipU+HtLweo+yrz+lRVx1KpDlcWO NJp3TN9CGQEHIx1HenUyONYoljQAIoAUAcADpT68tGrQUUUUCCiiimAUUUUDsFFFFAgooooAKKKK QBRRRTAKKKKACiiikAUUUUAFFFFMAooooAKKKKACiiigAooooAKKKKACiiigAooooGFFFFAgoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigYUUUUCCiiigAooooA KKKKACiiigAooooHYKKKKBBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUDCiiigQUUUUg CiiimAUUUUAFFFFABRRRQAHpWfrB/wCJHf8A/Xu//oJrQPSq9zAlzbPBLuKSAq23jijqVHc+Slx6 1pReIdaghjhi1i+jjjUIiLOwAAGAK9v/AOFSeEyT/ot0Pb7S1H/CpPCX/Prdf+BLV7Dx1CXxI5o0 ppbniP8Awkeuf9Bm/wD/AAIb/Gj/AISPXP8AoNX/AP4EN/jXt3/CpPCf/Ptdf+BLUf8ACpPCf/Pt df8AgS1T9cw/8v4F8s+54l/wkmuf9Bm//wDAhv8AGj/hJNc/6DV//wCBDf417b/wqTwn/wA+11/4 EtR/wqTwn/z7XX/gS1H1zD/y/gHLM8R/4SPXM/8AIZv/APwIb/GkfxFrboVbWdQII5H2hv8AGvb/ APhUnhP/AJ9rr/wJalHwl8JqwP2S6OOxuGo+uYf+X8ELkn3PAHlaVy00ssrkfekcsfzNbugeDdd8 TspsbMpbE4a5nBWNf6n8K940/wADeGtLO+20W335+/Ku9h9C2a6MRoEChQFHQAcCs6mY6WpxsEaT +0zkPCPgDTPCyCcAXWoEfNcOOnso7D9a65eOMfiadgUuK86cpTfNJ6myslZBRRRSEFFFFABTW6D6 06mnp+NIaPO/jL/yJUP/AF9x/wBa82+GP/JSNH/3pv8A0S9ek/GX/kSov+vuP+tebfDH/kpGj/70 /wD6JevVw/8AukvmYy/iI+kaKKK8o3CiiigAooooAKKKKACiiigAooooAKKKKAOK+LH/ACTjU/8A eh/9GpXhfhj/AJG3SP8Ar8j/APQhXunxY/5Jxqf+9D/6NSvC/DH/ACNmkf8AX5H/AOhCvVwf+7T+ ZjP40fU470UDvRXlmrCm4PanUUguNwfWjbTqKAuN20badRTC43bRtp1FAXEAoxyKWigLh3pDntS0 UhCYJ6mk2j0p1FMdxuwUbfSnUUBcbgelGKdRSC4UUUUBcKKKKYgooooAKKKKB3CiiigQUUUUAFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQMKKKKBBRRRQAUUUUAFFFFIAooopjCiiigQUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUgCiiigAooopgFFFFABRRRQAUUUUDCiiigQUUUUAFFFF ABRRRQAUUUUAFFFFA7hRRRQIKKKKACiiigAooooAKKKKACiiigdgooooEFFFFIAooopjuFFFFAgo oooAKKKKACiiigAooooAKKKKACm4PrTqKQ7iYPc0YpaKAuJijB9aWimFxuD60uD60tFAXExSbadR QFxAMUtFFAXCiiikIKKKKYBRRRQAU1ug+tOprdB9aQ0ed/GX/kS4f+vuP+tebfDH/kpGj/703/ol 69J+M3/Ilw/9fcf9a82+GP8AyUjR/wDem/8ARL16uH/3SXzMH/FR9I0UUV5R0BRRRQAUUUUAFFFF ABRRRQAUUUUAFFFFAHFfFj/knGp/70P/AKNSvC/DH/I26R/1+R/+hCvdPix/yTjU/wDeh/8ARqV4 Z4Y/5GzR/wDr8j/9CFerg/8Adp/Mxn8aPqYdT9aKB3oryjVhRRRTEFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFIAooopgFFFFABRRRQAUUUUAFFFFABRRRSAKKKKYBRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRSAKKKKYBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UgCiiimAUUUUgCiiigAooopgFFFFIAooopgFFFFABRRRQAUUUUAFFFFABRRRSAKKKKYBRRRSAKKK KYBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFIAooopgFFFFABTW6D606mnp+NIaPO/jL/yJcX/X 3H/WvNvhj/yUjR/96b/0S9ek/GX/AJEuL/r8j/rXm3wx/wCSkaP9Zv8A0S9erh/90l8zGX8RH0jR RRXlG4UUUUAFFFFABRRRQAUUUUAFFFFABRRRQBxXxY/5Jxqf+9D/AOjUrwvwwf8AirNI/wCvyP8A 9CFe6fFf/knOp/70P/o1K8K8Mf8AI2aR/wBfkf8A6FXq4P8A3afzMZ/Gj6o9aKO9FeUasKKKKYgo oooAKKKKACiiigAooooAKKKKACiiikAUUUUwCiiigAooooAKKKKQBRRRTAKKKKB2CiiikIKKKKYB RRRQAUUUUAFFFFABRRRQOwUUUUCCiiigAooooAKKKKBhRRRQIKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooopAFFFFMAooooAKKKKQBRRRTAKKKKBhRRRSEFFFFMA ooooAKKKKACiiikAUUUUwCiiigAooooAKKKKACiiigAooopAFFFFMAooooAKKKKACiiigdgooopC CiiimAUUUUDCiiikIKKKKYBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFIAooopjsFFFFAgooooAKKKK ACmnp+NOpp6fjSGjzv4y/wDIlw/9fkf9a82+GP8AyUjR/wDem/8ARL16V8Zf+RLi/wCvuP8ArXmv wx/5KRo/+9N/6JevVw/+6S+Zg/4qPpGiiivKOgKKKKACiiigAooooAKKKKACiiigAooooA4r4r/8 k41P/eh/9GpXhXhj/kbNI/6/I/8A0Kvdfix/yTjU/wDeh/8ARqV4Z4YH/FWaR/1+R/8AoQr1cH/u 0/mYz+NH1N60Ug7/AFpa8s1YUUUUCCiiigAooooAKKKKBoKKKKAYUUUUCCiiigaCiiigAooopCCi iigAooopgFFFFABRRRSHcKKKKYgooooAKKKKACiiigAooooAKKKKBhRRRQIKKKKACiiigAooooAK KKKACiiigaCiiigAooooEFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFIAo oopjYUUUUCCiiigAooooGFFFFAgooooGgooooBhRRRQIKKKKACiiigAooooAKKKKACiiigAooooA KKKKQBRRRTAKKKKACiiigAooooHcKKKKQgooopgFFFFAwooopCCiiimAUUUUAFFFFABRRRQAUUUU AFFFFIAooopgFFFFAwooooEFFFFABRRRQAU09Pxp1NboPrSGjzv4y/8AIlw/9fcf9a82+GP/ACUj R/rN/wCiXr0n4zf8iXD/ANfcf9a82+GP/JSNH/3pv/RL16uH/wB0l8zGX8RH0jRRRXlG4UUUUAFF FFABRRRQAUUUUAFFFFABRRRQBxXxX/5Jxqf+9D/6NSvC/DA/4qzSP+vyP/0IV7p8WP8AknGp/wC9 D/6NSvDPDB/4qzSP+vyP/wBCFerg/wDdp/Mxn8aPqYd6KB3oryjVhRRRTEFFFFABRRRSAKKKKYBR RRQAUUUUAFFFFABRRRSAKKKKYBRRRQAUUUUAFFFFABRRRSAKKKKYBRRRQAUUUUAFFFFABRRRSAKK KKYBRRRQAUUUUAFFFFIAooopgFFFFABRRRQAUUUUAFFFFABRRRQAUUUUgCiiimAUUUUAFFFFIAoo ooAKKKKYBRRRQAUUUUAFFFFIAooopgFFFFABRRRQAUUUUAFFFFABRRRSAKKKKACiiimAUUUUgCii imAUUUUgCiiigAooopgFFFFIAooopgFFFFIAooopgFFFFABRRRQAUUUUgCiiigAooooAKKKKYBRR RSAKKKKACiiigAooopgFFFFABRRRSAKKKKYBRRRQAUUUUAFFFFABRRRQO4U09Pxp1NPT8aQI88+M v/Ilxf8AX3H/AFrzX4Y/8lI0f/em/wDRL16T8Zf+RLh/6/I/615t8Mf+SkaP/vTf+iXr1cP/ALpL 5mD/AIqPpGiiivKOgKKKKACiiigAooooAKKKKACiiigAooooA4r4sf8AJONT/wB6H/0aleF+GP8A kbNI/wCvyP8A9CFe6fFj/knGp/70P/o1K8K8Mf8AI2aR/wBfkf8A6EK9XB/7tP5mM/jR9Ud6KO9F eUasKKKKYgooooAKKKKACiiigAooooAKKKKACiiigaCiiigAooooEFFFFABRRRQAUUUUAFFFFA7B RRRSEFFFFMAooooAKKKKACiiigAooooAKKKKACiiikAUUUUwCiiigAooooAKKKKACiiikAUUUUwC iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK KKACiiigYUUUUAFFFFAgooopAFFFFMAooooAKKKKACiiigAooopAFFFFABRRRTAKKKKQBRRRTAKK KKACiiigAooooAKKKKACiiikAUUUUwCiiikAUUUUwCiiikAUUUUAFFFFMAooooAKKKKACiiigAoo ooAKKKKACmnp+NOpp6fjSGjzz4y/8iXF/wBfcf8AWvNfhj/yUjR/96b/ANEvXpPxl/5EuH/r8j/r Xm3wx/5KRo/+9N/6JevVw/8AukvmYP8Aio+kaKKK8o6AooooAKKKKACiiigAooooAKKKKACiiigD ivix/wAk41P/AHof/RqV4Z4YH/FWaR/1+R/+hCvc/ix/yTjU/wDeh/8ARqV4X4Y/5GzSP+vyP/0K vVwf+7T+ZjP40fU/c/Wig9aK8o1YUUUUxBRRRQAUUUUgCiiimAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQMKKKKBBRRRSAKKKKYBRRRQAUUUUAFFFFA0FFFFA MKKKKBBRRRQNBRRRQDCiiigQUUUUAFFFFABRRRQAUUUUDQUUUUCCiiigAooooAKKKKQwooopiCii igAooooAKKKKQBRRRQNBRRRTBhRRRQIKKKKBoKKKKAYUUUUCCiiigbCiiigEFFFFAgooooAKKKKB hRRRQIKKKKACiiigYUUUUhBRRRTAKKKKBsKKKKBBRRRSAKKKKYBRRRQAUUUUAFFFFABRRRSAKKKK YBRRRQAUUUUAFFFFABRRRQMKKKKBBRRRQAUUUUDCmnp+NOpp6D60gR558Zf+RLh/6/I/615r8MP+ Sj6P/vTf+iXr0n4zf8iXD/19x/1rzf4Y/wDJSNH+s3/ol69XD/7pL5mL/io+kKKKK8o3CiiigAoo ooAKKKKACiiigAooooAKKKKAOK+K/wDyTnU/96H/ANGpXhXhj/kbdI/6/I//AEKvdfix/wAk41P/ AHof/RqV4Z4YA/4SzSP+vyP/ANCFerg/92n8zGfxo+pu5oo9aK8o1YUUUUxBRRSUgFopM0tA7BRS ZPpS0wsFFFFILBRRRTEFFFFABRRRQAUUUUgCiiimAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFIAooooAKKKKACiiigAooopgFFFFABRRRQAUUUUAFFFFIAooopgFFFFIAooopgFFFFIAooo pgFFFFABRRRSAKKKKYBRRRQAUUUUgCiiimAUUUUAFFFFIAooopgFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAFFFFABRRRQAUUUUgCiiimAUUUUAFFFFABRRRQAUUUUAFFFFIAooopgFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFIAooooAKKKKYBTT0/GnU09P xpDR538Zf+RLh/6/I/615t8Mf+Sk6P8A703/AKJevSfjN/yJcP8A1+R/1rzb4Y/8lK0f/em/9EvX q4f/AHSXzMH/ABUfSNFFFeUdAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBxXxX/5Jzqf+9D/6NSvC /DH/ACNekf8AX5H/AOhCvdPiv/yTjU/96H/0aleF+Gf+Rt0cf9Pkf/oVergv93n8zGfxo+pz1oo7 mivLNWFFFFAiC6kaKF5VBJVScA4zgGvIj8bZwxA0JSAepuOf5V65egfY5v8Acb+Rr5LP32+p/nXd gaEKvNzq9rEVZyjZLz/Q9X/4Xfcf9AFf/Aj/AOtR/wALvuP+gEv/AIEf/WryjBxRXf8AUqH8v4sy 9pPv+X+R6ufjdcH/AJgKf+BH/wBapYfjeF5n0GQj/pnOuf1FeRCl7UfUaHYHVn3PddL+MWgX0qRX kdxpzN0aYb1/ErnH4138FxHdRxywTJJC4yHRgwYexr5LxjqMg+tdr8O/Gc3hzVYbC6nY6TctsZGO RE56MPQZPNcuIwCUean9xcK19JH0MDxS5zTFIZVOeozTgMV5aZsLRRRQIKKKKACiiimAUUUUAFFF FABRRRQAUUUUAFFFFABRRRSAKKKKYBRRRQAUUUUgCiiimAUUUUgCiiimAUUUUAFFFFIAooopgFFF FABRRRQAUUUUgCiiimNBRRRQIKKKKACiiigAooooAKKKKQBRRRQAUUUUwCiiikAUUUUwCiiigAoo ooAKKKKQBRRRTAKKKKQBRRRTAKKKKQBRRRQAUUUUwCiiikAUUUUwCiiikAUUUUwCiiigAooooAKK KKACiiigAooopAFFFFMAooopAFFFFABRRRTAKKKKACiiigAooooAKKKKACiiigAooopAFFFFMAoo opAFFFFMAooooAKKKKACiiigApp6fjTqaen40ho88+Mv/Ilxf9fcf9a81+GP/JSNH/3pv/RL16T8 Zf8AkS4f+vyP+tebfDH/AJKRo/8AvTf+iXr1cP8A7pL5mD/io+kaKKK8o6AooooAKKKKACiiigAo oooAKKKKACiiigDivix/yTjU/wDeh/8ARqV4Z4Y/5GzSP+vyP/0IV7n8WP8AknGp/wC9D/6NSvDP DH/I16R/1+R/+hCvVwf+7T+ZjP40fU3c0UDqfrRXlmrCiiigCve/8ek3+438jXyWfvH6n+dfWl9/ x5zf7jfyNfJjfeP1P869TLPtfL9Tnr7x+f6FzR7WK+1zT7Off5NxcxxPtbBwzAHBr2v/AIU74W9d Q/C5/wDrV434a/5GrR/+v2H/ANDFfUwGOKMfVnCaUXbQqkk46o8+/wCFOeFhz/xMf/An/wCtVS9+ DGhvbuLG7v4ZyPlaWQSLn3GB/OvTu2KY3FcH1msteZmvJF9D5W1zRbvw/rE+m3u0zQkcp0ZSMqR+ FZxG8FM43AivSfjR5f8AwlOnhCN/2Q+Zjqfm4z+Ga82JwCfyr3KFT2lNSkck0lKyPpjwJqMmreB9 JvJSTI0Oxie5Viv/ALLXSZFcj8Mo3g+HOjq64Yo7YPoZGI/Q1k/EHxrrPhC/tPslnZT2tyjfPKXy HUjjg46GvDdNzquMO7Ou9ops9Ez70ua8JPxp8RdDpul/nJ/jXpPgTxTL4s8Pm9uI4orpJWjlSLO0 EcjGfYiqqYapTXNJaCjOLdkdbRSCkP3iOelc5YuaM15P4x+KOpaB4nudLsLOymitwuXlLZLlQSOD 2zWC/wAa/EQRm/szSuBn/lp/jXTHCVZRUkjNzinZnu9FZmhXF5d6JZ3F/HFHcyxiR0iztXPOBnno a0653poUFFFFIAooopgFFFFA0FFFFAgooopAFFFFMAooooAKKKKACiiigoKKKKBMKKKKBBRRRQMK KKKAYUUUUCCiiigaCiiigegUUUUEhRRRQNBRRRQAUUUUhBRRRTAKKKKBhRRRQCCiiigQUUUUAFFF FABRRRQAUUUUDYUUUUAgooooAKKKKAYUUUUCCiiigAooooAKKKKACiiigaCiiigAooooEFFFFIAo oopjCiiigQUUUUDQUUUUAwooooEFFFFABRRRQNhRRRQIKKKKACiiigbCiiigQUUUUDCiiigegUUU UEhRRRSAKKKKY0FFFFAgooooAKKKKBhRRRQIKKKKACiiigApp6fjTqaen40ho87+Mv8AyJcP/X5H /WvNvhj/AMlI0f8A3pv/AES9ek/Gb/kS4f8Ar7j/AK15t8Mf+SkaP/vTf+iXr1cP/ukvmYv+Kj6R oooryjcKKKKACiiigAooooAKKKKACiiigAooooA4r4sf8k41P/eh/wDRqV4X4YP/ABVmkf8AX5H/ AOhV7p8V/wDknGp/70P/AKNSvCvDH/I2aR/1+R/+hV6uD/3efzMZ/Gj6o70UdzRXlGrCiiimIr3v /HnL/uN/I18lk/Mfqf519aXv/HnL/uN/I18lN95vqf516mW/a+X6mNfePz/Q0NDuYrPxBpt1cMVh huY5HYDOAGBPFe5n4teE+P8ASrj8Ldq+fRQSe3FddfCwrSUpMzhNx0R9BH4t+E+11cf+A7Vn6j8Y 9BhgY2MF3dT4wqMgRT9STxXhnPrml6dRzWKy+lfW5ftpF/WtYu9e1ifUr0gzS4wAOFXoAKXRNGud f1i30y0GZJmwx/uJ/E34Cs7IIxXsnws1bwlbxCztN1rqs2BI12w3Sn0VsAYz0HWtsRP2NP3EKC5p XZ6bZW0VhYwWkS7Y4EVFA9AK4/4raR/aXgq5mVD5lkwuVI67QPm/Su5yB0781HcRR3NvJbzLuilQ qw9QRg14NOfLJT7HU43Vj5K4z1z7+temfBnVWg1u/wBKLgJcwiZAf76kA/p/KvPdS06TSNTu9Nlz vtZmiJPfHQ/lirnhfVDoninTNQB+WKcB891b5T/OvfxC9rRaXVXOSL5ZH1L3qG5mW2hknc/JEjO3 0AyalBHTIrj/AInaoNM8D3oV9stzi3THU7jg4/DNeBCPNJRXU6m+VNnz/qV82pand3rklrmZ5ee2 WJA/LFXPDGlnWvFGm6eASsswMgH9xeW/QVk4x8or0/4M6SJdWvtXkU7bZBDGe25s7v0xXv15qlRb RyxXNJI9qjAEagDAAAAFPpq/dp1fPI6nuFFFFMQUUUUAFFFFABRRRSAKKKKACiiimAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQMKKKKACiiikIKKKKYBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA UUUUgCiiimAUUUUAFFFFIAooopgFFFFABRRRSAKKKKYwooooAKKKKBBRRRQAUUUUAFFFFABRRRSA KKKKYBRRRQAUUUUAFFFFABRRRQAUUUUgCiiimAUUUUAFFFFABRRRQAUUUUgCiiimAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFIAooooAKKKKYBTT0/GnU09B9aQ0ed/ GX/kS4f+vuP+tebfDH/kpGj/AO9N/wCiXr0n4y/8iXD/ANfcf9a82+GP/JSNH+s3/ol69XD/AO6S +Zi/4qPpGiiivKNwooooAKKKKACiiigAooooAKKKKACiiigDivix/wAk41P/AHof/RqV4X4YH/FW aR/1+R/+hCvdPix/yTjU/wDeh/8ARqV4X4Y/5GzSP+vyP/0IV6uD/wB2n8zGfxo+p/Wigd6K8o1Y UUUUxFe+/wCPOb/cb+Rr5Lb7x+p/nX1pe/8AHnN/uN/I18ln75+p/nXqZZ9r5fqYV94/P9C1plmd R1K1sVcI1zMsQYjIBY4zXo//AApLUT01mzx/1xauC8ND/iq9H/6/Yv8A0MV9TKoHOBVY6vUpTSgx 0oxabZ4t/wAKS1HvrNof+2TVTufg14gjDNb3mnzADOCzqT+hFe7YFIVH0+lcaxtbuaezifKOq6Rf 6HfNZalbNBOMHaeQw9QehqorMrBkYq6nKsOCD6ivd/i7pMV34Ra+2fvrORXVx/dJwR+orwfnPTtX q4Wt7and7mM48r0PoL4a+LG8SaCIbxt2oWZCTMerj+Fv6fhXbnhcDtXgfwgung8bmBSQlzbOHHrt wRXvuPrXj4ukqdVxR0Qldang3xe0j7D4qh1FEPk6hCC3p5ik5/TbXnpGVK/rXv8A8WNHOo+DWuok JmsZBMPZOj/pz+FeA4+XIP416uBnz0kn00OerG0j6Y8Fat/bPg/TLx2DSmAJKR2deG/WvO/jTqjP fabpSkYjQ3L/AFJKj+Rq98F9UMun6lo7OMwyC4jU9SGzu/UD868+8cap/bHjPVLlW3RCXyoz/srx /PNceHo2xLXY0nO9NPuc8ccknA9a+ivhppX9k+CLJXXbNdA3Mgx3bp+gFeB6NpjazrdlpiHBuZhG T6A9T+VfU8MYjQIgAVVwoA4A7VpmNTSMPmTQjuyYdBS0UV5ZuwooopCCiiimAUUUUAFFFFABRRRS AKKKKACiiimAUUUUAFFFFABRRRQAUUUUgCiiimAUUUUAFFFFIAooopgFFFFABRRRQAUUUUAFFFFA BRRRSAKKKKYBRRRQAUUUUAFFFFABRRRSAKKKKACiiimAUUUUgCiiigAooopgFFFFABRRRSAKKKKY BRRRQAUUUUAFFFFABRRRQAUUUUgCiiimAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRSAKKKKYBT T0/GnU1un40ho87+Mv8AyJcP/X5H/WvNvhif+LlaP/vTf+iXr0n4zf8AIlw/9fcf9a82+GP/ACUn R/8Aem/9EvXq4f8A3SXzMX/FR9I0UUV5RuFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAcV8V/+Scan /vQ/+jUrwvwwP+Ks0j/r8j/9Cr3T4r/8k41P/eh/9GpXhnhj/kbNI/6/I/8A0KvVwf8Au0/mYz+N H1MO9FA6n60V5Rqwooophcr3v/HnN/uN/I18lsPmb6n+dfWl7/x5y/7jfyNfJZ++31P869TLPtfL 9TCvvH5/oavhr/kbNGHf7bF/6GK+pVII4NfJdrdT2N5Dd2zBZoHDoxUNgg5HB+ldV/wtLxn21aIf 9ucdaYzC1K004ipzUVZn0XmkLD1r51/4Wl4z/wCgvF/4Bx/4VDN8SfGFzE0b6wQrdfKgRCPoRXIs vq90X7WJ6N8XtfgtfDx0aKUfa7t1LxjqIxzk+nIFeH1LcXM95cPcXU8k87nLSSMWY9uTURPfj8a9 PDUfY0+VmMpczO7+ENu8vjpZlUlYLd2c+gOAP1r6AzmvMvhDoD6dok+r3Meya+ceUCOREOB+Zyfy r00DA5ryMZNTrOx0wVola/tY72wuLSb/AFc8bRN9GGP618q6hYy6dqV1ZSghreZ4jnuFOAfywfxr 6xcdOcV4J8XNHGn+MFvUGIr+EMcD+NeD+mDW2X1OWo4dyay925g+D/EJ8Na5NehyqvaTR9M/MQCn /jwH51gEkklslicknuaQUV6qhFScurOdttWPRfg9pBvPE9zqUibo7KEKrHtI3Tj/AHQa91AP41wn wn0gad4MgmdNs967Tvkc7ckJ+mPzrvAMV4WKqe0rNnVBcsUhRxRRRWBVwooooEFFFFABRRRQNBRR RQIKKKKBoKKKKAuFFFFAgooooAKKKKACiiigAooooAKKKKBoKKKKAYUUUUCCiiigYUUUUCCiiigA ooooAKKKKACiiigAooooGFFFFAgooooGgooooAKKKKBBRRRQAUUUUAFFFFAwooooEFFFFAwooooB hRRRQIKKKKBoKKKKACiiigQUUUUAFFFFABRRRQAUUUUAFFFFA7hRRRQIKKKKACiiigAooopAFFFF MAooooGwooooEFFFFABRRRQNhRRRQIKKKKACiiigaCiiigQUUUUAFFFFA0FFFFAgooooAKKKKB2C iiigQUUUUAFFFFA7hTT0/GnU09PxpAjzv4y/8iVD/wBfkf8AWvNvhj/yUjR/96b/ANEvXpPxm/5E uH/r7j/rXm3wx/5KRo/+9N/6JevVw/8AukvmYP8Aio+kaKKK8o6AooooAKKKKACiiigAooooAKKK KACiiigDiviv/wAk51P/AHof/RqV4Z4X/wCRs0j/AK/I/wD0Kvc/iv8A8k41P/eh/wDRqV4Z4Y/5 GzSP+vyP/wBCr1cH/u0/mYz+NH1MO9FA70V5ZqwooooEVr5gLOYkgfIev0NfJTSxgtmRPvHuPU19 dugcYIyPQjrWWPDGhjk6TZE56mBf8K6sLiVQvdXuROnz2d9rnyv5sX/PRP8AvoUebF/z0T/voV9V f8I1of8A0CLH/wAB1/wo/wCEa0P/AKBFj/4Dr/hXX/acf5WR7HzPlXzYu8if99Ck8+H/AJ7xf99i vqseG9EBBGkWII/6d1/wqVdE0tTxptl+Fun+FL+0l0iP2K7nyrbxvdyeXbRvcO3AWFS5J+gzXofg /wCFeoajNHd69CbSyBz9mcfvJfqP4R9a9tisbaA/ubaGL3jQKf0qfYB71hWzCc1aKsVGlFO7GRRJ FEsUaBURQqgcAAdKlGaMZ6/pRmuE1eoj8jmvPvi7pJv/AAl9tRB5unyiYnHJQjaR+o/KvQGIIIri /ifrEemeCL2NiBPd4giHqT1/QGtaDftY8vcmfwu588gYqxY2jahqFrZRgeZcTJEM/wC0cfyzUHHI 9K7r4S6T/aHjL7Yygx6fEZOR/EwKr/Mmvfrz5Kbl2OSC5mke8WNoljZwWkYASCNY0A7BRgfyq1Ua dcmpO1fNo7WFFFFMkKKKKACiiikAUUUUDuFFFFMQUUUUAFFFFABRRRSAKKKKACiiimAUUUUAFFFF ABRRRQAUUUUAFFFFABRRRQMKKKKACiiikIKKKKYBRRRQAUUUUgCiiimAUUUUAFFFFIAooopgFFFF ABRRRQAUUUUgCiiimAUUUUAFFFFABRRRQAUUUUAFFFFABRRRSAKKKKACiiimAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFIAooooAKKKKY7hRRRQIKKKKQBRRRTAKKKKQBRRRTAKKKKACiii gAooooAKKKKACiiigAooooAKKKKB3CiiigQUUUUgCiiimAU1ug+tOprdPxpDR538Zf8AkS4f+vyP +tebfDH/AJKRo/8AvTf+iXr0r4y/8iZEP+nyMfzrzX4Yf8lI0b6zf+iXr1cP/ukvmYP+Kj6Rooor yjoCiiigAooooAKKKKACiiigAooooAKKKKAOK+LH/JONT/3of/RqV4Z4Y/5GvSP+vyP/ANCFe5/F f/knGp/70P8A6NSvC/DH/I2aR/1+R/8AoQr1cH/u0/mYz+NH1OO9FA70V5ZqwooooEFFFFIAoooo AKKKKYBiiiigArJ8R6qdD8PX+qLCZjaQtL5YON2PetasXxTb/afCesQn+O0kH/jpoSvJD6HAj412 Xk/8ga4Evp5q4/PH9K848VeLL7xZqgu7tfKijBWG3ViQgPf3NYEeSi5PbvSkjGWAA969+lhaVKXN FanNKpJ6MO/UY9696+E2h/2d4RF7KoE+oP53uI8AKP0J/GvNPA/ge98T6hHLLFJFpSMDLKwK+YB/ Cvrn1r6IghSCBYokVI0G1VXoAOlcePr3Xs4v1Loxt7xIFwadRRXlmzCiiimIKKK5zxzI6eCNXdGZ GWAkMpwRyOhpxV2kPZHR4owa+TRqeoYB/tC7Pv57c/rR/aeof8/13/3+b/GvQ/s2X8xl7Vdj6ywa MGvk3+09R/5/7v8A7/N/jR/aeo/8/wDd/wDf5v8AGj+zZ/zB7Vdj6ywaMGvk3+1NR/5/7v8A7/t/ jR/amo/8/wDd/wDf9v8AGj+zp/zB7VH1lg0YNfJv9qaj/wA/93/3/b/Gj+1NQ/5/7v8A7/N/jR/Z s/5g9qj6ywaMGvk06nqH/P8A3f8A3+b/ABpP7T1D/n+uv+/zf40f2dP+YPao+s8GjBr5NGp6h/z/ AF3/AN/m/wAaP7U1H/n+u/8Av83+NH9mz/mD2qPrLBowa+TP7T1H/n/u/wDv83+NKNT1D/n/ALv/ AL/N/jR/Zs/5g9qj6ywaMGvk3+1NR/5/7v8A7/t/jSf2nqH/AD/3f/f5v8aP7On/ADB7VH1ng0YN fJo1PUP+f+7/AO/zf40f2pqH/P8A3f8A3+b/ABo/s6f8we1R9ZYNGDXyZ/aeof8AP9df9/m/xpf7 T1DH/H/d/wDf5v8AGj+zp/zB7VH1lg0YNfJv9qah/wA/13/3+b/Gj+1NQ/5/7v8A7/N/jR/Z0/5g 9qj6ywaMGvk3+1NQ/wCf67/7/N/jS/2pqH/P/d/9/m/xo/s2f8we1R9Y4NGDXyadT1D/AJ/rv/v8 3+NH9p6h/wA/13/3+b/Gj+zp/wAwe1R9ZYNGDXyb/aeo/wDP/d/9/m/xo/tPUf8An/u/+/zf40f2 dP8AmD2qPrLBowa+Tf7U1D/n/u/+/wA3+NH9p6j/AM/93/3/AG/xo/s6f8we1R9ZYNGDXyb/AGnq P/P/AHf/AH/b/Gk/tPUP+f66/wC/zf40f2bP+YPao+s8GjBr5M/tPUP+f66/7/N/jS/2nqGP+P8A u/8Av83+NH9nT/mD2qPrLBowa+TP7T1D/n+uv+/zf40v9qaj/wA/93/3/b/Gj+zZ/wAwe1R9ZYNG DXyZ/aeof8/11/3+b/Gl/tTUf+f+7/7/ALf40f2bP+YPao+ssGjBr5N/tTUf+f8Au/8Av+3+NA1T UP8An/u/+/zf40f2bP8AmD2qPrLBowa+Tf7U1D/n/u/+/wA3+NH9qah/z/3f/f5v8aP7On/MHtUf WWDRg18mnU9Q/wCf67/7/N/jR/aeof8AP/d/9/m/xo/s2f8AMHtUfWWDRg18m/2nqH/P9d/9/m/x o/tTUf8An/u/+/7f40f2bP8AmD2qPrLBowa+Tf7U1H/n/u/+/wC3+NH9p6h/z/Xf/f5v8aP7Nn/M HtUfWWDRg18m/wBp6h/z/XX/AH+b/Gg6nqH/AD/3f/f5v8aP7On/ADB7VH1lg0YNfJn9p6h/z/XX /f5v8aX+09Q/5/rv/v8AN/jR/Zs/5g9qj6ywaMGvk3+09R/5/wC7/wC/zf40f2nqH/P9df8Af5v8 aP7On/MHtUfWWDRg18m/2nqGf+P67/7/ADf40f2pqH/P/d/9/m/xo/s6f8we1R9ZYNGDXyb/AGnq H/P9df8Af5v8aBqeof8AP/d/9/m/xo/s6f8AMHtUfWWDRg18m/2pqP8Az/3f/f8Ab/Gj+09R/wCf +7/7/t/jR/Z0/wCYParsfWWDRg18mnU9R/5/7v8A7/N/jR/aeo/8/wDd/wDf5v8AGj+zp/zB7VH1 lg0YNfJv9qah/wA/93/3+b/Gj+09R/5/7v8A7/t/jR/Z0/5g9qj6ywaMGvk3+09R/wCf66/7/N/j Sf2nqH/P9df9/m/xo/s2f8we1R9Z4NGDXyb/AGpqP/P/AHf/AH/b/Gj+1NR/5/7v/v8At/jR/Zs/ 5g9qj6ywaMGvk3+1NR/5/wC7/wC/7f40v9qah/z/AF3/AN/2/wAaP7Nn/MHtUfWODRg18mnVNRP/ AC/3f/f9v8aP7U1H/n/u/wDv+3+NH9nT/mD2qPrLBowa+TP7T1D/AJ/7v/v+3+NKNU1D/n+u/wDv +3+NH9nT/mD2qPrLBowa+Tf7T1DP/H9d/wDf5v8AGj+1NR/5/wC7/wC/zf40f2bP+YPao+ssGjBr 5M/tPUf+f+7/AO/zf40v9p6j/wA/11/3+b/Gj+zp/wAwe1R9ZYNGDXyZ/aeof8/11/3+b/Gl/tPU f+f66/7/ADf40f2bP+YPao+ssGjBr5M/tPUf+f8Au/8Av83+NL/aeo/8/wDd/wDf5v8AGj+zp/zB 7VH1lg0YNfJv9qahj/j/ALv/AL/N/jQNT1D/AJ/7v/v83+NH9nT/AJg9qj6ywaMGvk3+09Qz/wAf 13/3+b/Gk/tPUP8An+uv+/zf40f2bP8AmD2qPrPBowa+TP7T1D/n+uv+/wA3+NH9p6h/z/XX/f5v 8aP7Nn/MHtUfWeDRg18m/wBp6h/z/Xf/AH+b/Gj+09R/5/7v/v8At/jR/Z0/5g9qj6ywaMGvkz+0 9R/5/wC7/wC/zf40v9p6j3v7v/v+3+NH9nT/AJg9qj6ywaMGvk3+1NQ/5/7v/v8AN/jSf2nqP/P9 df8Af5v8aP7Nn/MHtUfWeDRg18m/2pqP/P8A3f8A3/b/ABpP7T1D/n+u/wDv83+NH9nT/mD2qPrP Bowa+Tf7T1D/AJ/rv/v83+NH9qaj/wA/93/3/b/Gj+zp/wAwe1R9ZYNGDXyZ/aeo/wDP/d/9/m/x pf7T1H/n/u/+/wA3+NH9nT/mD2qPrLBowa+Tf7U1D/n/ALv/AL/N/jR/amof8/8Ad/8Af5v8aP7O n/MHtUfWWDRg18m/2pqP/P8A3f8A3/b/ABo/tPUf+f8Au/8Av+3+NH9nT/mD2qPrLBowa+Tf7U1H /n/u/wDv+3+NH9qaj/z/AN3/AN/2/wAaP7Nn/MHtUfWWDRg18mf2nqH/AD/XX/f5v8aUanqH/P8A 3f8A3+b/ABo/s6f8we1R9ZYNGDXyb/aeof8AP9d/9/m/xo/tTUP+f+7/AO/7f40f2bP+YPao+ssG jBr5N/tPUf8An/u/+/7f40n9p6j/AM/93/3+b/Gj+zZ/zB7VH1ng0YNfJo1PUf8An/u/+/zf40f2 pqP/AD/3f/f9v8aP7On/ADB7VH1lRXy5oupag/iDSle/u9jX1uGUzMcgyqOma+oRXLiMO6DSbvcu ElJaDqKKK5ymFFFFMApp6D606mnp+NIEed/GX/kSoj3+2R/1rzb4Y/8AJSNH+s3/AKJevSfjN/yJ cP8A1+R/1rzb4Yn/AIuTo/1m/wDRL16uH/3SXzMX/FR9I0UUV5RuFFFFABRRRQAUUUUAFFFFABRR RQAUUUUAcV8V/wDknGp/70P/AKNSvC/DA/4qzSP+vyP/ANCFe6fFj/knGp/70P8A6NSvDPDH/I2a R/1+R/8AoQr1cH/u0/mYz+NH1MO9FHrRXlGrCiiimIKKKKACiiigAooooAKKKKACmSRJLG0bgMjA qwPcGn0Uh3OTn+GvhG5Ys+jRAnrsdl/kaksvh34VsJRJBo8G8dDIS/8AMmuooq1Una3MxWW9iKOB I1VUUKqjCqBgD6CpQMDFFFQO4UUUUxBRRRQNBVTUdOttUsZ7K7QyW8y7XTJGR9RzVuigLnGD4V+D sY/sr8p3/wAaX/hVfg7/AKBJ/wC/8n+NdlRV+1qfzP7yeWPZHG/8Ks8Hf9Ao/wDf9/8AGj/hVng7 /oEn/v8Av/jXZUUe1qfzP7w5Y9l9xxv/AAqvwd/0Cj/3/f8Axo/4VX4O/wCgSf8Av/J/jXZUUe1q fzP7w5Y9kcb/AMKr8Hf9Ak/9/wCT/Gj/AIVX4O/6BJ/7/wAn+NdlRR7Wp/M/vDkj2Rxv/Cq/B3/Q JP8A3/k/xo/4VX4O/wCgSf8Av/J/jXZUUe1qfzP7w5Y9kcb/AMKr8Hf9Ak/9/wCT/Gj/AIVX4O/6 BJ/7/wAn+NdlRR7Wp/M/vDlj2Rxv/Cq/B3/QKP8A3/f/ABo/4VX4O/6BJ/7/AMn+NdlRR7Wp/M/v Dlj2Rxv/AAqvwd/0CT/3/k/xo/4VX4O/6BJ/7/yf412VFHtqn8z+8OSPZHG/8Kr8Hf8AQJP/AH/k /wAaP+FV+Dv+gSf+/wDJ/jXZUUe1qfzP7w5I9kcb/wAKr8Hf9Ak/9/5P8aP+FV+Dv+gSf+/8n+Nd lRR7Wp/M/vDkj2Rxv/Cq/B3/AECT/wB/5P8AGj/hVfg7/oEn/v8Ayf412VFHtan8z+8OSPZHG/8A Cq/B3/QJP/f+T/Gj/hVfg7/oEn/v/J/jXZUUe1qfzP7w5I9kcb/wqvwd/wBAk/8Af+T/ABo/4VX4 O/6BJ/7/AMn+NdlRR7Wp/M/vDlj2Rxv/AAqvwd/0CT/3/f8Axo/4VX4O/wCgSf8Av+/+Ndl+NFHt qn8z+8OWPZHG/wDCq/B3/QJP/f8Ak/xo/wCFV+Dv+gSf+/7/AONdlRR7Wp/M/vDlj2Rxv/CrPB3/ AECj/wB/3/xo/wCFV+Dv+gSf+/8AJ/jXZUUe1qfzP7w5Y9kcb/wqvwd/0CT/AN/5P8aP+FV+Dv8A oEn/AL/yf412VFHtan8z+8OWPZHG/wDCq/B3/QJP/f8Ak/xo/wCFV+Dv+gSf+/8AJ/jXZUUe1qfz P7w5Y9kcb/wqvwd/0CT/AN/5P8aP+FV+Dv8AoEn/AL/yf412VFHtan8z+8OWPZHG/wDCq/B3/QKP /f8Af/Gj/hVfg7/oEn/v/J/jXZUUe1qfzP7w5Y9kcb/wqvwd/wBAk/8Af+T/ABo/4VX4O/6BJ/7/ AMn+NdlRR7ap/M/vDkj2Rxv/AAqvwd/0CT/3/k/xo/4VX4O/6BJ/7/yf412VFHtan8z+8OWPZHG/ 8Kr8Hf8AQKP/AH/f/Gj/AIVX4O/6BR/7/v8A412VFHtan8z+8OWPZHG/8Kr8Hf8AQJP/AH/k/wAa P+FV+Dv+gSf+/wDJ/jXZUUe1qfzP7w5Y9kcb/wAKr8Hf9Ak/9/5P8aP+FV+Dv+gSf+/8n+NdlRR7 Wp/M/vDlj2Rxv/Cq/B3/AECT/wB/5P8AGj/hVfg7/oFH/v8Ayf412VFHtqn8z+8OSPZHG/8ACq/B 3/QJP/f9/wDGj/hVfg7/AKBJ/wC/8n+Ndl+NFHtan8z+8OSPZHG/8Kr8Hf8AQJP/AH/k/wAaP+FV +Dv+gSf+/wDJ/jXZUUe1qfzP7w5I9kcb/wAKr8Hf9Ak/9/5P8aP+FV+Dv+gSf+/8n+NdlRR7Wp/M /vDkj2Rxv/Cq/B3/AECT/wB/5P8AGj/hVfg7/oEn/v8Av/jXZUfjR7Wp/M/vDkj2X3HG/wDCrPB3 /QKP/f6T/Gj/AIVX4O/6BJ/7/wAn+NdlRR7Wp/M/vDlj2X3HG/8ACq/B3/QJP/f+T/Gj/hVfg7/o FH/v+/8AjXZUUe1qfzP7w5Y9kcb/AMKr8Hf9Ak/9/wCT/Gj/AIVX4O/6BJ/7/wAn+NdlRR7Wp/M/ vDlj2Rxv/Cq/B3/QKP8A3/f/ABo/4VX4O/6BJ/7/AMn+NdlRR7ap/M/vDkj2Rxv/AAqvwd/0CT/3 /k/xo/4VX4O/6BJ/7/yf412VFHtan8z+8OWPZHG/8Kr8Hf8AQKP/AH/f/Gj/AIVX4O/6BR/7/wAn +NdlRR7Wp/M/vDlj2Rxv/Cq/B3/QJP8A3/k/xo/4VX4O/wCgSf8Av/J/jXZUUe2qfzP7w5I9kcb/ AMKr8Hf9Ak/9/wCT/Gj/AIVX4O/6BJ/7/wAn+NdlRR7Wp/M/vDkj2Rxv/Cq/B3/QKP8A3/f/ABo/ 4VX4O/6BJ/7/AMn+NdlRR7ap/M/vDkj2Rxv/AAqvwd/0CT/3/k/xo/4VX4O/6BR/7/v/AI12VFHt an8z+8OWPZHG/wDCq/B3/QKP/f8Af/Gj/hVfg7/oFH/v/J/jXZUUe1qfzP7w5Y9kcb/wqzwd/wBA k/8Af+T/ABo/4VX4O/6BJ/7/AMn+NdlRR7Wp/M/vDkj2Rxv/AAqvwd/0CT/3/k/xo/4VX4O/6BJ/ 7/yf412VFHtqn8z+8OSPZHG/8Kr8Hf8AQJP/AH/k/wAaP+FV+Dv+gSf+/wDJ/jXZUUe1qfzP7w5Y 9kcb/wAKr8Hf9Ao/9/5P8aP+FV+Dv+gUf+/7/wCNdlRR7ap/M/vDlj2Rxv8Awqvwd/0Cj/3/AJP8 aP8AhVfg7/oEn/v+/wDjXZUfjR7ap/M/vDkj2Rxv/Cq/B3/QJP8A3/k/xo/4VX4O/wCgUf8Av+/+ NdlRR7Wp/M/vDkj2Rxv/AAqvwd/0Cj/3/k/xo/4VX4O/6BJ/7/yf412VFHtan8z+8OSPZHG/8Kr8 Hf8AQJP/AH/k/wAaP+FV+Dv+gSf+/wC/+NdlRR7Wp/M/vDlj2Rxv/Cq/B3/QKP8A3/k/xo/4VX4O /wCgSf8Av+/+NdlRR7Wp/M/vDlj2Rxv/AAqvwd/0CT/3/k/xo/4VX4O/6BJ/7/yf412VFHtan8z+ 8OWPZHG/8Kr8Hf8AQJP/AH/k/wAaP+FV+Dv+gUf+/wC/+NdlRR7Wp/M/vDlj2Rxv/Cq/B3/QKP8A 3/f/ABo/4VX4O/6BJ/7/AMn+NdlRR7Wp/M/vDlj2Rxv/AAqvwd/0CT/3/k/xo/4VX4O/6BJ/7/yf 412VFHtan8z+8OSPZHG/8Kr8Hf8AQJP/AH/k/wAaP+FV+Dv+gSf+/wDJ/jXZUUe2qfzP7w5I9kcb /wAKr8Hf9Ak/9/3/AMaP+FWeDv8AoEn/AL/v/jXZUUe2qfzP7w5Y9kcb/wAKs8Hf9Ak/9/pP8aP+ FV+Dv+gUf+/7/wCNdlRR7Wp/M/vDlj2X3HIwfDPwna3MNxBpmyWGRZY281zhlIYHk+orrAuBTqKm UpS+J3KWmwUUUUgCiiigQU09Pxp1NPT8aQ0ed/Gb/kS4f+vuP+tebfDEf8XJ0c+83/ol69J+M3/I lw/9fcf9a82+GP8AyUjR/wDem/8ARL16uH/3SXzMX/FR9I0UUV5RuFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAcV8WP8AknGp/wC9D/6NSvC/DH/I2aR/1+R/+hCvdPiv/wAk41P/AHof/RqV4R4enhtf Eml3Fw6xxR3cbO7HAADZJr1sFf6vK3mYVHaaPqr1orlf+FkeDh18Q2X/AH0f8KP+Fk+Dv+hhsv8A vo/4V5fs59n9xtdHVUVyv/CyfB3/AEMNl/30f8KP+Fk+Dv8AoYbL/vo/4U/Z1P5X9waHVUVyv/Cy fB3/AEMNl/30f8KP+Fk+Dv8AoYbL/vo/4Uezqfyv7g0Oqorlf+Fk+Dv+hhsv++j/AIUf8LJ8Hf8A Qw2X/fR/wo9nPs/uDQ6qiuV/4WT4N/6GGy/76P8AhR/wsnwd/wBDDZf99H/Cj2c+z+4NDqqK5X/h ZPg7/oYbL/vo/wCFH/CyfB3/AEMNl/30f8KPZ1Oz+4NDqqK5X/hZHg//AKGGy/76P+FH/CyPB3/Q w2X/AH0f8KPZz7P7g0Oqorlf+Fk+Dv8AoYbL/vo/4Uf8LJ8G/wDQw2X/AH0f8KPZz7P7g0Oqorlf +Fk+Dv8AoYbL/vo/4Uf8LJ8Hf9DDZf8AfR/wo9nPs/uDQ6qiuV/4WT4O/wChhsv++j/hR/wsnwd/ 0MNl/wB9H/Cj2c+z+4NDqqK5X/hZPg3/AKGGy/76P+FH/CyfBv8A0MNl/wB9H/Cj2c+z+4NDqqK5 X/hZPg7/AKGGy/76P+FH/CyfB3/Qw2X/AH0f8KPZz7P7g0Oqorlf+Fk+Dv8AoYbL/vo/4Uf8LJ8H f9DDZf8AfR/wo9nU7P7g0Oqorlf+Fk+Dv+hhsv8Avo/4Uf8ACyPB3/Qw2X/fR/wo9nU7P7g0Oqor lf8AhZHg/wD6GGy/76P+FH/CyPB//Qw2X/fR/wAKPZz7P7g0Oqorlf8AhZPg7/oYbL/vo/4Uf8LJ 8Hf9DDZf99H/AAo9nU7P7g0Oqorlf+Fk+Dv+hhsv++j/AIUf8LJ8Hf8AQw2X/fR/wo9nU/lf3Bod VRXK/wDCyfBv/Qw2X/fR/wAKP+Fk+Df+hhsv++j/AIUezn2f3BodVRXK/wDCyfBv/Qw2X/fR/wAK P+Fk+Dv+hhsv++j/AIUezn2f3BodVRXK/wDCyfB3/Qw2X/fR/wAKP+Fk+Dv+hhsv++j/AIUezqfy v7g0Oqorlf8AhZPg7/oYbL/vo/4Uf8LJ8Hf9DDZf99H/AAo9nU/lf3BodVRXK/8ACyfB3/Qw2X/f R/wo/wCFk+Dv+hhsv++j/hR7Op2f3BodVRXK/wDCyPB3/Qw2X/fR/wAKP+Fk+Dv+hhsv++j/AIUe zn2f3BodVRXK/wDCyfB3/Qw2X/fR/wAKP+Fk+Df+hhsv++j/AIUezn2f3BodVRXK/wDCyfB3/Qw2 X/fR/wAKP+Fk+Dv+hhsv++j/AIUezn2f3BodVRXK/wDCyfB3/Qw2X/fR/wAKP+Fk+Dv+hhsv++j/ AIUezqfyv7g0Oqorlf8AhZPg7/oYbL/vo/4Uf8LJ8G/9DDZf99H/AAo9nP8Alf3BodVRXK/8LJ8G /wDQw2X/AH0f8KP+Fk+Dv+hhsv8Avo/4Uezn2f3BodVRXK/8LJ8Hf9DDZf8AfR/wo/4WT4N/6GGy /wC+j/hR7OfZ/cGh1VFcr/wsnwb/ANDDZf8AfR/wo/4WT4N/6GGy/wC+j/hR7OfZ/cGh1VFcr/ws nwb/ANDDZf8AfR/wo/4WT4O/6GGy/wC+j/hR7OfZ/cGh1VFcr/wsnwd/0MNl/wB9H/Cj/hZPg3/o YbL/AL6P+FHs59n9waHVUVyv/CyfBv8A0MNl/wB9H/Cj/hZPg3/oYbL/AL6P+FHs59n9waHVUVyv /CyfBv8A0MNl/wB9H/Cj/hZPg7/oYbL/AL6P+FHs59n9waHVUVyv/CyfB3/Qw2X/AH0f8KP+Fk+D v+hhsv8Avo/4Uezqdn9waHVUVyv/AAsnwd/0MNl/30f8KP8AhZPg7/oYbL/vo/4Uezqdn9waHVUV yv8Awsnwd/0MNl/30f8ACj/hZPg3/oYbL/vo/wCFHs59n9waHVUVyv8Awsnwd/0MNl/30f8ACj/h ZPg7/oYbL/vo/wCFHs5/yv7g0Oqorlf+Fk+Dv+hhsv8Avo/4Uf8ACyfB3/Qw2X/fR/wo9nU/lf3B dHVUVyv/AAsnwd/0MNl/30f8KP8AhZPg7/oYbL/vo/4Uezqfyv7g0Oqorlf+Fk+Dv+hhsv8Avo/4 Uf8ACyfB3/Qw2X/fR/wo9nP+V/cGh1VFcr/wsnwb/wBDDZf99H/Cj/hZPg7/AKGGy/76P+FHs59n 9waHVUVyv/CyfB3/AEMNl/30f8KP+Fk+Df8AoYbL/vo/4Uezn2f3BodVRXK/8LJ8Hf8AQw2X/fR/ wo/4WT4O/wChhsv++j/hR7OfZ/cGh1VFcr/wsnwb/wBDDZf99H/Cj/hZPg7/AKGGy/76P+FHs59n 9waHVUVyv/CyfBv/AEMNl/30f8KP+Fk+Df8AoYbL/vo/4Uezn2f3BodVRXK/8LJ8G/8AQw2X/fR/ wo/4WT4O/wChhsv++j/hR7OfZ/cGh1VFcr/wsnwd/wBDDZf99H/Cj/hZPg7/AKGGy/76P+FHs59n 9waHVUVyv/CyfB3/AEMNl/30f8KP+Fk+Dv8AoYbL/vo/4Uezn/K/uDQ6qiuV/wCFk+Dv+hhsv++j /hR/wsnwd/0MNl/30f8ACj2dT+V/cGh1VFcr/wALI8H/APQw2X/fR/wo/wCFk+Dv+hhsv++j/hR7 OfZ/cGh1VFcr/wALJ8G/9DDZf99H/Cj/AIWT4O/6GGy/76P+FHs59n9waHVUVyv/AAsnwd/0MNl/ 30f8KP8AhZHg7/oYbL/vo/4Uezqdn9waHVUVyv8Awsnwd/0MNl/30f8ACj/hZPg7v4hsv++j/hR7 OfZ/cF0dVRXK/wDCyfBv/Qw2X/fR/wAKP+Fk+Df+hhsv++j/AIUezn2f3BodVRXK/wDCyfBv/Qw2 X/fR/wAKP+Fk+Dv+hhsv++j/AIUezqfyv7g0Oqorlf8AhZPg7/oYbL/vo/4Uf8LJ8Hf9DDZf99H/ AAo9nPs/uDQ6qiuV/wCFk+Df+hhsv++j/hR/wsnwb/0MNl/30f8ACj2c+z+4NDqqK5X/AIWT4O/6 GGy/76P+FH/CyfB3/Qw2X/fR/wAKPZz7P7g0Oqorlf8AhZPg7/oYbL/vo/4Uf8LI8Hf9DDZf99H/ AAo9nU7P7gujqqK5X/hZPg7/AKGGy/76P+FH/CyfBv8A0MNl/wB9H/Cj2c+z+4NDqqK5X/hZPg7/ AKGGy/76P+FH/CyfB3/Qw2X/AH0f8KPZ1Oz+4NDqqK5X/hZPg7/oYbL/AL6P+FH/AAsjwd/0MNl/ 30f8KPZ1Oz+4NDqqK5X/AIWT4O/6GGy/76P+FH/CyfB3/Qw2X/fR/wAKPZz7P7g0Oqorlf8AhZPg 3/oYbL/vo/4Uf8LJ8Hf9DDZf99H/AAo9nPs/uDQ6qiuV/wCFk+Dv+hhsv++j/hR/wsnwd/0MNl/3 0f8ACj2dTs/uDQ6qiuV/4WR4O/6GGy/76P8AhR/wsnwd/wBDDZf99H/Cj2c/5X9waHVUVyv/AAsn wd/0MNl/30f8KP8AhZPg3/oYbL/vo/4Uezn2f3BodVRXK/8ACyfBv/Qw2X/fR/wo/wCFk+Df+hhs v++j/hR7OfZ/cGh1VFcr/wALJ8G/9DDZf99H/Cj/AIWT4N/6GGy/76P+FHs59n9waHVUVyv/AAsn wb/0MNl/30f8KP8AhZPg7/oYbL/vo/4Uezn2f3BodVRXK/8ACyfBv/Qw2X/fR/wo/wCFk+Dv+hhs v++j/hR7OfZ/cGh1VNPT8a5f/hZPg7/oYbL/AL6P+FJ/wsbwe3A8RWX/AH0f8KPZz7P7gujE+M3/ ACJcP/X3H/WvNvhj/wAlI0f/AHpv/RL12PxP8V6DrvhRLXTNWtbqdblHKIxzgZ9q474Y/wDJSNH/ AN6b/wBEvXp0E1hZJ+ZhL+Ij6RoooryToCiiigAooooAKKKKACiiigAooooAKKKKAOK+K4J+HOpg Asd0PAGT/rUr532vziN/++TX14VBpNg9K68Pi3Ri42uZTpuTumfIu1wPuOPbaaMSf3H/AO+TX11t HpRtFdH9pP8AlI9i+58i4k/uP/3yaMSf3H/75NfXW0en6UbR6fpR/aT/AJfxF7B9z5Fw/wDcf/vk 0Yk/uP8A98mvrrYKNo9P0o/tJ/y/iHsH3PkXEn9x/wDvk0Yf+4//AHya+uto9P0o2Cj+0n/L+Iew fc+RcP8A3H/75P8AhRiT+4//AHya+utgo2D0/Sj+0n/L+Iewfc+RcSf3H/75NGH/ALj/APfJr662 j0/SjYKP7Sf8v4h7B9z5Ew/9x/8Avk0uH/uP/wB8mvrvaPSk2Cj+0n/L+Iewfc+RcSf3H/75NGJP 7j/98mvrraPT9KNg9KP7Sf8AL+Iewfc+RcP/AHH/AO+T/hRiT+4//fJr662CjYPT9KP7Sf8AL+Ie wfc+RMSf3H/75NLh/wC4/wD3ya+utgpdo9KP7Sf8v4h7B9z5ExJ/cf8A75NGJP7j/wDfJr662D0o 2j0/Sj+0n/L+Iewfc+RcSf3H/wC+TRiT+4//AHya+uto9P0o2Cj+0n/L+Iewfc+RcP8A3H/75P8A hRh/7j/98n/CvrrYKNgo/tJ/y/iHsH3PkXD/ANx/++TRiT+4/wD3ya+u9o9KTaPSj+0n/L+Iewfc +RMSf3H/AO+TS4k/uP8A98mvrvaKTaPSj+0n/L+I/YvufIuJP7j/APfJow/9x/8Avk19dbR6UbBR /aT/AJfxF7B9z5FxJ/cf/vk0Yk/uP/3ya+uto9P0o2j0/Sj+0n/L+Iewfc+RcSf3H/75NGJP7j/9 8mvrraPT9KNo9KP7Sf8AL+Iewfc+RcSf3H/75NGH/uP/AN8mvrraPSjYKP7Sf8v4h7B9z5Fw/wDc f/vk0Yk/uP8A98mvrrYKNg9P0o/tJ/y/iHsH3PkXD/3H/wC+TRh/7j/98mvrrYPQUbBR/aT/AJfx D2D7nyLiT+4//fJoxJ/cf/vk19dbR6fpRtHp+lH9pP8Al/EPYPufIuJP7j/98mjEn9x/++TX11tH pRtHpR/aT/l/EfsH3PkXEn9x/wDvk0Yk/uP/AN8mvrraPT9KNoo/tJ/y/iL2D7nyLh/7j/8AfJ/w ow/9x/8Avk19dbR6UbBR/aT/AJfxD2D7nyLh/wC4/wD3yaMSf3H/AO+TX11sFG0en6Uf2k/5fxD2 D7nyLiT+4/8A3yaMSf3H/wC+TX11tHp+lG0en6Uf2k/5fxD2D7nyLiT+4/8A3yaMSf3H/wC+TX11 tHp+lG0en6Uf2k/5fxD2D7nyLiT+4/8A3yaMSf3H/wC+TX11tHp+lG0en6Uf2k/5fxD2D7nyLh/7 j/8AfJpMP/cf/vk19d7R6Uu0elH9pP8Al/EPYPufImH/ALj/APfJpMP/AHH/AO+TX13tHpS7R6Uf 2k/5fxD2D7nyJh/7j/8AfJow/wDcf/vk19dbBRsFH9pP+X8Q9g+58iYf+4//AHyaXD/3H/75P+Ff Xe0elJsFH9pP+X8Q9g+58i4f+4//AHyaMP8A3H/75NfXWwego2Cj+0n/AC/iHsH3PkXD/wBx/wDv k0Yk/uP/AN8mvrrYKNg9P0o/tJ/y/iHsH3PkXEn9x/8Avk0Yf+4//fJ/wr662D0/SjYKP7Sf8v4h 7B9z5FxJ/cf/AL5NGH/uP/3ya+utg9KNg9BR/aT/AJfxD2D7nyLiT+4//fJoxJ/cf/vk19dbB6fp RtHp+lH9pP8Al/EPYPufIuJP7j/98mjD/wBx/wDvk19dbR6fpRsFH9pP+X8Q9g+58i4f+4//AHya MSf3H/75NfXe0elJtFH9pP8Al/EPYPufImJP7j/98mjD/wBx/wDvk19d7R6UbR6fpR/aT/l/EPYP ufIuJP7j/wDfJpMSf3H/AO+TX13tHp+lGwUf2k/5fxD2D7nyLh/7j/8AfJpMP/cf/vk19ebR6Um0 elH9pP8Al/EPYPufIuJP7j/98mjEn9x/++TX11tHp+lG0en6Uf2k/wCX8Q9g+58i4k/uP/3yaMP/ AHH/AO+T/hX11tHp+lGwUf2k/wCX8Q9g+58iYf8AuP8A98mlw/8Acf8A75NfXe0elJsFH9pP+X8Q 9g+58i4f+4//AHyaMSf3H/75NfXWwUbB6Uf2k/5fxD2D7nyLh/7j/wDfJow/9x/++T/hX11sFGwU f2k/5fxD2D7nyJh/7j/98mlw/wDcf/vk19d7R6Um0elH9pP+X8Q9g+58i4f+4/8A3yaMP/cf/vk1 9dbBRsHoKP7Sf8v4h7B9z5Fw/wDcf/vk/wCFGJP7j/8AfJr662CjYPSj+0n/AC/iHsH3PkXD/wBx /wDvk0mH/uP/AN8mvrzaPSk2Cj+0n/L+Iewfc+RcSf3H/wC+TRh/7j/98mvrrYPT9KNg9BR/aT/l /EPYPufIuJP7j/8AfJow/wDcf/vk19dbR6fpRsFH9pP+X8Q9g+58i4k/uP8A98mjEn9x/wDvk19d bB6fpRtHp+lH9pP+X8Q9g+58i4k/uP8A98mjD/3H/wC+TX11tHp+lGwUf2k/5fxD2D7nyLiT+4// AHyaMP8A3H/75NfXW0elLtHpR/aT/l/EPYPufImJP7j/APfJow/9x/8Avk19dbB6Uu0elH9pP+X8 Q9g+58h4f+4//fJpcP8A3H/75NfXWwUbR6Uf2k/5fxD2D7nyLh/7j/8AfJoxJ/cf/vk/4V9dbBRt FH9pP+X8Q9g+58i4k/uP/wB8mjEn9x/++TX11tHpRtHp+lH9pP8Al/EPYPufIuJP7j/98mjD/wBx /wDvk/4V9dbB6fpRsFH9pP8Al/EPYPufIuJP7j/98mjEn9x/++TX11sFG0en6Uf2k/5fxD2D7nyL h/7j/wDfJoxJ/cf/AL5NfXWwUbB6Uf2k/wCX8Q9g+58i4f8AuP8A98mjEn9x/wDvk19dbBRsHpR/ aT/l/EPYPufIuH/uP/3yaMSf3H/75NfXWwUbR6fpR/aT/l/EPYPufIuJP7j/APfJow/9x/8Avk/4 V9dbBRsFH9pP+X8Q9g+58i4f+4//AHyf8KMSf3H/AO+TX11sFG0en6Uf2k/5fxD2D7nyLiT+4/8A 3yaMSf3H/wC+TX11tHp+lGwelH9pP+X8Q9g+58i4f+4//fJpMP8A3H/75NfXewUu0elH9pP+X8Q9 g+58iYk/uP8A98mjD/3H/wC+TX11sHpRsFH9pP8Al/EPYPufIuJP7j/98mjD/wBx/wDvk19dbB6U bBR/aT/l/EPYPufIuH/uP/3yaMP/AM83/wC+TX11sFGwelH9pP8Al/EPYPufImJP7rj/AICa6z4Y qw+JOkfI/HnEnacD9y4/rX0ftHtRsFRUzBzg48u5UaTTuOooorzzcKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAP/ 2Q== --94eb2c0cc3f4e0af2d0554be428e Content-Type: image/jpeg; name="EVE-8122.jpg" Content-Disposition: inline; filename="EVE-8122.jpg" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: ii_j5cdbad81_15d5fcee8e08fec7 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAQCAwMDAgQDAwMEBAQEBQkGBQUFBQsICAYJDQsNDQ0L DAwOEBQRDg8TDwwMEhgSExUWFxcXDhEZGxkWGhQWFxb/2wBDAQQEBAUFBQoGBgoWDwwPFhYWFhYW FhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhb/wAARCAOEBFwDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD7+ooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooADTHlVe tOc4FY+t3ogQ5YZoAvTX0aEgsKrPq0KnlxXnfiXxWls75k5HpzXJXvj/AGPjfIfopoA9w/tiD++K P7Yg/vivCD8QD/el/wC+TR/wsE/3pf8Avk0Ae7/2xB/fFH9sQf3xXhH/AAsE/wB6X/vk0H4gH+9L /wB8mgD3f+2IP74o/tiD++K8I/4WCf70v/fJo/4WCf70v/fJoA93/tiD++KP7Yg/vivCP+Fgn+9L /wB8mj/hYJ/vS/8AfJoA93/tiD++KP7Yg/vivCP+Fgn+9L/3yaP+Fgn+9L/3yaAPd/7Yg/vij+2I P74rwj/hYB/vS/8AfJo/4WAf70v/AHyaAPd/7Yg/vij+2IP74rwg/EA/3pf++TR/wsE/3pf++TQB 7v8A2xB/fFH9sQf3xXhH/CwT/el/75NA+IBP8Uv/AHyaAPd/7Yg/vij+2IP74rwg/EA/3pf++TR/ wsE/3pf++TQB7v8A2xB/fFH9sQf3xXhH/CwD/el/75NH/CwT/el/75NAHu/9sQf3xR/bEH98V4R/ wsA/3pf++TR/wsA/3pf++TQB7v8A2xB/fFH9sQf3xXhH/CwD/el/75NH/CwD/el/75NAHu/9sQf3 xR/bEH98V4R/wsA/3pf++TQfiAf70v8A3yaAPd/7Yg/vij+2IP74rwj/AIWCf70v/fJo/wCFgH+9 L/3yaAPd/wC2IP74o/tiD++K8I/4WAf70v8A3yaP+FgH+9L/AN8mgD3f+2IP74o/tiD++K8I/wCF gn+9L/3yaP8AhYJ/vS/98mgD3f8AtiD++KP7Yg/vivCB8QD/AHpf++TR/wALAP8Ael/75NAHu/8A bEH98Uf2xB/fFeEH4gH+9L/3yaP+Fgn+9L/3yaAPd/7Yg/vij+2IP74rwj/hYJ/vS/8AfJo/4WAf 70v/AHyaAPd/7Yg/vij+2IP74rwj/hYB/vS/98mj/hYB/vS/98mgD3f+2IP74o/tiD++K8IPxAP9 6X/vk0f8LBP96X/vk0Ae7/2xB/fFH9sQf3xXhH/CwT/el/75NA+IB/vS/wDfJoA93/tiD++KP7Yg /vivCP8AhYB/vS/98mg/EE/3pf8Avk0Ae7/2xB/fFH9sQf3xXhH/AAsE/wB6X/vk0f8ACwT/AHpf ++TQB7v/AGxB/fFH9sQf3xXhH/CwT/el/wC+TR/wsE/3pf8Avk0Ae7/2xB/fFH9sQf3xXhA+IB/v S/8AfJoPxAI/il/75NAHu/8AbEH98Uf2xB/fFeEf8LBP96X/AL5NH/CwT/el/wC+TQB7v/bEH98U f2xB/fFeEf8ACwT/AHpf++TSf8LB5xul/wC+TQB7x/bEH98Uf2xB/fFeEf8ACwD/AHpf++TR/wAL BP8Ael/75NAHu/8AbEH98Uf2xB/fFeEf8LBP96X/AL5NH/CwT/el/wC+TQB7v/bEH98Uf2xB/fFe Ef8ACwT/AHpf++TR/wALBP8Ael/75NAHu/8AbEH98Uf2xB/fFeEf8LBP96X/AL5NH/CwT/el/wC+ TQB7v/bEH98Uf2xB/fFeEf8ACwT/AHpf++TR/wALBP8Ael/75NAHu/8AbEH98Uf2xB/fFeEf8LBP 96X/AL5NH/CwT/el/wC+TQB7v/bEH98Uf2xB/fFeED4gH+9L/wB8mlX4gH+9L/3yaAPd01aEnhxV iK/jfuK8GtPHu+QZeT8VNdZ4a8WJcsv70HOKAPVkkDDinisXRb0TKDu7VsocigBaKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA GXBxEa4Xx5dtDBIQcV3N1/qGrzT4lsRby4oAd+z9NHqVvrjTxRyGK8RVLoDj5Ae9ejfYrQ9bWD/v 2K8r/ZTYtaeI8npfp/6LFetigCD7FZ/8+kH/AH7FH2Kz/wCfSD/v2KnooAg+xWf/AD6Qf9+xR9is /wDn0g/79ip6KAIPsVn/AM+kH/fsUfYrP/n0g/79ip6KAIPsVn/z6Qf9+xR9is/+fSD/AL9ip6KA IPsVn/z6Qf8AfsUfYrP/AJ9IP+/YqeigCD7FZ/8APpB/37FH2Kz/AOfSD/v2KnooAg+xWf8Az6Qf 9+xR9is/+fSD/v2KnooAg+xWf/PpB/37FH2Kz/59IP8Av2KnooAg+xWf/PpB/wB+xR9is/8An0g/ 79ip6KAIPsVn/wA+kH/fsUfYrP8A59IP+/YqeigCD7FZ/wDPpB/37FH2Kz/59IP+/YqeigCD7FZ/ 8+kH/fsUfYrP/n0g/wC/YqeigCD7FZ/8+kH/AH7FH2Kz/wCfSD/v2KnooAg+xWf/AD6Qf9+xR9is /wDn0g/79ip6KAIPsVn/AM+kH/fsUfYrP/n0g/79ip6KAIPsVn/z6Qf9+xR9is/+fSD/AL9ip6KA IPsVn/z6Qf8AfsUfYrP/AJ9IP+/YqeigCD7FZ/8APpB/37FH2Kz/AOfSD/v2KnooAg+xWf8Az6Qf 9+xR9is/+fSD/v2KnooAg+xWf/PpB/37FH2Kz/59IP8Av2KnooAg+xWf/PpB/wB+xR9is/8An0g/ 79ip6KAIPsVn/wA+kH/fsUfYrP8A59IP+/YqeigCD7FZ/wDPpB/37FH2Kz/59IP+/YqeigCD7FZ/ 8+kH/fsUfYrP/n0g/wC/YqeigCD7FZ/8+kH/AH7FH2Kz/wCfSD/v2KnooAg+xWf/AD6Qf9+xR9is /wDn0g/79ip6KAIPsVn/AM+kH/fsUfYrP/n0g/79ip6KAIPsVn/z6Qf9+xSNY2ZGPssA/wC2S/4V YooAg+xWf/PrB/36FH2Kz/59IP8Av2KnooAg+xWf/PpB/wB+xR9is/8An0g/79ip6KAIPsVn/wA+ kH/fsUfYrP8A59IP+/YqeigCD7FZ/wDPpB/37FH2Kz/59IP+/YqeigCD7FZ/8+kH/fsUfYrP/n0g /wC/YqeigCD7FZ/8+kH/AH7FH2Kz/wCfSD/v2KnooAg+xWf/AD6Qf9+xR9is/wDn0g/79ip6KAKW oWloljOwtYBiJv8AlmPQ+1fIvwy8RSS3hBfjzWHX/aNfX+rf8gu5/wCuL/8AoJr4P+Ekz/2gRnrM 3/oRoA+uvAd4ZoUO7qBXdwcxg15n8MyWt4816VaHMK0AS0UUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAR3X+ob6V5l8Tzi1kr0 27/1DfSvMvih/wAeslAFT9lH/j08Sf8AYQT/ANFivXBXkf7KP/Hp4k/7CEf/AKLFeuCgAooooAKK KKACiiigAooooAKKKKACiiigAooooAKKKKAGyuscbSSMFRRlmJwAB1Nc0PiN8P8A/od/Dv8A4NIf /iq0/G/PgzVweh0+f/0W1fg8lvLc6sLW3TfLNP5ca56sWwBQB+5//Cxvh/8A9Dx4d/8ABpD/APFU f8LG+H//AEPHh3/waQ//ABVflIn7GH7RjIGXwAxVgCD9vg5H/fdH/DGH7R3/AET5v/A+3/8Ai6AP 1m0Lxh4V1q++xaP4k0nUbkIXMNpexyvtHU7VJOORVW5+IPgW3nkgn8Z6BFLC5SSOTUolZGBwQQW4 INfFf/BNH9nn4tfCz4/3PiPxx4UbTNOk0aa3Sc3UUn7xmQgYViecGvDP+CpXw5TwJ+1PqGo2lsIt N8VxDVINowolY7ZgP+Bjd/wKgD9ZNNvrXULGK8sbmG5tp1DxTQuHSRT3UjgirFfJ/wDwSG+IX/CV fs3P4SvJt994PvGt1DNybaQmSP8AAEuv4Cvq9ulAGd4h1/RNBt459c1iw02KV9kcl5crCrtjOAWI yaraD4v8La3ffYtG8S6TqFxsL+TaXscr7RjJwpJxyK/Oz/gs34+/tj4xaH4AtbgtbeG7D7TdIOn2 mfnn3Ear/wB9GvRP+CLHw5W08LeJPifeW+JtRmGl6e7LyIkw0pB932j/AIDQB9i3HxD8B287wT+N PD8csbFXR9ThDKQcEEbuCDW/bXMFzax3FvMksMqh45EYMrKeQQR1B9a/C7414Hxj8WADH/E+vf8A 0e9ftN8CQB8CfCAwB/xT1n0H/TBaALkvxD8BRStHJ428Po6MVZW1OEFSOCCN1IfiN8P8f8jx4d/8 GkP/AMVX4hfEcf8AFxdfAH/MVucf9/Wr1zT/ANjr9oW9023vrbwE8kFzCs0Ti+g+ZWAI/j9DQB+u Gj+KvDGryeXpXiLSb5/7ttexyH8lNaqt61+JHxH+Evxe+EUkOpeKvC2t+HVZwIb9CRHu7ASxkgH2 yDX1n/wTh/a51288XWPwr+KGrPqMWoMIdG1i5b97HL/DDK38St0VjyDgHrQB+gkjBIy7MFUDJJ6A etc3/wALG8ABireN/DwKnBH9qQ8f+PVr+IufDuoBv+fSXj/gJr8H9ThafxHcwRLl5Lt0QepLkAUA fuT/AMLG+H//AEPHh3/waQ//ABVH/Cxvh/8A9Dx4d/8ABpD/APFV+UMP7Gf7RcsKSx+AHZJFDqft 8HIIyP46f/wxh+0b/wBE+f8A8D4P/i6AP1m0Pxj4T1q/+xaP4m0jULnaX8i1vY5X2jqdqknAq14g 17RdBtUuNb1ex02GR9iSXlwsKu3XALEc18G/8E2v2dPi78MP2j18T+N/CR03TP7Iubf7QbqKTDsU wMKxPODXcf8ABacA/s/eGyQMjXx/6JegD6y0DxZ4Y1y7a10XxHpOozou9orS9jlYLnGcKSce9bGe K/D79nH4m6x8I/i/pHjnRi7NYzAXdspwLq3bAkiP1Xp7gGv2m+HXijR/G3gvTPFfh+7W50zV7VLm 2kU9mHQ+hB4I7EGgC14h1/RdBt0n1zWLHTYpX2RyXlwsKu3oCxGTUfhzxP4c1+aWPQ9f0zU3gAMq 2d2kxjB6E7ScV8h/8FsVB+CHhIkcjX25/wC2D1wH/BEAD/hMvHpx/wAuFr/6MegD9Eag1G8tbC0e 7vbqC2t4hmSWeQIij3Y8Cub+Nvj7Qfhj8M9U8beJJ/KsNLhLsq/fmc8JGnqzNgCvyQ/aN+PPxL+P fjcpfXl2mnzz+Vpnh6wZvJjBOFXav+sc9yc8+lAH6o6r+0F8ENNv2sr74q+FIbhG2tGdTjJB/A11 ng3xl4T8XWv2nwv4l0rWIgMlrG8SbH1Ck4r8qvDv7EH7Q2r6DHqY8KWdkJU3pb3uoxxz49CnOD7G vL9Y0z4n/A34liG7j1fwl4jsSJI2RzGzL2ZWX5XQ/iKAP3CyKzfEOv6JoMMc2u6xYaZFM+yN7y4S FXOM4BYjJxXgv/BPH9oh/jl8Obiz18xJ4t8PhE1FYgAt1G3CXCr2yQQw7H2NeYf8FtwP+FP+CuOf 7dl/9EGgD61/4WN8P/8AoePDv/g0h/8AiqP+FjfD/wD6Hjw7/wCDSH/4qvxe+Cfwl8efFrVr3TPA Wif2pdadALi5jEyR7ELbQcuRnk16OP2L/wBo3/on7f8AgfB/8XQB+rJ+I3w//wCh48O/+DSH/wCK rc0TU9O1jTkv9Kv7a+tZc+XPbSiSN8HBww4PNfkUf2Lv2jcf8k+b/wAGFv8A/F1+j/7B/g3xF4A/ Zg8O+FPFmnHT9WsRN9otzIrld0rMOVJHQigD2GiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKAK+q/wDIMuf+uL/yNfBnwj/5CJ9pm/8AQjX3nqv/ACDLn/ri/wDI18GfCP8A5CLf9dn/ APQjQB9V/DH/AI9oq9Ltf9QPpXmnwx/49oq9Ltf9QPpQBLRRRQAUUUUAFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBHd/6hvpXmXxQ/49ZK 9Nu/9Q30rzL4n/8AHrJQBU/ZR/49PEn/AGEI/wD0WK9cFeR/sof8eniT/sIJ/wCixXrgoAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACiiigDL8bf8ibq/8A2D5//RbV+FOgyJD4xsppXCRx6hGz u3AUCQEk1+63jb/kTdX/AOwfP/6LavwigtpLzWVs4SPNuLjyo8nA3M2Bk9hkigD9nLL9ov4FpZwo /wAVPDIZY1BBvl9Kl/4aO+BP/RVfDP8A4HLX54J+wN+0I6K66f4eKsAR/wATdf8A4ml/4YD/AGhv +gd4e/8ABuv+FAH6b/Dj4geCvH9tc3PgvxPp2uw2Uix3MllMJBExGQG9CRk184f8Ff8A4dHxR+z3 b+M7K333vhG7EsrKOfssuEfPsG2Gtj/gmb8EPHnwS8JeKtO8dW1jDNq1/BPbfZLoTAqiMpyQBjk1 9C/ELw7Y+LvA2r+F9SQPaaxZS2koIzgOpXP4Zz+FAH5ef8EnfiF/wh37UEGg3M/l2Pi62awYHp5w +eI/mCP+BV+qeq3tvp2l3OoXknl29pC00znoqKCxP4AGvw01a01v4Y/F+e1bfBq3hXWCoPQiSGTg /Q7f1r9Mv22vjRaQfsC/8Jdo9yq3HjqwgtLLa3I89cy491UOKAPza+N3im/+J/x01/xQqtNceINW c20Y5JVn2xIP+A7RX7F/syeA4fhn8CPDHguNAsum6eguiBjfOw3SE/8AAmNfl7/wTV+Hg+IP7Vmh rcwGTTvD4OrXmRlT5WPLB+shWv19XJ60AfhT8bf+Sy+Lf+w9e/8Ao96/af4E/wDJCPCP/YvWf/oh a/Fj42f8ll8Wf9h29/8AR71+0/wI/wCSD+Ef+xes/wD0QtAH4m/Eb/kpOvf9ha5/9GtX7i/DT/km /h7/ALBNr/6JWvw6+I3/ACUnXv8AsLXP/o1q/cX4Z/8AJN/D3/YJtf8A0StAD/iJ4X0bxr4K1Lwt r9nFd6fqls8E0cihhhhgMPcHkH1Ffh74y02+8EfEzUtJileO88PatJDHJ0ZXhlIVvr8oNfu2eor8 Rv2tpY5v2nfHskTAo3iK8wQcg/vWoA/YP4Z+JG8Yfs+6P4pZsvq3h5LmQ46u0OW/XNfieHWPxuZH YKqajlmPQAScmv2C/Y6jnh/Yh8Gx3OfMHhhTz6FGI/TFfjtqML3Pia4t48b5rxkXJ7lyBQB+yujf tFfAyLSLSOT4p+GldIEVgb1cghRmrP8Aw0d8Cf8Aoqvhn/wOWvzvt/2Cf2gp7eOeLT/D5SVA651Z QcEZHanf8MB/tDf9A7w9/wCDdf8ACgD9Nfh18RPA3xAjupPBfirTddSxZVuTZTiQRFhwGx64NfL3 /Baf/k37w5/2MA/9EvXQ/wDBMz4D/EH4I6d4rg8d22nwtq8tu1r9juxNkIGDZwOOornv+C0//Jv3 hz/sYB/6JegD85tI8MazqfhLV/EllZtNp+htCuoSL1h81iqEj0JGM/Svsv8A4JE/HUaNr03wZ8SX u2y1SRrjQJZH4iuMZeAHsHAyPcH1rM/4JA+GdI8Zj4o+FNftRc6Zq+i29tcxHurO4yPQg4IPYgV8 6/HrwB4l+BPx4vPDks80F3ot4t1pV+mVM0W7dDMp/AZ9CCKAPuL/AILXZ/4Ud4S/7D7Zz/1xeuA/ 4Ihf8jh49x/z4Wv/AKMesX9tr4x2nxt/Yb8B+KMxrq1nr/2LW4EP+pult2y2P7rj5h9cdq2v+CIX /I4+Pf8Arwtf/Rj0AbP/AAWz8a3UVv4O+H1vM6QXPm6rdqpwJNp8uLPqAfMP1rl/+CMvw503W/Hv iL4iapax3D+Ho4rXTd6bhHPJktIM/wAQQAD/AHqyf+C08V0P2ifDskxPkyeHE8n0GJ5d36163/wR Hnh/4VH41tww81ddidl77TAoB/MGgD7aVQRXi/7Zf7PGg/H7w5pNhqGonSL3SbvzYtRithJL5JBD xckcE4PPQivahSZ5xQB4X+y3+yv8PvgZrkmveHb/AFq+1ee1NtNcXlyNjoSCR5agLnIHrXjP/Bbn /kkHgv8A7Dsv/og19tZr4m/4Lcf8kh8Ff9h2X/0QaAPFP+CRnjvwd4D+Kfiy+8ZeJNP0O3utGjig lvZhGsriYEgE9TgZr71/4aN+BI/5qr4Z/wDA5a/Jf9nb4KeOPjbruoaP4FgsZbrS7YXNwLu6EKhC 20YJBycmvWv+GA/2hv8AoHeHv/Buv+FAH6Gv+0d8CcZPxV8M/wDgcK9LsLiC7tI7u2lWWC4jWSKR TkOrDII9iK/Kc/sCftCgc6d4f/DV1/wr9SfA1jcaZ4L0jTbsKLiy0+CCYKcgOkaqcHuMigDVoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigCvqv/ACDLn/ri/wDI18GfCP8A5CLf9dn/ APQjX3nqv/IMuf8Ari/8jXwZ8I/+Qi3/AF2f/wBCNAH1X8Mf+PaKvS7X/UD6V5p8Mf8Aj2ir0u1/ 1A+lAEtFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFAEd3/qG+leZfE7/j2kr027/wBQ30rzL4nf8e0lAFT9lD/jy8R/9hBP/RYr 1yvI/wBlD/jz8Rj/AKiCf+ixXrgoAKKKKACiiigAoopEYMuRn8aAFooooAKKKKACiiigAooooAKK KKAMvxt/yJur/wDYPn/9FtX4V+GQT4608f8AUSi/9GCv3W8YRyTeE9UhhRpJJLGZURRksxQgAe5r 8YJvgH8bPtTyJ8MPFHLkgjT39fpQB+1NhIn2CD51/wBUv8Q9BUvmJ/fX/voV+MX/AAqf9pH/AKFD x9/37n/xo/4VP+0j/wBCh4+/74uP8aAP2eDoSAHUk9OaVulfmd/wTw+H/wAadC/as8P6l4x8OeLb TSYorkSzagkvkqTEwG7ccdcV+mRoA/Ln/gsB8Ol8L/tD23jOyt9ll4vsxLKVXgXUWEf8Suw/nXgn jT4pa74k+CXhH4a3jE6f4Snuprdi2TJ5zAqCP9gbgPZq/Tj/AIKZ/Cq++KH7N1wND06W+1zw/dJf 2EEKbpJR9yRFA5JKtnH+zX5s6d+zz8a7vUbe1/4Vn4khE8qx+ZJp7hU3EDcT6DrQB9y/8EbPh0NC +C2rfEC8t9t34ovPJtnZcMLWHI49mcsfwFfZI9K5r4N+ErTwH8LNA8HWKgQ6Lp0VqCP4mVRub8Wy fxrpT1oA/Cn42f8AJZfFn/Ydvf8A0e9ftP8AAj/kg/hH/sXrP/0Qtfkz8XPgX8Yr74p+Jr60+Gni Wa3udau5YZU09yro0zkEEDkEc1+tXwYtbqx+C/hexvLaWC6t9CtYpYZFw6OsKgqR6gigD8SfiMP+ Lka9/wBha5/9GtX7ifDR0/4Vx4fG9cjSbXIz/wBMlr8fvHvwH+M11461u5t/hl4mkim1K4eN109y GUyMQQcelIvwm/aPVFRfB/j1VUAACOcAY6Y5oA/Vz9oD4xeCfhN4B1DX9e12xS4ggc2liJ1ae7mw dqKgOTk4+lfjXpOn658SfivFYWUD3Gr+JtVIVEBOZJZMk/QZJ+gr0Tw5+zJ+0P4v1WOH/hXuuh3O Dc6ofJRPcvIen0r7r/YR/ZCsvgzf/wDCZeL7u21fxc8ZSAQgm301WHzBCeWcjjd2HSgD6B8OeHrf wn8IbXwzaAeTpGiraIR3CQ7c/mK/EGLnx2v/AGEh/wCja/dnXo2fQr2ONSzvbSKqgck7TgCvxg1X 4C/Gp9YuZovhh4nKtcOysunvz8xwRQB+z+gyJ/YVl86/8e0f8X+yKtean99f++hX4xD4T/tIgADw h4+4HTy5/wDGj/hU/wC0j/0KHj7/AL4uP8aAP2d8xM43Lk9BnrXxx/wWn/5N+8Of9jAP/RL14f8A 8E/vh78bNE/au8Mal4u8OeLrTSITP581+sohXML43bjjrivov/grZ4O8VeNfgjoGneEvD2o61dQ6 2JZIbKAyMieU43EDtkigDxr/AIIhc+NfH2P+gdaf+jHr3L/gp98Cf+FofCA+LNCtPM8T+E43uIhG vz3dr1lh9yMbl9wR3rzP/gj98PPHXgfxj41l8YeE9W0SO7sLVbd762aISkSPkLnqRkV92uAVwRkd 6APwNF9epp0mnLcSrayyrLJAGIRnUEBivqASM19w/wDBEHnxj49/68LX/wBGPXGft7/sp+L/AA/8 b7nV/hp4R1DVvD3iDdeRw6dbmQWEpP7yIgdFydy+xx2r1n/gj/8ADzx14H8WeNJfF/hPVtEju7K2 WB762aISkOxIGepwRQBof8Fnvhxd6x8P/D3xI0+3eU+HpnstQKDJSCUgo59g4xn/AG68D/4JafGv RvhX8Xb/AELxVeLZaH4qijhN3I2I7W5Qny3f0VtzKT2yK/UnxTo2l+IvDt7oWtWUV7p2owNBdW8q 5WRGGCDX5nftWfsL+PPB+t3OsfDC0l8T+HZGMiWkZBvbMH+Eof8AWAdiOfUUAfp1Z3MF1ax3FrNH PDKoaOWJw6uPUMOCK+Iv+CsH7QVtpOhWPwy8C+JHj103iXerXOm3JV7JEzsiLoeGZjkr2AGetfFV vF8cfD1u2gW8Pj3TYW+T7HGl3Gp9go4/Kux+B/7KPxq+KGuRlvDV7omnzPuuNW1pGhVQTywVvnkb 2A/GgD6g/wCCUnxV+N3xI8VaxZ+LfEs2s+FtEsxvmvYFab7Q5xGgmwCcAMTnParv/Bbj/kkHgr/s Oy/+iDX01+zZ8JPDfwY+Ftn4N8OoZFjPnXl5IMS3s5A3SP8AkAB2AArwL/gr14K8XeOPhd4Rs/CH hzUdanttZllnjsYDI0aGEgMQOgzQB4v/AMESCF+MXjPcQP8AiQxDk/8ATda/SPzI/wC+v51+Kumf BL4+ac7vp3w98Y2buNrNb2ksZYZzgkYzVz/hU/7SP/QoePv++Lj/ABoA/Z3zU/vr/wB9U5GDDKkH 6GvxgHwo/aRyP+KQ8ff98T/41+i3/BMHQ/F3h79mYaf420/VbHVRrFy7RamGEuw7dp+bnHWgD6Ko oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigCvqv8AyDLn/ri/8jXwZ8I/+Qi3/XZ/ /QjX3nqv/IMuf+uL/wAjXwZ8I/8AkIt/12f/ANCNAH1X8Mf+PaKvS7X/AFA+leafDH/j2ir0u1/1 A+lAEtFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQAUUUUAFFFFAEd3/qG+leZfFD/AI9ZK9Nu/wDUN9K8y+KH/HrJQBU/ZR/49PEn/YQj/wDR Yr1wV5H+yj/x6eJP+whH/wCixXrgoAKKKTNAC0UmfaloAD0oFBOKQGgBaKKKACikJ5xRmgBaKAc0 mecUALRRRQAUUUE0AIRS0maUUAFFFFACYNLRRQAEZFNIPHNOooAQDFBGaWigBMHHJoxS0UAIBS4o ooAQigDFLRQAGkA96WigAooooAQjmjB9aWigBMHPWlPSiigBAOaBmlooAKQjnNLRQA0opYMVUkdC RyKXHOaWigAHSkAw2R360tFABRRRQAGiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigCvqv/ACDLn/ri/wDI18GfCP8A5CLf9dn/APQjX3nqv/IMuf8Ari/8jXwZ8I/+Qi3/AF2f /wBCNAH1X8Mf+PaKvS7X/UD6V5p8Mf8Aj2ir0u1/1A+lAEtFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAEd3/qG+leZfFD/j1k r027/wBQ30rzL4of8eslAFT9lH/j08Sf9hCP/wBFivXBXkf7KP8Ax6eJP+whH/6LFeuCgArwj9vb 44at8E/hrp174c0+2utb1/UBYWD3h/0e3OMtI/IzgYwCcflXu9fOv/BQ/wAUfDjR/AuiaB8VvBl/ rXhrxDqS28mpWkoj/seUYxNu6g7WYjHUAigDi/DXxM/at8BeP/Cq/ErRtD8Z+GPFF0lvLdeGLcyv p5Yj5mZABhdwPOQQDg8V9Pf8Jt4THj8eB/8AhIbD/hJDbfahpXnD7R5XXfs64xX54/EO30v9nXxT 4T1z4A/Hi88SprGpxRf8IwLsXSSwE8blQ7dpzt5UHJGK9i1rWdO0T/grxY6hr13b6ZDd+C1jSS6k EaGQxsdu48Z4I/CgD6K8e/FDw/D4V8bQ+FvEOmXviTwhpdxdXVisgd7SRI2K+anYZAry/wDZV/ah 8LeIvgp4d1f4q+OfDWk+KdaluFFmZlhyqzsiHZk7cgDrjOa8S+Dmr6Xr3x0/ap1jRruK9sbrRLpo LmJtySqA4ypHUZB5rjvg1p3wNn/4Jg+KbzWI9C/4S6JrkySzbPt63Qk/0YR5+bBXbgDjls0AfoR4 q+Ivgfw1q1hpniDxXpGmXeqRNNYxXV0sZuIx1dSTggetc/ZfH34L3fhu/wBftvib4ck03TJViu7k Xy7Ynb7o9TnnGM18O3ej/wDCU+LP2UNF8c2hv477TCl1b3YJM0InzGHB5IKhfqK9C+Hvw18A3v8A wVU8Z6Fc+E9Kk0mw0Fby3042y/ZkmaOAFxFjbnDv24zmgD6O+LnxPhvv2d9T8c/Crxz4SDRFFttY 1O5B0+I+YoZZGH3TgkAEdSK4P42/tRWvws8O/DzTdSutB1bxD4pFo+q3EF3ttbG3fZ5l0AOTGdzF TwPlOa+VfBkUVr+wp+0Jp8CiO1tfF8KQQg/LGonUAAdug/Kuz/au0bw83gP9mPU9R02wLXosLXUb iaMfvrZUt/3cjHqgDNwfU0Ae9+If2vvAdv8AtG6B8PtM1jQp/D99ZtcX/iRtQBhicg+XCmONxIGc n+IcV2Hg/wAd+JW/aL8aaJr3i7wdJ4X0LT1urextZ/8AiZWKgKWkuRjhcZOfpXzh468KfC6x/wCC nfhPTf7E8OW/he68MC4ERjjWylk2y7HH8JOQuD7CrumFT+2x+0j0/wCRInH/AJLpQB9N3f7QPwUt rXT7i4+J/hlItVJFm/29cTYbacegzxk10vjnx74O8F+Gk8ReLPEumaRpchURXd1cKqS7hkbD/Fkc 8Z4r8+fh58PvBcv/AAST8SeL5vDunS6811JMNSkhBuEZLlEUK/UAKSMDg5rV+IMul3HiD9lpviRK JfAz+H4TdPeMTbNcbRjzSeP+efXtmgD7g8KfF34Z+JdZ0/SNA8daFqV/qtubiytrW7V5J4xnLKB6 bT+VdlIcDJIAHU56V8HeFV+G4/4K3aOfhmuljT/7HlF7/ZaqLUXYgk37Nvy/d2Z28Zz719M/tv8A xEX4Y/szeJ/EkcwjvpLQ2On88meb5FI+mS34UAfPfhH9snxRqX7YaeFrq2sF+G97r8uiWl/9mKuZ FG1W83OD85UkejV9leLvEWieFfD9zrviPVrPS9Ms133F3dyiOOMe5Pevy81fwJ8bLD9jXTtNf4Nf ZNN0W+PitPFIv0Nz8y5LmLdnGzbxj+EGvXP21vHyfE39lz4K+Mb6SU+GNT1mH/hKBGTtSRFVHWTH TkTYoA+vNA+N/wAItcOmjSPiL4fvH1i5NrYRxXil7iUYygXrnkcH1qz8Rvi/8MvAOsQaV4z8c6Jo t9cqHitru6CyFScAkdh7mvjX9oQfBv8A4bi+CK/C4aF5i6jbf2gNFCeRs81PJ3bPl34z74xmuW0O DXtV/aR+No1ux+Gl3frezpeHx3NIkkFmN4BtQAeAmw8c424oA/QPxR8QPBfhvwra+Jtd8U6XYaNe uiW2oTXK+RMz8qFccHI6VmaB8Y/hdrXjpvBuk+P9BvdeUkfYILxWkYgZIHOCcdgc18AfFHSrnSv+ CYGmabN4q03xDYx+NwNOvNPaVoo4irZjBlVW+Vt3bHNel/tX+BPB3gT4wfs7SeEtBsdHkfU4IZZr OIRvMoaEguR945ZuTzyaAPrj4l/F34afD69gsvGvjbR9Dubld8UN5chZGX+9t6ge5qbUPij8PbDT 9Fv7zxno8Vr4jfy9Ina6XZfNwNsbdCckcV8k/Ce08A6p+3P8ck+NMWkz3UQK6autlSi2POTFv6fu /LwV5GTipfiL4G+Fnjz/AIJ+atP8BYdSNl4O1eTWNNe8WUyLPFgziIyclShJ+XjI9aAPr/xJ458I +HfEml+Htd8RWFhqutvs02ynmCy3bZxhF6nmuhU5HNfDf7J+uyftIftj2nxUuoJG0jwB4WtbaFZk 4GoSIQ+PfcZWB9hX3ImMUALRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBX1X/AJBlz/1x f+Rr4M+Ef/IRb/rs/wD6Ea+89V/5Blz/ANcX/ka+DPhH/wAhFv8Ars//AKEaAPqv4Y/8e0Vel2v+ oH0rzT4Y/wDHtFXpdr/qB9KAJaKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKAI7v/UN9K8y+KH/AB6yV6bd/wCob6V5l8UP+PWS gCp+yj/x6eJP+whH/wCixXrgryP9lH/j08Sf9hCP/wBFivXBQAVj+NvC3h7xh4euNB8U6PZ6tpl0 AJbW7iDo2Ohweh9xzWxRQB5T8Ov2b/gl4G8TR+IPDPw+0y01OBt0FzJvlaA+qByQp9xzWv8AF34L /DD4n39lfePPCFjrFzp/FvPMGV1XOdhKkZXPY13+BRQBwvhz4OfDDw/PrUuh+CdK09vEVr9k1UW0 RRbqHGPLZQcAY9AK5y5/Zf8AgHO2mE/DDRFGkkm1VEZRyxbD8/ONxJ+bNeu4HpRQByuv/DjwNrfi vRPE2qeGbK41bw2Nuj3RUhrEeiAEAD8KfYfD7wZZfEm8+IFp4etYvE1/bi2utTXd5ssYCgKecYwq 9uwrp6KAPP4fgl8KofCmt+GYvBGmrpHiS6F3q1oN+y8mDbg7c5znngipPiB8HPhr428Dad4O8TeF LO+0bR1VdOtm3L9kCrtARgdw+UY69K7yigDy7xT+zt8GvEdloVnrHgOwuIfDNuttpQ3OpghU5EeQ 2WXPODmuih+GHgGLxRrfiRPC9kNW8SWZstXu8NvvICoUo/OMEADj0rr6KAOKs/hL8OLT4Wz/AA4t vCVhF4UuCTNpS7vJclgxJ5z94A9e1eT/ALXnwu8c3/gXwzoPws8KeE9c8NaHiK78KazbKUkjUrsM MrHchABXhgec84r6NI4xSbRnNAHyJ+zV8EfHz/tO2HxT8U+BNA+H+ieHNGbTdI8P6XcLKXLBgXYr xn52JJOTx6V9K/E/4e+C/iLpFvpXjfw/a63ZWs4uIYLndtSQAgNgEZ4J6+tdMFApaAKN7pOm3ehS 6Lc2cUmnzW5tpLVl/dtEV2lMem3ivDv2gPg5q2m/AM+DPgP4e8MWtut8bi70DVbUT2l+jD5lHmE7 HyAQRj6ivf6TAzmgD4k+GfwH+JPiP40+AdV1r4VeGPhp4Y8CXLX0lvpd2s0mo3JIbPyknllGNx4A NfSPxV+AXwh+JWvx674z8DadqWpIApujujkkUdA5QjcB75r0vAooA4zxJ8J/hx4g8BWfgjVvB+mX Hh7T3R7XTfKKQwsmQpAUjkZP1zzVnxh8OPA/irUdEv8AxF4cs9QufDcol0mWYNmzcYwVwR/dXrnp XVUUAedfF74F/Cf4n6rDqnjjwXYapfW6hFumDRylR/CzIQWHsc1kfGyx8ZeBvg7b+GfgZ8OdH1IS LJZf2c062sNlC6MPMAPD/MeQTzmvXMCjAoA8P/YG+C938Fvgcui64LY+INVu3vtWNudyI7cLGG7h VAHHGc13Xxo1z4iaFpVnN8OvBdn4ou5Zyt1BdamLMQR4yGDEHdk8YrtgAOgooA8G/wCFg/tPf9EE 0P8A8KyP/wCJo/4WF+0//wBED0P/AMKyP/4mvecD0ooA8G/4WF+09/0QTQ//AAq4/wD4mj/hYX7T 3/RBND/8KuP/AOJr3migDwb/AIWF+0//ANEE0P8A8KyP/wCJo/4WF+09/wBEE0P/AMKuP/4mveaK APBv+FhftP8A/RA9D/8ACsj/APiaP+Fg/tP/APRBNC/8KyP/AOJr3migDwb/AIWD+0//ANEE0L/w rI//AImj/hYX7T3/AEQTQ/8Awq4//ia95ooA8G/4WF+0/wD9EE0P/wAKyP8A+Jo/4WF+0/8A9ED0 P/wrI/8A4mveaKAPBv8AhYX7T3/RBND/APCrj/8AiaP+FhftP/8ARBND/wDCsj/+Jr3migDwb/hY P7T/AP0QTQ//AAq4/wD4mj/hYX7T/wD0QTQ//Crj/wDia95ooA8G/wCFg/tPf9EE0P8A8KuP/wCJ o/4WD+09/wBEE0P/AMKuP/4mveaKAPBv+FhftP8A/RBND/8ACsj/APiaP+FhftPf9EE0P/wq4/8A 4mveaKAPBv8AhYX7T/8A0QTQ/wDwrI//AImj/hYP7T3/AEQTQ/8Awq4//ia95ooA8FPxB/af/wCi CaH/AOFXH/8AE0v/AAsH9p7/AKIHof8A4Vkf/wATXvNFAHg3/Cwf2nv+iCaH/wCFXH/8TR/wsL9p /wD6IJof/hWR/wDxNe80UAeDf8LC/af/AOiCaH/4Vcf/AMTR/wALC/af/wCiCaH/AOFZH/8AE17z RQB4N/wsL9p//ogeh/8AhWR//E0f8LC/ae/6IJof/hVx/wDxNe80UAeDf8LC/af/AOiCaH/4Vkf/ AMTR/wALC/ae/wCiCaH/AOFXH/8AE17zRQB4N/wsL9p//ogeh/8AhWR//E0f8LC/af8A+iCaH/4V kf8A8TXvNFAHg3/Cwv2n/wDogmh/+FZH/wDE0f8ACwv2n/8Aogeh/wDhWR//ABNe80UAeDf8LC/a e/6IJof/AIVcf/xNH/Cwv2n/APogmh/+FZH/APE17zRQB4N/wsH9p7/ogmh/+FXH/wDE0f8ACwf2 nv8Aogmh/wDhVx//ABNe80UAeC/8LB/ae7/APQ//AArI/wD4mur+D/ir4zaz4qez8f8Aww03w1pg t2dL221xLtmkyMJsAHUZ59q9PpAB6CgBaKKKAK+q/wDIMuf+uL/yNfBnwj/5CLf9dn/9CNfeeq/8 gy5/64v/ACNfBnwj/wCQi3/XZ/8A0I0AfVfwx/49oq9Ltf8AUD6V5p8Mf+PaKvS7X/UD6UAS0UUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAR3f+ob6V5l8UP8Aj1kr027/ANQ30rzL4of8eslAFT9lH/j08Sf9hCP/ANFivXBXkX7K QzZ+JB/1EI//AEWK9dFABRRRkUAFFGR60UAFFFFABRRRQAUUZFGRQAUUUZoAKKAaKACiignFABRR RQAUUUZFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFBoAKK M0mR60ALRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAFfVf+ QZc/9cX/AJGvgz4R/wDIRb/rs/8A6Ea+89V/5Blz/wBcX/ka+DPhH/yEW/67P/6EaAPqv4Y/8e0V el2v+oH0rzT4Y/8AHtFXpdr/AKgfSgCWiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigCO7/ANQ30rzL4of8eslem3f+ob6V5l8U P+PWSgCp+yj/AMeniT/sIR/+ixXrgryP9lH/AI9PEn/YQj/9FivXBQAV4/8Ati/HSL4D+DNK1+Tw 3Nrv9qagLJIIrgRFWKlgckHPTGK9gr5A/wCCw/8AySXwWf8AqaYv/QGoA1Zf2x9R8Narp5+KfwT8 V+DdG1CZYRq1wRJFEW6FvlHH05xX1DaXtrPYRX0VzE9tPGskUwYbGRhlWB9CCK+ev+CmNxpVv+xD rsWpvCJZ47RLNJGG5phIhG0HqQN3TtmvFvii2g6l8OPgj4F8Y3PjvX9eXwzb3DeB/DREZv1MY2vc S7lKYUY4OcAnigD7p1nVbDTdBu9Yu7lEsrO3e4mmB3KqIpZjx1wAa5T9n74oeH/i94AXxl4Yjul0 ua7mt7c3SBJJBG5Uvt7AkcA818Q/staPda94e/aC+F2vJr2kaHpVk15a6NcaoZZ9Mlj8xhGZcnP3 VDY4bHNcX4Ha9+HH/BOQePPCOoavZa7421s6Hf3EN22yC2WVziFekbsF2lhgnJoA/UeKeGUExyo+ 04O1gcH3xTbyeK3t5J55FiiiQu7ucKqgZJJ9AK/Pv4V+HvG3gL45+ANX+Gvw3+I/h+xu5EtvE8Xi LUopoNVibaGmRfMPI3M3A4+XGOa+0f2j7bUrv9n/AMaWujAm+l0G7W3Cg5LeU3A98ZoA8H1f9sTX Nb1rUz8Ivgxr/jbQNDmaO91iJjHG+3qYwFOR+uOcV7N+zB8aPC/xv+H58SeHUntJrWY22o6bcgCa ymAztbHUEdD3rzD/AIJWax4ef9jbS4bK7tYptMurr+1VMiq0MnmFt0noCuDk9h7VzHxw+PPge2/Z K+IPiX4A28en31lqkem6heWuni2MUsshVp1YDDkjOGycbgaAPr1ZoWlaJZULqMsgYEj6ivJfE3xv g0j9rHRPgkfD00sutaab5dTFyAkQCuduzHP+rx1718qfHX4S6f8ABz9lbwz8c/BPjnxBF42iaxur nUpdVeWPU2nAZlKE7SBnoOoBzmuxuNVude/4KX/CbXr2HybnVfAcN5PHjHlvJBKzLjtgmgD379lP 42wfGmw8S3UGgSaSPDmsNpjK9wJfOKj74wBj6V6sk8LuyJKjMn3lVgSv1r83PhL448QfD79jH45a 74YnktdSfxmbSO6i4e2Er7GdT2IBOD2zTfA/hzx14T1L4eeMPhh8PfiXpetvdW767qWtapFJZ69b yBTJtQyc5ySAB0OTzzQB+ks08MWPNlRN3C7mAz9K4r9oH4p+F/hD8P5PFvimS5+yidLaGG2i3yzy v91FHvjqeBXyV8NvA9j+018cfjDqXxL8Q61ajwre/wBn6HZwag8EelR5lAl2ggHb5Yzng5Oe1Y/7 c3w80aw/Yx8I35+I9148uvD+srptrrKXQ8uSGVtxjcKzBmTaArE5AoA++9KvorvSLfUAdkdxCso3 EfIGUHBPTvVhJY3jEiOrqehU5Br4B/axsrrwXffB/wCA3h6LxZqPhTVoG1HUtO07UCdQ1V2fJgWV yBgc4BOAD7CtP9n67+JHwt+IPj0eHfBHjDQvAv8Awi1zqNppXiS8S5m0++ii3KVw7MFY5xnrxmgD 7A+N/jiH4efCrxD4za0/tA6BYPePZJKEeRVxxk9OtR/ADx3H8Tfg7oPjyLTn05NctvPW1eQSGIbi uNw6/dr4J0D4T6b4o/4J++JfjvrHjTX5/GV9FdXFzdnU38p0EuxrZ487WDd89yMYAr7C/wCCfPH7 GfgDg/8AIL/9qPQB7NRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA Fcr8Z/E+seDvh5feItB8K3vie/tNnlaVZMBLcbmCnBwegJP4V1VI1AHyCf20PGo+II8Cf8M7+I/+ EkMH2gaX9tXz/Kxnft2dMV614J+L/jzXPE3hDTdR+C+vaTb+IoJZNRvJ51KaOyGQBZRjJLBFI6ff FePSEj/gsr1/5lEd/wDphV/9oK+vo/8AgqJ8ILKK+uUtpdKnMkCTMI3+S4+8ucHoPyFAH1m08KIW eVFC/eJYAD60rTRKVDSoC/3AWA3fT1r88vht8ObT4pfFD9oZPFHiHxAbHw/d3VxZWNrqckUQuB5x SR1B+bbsGFPFcPp/g6fXv+Cdtz8adY8XeJbrxPoOpLZ6PI2qSCOxgjmRNioDjncTuPPAoA/UZ5ER C7sEUdSxwBSJKjgFGDBhkEcg/jX54/Hrxj4n+IPxc+FfgLX9K8V+JNDk8D2Ws32jeHrsQXOr3MkG 5nZiVyFKgnnPXFet/wDBPCD4g+HfiX408Jal4d8S6T4GAW70G01+6jnudOfcA0LMrMRkHof7o70A fW1FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAFfVf+QZc/9cX/AJGvgz4R /wDIRb/rs/8A6Ea+89V/5Blz/wBcX/ka+DPhH/yEW/67P/6EaAPqv4Y/8e0Vel2v+oH0rzT4Y/8A HtFXpdr/AKgfSgCWiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigCO7/ANQ30rzL4of8eslem3f+ob6V5l8UP+PWSgCp+yj/AMen iT/sIR/+ixXrgryP9lH/AI9PEn/YQj/9FivXBQAV5j+1F8D/AA38dPCNh4f8TalqVjBp179sik09 1V9+0rgllPHNenUUAfNPhj9ib4Z2fiGy1PxL4k8X+LYtPkWWCx1vVPNtw69CVAGR7dK6z9oP9m3w 58T/AB1o/jW08Ta74R8RaPB9mi1HQ5VjkeDnCcjjGSAR6969qooA8U+DX7Mfgb4a694m1DRNU1y5 i8W6d9h1S2v7oTCUEYaTeRu3sSxJJ/iNc78P/wBjnwN4e8AeIvAmo+J/Eeu+GNdA8nSr2dRFprh9 4lg2jiQH+LuOor6NooA+e/hL+yX4Y8I/EHSvF2t+NvFfjC58PR+XoUGtXgeHTh22gAZx2zxwOK+g Wj3LtJyD1yOtPooA+bviH+xP8JfEniq+1vTb3xD4Z/tRy+oWei33k21yScnMZBAB54HHNeleF/gV 8MtA+Clz8KdP8ORf8I1exMl5BIxaS5ZsZkeTqXyAQe2BjpXo9FAHzNoP7FPga21jTY9b8a+MPEPh rRbjz9M8M6lfB7K3bOQCAMso9OOMivTNa+B/hjUf2jNG+Mb32oQ6tomnmwt7OJkFsY9rAZXbngOe hAr02igDxz4c/s1/D/wr8O/GHgmRr/V9I8bXsl3qUV9IpZWb+4VAxg4IPXIrkfAX7G/g7QvF+jap rHjbxd4l0vw1N52h6Jqd6GtLFsgrgAAkAgYHHTnNfSNFAHz98Xv2TfCnjH4h6p4y0Txh4n8HX/iC Ixa6miXQSLUlOA29SOCQOcdfStbxX+y/8ONW/Zst/gtZC+0vRrOdbq3ureQG5FwCSZmJGGYknOR+ WBXtdFAHgviX9lfwv4k+Eug+EfEPi/xNf6t4ZnefSfFD3QXUbZmOdoYDGwYGAemBzWt8BP2cvC3w 31rWfEN9rmteL/EOv25tb/VdduPNkeAjBjCjgAgDPU8CvZKKAPmL/hiH4fCDWdGj8ZeMofC2qu80 fhyHUQtnaTt0lUY+Yr2DZHrmvcvg54I0z4ZfCvSfBWkXN1dWOh2xhgkuSDK65Lc4AGeT2rq6MUAe ET/tU+E4p3iPw++JRKMVJHhaYgkHtTf+GrPCX/RPfiZ/4Ss1e8Ae5paAPBv+GrPCX/RPfiZ/4Ss1 H/DVnhL/AKJ78TP/AAlZq95ooA8G/wCGrPCX/RPfiZ/4Ss1H/DVnhL/onvxM/wDCVmr3migDwb/h qzwl/wBE9+Jn/hKzUf8ADVnhL/onvxM/8JWaveaKAPBv+GrPCX/RPfiZ/wCErNR/w1Z4S/6J78TP /CVmr3migDwb/hqzwl/0T34mf+ErNR/w1Z4S/wCie/Ez/wAJWaveaKAPBv8Ahqzwl/0T34mf+ErN R/w1Z4S/6J78TP8AwlZq95ooA8G/4as8Jf8ARPfiZ/4Ss1H/AA1Z4S/6J78TP/CVmr3migDwb/hq zwl/0T34mf8AhKzUf8NWeEv+ie/Ez/wlZq95ooA8GP7VnhL/AKJ78TP/AAlZqP8Ahqzwl/0T34mf +ErNXvNFAHg3/DVnhL/on3xM/wDCVmrsvgt8ZdF+JWt3mmaZ4Y8WaTJZW4neTWtHktI3BYLtVm4L c5x6Zr0ejFABQaKKAPMj8EfDZ/ab/wCF3/2hqP8Abn9nfYPsu5fs3l7NucY3Zx707xp8FPDniX9o Pwz8Xr3UdRj1jwtbvBaW0TqLeRWDglwVyT+8PQ+lel0UAeUfDv4CeF/B2uePtU07VNUlk+IbyPqS zOhWDeHB8rCjH+sPXNYum/sveCrL9mG7+B0Ws6ydCvLs3T3TSR/aQxdXwDt24yo7V7jRQB4d8U/2 X/B3jHw/4Shg13XdC1zwVYQ2Gk+INNuAl4sMahQrnGG6Z7dT61vfs3fArwx8HINUutN1LVNb1vXZ fN1TWdWn8y4ujkkA9gMknjr3Nep0UAeW/Fv46aD8PvFn/CP6l4T8Z6lN5CTefpGhyXUGGzgb143D HIrmP+GrPCX/AET74mf+ErNXvAHPWloA8G/4as8Jf9E9+Jn/AISs1H/DVnhL/onvxM/8JWaveaKA PBv+GrPCX/RPfiZ/4Ss1H/DVnhL/AKJ78TP/AAlZq95ooA8G/wCGrPCX/RPfiZ/4Ss1H/DVnhL/o n3xM/wDCVmr3migDwb/hqzwj/wBE++Jn/hKzUf8ADVnhL/onvxM/8JWaveaKAPBv+GrPCWf+Se/E z/wlZqP+GrPCX/RPfiZ/4Ss1e80UAeDf8NWeEv8AonvxM/8ACVmo/wCGrPCX/RPfiZ/4Ss1e80UA eDf8NWeEv+ie/Ez/AMJWaj/hqzwl/wBE9+Jn/hKzV7zRQB4N/wANWeEv+ie/Ez/wlZq6r4PfHDQ/ iL4pk0LTfCnjHTJY7dpzPrGiyWsJAIGA7d+elen0mPc0ALRRRQBX1X/kGXP/AFxf+Rr4M+Ef/IRb /rs//oRr7z1X/kGXP/XF/wCRr4M+Ef8AyEW/67P/AOhGgD6r+GP/AB7RV6Xa/wCoH0rzT4Y/8e0V el2v+oH0oAlooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAju/9Q30rzL4of8eslem3f+ob6V5l8UP+PWSgCp+yj/x6eJP+whH/ AOixXrgryP8AZR/49PEn/YQj/wDRYr1wUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBX1X/kGX P/XF/wCRr4M+Ef8AyEW/67P/AOhGvvPVf+QZc/8AXF/5Gvgz4R/8hFv+uz/+hGgD6r+GP/HtFXpd r/qB9K80+GP/AB7RV6Xa/wCoH0oAlooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAju/wDUN9K8y+KH/HrJXpt3/qG+leZfFD/j 1koAqfso/wDHp4k/7CEf/osV64K8j/ZR/wCPTxJ/2EI//RYr1wUAFcL8b/i14L+E1hpd740v7i1h 1i8FlaGG3aUvKRnBC9Biu6r4/wD+CvH/ACJfw5OMj/hLo/8A0GgD6gn8ZeGYfHFn4Ok1y0Gv31u1 1BpokzO0SjLOVHKr7nrXQV8A33hHx9c/8FX59OsviNLaai+lrfpfiyRitj8rfYtvTGz5d3Wq3jv9 ovxP41+KvjkQ/HAfDLT/AAvcS2Xh/S4dKa5OqyxlgWmcK2ASuP8AgQ44oA/Qeivgb4kftM/FTWf2 Pfh/430DVP7E8T3XittF1Vo7cCO7ZEyCVYcKwKEge4rU8Z67+0n4P/an8OfC5fjDDqT/ABC0wTPd T6VGI9HJLeY0EY7qEO3JOe4oA+5apa7qVro+jXeq38oitLGB7ieTGdqICzH8ga+Yv2J/HPxJT9pX 4k/Brx54vl8WQeFkS4sdTuYFjmOXUEHb2IdTjnBB55o/4Kn69caD8ITNZfFS68MXdxay28egQRIf 7fWR40YMx5UIrHJHYmgD1zw38efh3rtz4Mg02/vZJfHyTvoUbWTgzpDne7Z+4oweT1r00dK/NL9n G30f/hrHwbpEf7Qyzaf4R0S0j0i48iMLNLMy+bpkA6FTuZWfr+NfpanSgBaKKKACiiigAooooAKK KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAbI20ZJAGOSa+ffiB+2h8B/CPi2fw/d eIr3UZ7WQx3M+mWLXEEDA4ILggHBz0zXc/tjatqmh/sueO9V0VnS+ttCnMLx/eTK4LD6Ak15p/wT j8C+B2/Yz8PyHQ9NvH1+CaXVpJrdJGuJDIykOxGTgAADtQB7x8O/F/hzx34RtPE/hPVoNU0q9XdD cwNwcdQR1BB6g1vDpXzgmjeDPhV+zD4n/wCGffGnhvSEN60kuq6vqvn2lhMSFk9QrgDCpjrjg14b 8Fvjn400v9qjwH4S0/423fxL0TxP/o2sG70r7PBBOQc/Z3KgsAQCGH4jmgD9AaK/Or4pfHb4nRfG 3xnovjb4s678Lruw1BofDFimiLLptxCrsFeaTaXwyhTuAYHcfpXqv7Tf7Qni/wAFfszeAZtJ8XeH rrxH40mFrc+KdNjMtlBEv+suI0IzuwVyMcHdx0oA+wKbIwRCxIAUZJNfE37NXx28Qaf+09o3w7k+ LMnxS8M+JrZlGpzaW1tNp14qkhPujKnafXhh0Ir2X/goFrkvh34E3Gq2vxPufA11b+a9s1tEjvq0 nlNi1G7puPORzxQB0Fh+0R8ML3QtJ1i11a8ltdc8Qt4e04rZPuuLxTyFH90f3uleqrnHNfk/8KI9 Nbxn8JfDs37QS6dp9ray6/PJ5MZi0C/kYnyEz9+Vz13dM1+rtsQYExJ5nyj5/wC9x1oAkooooAKK KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAr6r/yDLn/ri/8A I18GfCP/AJCLf9dn/wDQjX3nqv8AyDLn/ri/8jXwZ8I/+Qi3/XZ//QjQB9V/DH/j2ir0u1/1A+le afDH/j2ir0u1/wBQPpQBLRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBHd/wCob6V5l8UP+PWSvTbv/UN9K8y+KH/HrJQBU/ZR /wCPTxJ/2EI//RYr1wV5H+yj/wAeniT/ALCEf/osV64KACvEP22fghrPxu0Dwxp+j63Y6W+g60uo StdxuwlUDG1dvf617fRQB82/FT4FfEuX9r3T/jZ8OfE+h2Uj6fFp2o22qW7viFcB9m0cllHHTBrB 8S/s3/Fjwj8R/FutfA/xroGl6T43mafULLWLEyvYTNu3SQMAcHLMR6Z9hX1hRQB8xfF79mPxb4v+ B/gjwUfiCuo6r4b1tdU1DVdWjYm7ODlIwn3QM4Gew5NdZ8SPgjrXiX9rXwL8XYNbsYLDwnYNa3Fj IjmacnzOUI+UD5+/pXuNIRQB4h8H/gnrXg79rHx/8WrvWrG5sPGMCxW1lEjia3wyH5yeD9zt61d/ a2+Cv/C57TwnY79Jgt9F12G/1CS8tjJLNbLndBGQON5xnPBwK9ixQBQB4T8Cf2b/AA94M+JnjLxj rWi+Gb2bXNaS80SK205QukQIMIqbh8rZ5JXjIr1Xx9468G+BbS3ufGPiXTdEivJDHbvfXCxCVgMk DPU4roqyPFXhfw54miii8R6BpurR27F4UvrVJhGx4JUMDg49KAON/wCGgvgh/wBFU8Lf+DKP/Gj/ AIaC+CH/AEVTwt/4Mo/8a2f+FUfDAf8ANO/C/wD4KIP/AImj/hVHww/6J34X/wDBRB/8TQBjf8NB /BD/AKKp4W/8GUf+NH/DQXwQ/wCiqeFv/BlH/jWz/wAKo+GH/RO/C/8A4KIP/iaP+FUfDD/onfhf /wAE8H/xNAGN/wANB/BD/oqnhb/wZR/40f8ADQXwQ/6Kp4W/8GUf+NbP/CqPhh/0Tvwv/wCCeD/4 mj/hVHww/wCid+F//BPB/wDE0AY3/DQXwQ/6Kp4W/wDBlH/jR/w0F8EP+iqeFv8AwZR/41s/8Ko+ GH/RO/C//gng/wDiaP8AhVHww/6J34X/APBPB/8AE0AY3/DQXwQ/6Kp4W/8ABlH/AI0f8NBfBD/o qnhb/wAGUf8AjWz/AMKo+GH/AETvwv8A+CeD/wCJo/4VR8MP+id+F/8AwTwf/E0AY3/DQXwQ/wCi qeFv/BlH/jR/w0H8EP8Aoqnhb/wZR/41s/8ACqPhh/0Tvwv/AOCiD/4mj/hVHww/6J34X/8ABRB/ 8TQBjf8ADQXwQ/6Kp4W/8GUf+NH/AA0F8EP+iqeFv/BlH/jWz/wqj4Yf9E78L/8Agng/+Jo/4VR8 MP8Aonfhf/wTwf8AxNAGN/w0H8EP+iqeFv8AwZR/40f8NBfBD/oqnhb/AMGUf+NbJ+E/ww/6J54X /wDBRB/8TQPhP8MP+ieeF/8AwUQf/E0AY3/DQXwQ/wCiqeFv/BlH/jR/w0F8EP8Aoqnhb/wZR/41 s/8ACqPhh/0Tvwv/AOCeD/4mj/hVHww/6J34X/8ABPB/8TQBjf8ADQXwQ/6Kp4W/8GUf+NH/AA0F 8EP+iqeFv/BlH/jWz/wqj4Yf9E78L/8Agng/+Jo/4VR8MP8Aonfhf/wTwf8AxNAGN/w0F8EP+iqe Fv8AwZR/40f8NBfBD/oqnhb/AMGUf+NbP/CqPhh/0Tvwv/4J4P8A4mg/Cj4YY4+Hfhf/AMFEH/xN AE3gD4l/D/xxqFxY+D/GOj63c2sQlnisbtZWjQnG4gdBkgV1VYXhPwX4R8MXUtz4d8L6RpM06bJZ LGyjhZ1znBKgZGa3aAKXiDTLLWdGu9J1K2S5sr6B7e5hf7skbgqyn6g18mQ/sn/GDwXb6n4X+EPx 1l0HwXqsru2mXtqZJrUP94RuAcHHGQVz35r7AooA+VvFf7Gmkj9khvhL4V8QvBqranHq9xqt4mUv 7pVK4lQdE2nAHOMZ5qjpH7NXxg1L4q/D34g+MvHvhme78EzpGmlWGmtBbR2q9oyoy0jckkgDpivr ekIBoA+VPil8BPjzqOp+ItJ0f4heGfEnhjxHI5SPxjpxu7vSFfI2wPggbQ2AfYHAPNWPEH7HtnJ+ zH4Y+HeieLJbbxF4Q1BtU03Wpod0f2p23ODH2jJxgc4x3r6kooA+f/gZ8LPjZbfFhfG3xY+Iem3c Nna/ZrXRNAtfJtJm5HnTAqPm5zx3x0AxXU/tifCe5+M3wam8FWVxptpcT3kEovL6AyfZ0VwXMeBl XKgqCPU16vSEUAfPnw7/AGX/AAronx717xtquh+F7zRbnSrOw0bSV0xcWjQhd8zhht8xmXO4c817 T4z8WeGPBehjVfFOt2Gjaf5iwrcXkwij3HouT34raxWf4l0HRfEOnf2fr2kWOqWm8P5F7brNHuHQ 7WBGfegDh/8AhoL4If8ARU/C3/gyj/xo/wCGgvgh/wBFU8Lf+DKP/GtkfCf4YY/5J34X/wDBRB/8 TR/wqj4Yf9E78L/+CeD/AOJoAxv+Ggvgh/0VTwt/4Mo/8aP+Ggvgh/0VTwt/4Mo/8a2f+FUfDD/o nfhf/wAE8H/xNH/CqPhh/wBE78L/APgng/8AiaAMb/hoL4If9FU8Lf8Agyj/AMaP+Ggvgh/0VTwt /wCDKP8AxrZ/4VR8MP8Aonfhf/wTwf8AxNH/AAqj4Yf9E78L/wDgng/+JoAxv+Ggvgh/0VTwt/4M o/8AGj/hoL4If9FU8Lf+DKP/ABrZ/wCFUfDD/onfhf8A8FEH/wATR/wqj4Yf9E78L/8Agog/+JoA xv8AhoL4If8ARVPC3/gyj/xo/wCGgvgh/wBFU8Lf+DKP/Gtn/hVHww/6J34X/wDBPB/8TR/wqj4Y f9E78L/+CeD/AOJoAxv+Ggvgh/0VTwt/4Mo/8aP+Gg/gh/0VPwt/4Mo/8a2f+FUfDD/onfhf/wAE 8H/xNH/Cp/hh/wBE88L/APgph/8AiaAMb/hoL4If9FU8Lf8Agyj/AMaP+Ggvgh/0VTwt/wCDKP8A xrZ/4VR8MP8Aonfhf/wTwf8AxNH/AAqj4Yf9E78L/wDgng/+JoAxv+Ggvgh/0VTwt/4Mo/8AGj/h oP4If9FU8Lf+DKP/ABrZ/wCFUfDD/onfhf8A8FEH/wATR/wqj4Yf9E78L/8Agog/+JoAxv8AhoL4 If8ARVPC3/gyj/xo/wCGgvgh/wBFU8Lf+DKP/Gtn/hVHww/6J34X/wDBPB/8TR/wqj4Yf9E78L/+ CeD/AOJoAxv+Ggvgh/0VTwt/4Mo/8aP+Ggvgh/0VTwt/4Mo/8a2f+FUfDD/onfhf/wAE8H/xNH/C qPhh/wBE78L/APgng/8AiaAMb/hoL4If9FU8Lf8Agyj/AMaP+Ggvgh/0VTwt/wCDKP8AxrZ/4VR8 MP8Aonfhf/wTwf8AxNH/AAqj4Yf9E78L/wDgng/+JoAxv+Ggvgh/0VPwt/4Mo/8AGtrwL8VPhx40 1ltJ8J+NtF1m+SIzNb2V4sjhAQC2B2yRSH4UfDDH/JO/C/8A4KIP/ia0PDHgbwZ4c1JtQ8P+E9F0 u6aMxtPZWEcLlT/CWUA44oA6CiiigCvqv/IMuf8Ari/8jXwZ8I/+Qi3/AF2f/wBCNfeeq/8AIMuf +uL/AMjXwZ8I/wDkIt/12f8A9CNAH1X8Mf8Aj2ir0u1/1A+leafDH/j2ir0u1/1A+lAEtFFFABRR RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFAEd3/qG+leZfFD/j1kr027/1DfSvMvih/wAeslAFT9lH/j08Sf8AYQj/APRYr1wV5H+yj/x6 eJP+whH/AOixXrgoAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigCvqv/ACDLn/ri/wDI18GfCP8A 5CLf9dn/APQjX3nqv/IMuf8Ari/8jXwZ8I/+Qi3/AF2f/wBCNAH1X8Mf+PaKvS7X/UD6V5p8Mf8A j2ir0u1/1A+lAEtFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFAEd3/qG+leZfFD/j1kr027/wBQ30rzL4of8eslAFT9lH/j08Sf 9hCP/wBFivXBXkf7KP8Ax6eJP+whH/6LFeuCgAqOaZIYmlldI40BZ2dsBQO5J7VJXyh/wVX8U63Z +B/Bvw+0e/m09PHWvJY39zCSreQCgKZHYmQEjuBQB9AaF8VPhvrXiFtB0jx34evdTVtn2SDUY2kL egAPJ+ldcCc18w+Pv2IPhFf+A7LSvBlvN4W1/TXie28QQyvJcMykEs4LAMTz0xg4xWx8fvjR4p+G WreC/hB4K0uLxl8Q9ftVRJb+TyIVRBta4mC92Ks2ARgA0AfQzHC5PSueXx14MbRbrWF8V6N/Z9lO ILm7F9H5UMh6I7Zwrcjg14l8Gvjz48X49SfBT41eFdL0bxJd2TXekX2kTtJaXyhSdo3cg4DYPqpG BXyPpCKP+CePxmAVRj4gR9v+mkdAH6g6fcwXlpHdWs8c8EyB4pY2DK6kZBBHUEVNXyl4p+O2t/D3 4e/Cf4afD/RNN1Txh4o8PWssB1W68izsoFiA8yRsjqVbHP8ACevAra+CX7TGo3OreN/CfxZ0nStK 8Q+BdMbVrmbRrsT2d9aKoJaIkkg/MvBP8Q6c0AfSdRTTRxMivIiGRtqBjjcfQepr5G8KftEftI+I fCunfE7Rvg3pmp+B9Uv/ACILCxnll1byNxXzto+XHB5x19BzXIftLeKvjPL/AMFDPA1toWi6fK0F k9x4a0u8v3ihuY3jfzJLhc4SUfOMf7IoA+7R0or5L8XftLfFPX/iL4o0H4SeF/CdzY+Bl8vVrrXd SMLX1woO+K2UMM4KsBnrjqMirniL9sWyX9lPQ/iZoHhk3XiLxFqf9i2miyynZHfL98FhyUAKkdCd wFAH0prfiPQdGvrOy1bWLGxudQfZaQ3Nwsb3Df3UBPzHkdKu3l1BaWct3dTRwwQIZJZZGCrGoGSS T0Ar8/P2jtd+LuqftHfA+w+MHg/RtIv4tcjuLS60i5aWC4R5Yt0bBuVkQgZGSDnivtr4/hT8DPGQ YAg6BeZB6f6h6AGr8WvhgxAX4h+GCT0xq0PP/j1dXpt5a6hZR3llcw3NtMu6KaFw6SD1DA4Ir8ov 2ddd/Z3sPgG1t8QfhB4j8ReJQ1znVLG1cxEEnyx5gcAFRjnBxivaP2XfH3jX4Of8E87z4g+GJtL8 TQW/iIyyaVNctKdJsn2oUYqQVfdhiDwA2aAPvyivnT4sftGapaeKvhN4b+Huk6fqt/8AEpI7tzdM 221tGC5cbT1H7zrx8lfRS9OaAFooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKAK+q/8gy5/wCuL/yNfBnwj/5CLf8AXZ//AEI1956r/wAgy5/64v8AyNfBnwj/AOQi 3/XZ/wD0I0AfVfwx/wCPaKvS7X/UD6V5p8Mf+PaKvS7X/UD6UAS0UUUAFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAR3f+ob6V5l8U P+PWSvTbv/UN9K8y+KH/AB6yUAVP2Uf+PTxJ/wBhCP8A9FivXBXkf7KP/Hp4k/7CEf8A6LFeuCgA rxX9uD4KT/Gv4YW+n6PqKad4i0K9XUNGupOEWYDlGI6BhjnsQK9qpCoJ6UAfFfjzTf21Piv4TtPh nrnhzRPCdr50Q1XxPaahte5RGB3KEckcjOFAz7Cuo/aC+DnxE8M/Ez4efFv4XW58Xar4J0tdL1LT r+6C3OpwqpUyB2OC53NnJznHWvq3ApNooA+T/hX4B+KnxQ/azsfjp8TfCK+C9O8Nae1pomivdLNc TOQw3uV4Ay7HnHYYrzbTv2f/AIuR/sX/ABO8EyeEJf7d17ximo6dZ/aod08AdCXDbto4U8Eg1984 FBAoA+KP2kf2e/GOpp8LvHtj4Fs/GM3hbw9b6V4g8J3VyI2uEReqOCASCzdD1A681qfAD4E6v4h0 zx7Lr3wg8NfDHTPEWjTaTo9tblpdSjEgGWmkDEFMqDjAJz2Ar7D2L6UbRQB8S/DOL9rvwR8LdG+C Phj4fWemXWj3vlx+MpLqKWyNnvLE+Wckn5vTOB0Brpv2ofBvxa0r9qj4bfFvwp4Kk8cR6BpBsdQi tZ0t3eYhwzkMflU+ZuB5HGK+tNoxjtRtFAH5+eNvgB4u8F/Fvxjqw+ANh8UdL8WzNf6RNLfeXJpF xJlmjlG4blDMQcddo5Ga7D4kfs2+P739lLwquheHPDek+OPDGv8A/CQf2JpAMdrK52jywWYgyAIm ecHBAr7T2igqD1oA+I/iX4d/aK+Mnxi+FXjTXvhRH4c0nwxqqPdWx1GOS4Q70aSZxkYQ7flUZPXN fXHxg0+91j4U+JtI02Ez3l/o91b20QYDfI8TKq5PHJIrpNozQAKAPhX9mRf2sfg18HYfh9p3wC0/ VYIp5plu7zV4lOZW3YZQ/IFei/sgfs9634W+Bnj7Svil/Z9tefEWaaa9063cG3sEZGA5Hyg5Ynjo AvpX1KQK5L40/Drw58UPA8vhPxP9uGnzSpKxsrpreUMp4w6846gjoRQB8Xf8ErPB2s6/8YdY8W+I r5dSsvhzZN4a0GcEGMZkcnYe4CZIP/TSvvwsFGWIA75Nct8GPhv4P+FngiLwp4K0pbDTYpGkKly7 yu3V3Y8sen5Vb+J/g3RvHvg668Ma99r+wXZQy/ZLp7eX5WDDDoQRyOfagDe8xO7qP+BUvmR/31/7 6rwo/sj/AAhJyW8V/wDhTXf/AMXR/wAMjfCH18V/+FLd/wDxdAHuvmR/30/76o8yP++n/fVeFf8A DI3wh9fFf/hS3f8A8XR/wyN8IfXxX/4Ut3/8XQB7r5kf99P++qTzE/vr/wB9V4X/AMMjfCH18V/+ FLd//F0f8Mj/AAh9fFf/AIUt3/8AF0Ae6eYn99f++qXzE/vr/wB9V4V/wyP8IfXxX/4Ut3/8XR/w yN8IfXxX/wCFLd//ABdAHuvmJ/eX/vqjzE/vL/31XhX/AAyP8IfXxX/4Ut3/APF0f8Mj/CH18V/+ FLd//F0Ae6+Yn99f++qTzE/vqf8AgVeF/wDDI3wh9fFf/hS3f/xdA/ZH+EI6HxX/AOFLd/8AxdAH unmJ/fX/AL6o8xP76/8AfVeFn9kb4Qk5J8V/+FLd/wDxdB/ZH+EOPveK/wDwpbv/AOLoA918yP8A vr/31R5if31/76rwn/hkb4Qf3vFn/hS3f/xdKP2RvhD/AHvFf/hS3f8A8XQB7r5id3X/AL6pPMT+ +v8A31Xhf/DI3wh/veK//Clu/wD4uj/hkb4Q/wB/xZ/4U13/APF0Ae6eYn99f++qPMQdXX/vqvCx +yN8If73iv8A8KW7/wDi6D+yP8IT1Piv/wAKW7/+LoA9081P76/99Cl8xP76/wDfVeFf8Mj/AAh/ veK//Clu/wD4uj/hkb4Q+viv/wAKW7/+LoA918xP7y/99UeYn99f++q8K/4ZH+EPr4r/APClu/8A 4uj/AIZG+EPr4r/8KW7/APi6APdPMT++v/fVHmJ/fX/vqvC/+GR/hD6+K/8Awpbv/wCLo/4ZH+EP r4r/APClu/8A4ugD3XzE/vr/AN9UeZH/AH0/76rwr/hkb4Q+viv/AMKW7/8Ai6P+GRvhD6+K/wDw pbv/AOLoA918yP8Avp/31SeYn99f++q8L/4ZG+EPr4r/APClu/8A4ug/sjfCH18V/wDhS3f/AMXQ B7r5if31/wC+qPMT++v/AH1XhI/ZG+EP97xZ/wCFLd//ABdL/wAMjfCH18V/+FLd/wDxdAHunmJ3 df8AvqjzFz99fzrwv/hkb4Q/3vFh/wC5mu//AIug/sj/AAh/veLP/Clu/wD4ugD3XzI/+eif99Ue ZH/fT/vqvCf+GRvhB/e8V/8AhS3f/wAXR/wyN8IfXxX/AOFNd/8AxdAHu3mR/wB9P++qPMT++v8A 31XhX/DI3wh9fFf/AIUt3/8AF0f8Mj/CH18V/wDhS3f/AMXQB7r5if31/wC+qPMT++v/AH1XhX/D I3whz18V/wDhS3f/AMXR/wAMjfCH18V/+FLd/wDxdAHuvmR/30/76o8xP76/99V4Uf2RvhD/AHvF f/hS3f8A8XSD9kb4Q/3vFf8A4Ut3/wDF0Ae7eYn99f8AvqjzE/vr/wB9V4V/wyN8IfXxX/4Ut3/8 XR/wyP8ACH18V/8AhS3f/wAXQB7p5qf31/76FHmR/wB9f++q8LH7I/wh9fFf/hS3f/xdIf2RvhCT kt4r/wDClu//AIugD3bzE/vL/wB9UnmIeQ6/99V4V/wyN8If7/iz/wAKW7/+LoH7I3whAwG8WY/7 Ga7/APi6APdTInTev/fVCOpbaHUnHY14V/wyN8If7/iz/wAKa7/+LrqvhD8CfAXw18Tvr3hn+2/t clu1u327WJ7lNpIJ+R2Izx1oA9OooooAr6r/AMgy5/64v/I18GfCP/kIt/12f/0I1956r/yDLn/r i/8AI18GfCP/AJCLf9dn/wDQjQB9V/DH/j2ir0u1/wBQPpXmnwx/49oq9Ltf9QPpQBLRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQBHd/6hvpXmXxP/wCPWSvTbv8A1DfSvMvif/x7SUAVP2Uf+PTxJ/2EI/8A0WK9cFeRfspDNn4k H/UQj/8ARYr10UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBX1X/kGXP8A1xf+Rr4M+Ef/ACEW /wCuz/8AoRr7z1X/AJBlz/1xf+Rr4M+Ef/IRb/rs/wD6EaAPqv4Y/wDHtFXpdr/qB9K80+GP/HtF Xpdr/qB9KAJaKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKAI7v/AFDfSvMvih/x6yV6bd/6hvpXmXxQ/wCPWSgCp+yj/wAeniT/ ALCEf/osV64K8j/ZR/49PEn/AGEI/wD0WK9cFABSBgTjmlr5L/4K4axrej/CTwmdD1vUNJluvEaQ STWNw0TshjbglSM+tAH1pRkV8MfH/wCEPj/9n74ZD4v+AfjV4x1SbRZIJr7TdZuvOhuIXYAjHT+I AgjpnmvbfF/7UHhbw78PfA+rJomra/4h8dafDd6Z4e0aISXEgZQWPJwFDEj3wfSgD3nIpcivEfhv +094B8TeCPFmu6raat4ZvfA8Zk1/R9Ut9t3aL0BCj7wY8D3I9a5rwf8Atf6Lq2qeH5NX+GHjbQ9A 8UzCHSNfubNZLW4JYKG/dkkDJ69qAPpOjNeM/H79onw98NvHdh4E0/w1rnjDxbfwfaRo2hwiSWKH n53J4GcHArP8LftTeBdc+Anib4nWulavEPCL+XrOjTxKl5bSbgAvJ2nr1z2NAHu2aTNfG3xN/am8 DfFf4IeLYbTSPH+iaNp+mW17NrmnBIJgxnjTyYnY4LbmwecEBq9C8T/tGeB/g18LPhkdatfEepWP inTYRaXjKstwqCOP55wDlnO8ZC5JOaAPofIoyK8A+Hv7VPh3xF8R7nwNrXgfxX4X102Ul7pdlq9q qSapGqFwsYB4dgpwp69M141+zj+0j4r+IHjn4qaV4y07xaumT2939ie0t1jTw5bwwzEo/wDcnIUY JzlloA+5M0ueK+WPgB8b/hv8OP2MNO8cX2t+K9S0yfUp7ayXW2W41S9uC5/dqFOCODjnAFdP8LP2 qvDniX4k6d4G8VeCvE/gTVtbjEmjjXrYJHfAjICsDwT2B78UAfQGRQDmvnXxX+1x4Z0r4neKfh7p vgPxdr3iHwzKUNppdqsv2sLje6kH5FUHJLY9smvQf2YPjR4Y+OHgGXxN4bt7yzNpdNaXtjeqBNay gA7WwSDkEHIoA9JJANJkV5x+0h8aPCPwY8O2epeIxeXl5qk32bTNL0+LzLm+k/uovpyOT6iuN+FH 7UPh3xX42ufA+v8Ag3xL4Q8Ux2b3dpo+sW4WTUEVC+ISDguQDgHGcGgD3nNGRmvzv/Zd8YXfxX/b r1nW/Ftr8RS8OrBtJtoLho7TR0XeRHexg4VcKAFHfOa9+/4Kr6xrGg/slXWo6Jqt5p12ur2iCe0n aJ9pZsjKnODQB9J59jSZFfnV4V0H4E33hvTbjUf2xvGVpqF1aQtc2q6u2IZmQbk+72YkV9ceEPjB 4f0/47WfwFurXVRqtvokV1Y6rdsjRanEsY+YMDkucMTx1U0AevZozXy98Yfj54N8e/CT4taXbw+L NO0zwOyWt/rekSRxyyy+cFxbsT1ypznHH1rZuPj54H+EX7MPgHWro+Iddl16wgh0WwkCy6nqB2jm Q5xnkZPqQBnNAH0QCD0or4am+Muq+Pv+Ch3w0s7fT/FnhNYbB4dY8PatugxJiZ1YoDtdSpQhvb2r 1bx7+1/4U0TxZrmnaF4H8WeK9L8LzCHXdc0i1V7SxfOGBJPzbe5HoaAPo7IoyK8Q+L37UPw78BfD nwh46kj1HV9C8ZT+XZXFjGCYhgEs6kg5GSCo5yCKofDf9qnwx4o+Ndp8NtT8GeJ/DF9q8TTaNPrN qIk1FACVYLncu4KSM/Q4NAHv+aCa+Z/G37ZfhDRte12HQ/A3izxNofhi4FvrWv6bbKbO0fdtPLEZ APeux+KH7Svw+8JfDnw14ps01HxBL4zVT4f0nTYN13f5xnCnG3aSAc9+KAPZsilryT9nj4+eHvil 4i1fwtLoGteFvFOhqJL3Q9ahEc6xngSLjgjkfmPWvW6ACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigCvqv/IM uf8Ari/8jXwZ8I/+Qi3/AF2f/wBCNfeeq/8AIMuf+uL/AMjXwZ8I/wDkIt/12f8A9CNAH1X8Mf8A j2ir0u1/1A+leafDH/j2ir0u1/1A+lAEtFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAEd3/qG+leZfFD/j1kr027/1DfSvMvih /wAeslAFT9lH/j08Sf8AYQj/APRYr1wV5H+yj/x6eJP+whH/AOixXrgoAK+RP+Cv9pf3Xwh8IvYa deXrW/iRJZEtYGlYKI2ycKDX13Sbec96APhr9oz46al8fPhI3wg+F3wv8ZSapr0kEFxd6jp32e3t o0dSxZiT/dHJxgZrB/af+GOqfCn4q/CrxHe33iu08J6H4Zh0O/1vwsm660+aNWDOODhXLE9ORnHP FfoHj3NNeJHRldQytwysMgj0xQB8HfAXw5oXiWL4rePNM8GfErx1YX+jHTpZvEN7HDJ4lj3LkRDy 1YSKEBB5xgDqcV5R4Xurzw3rHhxP2dfFPxKh8RXWoxJe+CtY06SS2sFydytKVEZUHjO3oTyCK/Uh IkRFRFCqvChRgD6CkSCFJmmWJFkcYZwoDN9T3oA+MPiTqd78Df8AgoFcfFvxxoeqXPhXxP4eS0Gp adaPdLZXCxoGjIXkfNHgD0YH1q18RvH3iD4ufsRfFfXF+GD+GtOn+TRnSFhc6wnmrmZo9gPTHPPO fSvsWSCKSMxyRq6N1VlBB/CnKgUYHAAwAO1AHxp8VdFuYf8AgkJp2lWmk3K3R0Sw3WqW7ebuNwjN lAM5zknNcB+1zcXmj+EP2X7uPQ59SutPjtZRpYizLcugtj5Ww/xHGMetfoXtGc968l/aD+CVv8UP iJ4D8VS+IJtNfwNqi6hFDHbhxdEPG+0kn5f9X29aAPn+88Sj9or9u/4c+I/Afh7W7bRvAcLzazqW o2D2uxiSfJ+YdQflx3ye1c/8Cdd/4RX4rftDfD/XNK1iDWvFs2pT6WgsZGilRYrl8lwMDIYYPfOK +944Yk3FI1XedzbQBk+p9aFgiWbzRGgk27d+0bsemetAH5peH/A3jM/sVfCnxpYeF9R1SPwJ4uur /VdGFuwmeAzK3mCMjJ+5j8RXpHxh8WJ+1V8fPhlp3wy8Pa7FZeFNRGp6zrN/p72y2aho2MeW7/Jj APJIxX3RtFMjhijBEaKgY5IVQMn14oA+TP2RdMvrf/goV8dL+5025hgnZBb3MsDKkg8wZ2sRg+vF P/4JRadf6d4c+JaX+n3VmZfGMrxCeBo967eq5AyK+s9oxSjigD5M/wCCgeheIdD+OHwv+Nln4fvt f0DwbdMusWdlH5skCFwwlCd+M8+qiuWudcb9pP8Abj+Hni/4eaDq8HhvwEnn6preoWTWwlO8t5Kh sEnOFx/tN2r7bKgk5HXrTIoYokCRIqKDnaqgD8hQB8m/sF2Go2v7Vfx3uLywureG61lWhkmhZElH my8qSMN17etbv/BWWyvtS/ZDu7XTrK5vJzrNmRFbxNI+AzZOFBOK+mCoJ60bRnNAHwd4M+MX7N+m +ENIstU/Z11qfULSxgjuZ/8AhEIz5kyIoZsnk5YE5rrf2+rXWV8M/Dr9pL4caPef2t4fCA2rW7CZ bW5jOwSRrk/IxwR23GvsTHvRtoA+IZPhhfeCP+CUfiG2uLC4l8ReJ7cazqaLCWmMs0yFVIAydqBf xzXO/FLR9f8ACngL9mv4xSeHdR1PRvBNhBHrVnBbs01sG2MHKEZHQ9R1Ar9ANtNaNWVlYBgwwQRk GgD4U1LxmPiv/wAFHvht4w8PeFfEFn4fTS5La21S902SD7X8k5MmGHCqz7QT1xx2ryjQ9O/4VRL8 QPAnxE1n4q6Nqd1qU8mn6Z4ZXFl4gjkyoyxjblhgZPGD68V+oaoqoEUAKBgADAFNkghkdHeJGaM5 QsoJX6HtQB+evx98AXfh39m/4D6HpvhjxFbRJ4rN3Lp+pYubmzSR1bbKY1AA5zggYzzXq37WGl31 7/wUU+DE9tY3L20dhcxzXMcDMkG7zgCzAYGM96+twMCkCgDAoA/P74B/FKX9mv4feOfhZ408A6zq Xio63PcaRajTXlttaEmFXLqCNvy578H1q5+2Vovja+1n4P8Axm1/w1r/AIW06xtGh1y18MHzLzw8 XcsrR/LgHaefl4II6195tBCzo7RozR/cYqCV+h7UrRIc5GQwwQRwaAPjP9h/SdB8U/tOav8AEPQJ PiXrdvp2mGyHifxTNGkV9uC/uhGY1cle3JxjnHFfZoYEcU1IYoogkUaoq/dVFwB+Arg/jT4O8eeK pbA+C/iddeDRbB/tIt9OiuftOcYzv6Yx29aAO/zRmvB/+FPfHTP/ACcxq3/hO2tB+D3x07ftMat/ 4TtrQB7xmjNeDj4PfHTv+0xq3/hO2tH/AAp746f9HMav/wCE7a0Ae8ZozXg//Cnvjp/0cxq//hO2 tJ/wp746/wDRzGrf+E7a0Ae8g0Zrwc/B746f9HMav/4TtrSf8Ke+Ovf9pjVv/CdtaAPec0Zrwf8A 4U98dP8Ao5jV/wDwnbWg/B746dv2mNW/8J21oA95zRmvBh8Hvjp3/aY1b/wnbWj/AIU98dP+jmNW /wDCdtaAPeM0Zrwf/hT3x0/6OY1b/wAJ21o/4U98dP8Ao5jVv/CdtaAPeM0Zrwb/AIU98df+jmNV /wDCdtaX/hT3x0/6OY1b/wAJ21oA94zRmvB/+FPfHT/o5jVv/CdtaP8AhT3x0/6OY1b/AMJ21oA9 4zRmvBz8Hvjp2/aY1b/wnbWgfB7469/2mNW/8J21oA94zRmvB/8AhT3x0/6OY1f/AMJ21o/4U98d P+jmNW/8J21oA94Jpc14L/wp746/9HMat/4TtrS/8Ke+On/RzGrf+E7a0Ae8ZozXg/8Awp746f8A RzGrf+E7a0f8Ke+On/RzGrf+E7a0Ae80Zrwb/hT3x0/6OY1b/wAJ21o/4U98dP8Ao5jVv/CdtaAP eM0Z9q8HPwe+Ovb9pjVv/CdtaT/hT3x07/tMat+Hh21oA95z7Uua8G/4U98dP+jmNX/8J21o/wCF PfHT/o5jVv8AwnbWgD3jNGa8H/4U98dP+jmNW/8ACdtaT/hT3x1/6OY1b/wnbWgD3kkUbucYrwc/ B746Y4/aY1b8fDtrXU/B/wAA/Evwx4pfUPF3xhvvF1g1u0a2M+lQ26q5IIfcnPAB/OgD1CiiigCv qv8AyDLn/ri/8jXwZ8I/+Qi3/XZ//QjX3nqv/IMuf+uL/wAjXwZ8I/8AkIt/12f/ANCNAH1X8Mf+ PaKvS7X/AFA+leafDH/j2ir0u1/1A+lAEtFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAEd3/qG+leZfFD/AI9ZK9Nu/wDUN9K8 z+JvNtL9KAKf7KP/AB6eJP8AsIR/+ixXrgryP9lH/jz8R/8AX+n/AKLFeuCgAooooAKKKKACiiig AooooAKCM0UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig AooooAKKKKAA8ijAoooAKKKKAK+q/wDIMuf+uL/yNfBnwj/5CLf9dn/9CNfeeq/8gy5/64v/ACNf Bnwj/wCQi3/XZ/8A0I0AfVfwx/49oq9Ltf8AUD6V5p8Mf+PaKvS7X/UD6UAS0UUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAR3f +ob6V5l8Tv8Aj2kr027/ANQ30rzL4of8eslAFT9lD/jz8R/9f6f+ixXrgryP9lH/AI9PEn/YQj/9 FivXBQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAFfVf+QZc/8AXF/5Gvgz4R/8hFv+uz/+hGvv PVf+QZc/9cX/AJGvgz4R/wDIRb/rs/8A6EaAPqv4Y/8AHtFXpdr/AKgfSvNPhj/x7RV6Xa/6gfSg CWiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigCO7/1DfSvMvih/x6yV6bd/6hvpXmXxQ/49ZKAKn7KP/Hp4k/7CEf8A6LFeuCvI /wBlH/j08Sf9hCP/ANFivXBQAUZFFeZfGLU/jrZ+JYo/hr4Y8I6npJtwZZdY1GWCYS5OVCqCNuMU Aem0V4N/bv7XP/QgfDb/AMHVx/8AE0f27+1z/wBCB8Nf/B3cf/E0Ae80V4N/bv7XP/QgfDb/AMHV x/8AE0HXf2uf+hB+G3/g6uP/AImgD3mivBv7d/a5/wChA+Gv/g7uP/iaP7d/a5/6ED4a/wDg7uP/ AImgD3mivBv7d/a5/wChA+Gv/g7uP/iaP7e/a5/6EL4aj/uN3H/xNAHvNFeDf27+1z/0IHw1/wDB 3cf/ABNH9u/tc/8AQgfDX/wd3H/xNAHvNFeDf27+1z/0IPw1H/cauP8A4mj+3f2uf+hA+G3/AIO7 j/4mgD3mivBv7d/a5/6ED4a/+Du4/wDiaP7d/a5/6ED4a/8Ag7uP/iaAPeaM14N/bv7XP/QgfDX/ AMHdx/8AE0f29+1yP+ZA+G3/AIO7j/4mgD3mivBv7d/a6/6EH4bD2/tq4/8AiaP7d/a5/wChA+Gv /g7uP/iaAPeaK8G/t39rn/oQPhr/AODu4/8AiaP7d/a5/wChA+G3/g7uP/iaAPeciivBv7e/a6P/ ADIPw2H/AHG7j/4mj+3f2uf+hA+Gv/g6uP8A4mgD3mivBv7d/a5/6ED4a/8Ag7uP/iaP7d/a5/6E D4a/+Du4/wDiaAPeaK8G/t39rn/oQPhr/wCDu4/+Jo/t39rn/oQPhr/4O7j/AOJoA95orwb+3f2u f+hA+Gv0/tq4/wDiaP7d/a5/6ED4a/8Ag7uP/iaAPeaK8G/t39rn/oQPhr/4O7j/AOJo/t39rn/o QPhr/wCDu4/+JoA95orwb+3f2uf+hB+Go/7jVx/8TR/bv7XH/QgfDX/wd3H/AMTQB7zRXg39u/tc f9CB8Nf/AAd3H/xNH9u/tc9vAPw1H/cauP8A4mgD3nIorwb+3v2uv+hA+G3/AIO7j/4mj+3f2uf+ hA+G3/g7uP8A4mgD3mjIrwb+3v2ue3gH4aj/ALjdx/8AE0f29+11/wBCB8Nv/B3cf/E0Ae80V4N/ bv7XP/QgfDX/AMHdx/8AE0HXf2uf+hA+G3/g6uP/AImgD3mivBv7d/a5/wChA+Gv/g7uP/iaP7d/ a5/6ED4a/wDg7uP/AImgD3mivBv7d/a5/wChA+Gv/g7uP/iaP7d/a57eAfhqP+41cf8AxNAHvNFe Df27+1z/ANCD8Nv/AAd3H/xNH9u/tcf9CD8Nf/B3cf8AxNAHvJNGa8G/t39rrt4B+G30/tq4/wDi aP7e/a5P/MgfDb/wd3H/AMTQB7zRXg39u/tc/wDQgfDX/wAHdx/8TR/bv7XP/Qg/DX6f21cc/wDj tAHvNFeDf27+1z/0IHw2/wDB3cf/ABNL/bv7XP8A0IPw2/8AB1cf/E0Ae8UV4Mdd/a5/6ED4bf8A g6uP/iaP7d/a5/6EH4aj/uN3H/xNAHvNFeDf27+1z/0IHw1/8Hdx/wDE0f27+1z/ANCB8Nf/AAd3 H/xNAHvNFeDf27+1z/0IHw1/8Hdx/wDE0f27+1z/ANCB8Nf/AAd3H/xNAHvNGa8G/t39rn/oQPht /wCDu4/+Jo/t39rr/oQvhsP+41cf/E0Ae80V4N/bv7XP/QgfDX/wd3H/AMTR/bv7XP8A0IHw1/8A B3cf/E0Ae80V4N/bv7XP/QgfDX/wd3H/AMTR/bv7XP8A0IHw1/8AB1cf/E0Ae80V4N/bv7XP/Qg/ Db/wd3H/AMTXVfB/Uvjxd+KpI/iT4X8IaZo/2ZjHLpGoyzTebkYBVgBjGeaAPT6KKKAK+q/8gy5/ 64v/ACNfBnwj/wCQi3/XZ/8A0I1956r/AMgy5/64v/I18GfCP/kIt/12f/0I0AfVfwx/49oq9Ltf 9QPpXmnwx/49oq9Ltf8AUD6UAS0UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAR3f8AqG+leZfFD/j1kr027/1DfSvMvih/x6yU AVP2Uf8Aj08Sf9hCP/0WK9cFeR/so/8AHp4k/wCwhH/6LFeuCgAooooAP89aP89aKKAD/PWj/PWi igA/z1o/z1oooAP89aOfWiigApMUtFAB/nrR/nrRRQAf560UUUAFH+etFFAB/nrR/nrRRQAf560f 560UUAH+etH+etFFAB/nrR/nrRRQAf560f560UUAH+etH+etFFAB/nrR/nrRRQAUUUUAHNFFFAB/ nrR/nrRRQAc+tH+etFFAB/nrR/nrRRQAUUUUAH+etH+etFFAB/nrRz60UUAH+etH+etFFAB/nrR/ nrRRQAf560f560UUAH+etHPrRRQAf560f560UUAH+etH+etFFAB/nrR/nrRRQAf560f560UUAH+e tH+etFFAB/nrRRRQAUUUUAV9V/5Blz/1xf8Aka+DPhH/AMhFv+uz/wDoRr7z1X/kGXP/AFxf+Rr4 M+Ef/IRb/rs//oRoA+q/hj/x7RV6Xa/6gfSvNPhj/wAe0Vel2v8AqB9KAJaKKKACiiigAooooAKK KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAI7v8A 1DfSvMvih/x6yV6bd/6hvpXmXxQ/49ZKAKn7KP8Ax6eJP+whH/6LFeuCvI/2Uf8Aj08Sf9hCP/0W K9cFABRRXi/7aXxxvfgZ4O0TW7PQIdYfV9WWwMUs5iEYKk7gQDnpQB7RRUNrMZbSKYjHmRhyPTIq vqur6ZpgQ6lqdlZiQ4Q3M6x7/puIzQBeoqOOaORBJHIroy7lZWyCPUH0qpYa1pF9cyW1jq1jdTQ/ 62OG5R2T6gHIoAv0Vn6prej6ZKkepavY2byDKJcXKRs30DEZrjP2jvi/4b+Dfwzm8Z+IFmu4PMSG 2trQqZLiR/uhcnp6t2oA9DoryvxV8SfGEfifwHD4V8GW2s6J4oZDq2o/2nGh0tG25wucyEBj09K9 G1PV9K0woNS1Ozs/NOI/tM6x7z7biM0AXqKry3trDafaZrqGODaG815AEwehz0qEaxpRv4rEapZG 6mQSRwfaE8yRTyGVc5I96AL1FZ/ii9u7Hw1qF9p9st1d2trLLBAzbRK6oSEJ7ZIAr59+GP7VEXiX 9kbxT8Y9S8Pw2N74Xmmt5tJW5LB5F2bF3kZG4uB07GgD6S5or5s/ZY/aph+K3wg8beMtV8PwaNc+ DImnms0ui4lj8pnVskAjJRlrnPBP7X/iPWrL4X3V18P7O1T4ka3cafHi+cm3jiljj8wfLzku3/fN AH1tRVLTtV0zUHlSw1K0ujA22UQTrIYz6NgnB+tFzrGlW1+ljc6nZw3UuPLt5LhFkfPTCk5NAF2i q11fWls8aXN3BA0zbYhLIFLn0APWoRrWknTn1BdVsTZxsVe4FynlIR1BbOAaAL9FV9PvrS/tVubG 6guoH+7LBIHRvoRxXL/HP4j+HfhV8M9S8b+KJXSw09BiOMZknkY4SNAerE/1NAHYUV8a3v7W3xt0 vw5H8RNZ/Z5uLb4fSlZBei8P2lIGIAkYdgcjkqB719U/D7xjofjD4fab400i7B0nVLRbqGab93tV h0bPQg5B+lAHQ0VS0zVNN1SNpNM1K0vI0OGe2mWQKfQlSa+c9P8A2pdTufCfxj1g+ELVW+F1x5UE f2tv9P8AnZcscfL93PHrQB9M0VxHwJ8er49+CHh74gahbwaWNa05LyWEzZjgyTxvOOOOprrNM1Kw 1G2+0affW13DnHmW8yyL+YJFAFuiqH9taR/av9mf2rY/bc4+y/aU83P+5nNeefEX45eFvCPxx8L/ AAruo5Z9Y8S7n81XVILKJVY7pGJ6nbgL7igD1KiqOpatpmmxo+o6lZ2aSHCNczrGH+m4jNWfPjMP miRPLK7g4YbSOuc9MYoAlorxD9rH4/J8JdD8MaloWnWHiNNf15NKlKXoC2xZc5yucn2Ne2xElAxx yAaAHUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQBX1X/kGXP/XF/wCRr4M+Ef8AyEW/67P/AOhGvvPVf+QZc/8AXF/5 Gvgz4R/8hFv+uz/+hGgD6r+GP/HtFXpdr/qB9K80+GP/AB7RV6Xa/wCoH0oAlooooAKKKKACiiig AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAju /wDUN9K8y+KH/HrJXpt3/qG+leZfFD/j1koAqfso/wDHp4k/7CEf/osV64K8j/ZR/wCPTxJ/2EI/ /RYr1wUAFfH/APwWI/5JH4MPYeKY/p9xq+wK86/aM+DXg341eGbLQfGv9o/ZNPu/tUP2G58l9+0r ycHIwaAO10q8sjp1qn2yAsYkAAlXJ4HvXxP8EPAnhv8AaO/aY+Lt38ZvtWo3HhvUm07SdGkvHiTT 7YPIgkRQRyAi8+pJOc163oH7Ffwf0fXbHVrS/wDGRn0+5juIRJrrMm9GDLkbeRkDit34y/su/Df4 heNp/GDza74e1u+Ty9QvNB1A2pvkwBiUDhsgAZ745zQB8a6X8R/G/hT9j/4xeEfD3iK/vdG8O+J7 fStK1UylpILSaV1kRZOoBCL0PG8461774M+A3wO8Caj8LPGml+Pbjwdr1zDBJFImog/8JJK6ozI4 cnOSxGB13Y617n4T+Bfwx8O/Bi5+Fmn+GYW8N3yMt7BMxeS6Y4zJJJ1L8DB7YGMVxXwt/ZE+Fngn xzpvieOfxBrU2htnRrXWNRM9vppzkGNMDocY7d6APnH9oew8E/Eb4tfFPUfDXw98SfEDUtHgkg1H WNW1pLTTfDbojc265DNgxnA77TxzXGeP9Mt/En/BK/wh4v117m81jQtfksLC5lnYmOCSc7kIzhuF GM9O1fYXin9kT4Ta98StV8XXP9u2667I0ur6TZ6m8NjfyEklpEXkjJztzjNan/DMXwyH7Pt18G8a u3hqa9N7EJL3dPbTFtwMb7eAD2IPU0AfPHxY8I6H4C+N37L/AIa8MW8tpph1BbowtOz5lmlhdyST k5Yn2qT9n/wB4X/aP+Pnxd1X4zNd6ld6Dqr6dpulSXrxJp1uGdRIigjGAgwemcnvX0BoH7MXgDTv +EJmn1PxLqV14AvHu9HuLzUvMfe7q5WTK/MoKDAGMDiovjB+yv8ADPx/43uvFxn13w7rGors1G40 HUDbfb1IwRKoBBJHU9++aAPj3SPEWu3H7B/xp8HTavd6poXhDxFBa6FfzSlm8o3OPLDdxhVb23eh FaH7QXwu8P8Aw8/Z4+DHxQ0C51NfGF9e6e13rEt7I8kyyRLIFOWwFXAVQMccV9ly/s6/DD/hQU3w ds9LuLHwzcssk4trjbcTSKwbzHlIJZiVGc1Y+I/wF8B+N/hr4a8C63/an9k+FJIH04QXe2TMKbE3 tg7uOvAoA9JsmaSzhd+WeNSxx1JAr8pfizJqXhXxz8SP2bdOglz4s8e2c1qVBAERdmUfQiSM/wDA a/V2CMRwpGv3UUKD7DivKfFP7O3w18QftAWfxj1G0v28S2LQvFsudtu7xrtRmjxyQMd+woA+HP2u 3X9n/wCLvxJ8FaTaNFpvxC8IWUFoIlwquCiuQPrHKP8AgVdX+0R8PIrC0/Zc+HV3NcWazRiC7ktp DHKhleBpCrDlWy55FfXXx+/Z5+G/xl8T6Nr/AI0tb+S90JSlsbS58pXUuH2yDB3DI/U+ta3xO+Df g3x7418I+KdeS+W/8FXHn6ULa48uMNlTh1wdwyi+lAHy94e8JaL8Gv8AgplY+Gvh1BPpuk6j4QuL u504XDyRzyrBKwJDEkktGp5759a8O8A6BrvxW+FfjXx5q/w21fxL4outSmKeM38Uw2a6HKmCieVI wIVSefUEAYxX6J6p8H/CF/8AH2x+MNwt/wD8JLp1ibGErcYt/LIYcx45OHbvXnHjb9jT4R+IPFmo avHN4i0m11icXGq6RpmptDZXr7txLx47n0/DFAHzn+1LaeM/FXw1/Zw0bxnqEtt4h1LUm0+8vLa9 SRmzLFEsoljJUsUwcgnnNL+0p8P7PwD8cPh58AvDXhzWvEng6YTazJoJ1dbaTW7t2YMHnbAIURrx 9e5r7C8afAT4deJG8EC4sLqyh+H1wk+g21hP5UURRkYBlwdwyi/Xn1qb9oT4IeBvjJZWC+KYLyC/ 0mQyadqmnXBgurUnrtcdiQDj1FAHgn7B+g+M/Bv7SHi3Q4fCkvhTwVfWf2mPw7c+ILe/k0q5BXoq OWUMGbqOmM1s/wDBX3T9Suv2Z7C/toZJrHTPEFvPqMaDP7ohlBPtuI5969c/Z5+BHgX4Pzaje+Hl 1G+1jWCDqGr6tdG4u7gDkKXPRfp1PWvRPEek6Zruh3WjazYQX2n30RhubaeMOkqHqCDQB5j4k+MP wv8AD37NcHjzUdS07UPDg0uHZaxPHKbrKKBCsZOC2eNp6Yr58/a58bWXxQ1b4GeENNudQ8O/Dnx/ dGa9IX7G8sYdUWFgpwq4Y4HT5ge1eoWv7D/7Ptv4lXVT4e1OWJJvNXTZdTkazU+mzrj2Jr1D4zfB z4f/ABR8BW3hLxToqmw09lbT2tG8mWxZRtBhZfu4HGOmKAPlnxj4S0X9n39vj4Y6P8IXuNOsfGA+ z67oUd00sLRbwnmFWJxkZbJ6FCfWuK0QY+Fv7XY/6iH/ALXkr6z+Bv7NHw7+GPjJ/GFpLrOveImi MMWqa7fG6mt4+m2PPC8cZ64qa2/Zv+HFtofj7Soxq/2f4jyiXXN15k7txb90dvycsfWgD46+Lmta 7dfs7/s2/DyKxvdR0HxBYo+oaXaXotG1VldVW3MzfKuQx68fNW/4Is/iJ8Ivir411fwT4An8DaC/ g67nn8NT+I4L57a6jhLR3KRK5frgjjucnFfVfjD9nT4ZeJfgtofww1WwvZNJ8NIq6RdLclbyzZej LKB19eMHFQfA39nD4efDLWNR120/tTX9b1S3Nrdanr12bqdoCMGIE9FIAB9QMUAfMXwO+CPwf8T/ ALIug/Fvxv47vfDXia91Jru98YHUyJ4p/OZRDljtGQAeRnPNH7Rvww8CeJv+Ch3w40y9jl1bT/GW krc6rci6ZTqDLG4WUFSNuQiH5cDrXuK/sUfBkeIxd/8AFQNoou/tn/CNnU2Om+bnOfK9O2M9OK6z 4+/s4+A/ixr2ia5q1xq+jajoEP2eyutFu/szrD18vgcAdsYIBoA+TfHtrqPxM/bb+IOgeIfhlqnx F07wnapYaTokGuJp6abCFVRPiRhvY5zkd2yeMVl+Jtb+Kvgv/gn3rnhzV9RmtLGTxdDp9lcxatFe S22nyAs0DSxM2MMoBBx1OOK+uvjJ+y/8PPiH4og8TXN74g0bXo7RbObVNH1Free8iVQoExx8xIGC eM1taH+z18K9L+Blz8JYPDiv4bvctdLLIWnnlOD57SdfMBAwe2BQB8bftp/Bf4bfCvwn8Ib/AMBy TQTaprFqt2n21pE1ABUf7SUJI3ZONwA4YCv0bg/1S/7or5w079if4PRWWnRX954p1KfSbtJ7C5u9 XZmt0Q5WBARtWPPOABk969x+I3iObwj4IvNeg0HVNdkslXbp+mRCS5nyQPlUkZPOfwoA6GivBj+0 jq3b4A/FT/wUJ/8AF0n/AA0jq/8A0QD4qf8AgpT/AOLoA96orwX/AIaR1f8A6IB8VP8AwUJ/8XTv +GkdW/6ID8U//BQn/wAXQB7xRXgv/DSOr9/gB8Ux/wBwhP8A4ulH7SOr5/5IB8VP/BQn/wAXQB7z RXgx/aR1bH/JAfin/wCChP8A4uk/4aR1f/ogHxU/8FKf/F0Ae9UV4MP2kdW/6ID8U/8AwUJ/8XQ3 7SOrdvgD8U//AAUJ/wDF0Ae80V4N/wANI6t/0QH4p/8AgoT/AOLpD+0jq3/RAPip/wCChP8A4ugD 3qivBf8AhpHV/wDogHxU/wDBSn/xdOP7SOrY/wCSA/FP/wAFCf8AxdAHvFFeC/8ADSOr/wDRAPip /wCClP8A4ulH7SOrZ/5ID8U//BQn/wAXQB7zRXgx/aR1bH/JAfin/wCChP8A4uk/4aR1f/ogHxU/ 8FKf/F0Ae9UV4L/w0jq//RAPip/4KU/+Lo/4aR1f/ogHxU/8FCf/ABdAHvVFeDD9pHVsf8kB+Kf/ AIKE/wDi6D+0jq3f4A/FMf8AcIT/AOLoA95orwY/tI6tn/kgPxT/APBQn/xdH/DSOq/9EB+Kf/go X/4ugD3mivBf+GkdX/6IB8VP/BSn/wAXR/w0jq3b4A/FT/wUJ/8AF0Ae9UV4L/w0jq//AEQD4qf+ ChP/AIulH7SOrY/5ID8U/wDwUJ/8XQB7zRXgx/aR1bP/ACQH4p/+ChP/AIuk/wCGkdX/AOiAfFT/ AMFKf/F0Ae9UV4OP2kdWx/yQH4p/+ChP/i6b/wANI6v/ANEA+Kn/AIKU/wDi6APeqK8F/wCGkdW7 /AH4pj/uEp/8XXWfB74uX3jnxVJo9z8L/G3hpI7Zpvtmt2KwwNggbAQx+Y5z+FAHp1FFFAFfVf8A kGXP/XF/5Gvgz4R/8hFv+uz/APoRr7z1X/kGXP8A1xf+Rr4M+Ef/ACEW/wCuz/8AoRoA+q/hj/x7 RV6Xa/6gfSvNPhj/AMe0Vel2v+oH0oAlooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAju/9Q30rzL4of8AHrJXpt3/AKhvpXmX xQ/49ZKAKn7KP/Hp4k/7CEf/AKLFeuCvI/2Uf+PTxJ/2EI//AEWK9cFABRRRQAUUUUAFFFFABRRR QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAV9V/5Blz/ANcX/ka+DPhH/wAhFv8Ars//AKEa+89V/wCQZc/9cX/ka+DPhH/y EW/67P8A+hGgD6r+GP8Ax7RV6Xa/6gfSvNPhj/x7RV6Xa/6gfSgCWiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigCO7/wBQ30rz L4njNrLXpt3/AKhvpXmXxN/49pfpQBU/ZR/49PEf/X+n/osV64K8j/ZQ/wCPLxH/ANf6f+ixXrgo AKKK8p/aI+Pvg/4N6lptl4n0zX7t9UieWFtM083CqEIB3EHg89KAPVqK+ZPD37c3wi1zUILTTNH8 YXDz3CW4aPRyyq7EAAkNx1r6YRwcHnkZxQA+ik3DOKNwzjkUALRSFgBnBP0FAbigBaKTPHFc38W/ HPh/4cfDzU/Gnie4kg0vSofMnaNN7tkhVVV7kkgCgDpaM15r+zj8YtK+Mnhy71vR/DfiDSLS1kRY 21e08kXSuCVeLkhlx3FVv2jfj78PPgpZ2n/CX31xJqGo5NlpljF5tzOAcbgvZc8ZJHPSgD1IEGlr wX4HftafC/4leM4vB6Lq3h3Xrn/j0sdbtfINzxnCNkgt6A4J7ZrS+PH7Sngv4XfEWx8CXWjeIfEH iC9txdNY6LYm4eGEkgOwyM9DwM8CgD2jNFeHeLv2nvBWifGaD4Y2vh7xPrWt7YDejTdP81NP80KV 8054wHXcegr28N14/KgB1FNDA9jQXA68ZoAdRSbvY0gYGgB1FJuGcUtABRRRQAUUUUAFFFFABRRR QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAFfVf+QZc/wDXF/5Gvgz4R/8AIRb/AK7P/wChGvvPVf8A kGXP/XF/5Gvgz4R/8hFv+uz/APoRoA+q/hj/AMe0Vel2v+oH0rzT4Y/8e0Vel2v+oH0oAlooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAju/8AUN9K8y+J3/HtLXpt3/qG+leZfE84tZaAKf7KRC2fiLJ66gmP+/Yr10V5H+ylg2ni PIHGoJ/6LFeuCgAqpq8MT2M7vFGxWJtpZAcce9W6iuo/NtpYs48xCoPpkYoA+JP+CZeiX/iH9mr4 oaTpGoSabql1rdzHYX0GFktpjF8jKe2GxXNSftD/ABDl/Yes/DkXiC9HxOm8YHwubsSf6UCH37ye ucEJmvpL9lX4R2/7N3w28U/254rh1Gyub+XV7i7Fo0K20QTnI3MTgDORXzj8APCHhL4t/wDBSfXv iJ4JM154J0SUau9yYmW3m1BkCjYCADlyz+vFAHXftIar8XND/aU+Dfwr8LfEvVNMm1fRVttTvJWE onlBIkmdTw74DY98U7wx40+IHwE/ax1X4aeIvHOreOvDl94XuNcsn1dg1zBLFFJJt3D1MTA44wQc Aiq37dvh6+8Uft8/CPRdN1u80O9uLGT7LqlqgaS0lV3dGweDyvIPUGvT/gx+zfrVl8V9X+Jnxg8b J418Sahpr6XB5Nn9nt7a2ddjAL6lSRxwNx7mgD5M0343fELxF4FuvidbfFzxxH47a/aWw8L2OhzT aO0CvjydyqUOVyc54xg8nNfop8GPE9x4y+Efh/xXfWMljc6rpsVzcWrxsjQyFfnXaeRzng184aX+ yh8UvDukXPgLwb8d7vRvh5c35u1sY7HF/bqW3NHHODxz+B7jrX1V4Z01NH8PWWlR3FxcJZW6QrNc yF5ZdoA3Ox6scZJoA+NfhhJ8Vf2o/G3j3X7P4ta34G0Lwvqkmm6FpujEJmRc7ZJjwWGACR15OMYr zT4keP8Ax38W/wBhDxhH4t8UXKar8N9eWw1J7dFEWvxtIqp53ujAnI64FfQnib9mPx54d8feI9d+ BvxYPg6y8YStNrGm3VgLlEkbO6SE5+U8tjuM9a0G/ZO0bT/2StZ+DmgeIpYb7xBOl3qevXdv5r3F wHVixjDDjC4Az+NAHV/sJeGdX8O/s3+HTq3i7UPEA1Kwt7u2F4oH2CJolxbx4/gXtXifhKysPEn/ AAV18Tr4tt4rmbRtDV9CguPnVMRx/OinjIDufYkmvq/4TeG28G/DLQfCb3a3baLp0NmbgJsEvloF 3becZx0ryP8Aaj/Zrg+JvjXTviJ4P8WXfgzx1pCCODV7VNyzKM7RIoIORkjIPQ4ORQB5n/wVvsdK 03w/4A8WWEEUHim18TRR2E0QCzSIBuK5HJAZUPsT71w2ueA/Furf8FR4NKX4ma5p2pX+gDVBqMEa +daxFWY2SDOPLGCvrg1674C/ZT8U6r8U9L8d/Hj4o3Hju50Bw+l6etv5VrGwOQzA9eQDgAZIGSa9 Bn+CVxL+2dB8dv8AhIIxFDoZ0saT9lO4naw3+Zux/F0xQB8pfCPwz4j8Nft4fFPUn+IuuSyeC9Pb WNQmVVEmuRIEk+zTc4CHIHHpXKWXxw+IfibwTe/E2D4t+N7fxy1+0um+FtP0SabRjbq/+pLKpQkr nnPHQ8nI+zvBHwDXRf2lvHvxQ1HXYb+w8caf9ik0k2pUwoQgbdJuIYELjoOtebab+yh8UPDml3fg PwR8drvRfh5eX/2v7Alj/p1spfc0ccwPAJ+gOORQBy/x3+KnxV8T/Er4CW3hHxLfeD7jx3p4bUbQ xny45mcK7PE2M7fmwD7Vp/CbWPil8OP25te+DsvxB1fxrp934Xl1Sy/ttw0iXPl70AxwvzZBxgYI 9K9Z+In7PsniL4z/AAv8bW3iuWKD4coEa3vIjPPqGCDuaXcMMcckg1LrfwFl1L9re5+M0nicw213 4efRn06GApMu5NnmLMG4PccUAfGGmfFfx7Za1Mfid8ZPiN8PvH0WrEtHqOntLoQh3fc8lBuHHflc fnXtf7bHxt1uL4geAfhxpXjm/wBC0XXNKj1TW/Efhyzee5uY2B2/Z1TLbG2k8f3hngVs+J/2U/i1 rfhe4+Heo/HKPVPBFxdeb/xNNGW51WOPcGMa3DEkcjqCB7dq7P4w/sxpq9l4H1T4beLLjwl4o+H1 kljpGoyQ+eksCjGyZe/8Rz0+YjFAHFfsFfE7xXffGfxH8OL/AF/xL4t8KxWgvdA8Qa7pcttcjBUP FIzqM/e/NeK+vK8d/Zu+FHjbwV4g1nxX8RPibf8Ai/XdawrxKphsLRB/zyhzgHgDPHA6V0nxO+NX wv8Ah3rkWj+NvGNho19PCJ44LgNuaMkjdwD3BoA76ivHf+Gqv2ff+ioaP+Un/wATR/w1V+z7/wBF Q0f8pP8A4mgD2KivHf8Ahqn9n3/op+j/AJSf/E0v/DVP7Pv/AEVDR/yk/wDiaAPYaK8dP7VP7Pv/ AEVDR/yk/wDiaB+1V+z6f+aoaP8AlJ/8TQB7FRXjv/DVP7P2cf8AC0NH/KT/AOJo/wCGqf2ff+io aP8AlJ/8TQB7FRXjv/DVP7Pvb4oaP+Un/wATR/w1T+z7nH/C0NH/ACk/+JoA9iorx3/hqn9n3/oq Gj/lJ/8AE0f8NVfs+/8ARUNH/KT/AOJoA9iorx0ftVfs+/8ART9H/KT/AOJoP7VP7Pv/AEVDR/yk /wDiaAPYqK8d/wCGqf2ff+ioaP8AlJ/8TR/w1T+z7/0VDR/yk/8AiaAPYqK8d/4aq/Z9/wCioaP+ Un/xNH/DVP7Pv/RUNH/KT/4mgD2KivHf+Gqf2fT0+KGj/lJ/8TR/w1V+z7/0VDR/yk/+JoA9iorx 3/hqn9n3/oqGj/8AkT/4ml/4ap/Z9/6Kho/5Sf8AxNAHsNFeO/8ADVX7Pucf8LP0f8pP/iaP+Gqv 2ff+ioaP+Un/AMTQB7FRXjv/AA1V+z7/ANFQ0f8A8if/ABNH/DVX7Pv/AEVDR/yk/wDiaAPYqK8d /wCGqv2ff+ioaP8AlJ/8TR/w1V+z7/0VDR/yk/8AiaAPYqK8d/4aq/Z9/wCioaP+Un/xNH/DVX7P v/RT9H/KT/4mgD2KivHv+Gqf2fe/xQ0f8pP/AImk/wCGqf2ff+ioaP8A+RP/AImgD2KivHf+Gqf2 fSf+SoaP+Un/AMTQf2qv2fR/zVDRz9BJ/wDE0AexUV47/wANU/s+/wDRUNH/APIn/wATR/w1T+z9 /wBFQ0f8pP8A4mgD2KivHf8Ahqn9n3/oqGj/AJSf/E0f8NU/s+/9FQ0f8pP/AImgD2KivHf+Gqv2 ff8AoqGj/lJ/8TR/w1V+z7/0VDR/yk/+JoA9iorx3/hqn9n3/oqGj/lJ/wDE0f8ADVP7Pv8A0U/R /wApP/iaAPYqK8d/4aq/Z9/6Kho/5Sf/ABNH/DVP7Po6/FDR/wApP/iaAPYqK8dH7VP7Pp/5qho/ 5Sf/ABNdF8Mfjd8LPiH4hfQvBfjKw1jUI4DO8EAfIQEAtyB3IoA9AooooAr6r/yDLn/ri/8AI18G fCP/AJCLf9dn/wDQjX3nqv8AyDLn/ri/8jXwZ8I/+Qi3/XZ//QjQB9V/DH/j2ir0u1/1A+leafDH /j2ir0u1/wBQPpQBLRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQBHd/wCob6V5l8UP+PWSvTbv/UN9K8y+KH/HrJQBU/ZR/wCP TxJ/2EI//RYr1wV5H+yj/wAeniT/ALCEf/osV64KACjFFFADLiGKeB4Zo0kjkUq6Ou5WBGCCD1FV dD0fStGtTbaPpllp8BO4xWlukSE+uFAGau0UAVbjTrCe/ivZrG2kuYQRFO8KmSMH+6xGR+FWcDOa WigBMD0pcUUUAGKTHGKWigBMCjApaKAEwKXAoooAMUmB6UtFACFRmjaM5paKAEwKMD0paKAEwKoa joei6jOJdQ0iwu5FXar3FskjAemWB4rQooAyP+EU8Lf9C1o//gBF/wDE0f8ACKeFv+ha0j/wAi/+ JrXooAyP+EU8Lf8AQtaR/wCAEX/xNH/CKeFv+ha0f/wAi/8Aia16KAMj/hFPC3/QtaR/4ARf/E0f 8Ip4W/6FrR//AAAi/wDia16KAMj/AIRTwv8A9C3pH/gBF/8AE0f8Ip4W/wCha0j/AMAIv/ia16KA Mj/hFPC//Qt6R/4ARf8AxNH/AAinhf8A6FvSP/ACL/4mteigDI/4RTwt/wBC1pH/AIARf/E0f8Ip 4W/6FrSP/ACL/wCJrXooAyP+EU8Lf9C1pH/gBF/8TR/winhf/oW9I/8AACL/AOJrXooAyP8AhFPC 3/QtaR/4ARf/ABNH/CKeFv8AoWtH/wDACL/4mteigDI/4RTwv/0Lekf+AEX/AMTR/wAIp4W/6FrS P/ACL/4mteigDI/4RTwv/wBC3pH/AIAxf/E0f8Ip4W/6FvSP/ACL/wCJrXooAyP+EU8Lf9C1o/8A 4ARf/E0f8Ip4W/6FrR//AAAi/wDia16KAMj/AIRTwt/0Lekf+AEX/wATR/winhf/AKFvSP8AwAi/ +JrXooAyP+EU8Lf9C1pH/gBF/wDE0f8ACKeF/wDoW9I/8AIv/ia16KAMj/hFPC3/AELWj/8AgBF/ 8TR/winhb/oWtI/8AIv/AImteigDI/4RTwt/0LWkf+AEX/xNH/CKeFv+ha0j/wAAIv8A4mteigDI /wCEU8Lf9C1pH/gBF/8AE0f8Ip4W/wCha0f/AMAIv/ia16KAMj/hFPC//Qt6R/4ARf8AxNH/AAin hf8A6FvSP/ACL/4mteigDI/4RTwt/wBC1pH/AIARf/E0f8Ip4X/6FvSP/AGL/wCJrXooAyP+EU8L /wDQt6R/4ARf/E0f8Ip4W/6FrSP/AAAi/wDia16KAMj/AIRTwt/0LWkf+AEX/wATR/winhf/AKFv SP8AwAi/+JrXooAyP+EU8L/9C3pH/gBF/wDE0f8ACKeFv+ha0j/wAi/+JrXooAyP+EU8Lf8AQtaR /wCAEX/xNH/CKeF/+hb0j/wAi/8Aia16KAMj/hFPC3/QtaR/4ARf/E1Ppmh6Lp1yZ9P0iwtJSu0y W9qkbEemQAcVoUUAFFFFAFfVf+QZc/8AXF/5Gvgz4R/8hFv+uz/+hGvvPVf+QZc/9cX/AJGvgz4R /wDIRb/rs/8A6EaAPqv4Y/8AHtFXpdr/AKgfSvNPhj/x7RV6Xa/6gfSgCWiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigCO7/1D fSvMvih/x6yV6bd/6hvpXmXxQ/49ZKAKn7KP/Hp4k/7CEf8A6LFeuCvI/wBlH/j08Sf9hCP/ANFi vXBQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFAIPQ1GZ4RP5Jmj808hNw3flQBJRRRQAU UmaCQKAFoopMigBaKCeKQnHWgBaKTPGaNwoAWijNFABRSZ5xTI54XkaNJo2dfvKGBI+ooAkopAec UtABRRRQAUUZHrSOyqhZmCqOSScAUALRTYpI5E3xyK6/3lORS5GcUALRSEgUA5oAWik3DOKZJPDH Isbyort91WYAn6CgCSikJpaACiikLAdaAFopssscSb5ZFRfVjgUI6ugdCGU9CDkGgB1FIGFLQAUU hIHWgEHpQAtFJkUZHrQAtFICCMg5paACiiigAooooAKKKKACiiigAooooAKKKKACiiigCvqv/IMu f+uL/wAjXwZ8I/8AkIt/12f/ANCNfeeq/wDIMuf+uL/yNfBnwj/5CLf9dn/9CNAH1X8Mf+PaKvS7 X/UD6V5p8Mf+PaKvS7X/AFA+lAEtFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAEd3/AKhvpXmXxQ/49ZK9Nu/9Q30rzL4of8es lAFT9lH/AI9PEn/YQj/9FivXBXkf7KP/AB6eJP8AsIR/+ixXrgoAKKKKACiiigAooooAKKKKACii igAooooAKRulLQaAPiH/AIKP/tFeNtM+I1j8DvhJdTW2t3oiTUby0P8ApHmS48u3ib+EkEFm6jI6 c1xc37CHxmbwqfETfFZX8VeX9o+xG4n5kxnZ9o3Z3ds4xnvXMaSwP/BY2Q6wBn/hLZBFv558o+X/ AOy4r9Nm2nj/APXQB8ef8Exfi78VfEV5q/w3+KGmazdvo0btY63eW0nVGCPbyykYYjqpznANeWfF fxD4hi/4K56To8Ou6mmnv4g09Ws1u5BCVMaZGzOMHntX6B6Brfh7VXnh0XVtNvGtpmjuI7S4RzFI DhgwU5BB65r8wv2x7PxbqH/BTK6sfAl2tr4luNRsk0mcyBBHOYk2nccgc96AP0+8ZFl8H6uykqVs ZyCp5B8tufavgn/gjN4h1/Wvil43i1jXNS1GOLSYTGt3dvKFPnEZAYnH4VY1j4b/APBQSPR7uS+8 fxNapBIZ1OrwncgU7hjZ6ZrF/wCCJBP/AAtfx1nqdHgz/wB/jQB9Uf8ABRP4mP8ADL9l3XL6zumg 1bWQNL05kbDrJJnc4/3UDH8q+D/2Ffix4x+HX7THhaXxlq2sPo3imEWrrqF1I6NDMxWOZQxIwJFH P1ruP+Ct/j+Lxf8AtDaF8MY9UjtNL8PLH9undv3cNxORudsf3I9v5msz/govqfwW1rwL4BvvhT43 0rUdS8JWqaO9taFhIbdVBjkGQM7XB/76oA/TfUSf7MnIJB8p+QfY81+en/BJHxDr+r/tM+MLfVdc 1K/hi0uVkjurt5FU/aFGQGJAr67/AGR/iRF8VP2YND8WGYSXp09rTUR3S5iXY+frgN9GFfGX/BHf /k6Dxp/2CZf/AEpWgDyrx98ZPHHw3/bW8Q+JNN1/Up4dH8U3LfYJr2RoJYfNYNEUJxgrke3Ffob8 c/HWneM/2FPE/jzwjqEgttR8MS3VpPE5WSBtvK5HIZTkH3FfC3gP4a6X8XP28/iV4E1T5P7QbWGt LjvbXCOWjk/Buvsai+CXxL1j4YfDP4tfs7eP2az+0aZeLpyTn5be9VcNEP8AZlXBHuPegD6Z/wCC NesavrXwS8T3Gsare6hKmuhEe7uGlZV8lDgFiSBmvsIfSvjD/gif/wAkL8Vf9h8f+iEr7G1gyf2V deR/rfIfZ/vbTigD88P2qPjj8U/jv+0bJ8D/AIMalcWGlQXb2TS2cxha9dP9bLLKOViXB4HXHOcg VN4j/YV+M3hnw23iPwp8V2v/ABFaRmc2lvNPA8rDnbHLu5b0yBmsH/gkYYT+134obU8HUTpV0U3f eLeevmY96/S8EZ60AfHH/BM39pTxN8QNWvvhZ8SJ2ufEelwNLZX0y7ZrlEO2SKUd5E656kZzXh/7 ecvi/Xv+ChUvgXQ/F+p6RHq76daw+VeypDC0kSDcUUjuc8Un7P5jX/grlqH9gHFofEWphth42bJN /wCG6sz9v1PEsn/BSR08GyBPEDS6aNLYlRtn8lNh+bjrjrQB6kf2FPjVkgfH1yPea7/+Kr6//Zp8 E6z8Ovgxo3g7xBrn9t6jpsbrPqG5z55LswPzndwCBz6V8fyaT/wUb5H9rJ16rNYf/E192+GBfr4d sBqpzfi0iF2eP9bsG/px97PSgCh8T/FWl+BvAGseMNacpYaLZSXU+OrBRnaPcnA/Gvzi8GW/x7/b a+IGq36+LJPDvhPTZcNGksiWloG5SJY0IMsm0ZJb9OlfXX/BT97xf2LfFn2Mtkm2Eu3/AJ5+em78 MVw3/BGz7H/wy9qBi2+efEM/2jHXPlx4z/wGgDwH4ofCv9oD9kfxDo/i3wd41vvEWmXlyIDHarK6 PJjPlTW5LAhgDgj9DX0n+2b431fxH/wTmuvG0drqfhzUtQtrKWa1bfbz2khmUOnZgM5+oIr6R8Sa tomi2kV3rupWNhA86xRy3kyxoZD91QW43HnFeFf8FP3Sf9ifxNNA6yI72jK6NuDDz05BHUUAZH/B JTU9T1f9lEXeqahd31x/bl0vnXM7SvgbMDLEnArxD/gsP4h8Q6L8bvBkOka7qVhFLpTNJHa3bxK5 8/GSFIBNezf8EeuP2RBn/oPXf/sleEf8Fofm+O3gcDBP9kt/6PoA9/8A+Chfxj8SfCT9mPQ5/Ctw 9trXiJobKK/UbmtV8ne7rn+MgYB7ZzXzt8K/2Ovif8VfhbZfEi4+MK/2jrUH2y1ikuJrg88gSShv lbPXAOK+yf2hfhX4T+MP7Ptl4R8VajHpZ+ywXFhfl1VrSdYxhwGIyMEgjuDXxTdfs1/tcfBSeW7+ GPiK81LTkO9H0DUiPNXrk27kZyMcYP40Aem/8E1PH/xm0X4uaj8H/iVZa/faVAs62d/qEErrZXEP 3kE7D5o3AOAT1xjrUXxm/Y9+Llzrnirxna/G2S2snlutRisknugY4/mkEfDY4HHHFX/2Dv2uPGvi z4rR/CT4vWcf9sTl4bPUBa/Z5hPGCTDPGMDJAOCAOetfYHxP/wCSY+Iv+wRdf+imoA/Kz9jj4Z/E /wDaB1fXbDSPitqejNocEUrvdXtxIJQ7MuAFbj7tfW7XfiH9jD9k3XLzxX4qTxf4g1HVcaK0jysp leMABt5LbVCsx/LvXlP/AARAP/FbePx/1D7T/wBGSV1f/Bb1rv8A4QHwKqbvsh1K6L46b/LXbn8N 1AHl3wW+B/x6/aqspviN4x+JF3pmkXczC0kuZJG88g4PkwIQqRqeAeOneofHmn/tB/sUeNNM1WHx dJr/AIV1CfYqPNJJZ3W3lopInJMT7c4ZfzOMV91fsTCyX9kvwB9hC+T/AGFBjb03YO7/AMe3V5X/ AMFe/sH/AAyFJ9q2+edbtPsh77/mz/47uoA6f9ojx/aeN/8Agnn4j+IXhi7ntotU8OC6t3ikKS27 l1DLuHIZWDL+FfFf7IPwN+K3x88E6l4i0n4wX+jppt6LRorq8uZC52Bsgq3HWvYvg0bs/wDBGjxR 9p3bRbXwg3f88/tC9PbO6ui/4Ipf8kK8Un015f8A0StAHi3iTXf2if2NPinpC+J/Fdx4m8M6m5by pLqSe1vY1IEiqJPmikAORj1719Ift7eCNS+L/wCznp3xR+GWsapBqel6eNQt47G6kiN/ZOod4yqk ZdR8w+hHeuU/4LXi0/4Un4RLqv2ga8/leoHkNu/DpXt/7AInk/Y18Ai5DEnSQAG5ym5tv4YxQB5Z /wAEwv2gIvG3wZvvC/jPVgNb8FQGWW6upPmuLAZIlYnqUwVY/wC7614Joes+OP2vv22bkaPrus6V 4L01wZTZ3UkSwafG2BkKQPMlP/oXtXK/8FHvhjJ8Evj9c33g2/k0/SPHNlNKtrbSFDEHYLPAQOsZ bBA9DjtX3V+wF8GNP+D/AMB9PgAim1vX4o9Q1a7X+JnUFI1P91FOB75PegD2zS7WGx02Cytk2QW0 SxRKWJwigADJ5PAHWrFA4GKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigCvqv8AyDLn/ri/ 8jXwZ8I/+Qi3/XZ//QjX3nqv/IMuf+uL/wAjXwZ8I/8AkIt/12f/ANCNAH1X8Mf+PaKvS7X/AFA+ leafDH/j2ir0u1/1A+lAEtFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAEd3/qG+leZfFD/AI9ZK9Nu/wDUN9K8y+KH/HrJQBU/ ZR/49PEn/YQj/wDRYr1wV5H+yj/x6eJP+whH/wCixXrgoAKKKKACiiigAooooAKKKKACiiigAooo oAKRulLQRkUAfDH/AAUf/Z48bSfE60+O/wAJLWe51W1aKXU7SzXNxHLDjZcRr/HwAGA54Bx1rkL3 9vP4vXHg1vDkPwqEPix4vs/29Y5ziTGN622zIf8A2d2M/lX6KbeBzUP2K1+0/aPs8HnZz5nlDd+f WgD40/4JcfADxj4R1bVvi18RYbqy1XWonisNPuWKzbZGDyTzL2ZiAADzjJ4zXm3xX0LXJf8Agrrp WrR6LqL6eniDT2a7WzkMIURpk7wMYHrmv0b2jvzQV+XGTQBl+M8v4Q1ZEDMxsJwABnP7tu1fnp/w SUj1bwJ4i+JPiTX9B1a0trHw4tztlsJVabZIzbUBXLMcdBzzX6PbBgD0oK56k0AfmF+x38E7v9or 9orxf4r+LuiazDpUglvp0lWW1aaeaT92isQDhVzwOwFfS3jD9gr4GSeFNSj0DStVttVa0kFjM+qS OqTbTsJU8EbsV9UbT3OaCM0Afn7/AMEl9b8VeEfEfjD4V+JtE1WztryKS8snns5ViW4iBSVQxGPm XB99tZn/AASO0HXdK/aX8YXGqaJqVlDLpUoSW5tJIkY/aFOAWAGa/RQqT1Y0uD3OaAPzx/Y+0PW7 T/gqN4s1O60bUILGW51fZdS2kixNljjDkY57c810v/BW74A3Gt2tt8X/AAfpctzfwbLTXbW1hLyT x5xHOFAJJX7re2PQ190FSRjdQF56/lQB8ef8EadK1TR/gn4oh1bTL2wlfXgyJd27xMw8lOQGAyPe vsTqOn50bec55pRQB+cP7UXwS+KvwE/aOm+Nfwc0+51DSJ7t70rZwGVrJpCTLBNEOWiYk4I7HsRV vxL+3l8W/Enhd/D3hT4Utp3iK8jMJvYfOuWhY8bootgw3pkkA+tfolj3qCGxtIpjNFawRyHrIkQD H8RQB8b/APBMb9m/xL4H1W9+LPxJtJLbX9ShaPT7Kc7p4EkO6SaX0d+mOuM5615j+09oOvXP/BVj SNVttE1OaxTVNJLXUdnI0QASPJ3gYwOc89q/Rzb6Gl24AAOAKAE6mnCkAwaWgDnfit4Q0vx78Oda 8G60m6x1qye2lI6puHDD3U4P4V+cfgPU/jt+xH8Q9X0q68IyeIPC2pyhi6JIbW728JNHKoPlvtOC rD2xxX6ekZpk0CSwmKVVkRuquoIP4GgD8wvjH8Qfjf8AtmeI9I8G+HPAU+j6DZ3Il2AOYY3I2+dc TsoGFUnCgdz1NfanjD4DwXX7FU/wP0u/3zR6Mtvb3k5JEl0pEm9s8gM4P0Br2iC2hgi8uCNIk/ux oFH6VJj3oA/Lz9nD43fFb9k5dV+H3i34ZX19YPdtOsMoeFoZSApaOQKyujbQaS+tvit+2d+0xo2u y+DZtC0LSzFDJO8T+RZ2yyb2zIwG+RueAO47V+n11aW9yoW5gimC9BJGGx+dPghjhjEcSJGi9FRQ APwFAHy//wAFNfgf4i+KPwo0vU/A6TXOteF2YrYxSlWvLZlAdVHQuCoIHfkV4J8Nf23/AIqfD7wH a+C/FXwrm1TV9HgW0gurgzW0jBBtUSx7DkgAcgjNfo7tPrUM9jaTyiWe2glcdGeJSR+JFAH52/sL /DH4n/FP9rd/j7470O40ewgvJdQaWW3a3F1cMpVI4UbkqoIyfQDkk19+fExXk+G/iCONGd20m5Cq oyWJibAAHet3b78elBX0oA/Pz/gi1oet6P408dvq+jahp6y6faCNru1eIORJJkAsBmvqX9tn4MQf HD4IXfhaKaK21e1kF5pFxJ91LhQQFY9lYEqT7g9q9ewcdaQrQB+ZHwQ+O/xz/ZXs5fhz41+G97qm k2szm0huhJGbckknyZlVleMnnHv15qt8Q9Z+Pv7a3jrS9GsfB02heGbCbegMci2lqW4aaWZgPMfH AAHsBzX6eXNtBcIEuIY5VHIWRAwB/GnwxJFGI4lVEXoqrgD8BQB8/wD7Q3w+s/Af/BPDxH8PfDNr PdRaX4d+ywrFEWluJN6ln2jJJZizfjXxb+x18eviP8AfBOp+HbD4OalrialfC8aeeO4hMZ2BduBE cjj1r9VCPzoAOOtAH5k+MrD9oP8AbQ+JeiRav4Mn8L+GNLcgu8EkVvaoxHmSbpADJIQMDAr9IfAn h/T/AAp4N0zw1pUfl2Ok2kdpbr6IihQT7nGa1dvPJ49KAMUAfn3/AMFntD1zV/iD4Fk0nRtRv1i0 +48xrS0klCHzVwCVBwfavuv4cK0fw80GORSjrpVsGVhgqfKXIIrZwfWgKBQAtFFFABRRRQAUUUUA FFFFABRRRQAUUUUAFFFFABRRRQBX1X/kGXP/AFxf+Rr4M+Ef/IRb/rs//oRr7z1X/kGXP/XF/wCR r4M+Ef8AyEW/67P/AOhGgD6r+GP/AB7RV6Xa/wCoH0rzT4Y/8e0Vel2v+oH0oAlooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA ju/9Q30rzL4of8eslem3f+ob6V5l8UP+PWSgCp+yj/x6eJP+whH/AOixXrgryP8AZR/49PEn/YQj /wDRYr1wUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBX1X/kGXP/XF/wCRr4M+Ef8AyEW/67P/ AOhGvvPVf+QZc/8AXF/5Gvgz4R/8hFv+uz/+hGgD6r+GP/HtFXpdr/qB9K80+GP/AB7RV6Xa/wCo H0oAlooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAju/wDUN9K8y+KH/HrJXpt3/qG+leZfFD/j1koAqfso/wDHp4k/7CEf/osV 64K8j/ZR/wCPTxJ/2EI//RYr1wUAFFFfOf7UX7R3iv4bfHDQ/hn4R+HQ8Wanrtj9pto1vvJdm3MN gBGOAhPWgD6Mor5c8MftV+L9J+K3h/wX8Yvg9f8AggeKJxb6dfNerNGZCQAGAHTcQDg5GRxX0vqO pWGnhP7Qv7W1Eh2oZ5lj3n0GTzQBcopgcGLeGBUjO7PGPWq2manp2oPIthqFpdGI4kEE6yFD74PF AFyiivEv22Pjve/AnwroGq2Hhhdfm1zUzYpA1yYdrbNwIODnJ4oA9tor5v8AA/xq/aI1bxdpWnaz +zZe6Xpt5dxxXV+2qowtYmYBpCO+Bk19Bz6pp0G/ztRtE8pgjl51XYx6A88E+lAF2iqV/qmnWBQX 2oWtsZf9WJ51Qv8ATJ5qa6ube3h824uYoYz0eRwo/M0AT0VTj1CykvXs4763a5Rd7wLMpdF9Sucg e9Lp2oWN+HNjfW10I22uYJlfYfQ4PBoAt0UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRXkn7Z3xmuPgZ8JY/GdtoUesvJqMVn9mecxAbwx3ZAP9 39a8d8RftYfGTwf4ah8XeOP2ctQ03wxmJp9Qj1NX2JIRtYDB65GM4GSKAPr2isHwT4r0bxT4V0nx Bpd7GbXW7OO8s1kYLI8bqCPl65GcH6VrNdW6XC2z3MSzOMrGzje30HWgCxRQOlFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAV9V/5Blz/ANcX/ka+DPhH/wAhFv8A rs//AKEa+89V/wCQZc/9cX/ka+DPhH/yEW/67P8A+hGgD6r+GP8Ax7RV6Xa/6gfSvNPhj/x7RV6X a/6gfSgCWiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigCO7/wBQ30rzL4of8eslem3f+ob6V5l8UP8Aj1koAqfso/8AHp4k/wCw hH/6LFeuCvI/2Uf+PTxJ/wBhCP8A9FivXBQAV8Lftx6d4q1X/gop8NtP8Ea7b6Hr9xpJWx1C4g82 OB8zZJXBz8uR+NfdNedeMfgt4O8S/HPQPixqR1H/AISDw3F5Vj5Vztg2/N95Mc/fbvQB8eeAtN8V +Jf269G8EftP+M7q41bwy4u/CtvDbJHY6q/31YOAMZ2ggYyShXjvmeP4tV+Lf7Y3xOs/FXww174i W/hpzYaZptjraWCaREDtEwVyNxbG7I7nJ7V9m/Hf4E+B/i1rmh634kXUbXVfDkpl07UdMufInjOQ wBbByAwBA9a5v41fss+AfiL41Pi+TVPEPh/XZ7dbe+vtEvzbvfxhQuJQBgkgAEjGcc0AfKHjLxF8 XfBv/BP+Pwr4j1C5sIbzxgmkw38epx3U0emMm8xNNEzAYYbSCehx0r3zwN8BPg18KPjN4I17wp4/ ufCuq3lmI49HOoB18SAgZLBzk53fw98EYxXqGn/s7/Cq0+A8vwgTw7v8NXB8yZXlJnkmyD55k6+Z kDn26Yrm/gz+yf8ADr4e+PbXxiNQ8QeItV0tPL0l9cvzcLpyYwBEuBjAJA9KAPb7C+sbm4ngtry3 lmt2xNHHKrNEfRgDkfjXyB/wWQSaX4d/D+K1nEM7+KQIpSM+WxjIDY74ODX0T8Jvg/4U+HnjjxX4 r0F9Ra/8ZXS3Wp/arnzIw6s7DyxgbRmRvXtUf7QXwY8H/GTTNHsPF51ARaJfi+tPsdwIj5gGPmyD ke1AHDfBb4c/tG6H8QNM1bxx8bdP8Q6BCrfadMi0kQtMChC4bHGGIP4V86/Cj4NaJ8Zv23fjHZ+L NS1ZdJ0TVVu0srO7Ma3E5kOwuOcgBT+dfoJCnlxLGM4UADPtXAfDP4O+EvAvxK8VeOtDOof2t4wl WXUzcXAePIJI2LgbeSe5oA+TP2aPhp4V/aW8ZfFLxV8Ybi9vtT0rWpNMsbMXrwro9uoYKyKCMY24 GePlPc15Xrni7xJq3/BOXxfoGpavd6lZeFPHdtYaPqMjlmlg+chQ/cDAI9Nwr7N+LH7JPw18a+N7 7xVb3/iHwzf6xxqw0HUTbxagD18xMEZPfHWtzxB+zT8LtV+AkHwfTTbvT/DVvdJdhbO42TyTLn53 kIO4nPOR6UAfIvx++Dvh7wZ8XPgjb+GtV16wu/HcSWviG/TU5Tc3quIQ5L5yNyyMuBxjHpXov7On hLSPhZ/wUx8S+APBX2qw8Oy+GEuXsGuGkQybYzu+YnPJJH1NfRXxA+B/gzxj4l8F65q7aiLrwGyt pHkXIVeNmPMGPm+4vTFW7H4P+E7T4/3Xxjja/PiS908WE2bj/R/KAUcJjIOFHegD0AUVwHxt+Jkv w6SwaLwJ4q8Ufbi4I0GyE5g24+/kjGc8fSuA/wCGm7v/AKIN8Vf/AASr/wDF0Ae/UV4D/wANN3f/ AEQb4q/+CVf/AIuj/hpu7z/yQb4q/wDglX/4ugD36ivAf+Gm7v8A6IN8Vf8AwSL/APF0f8NN3f8A 0Qb4q/8AglX/AOLoA9+orwH/AIabu/8Aog3xV/8ABKv/AMXQf2m7vPHwG+Kv/glH/wAXQB79RXgP /DTd3/0Qb4q/+CVf/i6B+03d4/5IN8Vf/BKP/i6APfqK8BP7Td3kf8WG+KuP+wKv/wAXR/w03ddv gP8AFX/wSL/8XQB79RXgP/DTd3/0Qb4q/wDglX/4ugftN3ef+SDfFX/wSr/8XQB79RXgLftN3Y6f Ab4qn/uCj/4ul/4abu/+iDfFX/wSr/8AF0Ae+0V4F/w03d/9EG+Kv/glX/4uj/hpu7/6IN8Vf/BK v/xdAHvtFeA/8NN3f/RB/ir/AOCVf/i6B+03d4/5IN8Vf/BKv/xdAHv1FeA/8NN3f/RBvir/AOCV f/i6P+Gm7vH/ACQb4q/+CQf/ABdAHv1FeA/8NN3f/RBvir/4JV/+Lo/4abu8/wDJBvir/wCCVf8A 4ugD36ivAT+03d44+A3xVP8A3BR/8XQf2m7vH/JBvir/AOCVf/i6APfqK5L4OeNn8eeE21yTwvrn hwi5eD7Frdt5NwdoB37cn5TkgfQ11tAHyl/wWHBP7KduAcH/AISC1xx7PXk37SHwo+OVj+y9L4h8 WfHi18ReGdPsrW9uPD89uLZbqNdjLCHXlj0wO+PWvsr9ob4S+FfjN4ETwl4wN8NPS6S6/wBCn8py 6Zxzg8cmvIE/YU+CTSRi8uPF19BGwP2a51tmifHQEbelAHl/7SV3/av7M3wa/aS8G6K+hv4OntPO sISxWCzLhCoPdA6AAns9dR+zVdxfG79vXxj8XrWZrnw34RsItK0NwSY3ldBuYD1AMh/4EK779tPW I/BvwDl+Gfhn4V634kg1/SZdLsLfSLQvbWGFCxmUjlQMhh6la2P2AfhPdfCH9nHS9A1a2EGt37Pf 6snG5JZOkZI/uoFH1zQB7YDxS1538cPijL8OZbCOLwD4s8Ufbw5J0GxE4g244fJGM54+lcL/AMNN 3f8A0Qb4q/8AglX/AOLoA9+orwH/AIabu/8Aog3xV/8ABKv/AMXR/wANN3f/AEQb4q/+CVf/AIug D36ivAf+Gm7v/og3xV/8Eq//ABdL/wANN3f/AEQf4q/+CVf/AIugD33I9aK8BH7Tl3/0Qb4q/wDg kX/4ul/4abu/+iDfFX/wSL/8XQB77RXgJ/acuh/zQf4q5P8A1BR/8XR/w03d/wDRBvir/wCCVf8A 4ugD36ivAf8Ahpu7/wCiDfFX/wAEq/8AxdB/abu/+iDfFX/wSr/8XQB79RXgQ/abuz/zQf4q/wDg lH/xdJ/w03d5/wCSDfFX/wAEq/8AxdAHv1FeA/8ADTd3/wBEG+Kv/glH/wAXR/w03d4/5IN8Vf8A wSL/APF0Ae/UV4D/AMNN3f8A0Qb4q/8AglX/AOLo/wCGm7v/AKIN8Vf/AASj/wCLoA9+orwL/hpu 7/6IP8Vf/BKP/i6Rf2m7sjn4D/FUH0/sVf8A4ugD36ivAT+03d5/5IN8Vf8AwSr/APF11nwa+Mk3 j7xW+iyfDLxr4bCWzT/bNb04QQtggbA2T83P6UAepUUUUAV9V/5Blz/1xf8Aka+DPhH/AMhFv+uz /wDoRr7z1X/kGXP/AFxf+Rr4M+Ef/IRb/rs//oRoA+q/hj/x7RV6Xa/6gfSvNPhj/wAe0Vel2v8A qB9KAJaKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK KKACiiigAooooAKKKKAI7v8A1DfSvMvih/x6yV6bd/6hvpXmXxQ/49ZKAKn7KP8Ax6eJP+whH/6L FeuCvI/2Uf8Aj08Sf9hCP/0WK9cFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABQelFFACAYJ4xS4 oooAMUYoooAMUY/zmiigAxRiiigAxRiiigBCKAKWigAxRiiigAx9fzox9fzoooAMfX86MfX86KKA EI9KAD60tFABijFFFABijH1/OiigAx/nNJS0UANA55p1FFABRRRQAhzQowPelooAQjnIH/16Mf5z S0UAGKMUUUAGKQilooAQClxRRQAmKMf5zS0UAGKMUUUAGKMUUUAGKMUUUAGKMUUUAGPr+dJg/wCT S0UAJigZzzS0UAFFFFAFfVf+QZc/9cX/AJGvgz4R/wDIRb/rs/8A6Ea+89V/5Blz/wBcX/ka+DPh H/yEW/67P/6EaAPqv4Y/8e0Vel2v+oH0rzT4Y/8AHtFXpdr/AKgfSgCWiiigAooooAKKKKACiiig AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigCO7/ANQ3 0rzL4of8eslem3f+ob6V5l8UP+PWSgCp+yj/AMeniT/sIR/+ixXrgryP9lH/AI9PEn/YQj/9FivX BQAUUV43+0D+0x8Ofg74zs/C/iyPWpNQv7UXUCafYGcMm4r2I5yDxQB7JRXi3wS/am+EfxQ8YDwn oeqX1hrkiloLDVrJrZ5wBkhM8E45xnNezhiRwKAHUVjePPFXh/wZ4Xu/EfinVbbS9KsV3T3Vw+1F HYe5J4AHJq34d1S01vQ7PWNOkMtnf26XFvIVK743G5Tg8jIIoAvUUDNFABRRRQAUUUUAFFFFABRR RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRXj/x+/aR8AfB/ xTb6B4rtNflubm0+1I+n6a08YTJHLAjng1yXgb9tb4P+LvEWnaLotp4pln1S7S0gkOjt5QkYgDcw Y4HIz6UAfRtFcL8Efiv4b+Kdrq9x4bt9UhTRL42N0L+zaAtIOSUz95feu5JIFAC0UmTRk+lAC0Ug OaWgAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigCvqv/IMu f+uL/wAjXwZ8I/8AkIt/12f/ANCNfeeq/wDIMuf+uL/yNfBnwj/5CLf9dn/9CNAH1X8Mf+PaKvS7 X/UD6V5p8Mf+PaKvS7X/AFA+lAEtFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAEd3/AKhvpXmXxQ/49ZK9Nu/9Q30rzL4of8es lAFT9lH/AI9PEn/YQj/9FivXBXkf7KP/AB6eJP8AsIR/+ixXrgoAK+Nv2kFVv+CqXwkVlDA6a2QR kf8ALevsmvnL9qL9nLxb8SPjloXxN8HfEaPwpqeg2P2a2f7B57q25suOQOjkdKAPPv8AgqHZWOh/ EP4PeKtCtYbbxGPFCwJLboElmiDxkKcckZOP+BGqf7YvjbU7f41a3p9z+0BrGjJZaeG0jwv4M06W 4u4pwgObtlG0ZOTywIBHAr0T4cfsveIX+LWk/EP4y/FS+8faj4eO/SLWS1ENtbv1DlcnJB54A5wT 0rP1/wDZf8e23x18X+LfAXxUj8PaP49LHW4n05Z7yMN99YJG4GSWweMA+woA+fvix4r8dfFj/gl7 b+MvFXi28luNC8QGyvovLUDVl82MRmY/3k3Z46kc10nxS8f+Ofhb8OvhV8Kv+Fo61BB4ss01bU/E kVkZ73T7IqgS1t0QFiFw3I56dq9e0j9km8tP2O9f+Bk/jSGcahqx1HT9RFmV8khkYLKu47uU5Ix1 pmsfswfEHXfAHg+61T4nWlt8RPAdwRoWu2en4hS02oEt5E6tgqTu9yMGgDA/Ye+LPiu4/aD1T4az eK/EHjfwfdWBvNH1/W9KltriGVAC8LF1GRy34jjrX2MnIrxf9nP4U/Efwt4z1Xxn8T/ileeKdW1O EQx2Fqpg060UY5WHoX+UDOBjn1rt/il8VPh78Nns08c+K7HRDqG42oui373bjdjAPTIoA7KivIP+ Gpf2fRx/wtTQ/wA5P/iaP+Gpf2ff+iqaJ+cn/wATQB6/RXkH/DU37Pv/AEVTRPzk/wDiaP8Ahqb9 n3/oqeif+RP/AImgD1+ivIP+Gpf2ff8Aoqeh/nJ/8TQP2pv2ff8AoqmifnJ/8TQB6/RXkB/am/Z9 /wCiqaJ+cn/xNH/DU37Pv/RVND/OT/4mgD1+ivIB+1N+z7/0VTRPzk/+Jo/4am/Z9/6Kpof5yf8A xNAHr9FeQf8ADU37Pv8A0VTQ/wA5P/iaP+Gpf2ff+iqaH+cn/wATQB6/RXkH/DU37Pv/AEVTRPzk /wDiaP8AhqX9n3/oqmh/nJ/8TQB6/RXkH/DU37Pv/RVNE/OT/wCJo/4am/Z9/wCiqaH+cn/xNAHr 9FeQH9qb9n3/AKKpof5yf/E0f8NTfs+/9FU0P85P/iaAPX6K8g/4al/Z9/6Kpon5yf8AxNH/AA1N +z7/ANFU0T85P/iaAPX6K8g/4al/Z9/6Kpof5yf/ABNA/al/Z9P/ADVPQ/zk/wDiaAPX6K8g/wCG pv2ff+iqaJ+cn/xNH/DU37Pv/RVND/OT/wCJoA9foryD/hqb9n3/AKKpof5yf/E0f8NTfs+/9FU0 P85P/iaAPX6K8g/4am/Z9/6Kpof5yf8AxNH/AA1L+z7/ANFU0P8AOT/4mgD1+isnwX4k0Txd4XtP EXhvUodR0u/QyWt3DnZKoJGRnnqCPwrWHSgDm/i1bwP8MfEjyQxsy6Nd4LICR+5evnX/AIJBRRP+ yIXaKMuNfvMMVGRxH3r6d8YaY2teEtU0ZJhC2o2M1sJSuQhdCu7HfGc15n+xp8HLn4G/B1vA9zrk WsOdQmuxcxwGJR5gUbcEnptoA+W/Avxf+Jt5+xV8ZvE9z401N9Y0PxELfTb4OoltYzIoKoQOBgms /wCJ/ib4/wDgP4a/Cf4pxfGfUb/U/GksNm+mXFun2GASRgxkoP8AWHByxPJPIr2vw1+yTqGlfs7f EH4Z/wDCa20s3jbVhfx3v2FgtqAwbaV3Zbp14ra+LX7NF740+Dnwy8EReLYLST4fXdvcSXTWZYXv lIFwq7htzjPegDzvwrrnxQ+Ef7dGj/D7xF8TtW8aaP4g8PzalfRagqgRyJFK58sDhcNFxjscGvGj 8ffHPjnR/EXxC/4XH4s0LxHBeyHw54W0nQ5ptPeJCNscjqpUlhwc+hz1r7L8dfAy58RftceHPjKf EEEVromlPYS6U1qWa4DLICd+cAHzOmO1eZL+yv8AFPwuNa8MfCz40/8ACPeB/EF813NYSWO67syx y6wyqeOABkEdBQB71+zJ411D4h/Azw34v1iwew1PUbMG/t2jMeydSVfCnkAkEj2Nd7WH4L0mPwh4 DsdIuNWvdQj0izCS6hqEpknnCjLSSN3J5Neet+1J+z8rFW+KWiBlOCP3nB/75oA9eoryD/hqb9n3 /oqmh/nJ/wDE0f8ADU37Pv8A0VTRPzk/+JoA9foryD/hqX9n3/oqmh/nJ/8AE0D9qb9n3/oqmifn J/8AE0Aev0V5Af2pv2fB/wA1U0T85P8A4mj/AIal/Z9/6Kpof5yf/E0Aev0V5AP2pv2fSM/8LT0T 85P/AImj/hqb9n3/AKKpof5yf/E0Aev0V5B/w1N+z7/0VTQ/zk/+Jo/4al/Z9/6Kpof5yf8AxNAH r9FeQf8ADU37Pv8A0VPRPzk/+Jo/4al/Z9/6Kpof5yf/ABNAHr9FeQf8NTfs+/8ARVND/OT/AOJo /wCGpv2ff+iqaJ+cn/xNAHr9FeQf8NS/s+/9FU0T85P/AImj/hqb9n3/AKKpof5yf/E0Aev0V5B/ w1N+z7/0VTQ/zk/+Jo/4am/Z9/6Kpon5yf8AxNAHr9FeQf8ADUv7Pv8A0VTRPzk/+Jo/4am/Z9xn /hamh/nJ/wDE0Aev0V5B/wANTfs+nj/hamif+RP/AImuh+Gnxq+FnxC199E8F+NdO1nUI4TO9vbl twQEAtyBxyKAO+ooooAr6r/yDLn/AK4v/I18GfCP/kIt/wBdn/8AQjX3nqv/ACDLn/ri/wDI18Gf CP8A5CLf9dn/APQjQB9V/DH/AI9oq9Ltf9QPpXmnwx/49oq9Ltf9QPpQBLRRRQAUUUUAFFFFABRR RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBHd/6h vpXmXxQ/49ZK9Nu/9Q30rzL4of8AHrJQBU/ZR/49PEn/AGEI/wD0WK9cFeR/so/8eniT/sIR/wDo sV64KACkwPQUtFAAQPSkwKWigBAoFLgelFFABVDWdE0XV/L/ALW0iwv/ACs+X9qtkl2Z643A46Cr 9FAGH/whfg7/AKFPQ/8AwWw//E0f8IV4N/6FLQ//AAWw/wDxNblFAGH/AMIX4O/6FPQ//BbD/wDE 0f8ACF+Dv+hT0P8A8FsP/wATW5RQBh/8IX4O/wChT0P/AMFsP/xNH/CF+Dv+hT0P/wAFsP8A8TW5 RQBh/wDCF+Dv+hT0P/wWw/8AxNH/AAhfg7/oU9D/APBbD/8AE1uUUAYf/CF+Dv8AoU9D/wDBbD/8 TR/whfg7/oU9D/8ABbD/APE1uUUAYf8Awhfg7/oU9D/8FsP/AMTR/wAIX4O/6FPQ/wDwWw//ABNb lFAGH/whfg7/AKFPQ/8AwWw//E0f8IX4O/6FPQ//AAWw/wDxNblFAGH/AMIX4O/6FPQ//BbD/wDE 0f8ACF+Dv+hT0P8A8FsP/wATW5RQBh/8IX4O/wChT0P/AMFsP/xNH/CF+Dv+hT0P/wAFsP8A8TW5 RQBh/wDCF+Dv+hT0P/wWw/8AxNH/AAhfg7/oU9D/APBbD/8AE1uUUAYf/CF+Dv8AoU9D/wDBbD/8 TQfBfg49fCeh/wDgth/+JrcooAw/+EL8Hf8AQp6H/wCC2H/4mj/hC/B3/Qp6H/4LYf8A4mtyigDD /wCEL8Hf9Cnof/gth/8AiaP+EL8Hf9Cnof8A4LYf/ia3KKAMP/hC/B3/AEKeh/8Agth/+JoPgvwc evhPQ/8AwWw//E1uUUAQ6fZ2lhZR2djaw21vEMRwwxhEQdcBRwKmoooAKKKKADA9KQgGlooATaKA ABS0UAI6q6FGUMrDBBGQRWJ/whfg7/oU9D/8FsP/AMTW5RQBh/8ACF+Dv+hT0P8A8FsP/wATR/wh fg7/AKFPQ/8AwWw//E1uUUAYf/CFeDf+hS0P/wAFsP8A8TQfBfg49fCeh/8Agth/+JrcooAw/wDh C/B3/Qp6H/4LYf8A4mg+C/Bx6+E9D/8ABbD/APE1uUUAYZ8F+DiefCehn/uGxf8AxNH/AAhfg7/o U9D/APBbD/8AE1uUUAYf/CF+Dv8AoU9D/wDBbD/8TR/whfg7/oU9D/8ABbD/APE1uUUAYf8Awhfg 7/oU9D/8FsP/AMTR/wAIX4O/6FPQ/wDwWw//ABNblFAGH/whfg7/AKFPQ/8AwWw//E0HwX4O/wCh T0P/AMFsP/xNblFAGH/whfg7/oU9D/8ABbD/APE0f8IX4O/6FPQ//BbD/wDE1uUUAYf/AAhfg7/o U9D/APBbD/8AE0f8IX4O/wChT0P/AMFsP/xNblFAGH/whXg3/oUtD/8ABbD/APE0f8IX4Ozn/hE9 Dz/2DYf/AImtyigDD/4Qvwd/0Keh/wDgti/+JqzpHh3w/pV0bnS9C0yynKbDLbWccbleuMqAce1a dFABRRRQBX1X/kGXP/XF/wCRr4M+Ef8AyEW/67P/AOhGvvPVf+QZc/8AXF/5Gvgz4R/8hFv+uz/+ hGgD6r+GP/HtFXpdr/qB9K80+GP/AB7RV6Xa/wCoH0oAlooooAKKKKACiiigAooooAKKKKACiiig AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAju/wDUN9K8y+KH/HrJ Xpt3/qG+leZfFD/j1koAqfso/wDHp4k/7CEf/osV64K8j/ZR/wCPTxJ/2EI//RYr1wUAFFFcl47+ J/w98F6pHpvizxlo2jXcsXmxwXt0sTsmcbgD2yKAOtorkfBPxS+HPjDVDpvhfxvoWrXgUt9ntL5H kIHUhQcn8K60kUALRSbhijcKAFopAQTWD4/8b+EfA9jBe+L/ABHp2i29zIY4Zb6cRrIwGSoJ6nFA G/RXn+kfHL4P6rqttpmm/Ejw5dXl5KsVvBFfozyuxwFAzySa7/cKAFopMj1oyPWgBaKQkUbhnFAC 0UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR WN458W+GvBmjjVvFWuWOj2LSiIXF5MI0LnouT3ODXL6V8c/g7qV/FZWPxL8MT3E7hIo11KPLsTgA ZPXNAHoNFIGBUMCCD0IoLAdaAFooHNFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAV9V/5Blz/ANcX/ka+DPhH/wAhFv8Ars//AKEa+89V/wCQZc/9cX/ka+DPhH/y EW/67P8A+hGgD6r+GP8Ax7RV6Xa/6gfSvNPhj/x7RV6Xa/6gfSgCWiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigCO7/wBQ30rz L4of8eslem3f+ob6V5l8UP8Aj1koAqfso/8AHp4k/wCwhH/6LFeuCvI/2Uf+PTxJ/wBhCP8A9Fiv XBQAV8Bf8FE73wvp37eHgG+8ZeGp/Eehw6Nm90u3tvPkuV3y4UR/xYJB/Cvv2vm74zfCXx14g/bz +H3xO0nT4JPDfh+zMWoXDXKK6MfN4CHk/eWgD5s8NQeDfi9+1N4Fuf2bPhnfeEY/Ct+tz4k1DyVt 0ij3gkOgY84V155O7GK9t+LP7RnxG1j47+Jfh/8ACS58D6Pb+DY9uo6h4suxEL647wwjcOh4+oOc DFaHxz+CXj7w5+1Jonxt+B1hbvPcv5XirR2u0to76PgF/mIUllzn0ZQfWuF+L/7Pvjjw9+0D4o8e eHfg94W+JujeMsXIsNamRJtHum5cjccFd2c46g44xQB1cP7ZKn9kaX4kt4dt5PFcWsf8I/8A2THM TA97jIcMOfLK/NjOeMZ711Hwk8Y/tS2HxQ0PSfid4I0LVfDuv23mS6n4eVlOjMRkLNuYhu2cDvkH iuK8S/sx+NvE/wCx8nhq6svCeheOINYTW7a10WzW1sw6LtWGUrwz7Sfn6ZwO2a6r4WTftX+L/ir4 cn8Y6XpvgLwroEOzV4La5jum1twB90clAcdjwM9c0AfS6kZxXxp/wWZMC/DTwFLdW5uIU8TZkhC5 Mi+UcqB7jivoX4N3nxguPH/jKP4iaZpNr4eiu1HhaSydTLNBufcZcE4OPL646mvOv+Cinwm8cfFj w14Ms/BGnwXk2jeIFvbsS3Sw7IguMgt1P0oA4L9nvV/2dfFHxa0LR9B/Zr1nw/qplE9rqt9oPkxW 0kalwxfPB+Xg9yRQ/wC0F+0T4r/aL8a/DD4a+FfDV6vhnU1BvLvcn2e1Vwrb8uA7NnjGMYPFfYtq GW3jVuCqgH8q+e/2XPhR408GftPfFrxn4i0+3g0jxbdJJpcqXCu8qh2Jyo5XgjrQByVr8b/j78Wv G3iu3+BOieFU0DwdctZS3ut7y+qXK/eWIBgFBKnGexGTzWZ4j/bB8Qzfsc33xK0XQbCx8XaD4gh0 XWdOug0kMTtuyygEHBA4yeCD1p/hf4f/ALQn7PfjTxlZfCfwho/jPwz4t1F7+xe5vxby6XM2f9Yp I3KAQMDrtHIrn/EX7J3xDtf2KdY8H2RstW8deKfE0Gt6uiXKxwRbd2UV24ONxOe5bjpQBqeM/wBo r9o/wV4+8H2viLwX4SubX4h2yjQ9KtbiRZbaZggXzpiexdSQBjGRniu6/Zw+MvxZuP2odb+Cfxes PDz6lZ6Yuo2t7oiusYUhW2HcTkYb0ByKj/aE+DvjvxZ8T/gfrWjabBLaeCZEbW2e6RTCB5OdoJ+f 7jdK1tC+FvjO3/4KIav8WZbCAeFrvw6ljDci4UyNKFQY8vqOVPNAH0NRUFzeW1sV+03EMIb7pkkC 5+metRf2rpf/AEErT/v+v+NAFyiqf9q6X/0ErT/v+v8AjR/a2lnpqVmf+3hf8aALlFUzqumD/mI2 n/f9f8aP7V0z/oI2n/f9f8aALlFU/wC1tLPTUrP/AL/r/jQdW0sddSs/+/6/40AXKKp/2rpf/QRt P+/6/wCNH9raWempWn/f9f8AGgC5RVM6tpY66lZ/+BC/40f2tpn/AEEbT/wIX/GgC5RVP+1tL/6C Np/3/X/Gj+1tL/6CNp/3/X/GgC5RVP8AtbSx11Kz/wC/6/40f2rpn/QRtP8Av+v+NAFyiqY1XSz/ AMxGz/7/AK/40HVtL/6CVp/3/X/GgC5RVP8AtXS/+glaf9/1/wAaP7V0vtqNp/3/AF/xoAuUVT/t bS84/tKz/wDAhf8AGj+1dM/6CNp/3/X/ABoAuUVTGraWempWn/f9f8aP7V0vP/IStP8Av+v+NAFy iqZ1bSx11Kz/AO/6/wCNH9q6Wemo2n/f9f8AGgC5RUVvcwXCb7eaOVQcbo3DDPpkVLQB8of8Fisf 8Mp25IzjX7bjH+y9fMHx9174Rap8C7fSfD37OWs+ENal+yIPFF5p5tre3OV3ys653BhnqOQc9a+0 f+CjPwx8YfFn4Cw+F/BFjBeamurwXJjmuFhUIgbJ3Nx3FeXfEfRP2zPH3win+F9/8P8AwPpmmahZ xWFzfLqQeRIlABIBc4JC9QCR2oA6X4g/FrxX8FPCfwUe21PSvEvgrWorXSta1rY0kjsVQLLHJkAK VLYyM/Ka63TfjH4q8Q/tyXnwi8N22mt4Z8N6ULrXbx42acTMoKxq27A5dO3Y1zXx9+EugeGP+CdU /wANda8QWqXHhfR1u7O/uZQmbuFjJlAecFiyADs2Kp/8EpPCmqr8I9W+Kfih5LnXvHV8ZTdTD53t oRsQ59CwY/lQB9WJ92lqvcXdtbEC5uIYS33fMkC7vpmo/wC1dM/6CNp/3/X/ABoAuUVTGq6Wemo2 n/f9f8aP7W0v/oJWf/gQv+NAFyiqf9q6X/0ErT/v+v8AjQdW0zH/ACEbP/wIX/GgC5RVP+1tLPTU rM/9t1/xo/tbS84/tKzz/wBfC/40AXKKpnVdLHXUrT/v+v8AjR/aumf9BG0/7/r/AI0AXKKp/wBr aXnH9pWef+u6/wCNB1bSx/zEbT/v+v8AjQBcoqmNV0z/AKCNp/3/AF/xo/tbS+2pWf8A3/X/ABoA uUVT/tbSx11G0/7/AK/40v8Aaumf9BK0/wC/6/40AW6KpjVtLP8AzErP/v8Ar/jQdW0sddSs/wDv +v8AjQBcoqn/AGrpn/QRtP8Av+v+NH9raX21KzP/AG3X/GgC5RVM6tpn/QRs/b/SF/xqS2v7K4k8 u3u4JXxnbHKrHHrwaALFFFFAFfVf+QZc/wDXF/5Gvgz4R/8AIRb/AK7P/wChGvvPVf8AkGXP/XF/ 5Gvgz4R/8hFv+uz/APoRoA+q/hj/AMe0Vel2v+oH0rzT4Y/8e0Vel2v+oH0oAlooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAj u/8AUN9K8y+KH/HrJXpt3/qG+leZfFD/AI9ZKAKn7KP/AB6eJP8AsIR/+ixXrgryP9lH/j08Sf8A YQj/APRYr1wUAFIVBNLRQAm0UbRj6UtFADQgApdopaKAECgZ96CoNLRQAmBRtHqaWigBNo780mwd vyp1FACFQaNozS0UAcN8ZPhD4C+KaWKeN9HfURppc2wW6lh2bsZ+4wz0HWuG/wCGQfgF/wBCbN/4 Nbr/AOOV7lRQB4b/AMMhfAL/AKE2b/wa3X/xyj/hkH4Bf9CbN/4Nbr/45XuVFAHhp/ZB+AR/5k2b /wAGt1/8co/4ZC+Af/QnTf8Ag1uv/jle5UUAeG/8Mg/AL/oTZv8Awa3X/wAco/4ZB+AX/Qmzf+DW 6/8Ajle5UUAeG/8ADIXwC/6E6b/wa3X/AMco/wCGQvgF/wBCdN/4Nbr/AOOV7lRQB4b/AMMhfALv 4NmP11W5/wDjlH/DIXwC/wChNl/8Gt1/8cr3KigDw3/hkL4Bf9CbN/4Nbr/45R/wyD8Av+hNm/8A Brdf/HK9yooA8NP7IPwC/wChNm/8Gt1/8co/4ZC+Af8A0J0//g1uv/jle5UUAeGj9kL4BDp4Nm/8 Gt1/8co/4ZB+AX/Qmzf+DW6/+OV7lRQB4b/wyF8A/wDoTpv/AAa3X/xyj/hkL4Bf9CdN/wCDW6/+ OV7lRQB4b/wyD8Av+hNm/wDBrdf/AByj/hkH4Bf9CdN/4Nbr/wCOV7lRQB4aP2QfgEP+ZNm/8Gt1 /wDHKP8AhkH4BZ/5E2b/AMGt1/8AHK9yooA8N/4ZB+AX/Qmzf+DW6/8AjlA/ZC+AQ/5k2b/wa3X/ AMcr3KigDl/hN8PfCnw18Lt4d8H6e9jpzXD3Biad5T5jAAnc5J/hHGa6iiigBGAYYNG0ZzS0UAee /HH4J/Dn4vSaY3j7Q21P+yWZrUC6kiA3Y3BghG4HaODXa+H9J03Q9EtNH0izis7CxhWC2t4V2pEi jAUD0xV2igDg/jH8HPh98U5rGXxvoz6i2mhxbFbuWHYGxn7jDPQda4n/AIZC+Af/AEJ03/g1uv8A 45XuVFAHho/ZC+AX/QnTf+DW6/8AjlH/AAyD8Av+hNm/8Gt1/wDHK9yooA8N/wCGQvgH/wBCdN/4 Nbr/AOOUH9kH4BH/AJk6b/wa3X/xyvcqKAPDR+yD8Ah08HTf+DW6/wDjlH/DIPwC/wChNmz6/wBq 3X/xyvcqKAPDf+GQvgF38HTf+DW6/wDjlH/DIXwD/wChOm/8Gt1/8cr3KigDw3/hkH4BZz/whs3/ AINbr/45Qf2QfgEf+ZOm/wDBrdf/AByvcqKAPDf+GQfgF/0Js3/g1uv/AI5R/wAMg/AL/oTZv/Br df8AxyvcqKAPDf8AhkH4Bd/B03/g1uv/AI5R/wAMhfAL/oTZv/Brdf8AxyvcqKAPDR+yD8Ah/wAy bN/4Nbr/AOOUH9kH4BHr4Nm/8Gt1/wDHK9yooA8N/wCGQvgH/wBCdN/4Nbr/AOOUf8Mg/AL/AKE2 b/wa3X/xyvcqKAPDf+GQfgF/0Js3/g1uv/jldR8JfgL8L/hp4nk8QeDtAksL+W3a3aRr2aUbCQSM OxHUCvSqKACiiigCvqv/ACDLn/ri/wDI18GfCP8A5CLf9dn/APQjX3nqv/IMuf8Ari/8jXwZ8I/+ Qi3/AF2f/wBCNAH1X8Mf+PaKvS7X/UD6V5p8Mf8Aj2ir0u1/1A+lAEtFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAEd3/qG+le ZfFD/j1kr027/wBQ30rzL4of8eslAFT9lH/j08Sf9hCP/wBFivXBXkf7KP8Ax6eJP+whH/6LFeuC gAoopCQOpA/GgBaKAQehzRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRSEgdSB+NAZSeGH50ALRSAg9CDS0AFFFFABRR RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBX1X/kGXP/ AFxf+Rr4M+Ef/IRb/rs//oRr7z1X/kGXP/XF/wCRr4M+Ef8AyEW/67P/AOhGgD6r+GP/AB7RV6Xa /wCoH0rzT4Y/8e0Vel2v+oH0oAlooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAju/9Q30rzL4of8eslem3f+ob6V5l8T/+PWSg Cp+yj/x6eJP+whH/AOixXrgryP8AZR/49PEn/YQj/wDRYr1wUAFfD/7behv42/4KB/DvwFea7rem 6XrWlFLn+zb1oWODKwIwcZ+UDpX3BXxN+2vc694U/b08AfEa08E+IfEOmaFpW65XSLF5mJLSrtyB gH5weTQBm/FLw7r/AOyL8avAXiDwr478R6v4S8VaoNM1bSdZvTOBkqCwJ4BwxYHAIK+hr2z4zftH 6h4T+JOqeDvCPwm8T+MbjQrMXeq3doPIt7dNob5WYfPgEZI+navHPH9346/az+MvgWwt/hl4h8Je DfCWpjUtTv8AXIfJeVgVOxVI5yF2jGfvE9qwPj9qnjnXf2lvG3hf4kaZ8Tr3S9hi8FaN4T3Q2V8p BCGaRcBlPBJJ4OaAO2/ae/al1XWf2Kbf4h/CvTdZ02XXLxrC61DahOisjgOrnnl84Vh65611Wgft Pjwt8A/Blzr3gPxLc+MNf2afpHh93D3mrFETN0G7RsWzkjJNeDeG/BPjF/8AglH4q8Jf8Ipq8Ot2 Hic3M2nyWjiYxCWFiyqRlwAD0z0p/wAbbTU/Hvh34R/FvT/DPjn+wPB9muga/BpsT2mq2rRqpM8G ATtOSNw/u44oA+sv2ePj7Y/Ejxlq/gbXfCmq+DPGWiRLPdaLqZDM8Jx+8jccMPmGfqOteyL0r41/ Yc8M6HrX7Q2qeP8AQvB/xEisdO042dv4l8Yaszy3u4KPK8h0DEDBIIYhcD1r7JjJxzQA6iiigAop M+1LQAUUfhRQAUUUUAFFFFABRRRQAUUmfaloAKKM0mfagBaKKKACiiigAooo59KACiiigAooooAK KKKACikyM4paAPCP2tvgNoHxEgvvG2o+JvFOmXujaJMIYdK1EwQv5avIpZccnPWvn3/gm38FNM+I 3ww074o6/wCMvGB1XS9ekCW8WrOLeUQlGUMpySDnnmvtz4oxSz/DPxFDBE8ssmkXSxxouWdjCwAA 7kmvAP8AglHomteHf2U5NO1/SL7TLwa5dv8AZ7y3aKTaVTB2sAccGgDl/wBnT4xeBfAfwB+J/wAQ tA0bxdeWmh+Iit9aaxqqXEkkrEL+5bGEQbuhyeK0779t7RdNj8O63rnwr8W6b4U8Rpi01yRFYSyg ZZY4xy4B4zkZ6gYrxX4feDPGEH7Cvxw0mbwtrMd/f+JRLaWrWMgluE8xPmRcZYcHkV137T/hTxLe /sq/s+adY+G9UubnTNSsWvraKyd3tQsQDeYoHy496APafhJ+1BB4q+OEPwx8T/DvXvBmp6jZNe6U 2qOp+1QhSwLKPuEqpPfGCDWD4h/bHsYbzW9T8NfC3xR4j8GeG7v7Lqvii02rBEwOHZEIyyr656c8 ZFZXxs8Na7qf/BTDwTqNrpF+2l/8ItcWsuoJauYIGeO4UBnAwCNwOM9xXzZ4c8IN8OPDHiP4a+Pf Cnxfu/EH9oyR2GneH7+WHSNYhdgAzbVK8jknByMZoA/TPwJ4j0jxd4Q03xPoN2t1pmrWyXNpMv8A GjDI+h7EeorXrgP2YPCyeCvgP4b8OJpF5pH2WzDNp15eC5ltGclzG0gADEbuwFd+OlABRSZ9qWgA opM+1LQAUUUZoAKKM0UAFFJn2paACikz7UtABRRRQAUUUUAFFJn2oyfSgBaKKTPtQAtFFGRQAUUU UAV9V/5Blz/1xf8Aka+DPhH/AMhFv+uz/wDoRr7z1X/kGXP/AFxf+Rr4M+Ef/IRb/rs//oRoA+q/ hj/x7RV6Xa/6gfSvNPhj/wAe0Vel2v8AqB9KAJaKKKACiiigAooooAKKKKACiiigAooooAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAI7v8A1DfSvMvif/x7SV6bd/6h vpXmXxQ/49ZKAKX7KQb7N4j54+3px/2zFevV5H+yj/x6eJP+whH/AOixXrlABSYNLRQA0gmjbyDj p+lOooAQgmmhMDAAGOw6U+igBqqF4A47DsK4H42fD7xJ43fT28P/ABP8Q+DBZhxKNISM/at2MF94 7Y4x616BRQB4IfgD8R8Ef8NN/ED/AL9W/wDhS/8ACgviR/0c58QP+/Nv/wDE171RQB4J/wAKB+JH /RznxA/79W/+FB+APxIP/NznxA/79W/+Fe90UAeC/wDCgviR/wBHN/ED/v1b/wCFIPgD8SB/zc58 QP8Av1b/AOFe90UAeCH4A/Eg/wDNznxA/wC/Vv8A4UH4BfEjH/JzfxA/79W/+Fe90UAeCf8ACgvi R2/ac+IH/fm3/wAKP+FBfEjIP/DTnxA/79W/+Fe90UAeCf8ACgfiRjH/AA038QP+/Vv/AIUD4BfE kD/k5z4gf9+bf/Cve6KAPBP+FA/EjOf+GnPiB/36t/8ACl/4UF8SP+jm/iB/36t/8K96ooA8E/4U D8SP+jnPiB/36t/8KB8AfiQB/wAnOfED/v1b/wCFe90UAeCH4A/Eg/8ANznxA/79W/8AhSn4BfEj H/JzfxA/79W/+Fe9UUAeCD4BfEgf83OfED/vzb/4UH4A/EgnP/DTnxA/79W/+Fe90UAeC/8ACgvi T/0c58QP+/Nv/wDE0g+AXxIAx/w038QP+/Vv/hXvdFAHgg+APxIBz/w058QP+/Vv/hQfgF8SD/zc 58QP+/Nv/hXvdFAHgo+AXxIx/wAnN/ED/v1b/wCFIPgD8SB/zc58QP8Av1b/AOFe90UAeCH4A/Eg 4/4yc+IHH/TK3/wpf+FBfEj/AKOb+IH/AH6t/wDCveqKAMP4daJf+G/BlhouqeIb3xBeWcZWXVL4 AT3RLE7nC8Z5A49K3KKKACkIJpaKAEwc0gBGfenUUANwcfhRt6e36U6igCC8geazmhjlaF5I2VZU +9GSMbh7jrXhr/AP4jlyR+014/UEk4EVvge3SveaKAPBP+FA/EfJP/DTfxA5/wCmVv8A4UH4A/Eg jH/DTnxA/wC/Vv8A4V73RQB4J/woH4kf9HOfED/v1b/4UD4A/EgdP2nPiB+MVv8A4V73RQB4IfgD 8SD/AM3OfED/AL82/wDhQfgD8SP+jnPiB/36t/8ACve6KAPBB8AviQP+bnPiB/35t/8ACj/hQPxI zn/hpz4gf9+rf/Cve6KAPBP+FA/EjGP+Gm/iB/36t/8ACgfAH4kY/wCTnPiB/wB+rf8Awr3uigDw T/hQPxIzn/hpz4gf9+rf/Cg/AH4kEY/4ac+IH/fq3/wr3uigDwQ/AL4kY/5Ob+IH/fq3/wAKB8Av iQP+bnPiB/35t/8ACve6KAPBD8AviQRz+058QP8Av1b/AOFA+AXxI/6Ob+IH/fq3/wAK97ooA8EH wB+JAGP+GnPiB/35t/8ACg/AH4kE5/4ac+IH/fq3/wAK97ooA8F/4UF8SP8Ao5v4gf8Afq3/AMKQ fAH4kAAf8NN/EDj/AKZW/wDhXvdFAHgh+APxH3bv+Gm/iB9PKt/8K6v4PfC7xf4N8VSatrnxj8U+ LrZ7dohYapHEIlYkESDaM5AGPxr1CigAooooAr6r/wAgy5/64v8AyNfBnwj/AOQi3/XZ/wD0I195 6r/yDLn/AK4v/I18GfCP/kIt/wBdn/8AQjQB9V/DH/j2ir0u1/1A+leafDH/AI9oq9Ltf9QPpQBL RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQBHd/6hvpXmXxQ/49ZK9Nu/8AUN9K8y+KH/HrJQBU/ZR/49PEn/YQj/8ARYr1wV5H +yj/AMeniT/sIR/+ixXrgoAKKKTNAC0Umf50tABRRRQAUUUhOKAFopCT6UtABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUjHFA NAC0UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAV9V/ 5Blz/wBcX/ka+DPhH/yEW/67P/6Ea+89V/5Blz/1xf8Aka+DPhH/AMhFv+uz/wDoRoA+q/hj/wAe 0Vel2v8AqB9K80+GP/HtFXpdr/qB9KAJaKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAI7v/UN9K8y+KH/HrJXpt3/qG+leZfFD /j1koAqfso/8eniT/sIR/wDosV64K8j/AGUf+PTxJ/2EI/8A0WK9cFABXyH+2L48+LkP7YHg34Wf Dzx7H4XtfEWmmR5prVJY45A0hLMCM8hAOtfXlfC37cHhDRvHv/BRj4a+ENekuk0/VdKMU7WtwYZQ MzMNrjkHKigC/rXxE+PnwO+P3gTw742+Jej/ABA0rxhei0ntLayWOeAF1TeAORgsCDnBwRX0J8av 2i/hL8KPEcWgeMvE/kanJGJWtLW1kuZIYz0eQRg7B357V8meE/BHhr9lj9ubSbbxvpqa34Y8S4Hh nxJqTl5dIlJ24Yn5chmCk4yAwYY5rL1e+1rwh+2x8Wn1z4keGvBFxqbefbXfiTRBfx6jZNyqQsxA X5NowPvYx2oA+7Y/il4Bf4Vf8LJXxTpx8K+R551Tzf3YXOMeu7PG3Gc8Yrkfg7+018HPid4s/wCE a8KeKjJqroXgtbyzltmuVHUxmRQG/CviPxX4Ta0/4J6PqXhnX9R8S+Fv+E9TUr7OkSWKxw7Nkm2M sd0e/adw4B+lfSuj/Ff9nDxR8b/h1pPhTwva+KfEj2YGm6lpFsp/sJAo+WYgjbj5s5B2496APqRT nPNfMn/BTb4lePfhv4K8Hz+AfEB0W71jXvsVxP5KSAoUyMhgeAea9l+GXxX8E+PfGHibwx4Z1KW5 1Hwlcrb6tG1uyCJyXUAE8NzG3I9K+bP+CyEMN18PPh/aXG7yrjxQI5ADglTHg4Pbg0Adl4B8AftK QeMNJu9X/aO0PVtNiuo5buwh0tA91ECC6AjpkZGfxrsPF/7VHwO8L+JNS8P6z4x8jU9Jv1sbq0Fn M0glY4woC/MB3YcCqnwc/ZU+E/w78b6b418Opr39qWKkwG61eSaLLoVOUPB4Y14x+yJ4P8M+Jf28 fjjf67o1hqc+nXqizF5brKsLNKSXUMDhsoOaAPefix+078F/hz4mPh/xN4sK6lGivcW1nZy3LWoI BBl8tTs4I4PPNbviP44/DHRPhJb/ABOvPFNvJ4Wu5Uhh1C2jeZWd8gKVUFgcg5BHHevk79kPxl8N fhj42+MWi/HK6sNN8TXOuTzyyazBua/tDu+WMsPmyTnaOu4V4/e6bqtp/wAE3PGeqSWtxaeHdY8f 28/h2CcEYg+fJUHoDwM99poA+6LD9rX4A3XiqbQU8f2kc0EDT/aZYJEtpFUZISUrtY9eB1IIHNdB 8Dvj98Lvi5q19pXgjxEbu/05BJPa3FrJby7M43qsgBK5x09RXzB+1t4c8OR/F39mbTo9F0+O0lMM UkCW6hJEBtyFYAcjJPX1Ndb4Lt7Sz/4K8+IorSCGBX8IozJEgQFvLi5wO+AKAPr+ijvRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAfPX/BSz4h+MPh n+z5D4i8Eau2l6k2sQW5nWNXPlsGyMMCOwrxT4t+JP2k/hb8JYfidJ+0L4Z8QRxfZpDov2GISTiU r8gHO4jdyBg4BNehf8Fidv8AwyjAGYAHX7X+T182fGDRf2N9P+B0mq+A/FmpP49trOCXTore4uJc 3gCnBV12hd2c88dqAPuzQfjj4VgsfAFh4ynk0LxF490+G4sbCW3cq0rqMpvxtX5iMAkHkV0Op/FL wTY/GCy+F02rE+Kr+1N1DYRwO+IsE7mYDaowp6mvmD9pTw/448Z/sAeCPid4ht5E8deCVtdclbZs laMMA5IA4YoEcj1U1o/8E95bj4vfHbx/+0ZqVo8MV8YtH0aKUZMMaohk2n8FH4mgD7CHSiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAK+q/8gy5/wCuL/yNfBnw j/5CLf8AXZ//AEI1956r/wAgy5/64v8AyNfBnwj/AOQi3/XZ/wD0I0AfVfwx/wCPaKvS7X/UD6V5 p8Mf+PaKvS7X/UD6UAS0UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAR3f+ob6V5l8UP+PWSvTbv/UN9K8y+J3/AB7SUAVP2Uf+ PTxJ/wBhCP8A9FivXBXkf7KH/Hn4j/6/0/8ARYr1wUAFZd74d0C78QW+u3eiafPqloNtvfS2qNPC PRHIyvU9DWpRQBleJ/DXh3xJbxQeINC07VY4GLxJfWqTCNjxlQwOD9KzvG3w98C+L47ZfFHhDRtZ +xgLbm9sklMIHZSRkD2rpqKAKEGj6TDoS6NDplmmmrD5C2awKIBH/c2Y27fbFY/gn4eeBPB17Pd+ FfCGi6NcXWfOmsbGOJ3z2LAZx7dK6eigDN0bw/oWk395faXo1hZXWouHvJ7a2SN7lhnBkYDLHk8n 1pviXw7oHiGKCLXtEsNUS2k82Bby2SYRP/eUMDg+4rUooAaqgLgDAHpWdpXh/QdM1S81LTdGsLS9 1Bt15cwWyJJcn1dgAW/GtOigDmPGvw78CeML2C88U+DtE1i5tv8AUzX1jHLIntuIzj26Vo6v4Z8O apoMeh6loOm3emRbTHYz2iPAm37uEI2jHbitaigDJ1Lwz4d1C6sLm/0HTbqbSiDYSzWqO1pjGPLJ GU6DpjoKemgaHH4jfxCmjWK6vLF5T6gLZBcMn90yY3EcdM1p0UAeffGw/GIrp/8AwqdvCu7L/b/7 e83BHG3y/L/HOa4ID9sY/wAfwqH4Xde/UUAeBbf2xv7/AMKvyu6Mftjf3/hUfbF3XvtFAHgWP2xv 7/wq/K7pNv7Y/wDf+FX5Xde/UUAeBbf2xf8Anp8Kfyu6Nv7Y39/4Vfld177RQB4EV/bG/wCenwq/ K7pFX9scdZPhSfwu69+ooA8CI/bFznzPhSPbF3zSFf2xs5Enwq+mLuvfqKAPAQv7Y3eT4Vfld0bf 2x8/6z4VY+l3Xv1FAHgRX9sX/nr8Kh+F3Rt/bG/56fCr8ruvfaKAPAtv7Yuf9Z8Kvyu6Mftjf3/h V+V3XvtFAHgJX9sbs/wq/K7oC/tjd3+FR/C7r36igDwLb+2L/wA9PhUPbF3Rj9sX+/8ACr8ruvfa KAPAtv7Y3/PT4Vfld0bf2xf+enwpPti7r32igDwEj9sb+/8ACoe+Lul2/ti/3/hUPwu699ooA5H4 On4iDwm3/CzjoZ1v7S+3+xN/2fycDb9/ndndn8K66iigDO8TaDoniHTxYa/pFjqlqHDiC9t1mjDD odrAjPvWLZfDP4c2lwlxbeAvDUM0bBkdNJhBU+oO3g11dFAHjn7X3hn4y+L/AAZ/wi3wrv8Aw5ZW WsW01prUuqh/NSJwBmEgEfd3A5HcYro/2Y/hnY/CH4K6L4EspluDp8Ra6uAu37RO53SPj0JOB7AV 6BRQB578bT8ZvPsP+FUnwmIwr/bv7e87OeNuzy/xzmuD2/tj/wDPT4U/ld179RQB4EV/bGx/rPhT +V3SBf2xv+enwq/K7r36igDwLb+2L/f+FQ/C7o2/ti/89PhV+V3XvtFAHgQX9sYf8tPhSfwu6Qr+ 2PniT4U/ld179RQB4Ft/bF/v/Cofhd0bf2xv+enwq/K7r32igDwLb+2L/wA9fhV+V3QV/bG/56fC r8ruvfaKAPAdv7Y//PT4U/ld0Bf2x+8nwp/K7r36igDwLb+2L/z0+FX5XdIV/bG7SfCn8ruvfqKA PAQv7Y3eT4Vfld0u39sXj978Kh+F3zXvtFAHgWP2xv7/AMKvyu6FX9sYDmT4VN+F2K99ooA8B2/t j5z5vwqA9MXddb8HP+F/DxVIPic3gk6P9mby/wCxPP8AP83IxnzONuM16jRQAUUUUAV9V/5Blz/1 xf8Aka+DPhH/AMhFv+uz/wDoRr7z1X/kGXP/AFxf+Rr4M+Ef/IRb/rs//oRoA+q/hj/x7RV6Xa/6 gfSvNPhj/wAe0Vel2v8AqB9KAJaKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAI7v8A1DfSvMvid/x7SV6bd/6hvpXmXxO/49pK AKv7KP8Ax5+I/wDr/T/0WK9bFeR/sof8efiP/r/T/wBFivXBQAUUUmRQAtFGRRQAUUZFJkUALRRR QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUZoPFABRSAjOKWgAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKAK+q/wDIMuf+uL/yNfBnwj/5CLf9dn/9CNfeeq/8gy5/64v/ACNfBnwj /wCQi3/XZ/8A0I0AfVfwx/49oq9Ltf8AUD6V5p8Mf+PaKvS7X/UD6UAS0UUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAR3f+ob6 V5l8UP8Aj1kr027/ANQ30rzL4of8eslAFT9lH/j08Sf9hCP/ANFivXBXkf7KP/Hp4k/7CEf/AKLF euCgAr5p/ao/aB+I3gP9oTw78LPh94J0nxDf+IbD7Rbre3TQsX3Plc5AAwhPNfS1fGX7S88Nt/wV O+Es9zPFBCmmsXklcKqjE/Un3oA6zwV+0x490L4x6L8Pvjx8MofB8niVxHpOp2d559vJLnAVjyOT gcHgkcV9EeJPFvhbw7NFF4g8R6TpUk4JjS+vY4S4HcBiMivkb/gphq2l+L/iR8H/AAX4V1G11HxC fE63AisplleCPdGAx2k46E/8BNcr+0BB4Q+Iv7RXxGj8L/DH/hNNZ0LTzb61q3ibxCLbTtIKIVLW 0R5+Uqe+M545oA+s/wBov4y+F/hH8Ibnx/qUi6jbLsWyt7OdC167kBQhzgrk5JGcDJre8D+O9B1z 4Z6d41udT02zsru0jnuJGvYzFbMyhjG0mcZBOK/OZ9Jsda/4JInW9Xj+2ah4b8UyQ6TPJIxNokk0 QdV5xtIJ/Oui+P3hyz0S6+A3w18MeGLa98Ma7ZJrF5oL6qbS11fUXVAwlnJIU4C/99Y70Afol4f1 3RdesBfaHq1lqVqW2iezuFmTPpuUkZ9qvg5FfF37GXhXxZ4O/bC1+G10Lw94O8PalpWdR8I2HieO /e0nVVKTLEPmUEn043Yr7RTGOBigBaKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooA8T/AGl/Hnx18Haz53w3+GukeI9Bt9Na6vb281DyXidd xZQu4ZAUA15j+zd+0V+0P8XoNN17SfhF4dPhefUhaXuopqbK0Cqw8xgrNklQc9K+mfiwAPhZ4m/7 At3/AOiXr50/4I/nP7ITZ6f2/eDp/sx0AeufA3x74s1nRfEGp/Eqw8OeHoNM1FoLSay1iOeJ4ezy sGIjYnHykg128Hi3wtNrEGkw+JNJkv7mMSQWqX0ZllQjIZUByQRzkV+cPw4AX/gn98e8AYPipevX /WJSftBfCnwd4Y/Zt+BXifQrS4sdf8SX1tDqerRXMguJ1miBPzZ4x0XGMDigD9ItE8UeG9Zvriy0 jX9M1C5szi4htbyOV4TnHzKpJH41HqXi/wAK6drcejah4l0i01KbHl2c99GkzZ6YQnPNfF+oeCfD /wAH/wDgpZ4Q0f4c6adKtbzwlcST20LsRdSLDPgsCfmLGNCfU814l8NvC+ufEn4LeNvFur/D3Rda 1m81SY3fjPVvFq2dzo0wIK/un+6qn8DnHagD9VlOaWvN/wBkiXxNJ+zp4UHi++tb/V4tPWKa8tbt bmO5VSVSQSrkNlQuSO9ekUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAV9V/5Blz/ANcX/ka+DPhH/wAhFv8Ars//AKEa+89V/wCQZc/9cX/ka+DPhH/yEW/6 7P8A+hGgD6r+GP8Ax7RV6Xa/6gfSvNPhj/x7RV6Xa/6gfSgCWiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigCO7/wBQ30rzL4of 8eslem3f+ob6V5l8UP8Aj1koAqfso/8AHp4k/wCwhH/6LFeuCvI/2Uf+PTxJ/wBhCP8A9FivXBQA V5P8df2cfhX8XvFVr4i8caTeXd/Z232aGSC+khAj3FsYUjnJPNesUUAeTfBX9mv4PfCrxA2veEPC qxaqVKpe3c73EsQIwQhcnbkelZvj39lX4N+MPifc+OtZ0O7N/fsH1G3t76SK2v2GOZo1IDdBkdD3 r2uigDybTP2c/hTY/BzWPhdbaLcL4Y1q6N3cWjXbsY5SVIaNicpgquMelZf/AAyn8H5fhDB8Or3T NRvtMs71r60ubnUHa7tZmABMcvVRhR8o446V7bRQB5j8AvgH8Ofg/LfXnhLTbh9T1LAu9T1C4a4u pVHOzzG5C9OBjOBmr3xs8f8AifwPJp6+Hfhhr/jQXgczHSpI1+y7cY3b+ucnH0r0CkI5zQB4L/wv z4mf9GxePf8AwJt/8aUfHr4mEZ/4Zi8ef+BNt/jXvWKKAPBP+F+fE3/o2Hx7/wCBNv8A40n/AAvz 4m/9Gw+Pf/Am3/xr3yigDwT/AIX38TP+jYvHn/gTb/40n/C/Pib/ANGw+Pf/AAJt/wDGvfKKAPBB 8fPibn/k2Hx7/wCBNv8A40H49/Ewf82xePT/ANvNv/jXvdFAHgn/AAvz4m/9Gw+Pf/Am3/xo/wCF +fE3/o2Hx7/4E2/+Ne90UAeCf8L8+Jv/AEbD49/8Cbf/ABpP+F+fE3/o2Hx7/wCBNv8A4175RQB4 J/wvz4m/9Gw+Pf8AwJt/8aP+F+fE3/o2Hx7/AOBNv/jXvdFAHgn/AAvz4m/9Gw+Pf/Am3/xo/wCF +fE3/o2Hx7/4E2/+Ne90UAeCf8L8+Jv/AEbD49/8Cbf/ABpP+F+fE3/o2Hx7/wCBNv8A4175RQB4 J/wvz4md/wBmHx7/AOBFv/jSf8L8+Jv/AEbD49/8Cbf/ABr3yigDwT/hfnxN/wCjYfHv/gTb/wCN A+PnxNH3v2YvHo+lzbn+te90UAeCf8L8+Jv/AEbD49/8Cbf/ABo/4X58Tf8Ao2Hx7/4E2/8AjXvd FAHgn/C/Pib/ANGw+Pf/AAJt/wDGj/hfnxN/6Nh8e/8AgTb/AONe90UAeCf8L8+Jv/RsPj3/AMCb f/Gj/hfnxN/6Nh8e/wDgTb/4173RQBh/DvXNR8R+C7DWtV8O3vh68vIy02l3rK01qdxG1yvGcAHj 1rcHSkwM5paAKutWFtqujXel3qF7a9t3gmUHBZHUqwz24Jrlfgl8MPB/wm8FHwp4Ksp7TTGuHuTH LO0rb3wGO5uewrtKKAPJNL/Zw+FOn/DXxH4DtNGu00XxVd/a9UiN7IWlkyDkNnKjI6Cr3jL4D/Df xR4J8LeE9Z0u6l0vwbNHLo8SXbq0LRrtXcwOW4HevTaKAOF1z4TeCdX+M2lfFO+sLh/E2jWptbO5 FywRIzu4KZwfvt19a8+8afsefA/xP4zu/Ed3oeoWj6jP59/ZWOoSQWl3JndueJTjkknjHWve6KAM 3TtOsPDnhiLTdD0xILPTbXy7SytkChURfljQdB0xXiz/AB7+JauVH7Mfj1sHGRcW/Pv1r3sigUAe B/8AC/PiZ/0bD49/8Cbf/Gl/4X58Tf8Ao2Hx7/4E2/8AjXvdFAHgf/C/Pib/ANGw+Pf/AAJt/wDG j/hfnxN/6Nh8e/8AgTb/AONe+UUAeCf8L8+Jv/RsPj3/AMCbf/Gj/hfnxN/6Ni8e/wDgTb/4173R igDwP/hfnxN/6Nh8e/8AgTb/AONL/wAL8+Jv/RsPj3/wJt/8a97ooA8E/wCF+fE3/o2Hx7/4E2/+ NH/C/Pib/wBGw+Pf/Am3/wAa97ooA8E/4X58Tf8Ao2Hx7/4E2/8AjR/wvz4m/wDRsPj3/wACbf8A xr3uigDwT/hfnxN/6Nh8e/8AgTb/AONH/C/Pib/0bD49/wDAm3/xr3uigDwT/hfnxN/6Nh8e/wDg Tb/40f8AC/Pib/0bD49/8Cbf/Gve6KAPBP8AhfnxN/6Nh8e/+BNv/jR/wvz4m/8ARsPj3/wJt/8A Gve6KAPBP+F9/Ev/AKNi8e/+BNv/AI0g+PnxNx/ybD49/wDAm3/xr3yigDwQfHz4mf8ARsPj3/wJ t/8AGur+DnxQ8ZeMfFMmla/8GvE/hC2S3Mq6hqcsTROwIGwBTnJzn8K9QoxQAUUUUAV9V/5Blz/1 xf8Aka+DPhH/AMhFv+uz/wDoRr7z1X/kGXP/AFxf+Rr4M+Ef/IRb/rs//oRoA+q/hj/x7RV6Xa/6 gfSvNPhj/wAe0Vel2v8AqB9KAJaKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAI7r/UNXmXxOGbaSvTrj/UmvO/iLbmS3kAGc5o Ay/2URiz8R/9f6f+ixXrYr538BfELTfhwuqw6jpl7dG9uVlX7MAQoC45z9Ku3P7VXhG3JV/DOvkj 0jT/AOKoA97or5+/4az8H/8AQr+If+/cf/xVH/DWfg//AKFfxD/37j/+KoA+gaK+fv8AhrPwf/0K /iH/AL9x/wDxVH/DWfg//oV/EP8A37j/APiqAPoGivn7/hrPwf8A9Cv4h/79x/8AxVH/AA1n4P8A +hX8Q/8AfuP/AOKoA+gaK+fv+Gs/B/8A0K/iH/v3H/8AFUf8NZ+D/wDoV/EP/fuP/wCKoA+gaK+f v+Gs/B//AEK/iH/v3H/8VR/w1n4P/wChX8Q/9+4//iqAPoGivn7/AIaz8H/9Cv4h/wC/cf8A8VR/ w1n4P/6FfxD/AN+4/wD4qgD6Bor5+/4az8H/APQr+If+/cf/AMVR/wANZ+D/APoV/EP/AH7j/wDi qAPoGivn7/hrPwf/ANCv4h/79x//ABVH/DWfg/8A6FfxD/37j/8AiqAPoGivn7/hrPwf/wBCv4h/ 79x//FUf8NZ+D/8AoV/EP/fuP/4qgD6Bor5+/wCGs/B//Qr+If8Av3H/APFUf8NZ+D/+hX8Q/wDf uP8A+KoA+gaK+fv+Gs/B/wD0K/iH/v3H/wDFUf8ADWfg/wD6FfxD/wB+4/8A4qgD6Bor5+/4az8H /wDQr+If+/cf/wAVR/w1n4P/AOhX8Q/9+4//AIqgD6Bor5+/4az8H/8AQr+If+/cf/xVH/DWfg// AKFfxD/37j/+KoA+gaK+fv8AhrPwf/0K/iH/AL9x/wDxVH/DWfg//oV/EP8A37j/APiqAPoGivn7 /hrPwf8A9Cv4h/79x/8AxVH/AA1n4P8A+hX8Q/8AfuP/AOKoA+gaK+fv+Gs/B/8A0K/iH/v3H/8A FUf8NZ+D/wDoV/EP/fuP/wCKoA+gaK+fv+Gs/B//AEK/iH/v3H/8VR/w1n4P/wChX8Q/9+4//iqA PoGivn7/AIaz8H/9Cv4h/wC/cf8A8VR/w1n4P/6FfxD/AN+4/wD4qgD6Bor5+/4az8H/APQr+If+ /cf/AMVR/wANZ+D/APoV/EP/AH7j/wDiqAPoGivn7/hrPwf/ANCv4h/79x//ABVH/DWfg/8A6Ffx D/37j/8AiqAPoGivn7/hrPwf/wBCv4h/79x//FUf8NZ+D/8AoV/EP/fuP/4qgD6Bor5+/wCGs/B/ /Qr+If8Av3H/APFUf8NZ+D/+hX8Q/wDfuP8A+KoA+gaK+fv+Gs/B/wD0K/iH/v3H/wDFUf8ADWfg /wD6FfxD/wB+4/8A4qgD6Bor5+/4az8H/wDQr+If+/cf/wAVR/w1n4P/AOhX8Q/9+4//AIqgD6Bo r5+/4az8H/8AQr+If+/cf/xVH/DWfg//AKFfxD/37j/+KoA+gaK+fv8AhrPwf/0K/iH/AL9x/wDx VH/DWfg//oV/EP8A37j/APiqAPoGivn7/hrPwf8A9Cv4h/79x/8AxVH/AA1n4P8A+hX8Q/8AfuP/ AOKoA+gaK+fv+Gs/B/8A0K/iH/v3H/8AFUf8NZ+D/wDoV/EP/fuP/wCKoA+gaK+fv+Gs/B//AEK/ iH/v3H/8VR/w1n4P/wChX8Q/9+4//iqAPoGivn7/AIaz8H/9Cv4h/wC/cf8A8VR/w1n4P/6FfxD/ AN+4/wD4qgD6Bor5+/4az8H/APQr+If+/cf/AMVR/wANZ+D/APoV/EP/AH7j/wDiqAPoGivn7/hr Pwf/ANCv4h/79x//ABVH/DWfg/8A6FfxD/37j/8AiqAPoGivn7/hrPwf/wBCv4h/79x//FUf8NZ+ D/8AoV/EP/fuP/4qgD6Bor5+/wCGs/B//Qr+If8Av3H/APFUf8NZ+D/+hX8Q/wDfuP8A+KoA+gaK +fv+Gs/B/wD0K/iH/v3H/wDFUn/DWfg//oV/EP8A37j/APiqAPetV/5Blz/1xf8Aka+DPhGCdROP +ezf+hGve/8AhqfwlewyQR+GdfUyIVBaNMcj/eryD4U6O6XYk2EBnLY7jLE/1oA+j/hiD9njr0u1 /wBQPpXnvw8t2jgTIx0r0O3/ANSKAJKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAGyDKEVzfinTxcQsuM5rpqr3EAkBGBzQB4 R418H/anf9319q8/1P4cF5TiHP4V9RXujRy9UBrPl8NRE/6taAPmI/DXn/VfpSf8K1/6ZfpX04PD MePuL+VH/CMx/wBxf++aAPmP/hWv/TL9KP8AhWv/AEy/Svpz/hGY/wC4v/fNH/CMx/3F/wC+aAPm P/hWv/TL9KP+Fa/9Mv0r6c/4RmP+4v8A3zR/wjMf9xf++aAPmP8A4Vr/ANMv0o/4Vr/0y/Svpz/h GY/7i/8AfNH/AAjMf9xf++aAPmP/AIVr/wBMv0o/4Vr/ANMv0r6c/wCEZj/uL/3zR/wjMf8AcX/v mgD5j/4Vr/0y/Sj/AIVr/wBMv0r6c/4RmP8AuL/3zR/wjMf9xf8AvmgD5j/4Vr/0y/Sj/hWv/TL9 K+nP+EZj/uL/AN80f8IzH/cX/vmgD5j/AOFa/wDTL9KP+Fa/9Mv0r6c/4RmP+4v/AHzR/wAIzH/c X/vmgD5j/wCFa/8ATL9KP+Fa/wDTL9K+nP8AhGY/7i/980f8IzH/AHF/75oA+Y/+Fa/9Mv0o/wCF a/8ATL9K+nP+EZj/ALi/980f8IzH/cX/AL5oA+Y/+Fa/9Mv0o/4Vr/0y/Svpz/hGY/7i/wDfNH/C Mx/3F/75oA+Y/wDhWv8A0y/Sj/hWv/TL9K+nP+EZj/uL/wB80f8ACMx/3F/75oA+Y/8AhWv/AEy/ Sj/hWv8A0y/Svpz/AIRmP+4v/fNH/CMx/wBxf++aAPmP/hWv/TL9KP8AhWv/AEy/Svpz/hGY/wC4 v/fNH/CMx/3F/wC+aAPmP/hWv/TL9KP+Fa/9Mv0r6c/4RmP+4v8A3zR/wjMf9xf++aAPmP8A4Vr/ ANMv0o/4Vr/0y/Svpz/hGY/7i/8AfNH/AAjMf9xf++aAPmP/AIVr/wBMv0o/4Vr/ANMv0r6c/wCE Zj/uL/3zR/wjMf8AcX/vmgD5j/4Vr/0y/Sj/AIVr/wBMv0r6c/4RmP8AuL/3zR/wjMf9xf8AvmgD 5j/4Vr/0y/Sj/hWv/TL9K+nP+EZj/uL/AN80f8IzH/cX/vmgD5j/AOFa/wDTL9KP+Fa/9Mv0r6c/ 4RmP+4v/AHzR/wAIzH/cX/vmgD5j/wCFa/8ATL9KP+Fa/wDTL9K+nP8AhGY/7i/980f8IzH/AHF/ 75oA+Y/+Fa/9Mv0o/wCFa/8ATL9K+nP+EZj/ALi/980f8IzH/cX/AL5oA+Y/+Fa/9Mv0o/4Vr/0y /Svpz/hGY/7i/wDfNH/CMx/3F/75oA+Y/wDhWv8A0y/Sj/hWv/TL9K+nP+EZj/uL/wB80f8ACMx/ 3F/75oA+Y/8AhWv/AEy/Sj/hWv8A0y/Svpz/AIRmP+4v/fNH/CMx/wBxf++aAPmP/hWv/TL9KP8A hWv/AEy/Svpz/hGY/wC4v/fNH/CMx/3F/wC+aAPmP/hWv/TL9KP+Fa/9Mv0r6c/4RmP+4v8A3zR/ wjMf9xf++aAPmP8A4Vr/ANMv0o/4Vr/0y/Svpz/hGY/7i/8AfNH/AAjMf9xf++aAPmP/AIVr/wBM v0o/4Vr/ANMv0r6c/wCEZj/uL/3zR/wjMf8AcX/vmgD5j/4Vr/0y/Sj/AIVr/wBMv0r6c/4RmP8A uL/3zR/wjMf9xf8AvmgD5j/4Vr/0y/Sj/hWv/TL9K+nP+EZj/uL/AN80f8IzH/cX/vmgD5j/AOFa /wDTL9KP+Fa/9Mv0r6c/4RmP+4v/AHzR/wAIzH/cX/vmgD5j/wCFa/8ATL9KP+Fa/wDTL9K+nP8A hGY/7i/980f8IzH/AHF/75oA+Y/+Fa/9Mv0o/wCFa/8ATL9K+nP+EZj/ALi/980f8IzH/cX/AL5o A+Y/+Fa/9Mv0pR8Nef8AVfpX03/wjMf9xf8AvmkPhmP+4PwWgD5w074cbJQfKx+FegeC/B32V1xH yDXqcXhqINu8sflWhZaKkXIQD6UAVvDGn/Z4gNoGK6OMYQCore3EY4qcdKACiiigAooooAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo oAMD0pNo9BS0UAJtX0FG1fQUtFACbV9BRtX0FLRQAm1fQUbV9BS0UAJtX0FG1fQUtFACbV9BRtX0 FLRQAm1fQUbV9BS0UAJtX0FG1fQUtFACbV9BRtX0FLRQAm1fQUbV9BS0UAJtX0FG1fQUtFACbV9B RtX0FLRQAm1fQUbV9BS0UAJtX0FG1fQUtFACbV9BRtX0FLRQAm1fQUbV9BS0UAJtX0FG1fQUtFAC bV9BRtX0FLRQAm1fQUbV9BS0UAJtX0FG1fQUtFACbV9BRtX0FLRQAm1fQUbV9BS0UAJtX0FG1fQU tFACbV9BRtX0FLRQAm1fQUbV9BS0UAJtX0FG1fQUtFACbV9BRtX0FLRQAm1fQUbV9BS0UAJtX0FG 1fQUtFACbV9BRtX0FLRQAm1fQUbV9BS0UAJtX0FG1fQUtFACbV9BRtX0FLRQAm1fQUbV9BS0UAJt X0FG1fQUtFACbV9BRtX0FLRQAmB6Cl/CiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigD/9k= --94eb2c0cc3f4e0af2d0554be428e-- From nobody Thu Jul 20 11:00:38 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5654912EC5D for ; Thu, 20 Jul 2017 11:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=Fb5v7OCT; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=kw0+Nmu3 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 3uJNIjSq26ps for ; Thu, 20 Jul 2017 11:00:35 -0700 (PDT) Received: from ftp.catinthebox.net (dkim.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id BC022129B14 for ; Thu, 20 Jul 2017 11:00:34 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3686; t=1500573632; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=b3i/wXduDKuhUEGuCxGeZAiShSs=; b=Fb5v7OCTOfqpxxSXhuPc6x9nwzlGtU+A5Nz4bodOjt65waFQgxk7tHGunz+y3Q gAbElgckE190htylm7HAorAoOJ35VonZ/mSvNvASceGMcUqUIXnkeUJEqxtsnA9n ViTMp+MAGmkcPBAge0+0QpMAQzee9qexW50sRyDbs4dO8= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Thu, 20 Jul 2017 14:00:32 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 637514723.1.3456; Thu, 20 Jul 2017 14:00:31 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3686; t=1500573369; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=xPfFKKL wt6i9bsfMgVfUE8ypbOM9aIG8S7wy1ZbuSf4=; b=kw0+Nmu3A7o5rvccNZ24L63 vlrZjRJ7OeDdwuU6D6hsnlAYOe54MEvwQ+F/my4zvKqimCAm1QLa3rkI55yIATVL YF0JzkSonDM1fq3ZYpc3wQpAaDCRQPNDqI1CWkdkKuDFKgxspYia/HrDYF7I+qvL HSmIgjd/ubzA68oYJpfc= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.5) for dmarc@ietf.org; Thu, 20 Jul 2017 13:56:09 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.5) with ESMTP id 1180039080.9.418380; Thu, 20 Jul 2017 13:56:07 -0400 Message-ID: <5970EFBE.1040807@isdg.net> Date: Thu, 20 Jul 2017 14:00:30 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] DMARC mailing list policy with respect to DMARC bounces causing subscription suspensions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 18:00:37 -0000 Wow. This is why I always said the DKIM Policy Model "protocol" should provide a guideline for Mailing List Server (MLS) processors/receivers to A) check for policies and B) not accept for submission the strong, exclusive domain policies. Only accept relaxed policies. I proposed this back with the 2006 DSAP draft: https://tools.ietf.org/html/draft-santos-dkim-dsap-00#page-12 3.3. Mailing List Servers Mailing List Servers (MLS) applications who are compliant with DKIM and DSAP operations, SHOULD adhere to the following guidelines: Subscription Controls MLS subscription processes should perform a DSAP check to determine if a subscribing email domain DSAP policy is restrictive in regards to mail integrity changes or 3rd party signatures. The MLS SHOULD only allow original domain policies who allow 3rd party signatures. Message Content Integrity Change List Servers which will alter the message content SHOULD only do so for original domains with optional DKIM signing practices and it should remove the original signature if present. If the List Server is not going to alter the message, it SHOULD NOT remove the signature, if present. Let software handle it, otherwise you (speaking in general) are going to always have this issue of blocking organizations who are using a DKIM Policy, whether it was ADSP with DISCARDable or DMARC with reject, for their operations. Of course, they should be aware of it. But this problem stems from the "ignorant" IETF or other mail list servers who want do play "DKIM" but don't want to 'correctly" fit into the Policy model namely because of old excuses "that it wasn't done like that for 30 years." Well, they have to change now for the new, higher overhead, complex, big ARC push (or maybe they won't). The issue will still apply -- if the MLS sees a restrictive DMARC policy, it should not accept it for submission. Anyway, we been here and there already. I just find it interesting that it has come to this new manual "unfriendly" administrative policy. It should to be codify into the integrated specs and everyone will quickly see what needs to be done. Thanks -- Hector Santos, CTO/Founder Santronics Software, Inc. On 7/20/2017 6:08 AM, Barry Leiba wrote: > As noted in the IETF 99 minutes, we have announced a new policy for > the DMARC mailing list, at least until the list is under some DMARC > damage-mitigation: > > If you post with an email address in a domain with a DMARC "reject" > policy, and that policy causes other subscribers to have their > subscriptions disabled due to the DMARC-related bounces, then: > > 1. You will be asked to post from a different address, in a domain > that does not have a "reject" policy. > > 2. If you continue to post from the problematic address, that address > will be blocked from posting on the grounds that it is disrupting the > operation of the working group. > > Brandon, you are on notice that your address has > been causing problems for some time, and you have not responded to my > off-list notes. I got a new batch of disabled subscriptions this > morning. If it happens again, will not be allowed > to post. > > I want to stress that your participation is valuable and we *do* want > you here. It's just that the DMARC policy at is > inconsistent with posting to mailing lists, and we can't continue to > accept the disruption that causes. > > Barry, as chair > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > From nobody Thu Jul 20 11:21:55 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6861131B08 for ; Thu, 20 Jul 2017 11:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eudaemon.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHZFzsDy9q85 for ; Thu, 20 Jul 2017 11:21:52 -0700 (PDT) Received: from mail-yb0-x243.google.com (mail-yb0-x243.google.com [IPv6:2607:f8b0:4002:c09::243]) (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 E43A313191D for ; Thu, 20 Jul 2017 11:21:51 -0700 (PDT) Received: by mail-yb0-x243.google.com with SMTP id w187so1040045ybc.3 for ; Thu, 20 Jul 2017 11:21:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eudaemon.net; s=dkey; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=iKtggJF1Ou8iLzRvPoi+8CBq1pTgreyDwSC1/qxSfIs=; b=etZMial1l3fRtxC1JlQGhxjD79Zg1VPB2Di/ELpDKhwkaPFosbv081JCUGncbXpK8l LISI/rdhEsh7Oh3Alh+25iOYFbW8HfiYi0RBT6a/PJnfq7cfMnzVUbhn6e1ZIHMbIOvB DNS9lyexPjXAPAEQ2Pizx0mycebQhC6LtBeOg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=iKtggJF1Ou8iLzRvPoi+8CBq1pTgreyDwSC1/qxSfIs=; b=dWbpTiPwup+mKMLKr4xzahgNEOI11EA8Z0FD5JXyKffQBmsNOyx3zpaL9n0g5/N+dj bSnHC5tkJWZmb8OHeipVJdkPhd4vmFZ6YAGjb5uFHJnVuiPo+TVBXabSWNR4RiT/NQeu pI1nGcnpCaoTlZhuKNYTFhgG9mN9z1MWrO4xa6YIcQ7fKy09smgb14b5/CcZ4rZd9k9x dXPDLPZJeEhPLE2t3kZiflfapbinmcNfltA7UWU3ZhJ+Dp6WRP31hsFdV8PlKjT9/e1F ZOavjUZvuRpMqcCDY4Xl3ZsYQ45EbFU7lwLGD+OP2F4PW3PW2uEQLajp2Cyn1+3E33YX GiVg== X-Gm-Message-State: AIVw1113U+CgTTwG7cBp6j/9681hbnFasRfyQYDqI2lH8Np405opl+7v ic7X79SJbrtNrnZKXl5aQA== X-Received: by 10.37.96.69 with SMTP id u66mr3946550ybb.334.1500574911099; Thu, 20 Jul 2017 11:21:51 -0700 (PDT) Received: from [192.168.0.18] (208-104-133-98.brvd.dsl.dyn.comporium.net. [208.104.133.98]) by smtp.gmail.com with ESMTPSA id i125sm105856ywd.70.2017.07.20.11.21.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jul 2017 11:21:50 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Tim Draegen In-Reply-To: <5970EFBE.1040807@isdg.net> Date: Thu, 20 Jul 2017 14:21:48 -0400 Cc: dmarc@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6E20513C-7A0F-4BC2-9652-905C256C76E3@eudaemon.net> References: <5970EFBE.1040807@isdg.net> To: Hector Santos X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [dmarc-ietf] DMARC mailing list policy with respect to DMARC bounces causing subscription suspensions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 18:21:54 -0000 > On Jul 20, 2017, at 2:00 PM, Hector Santos wrote: >=20 > Anyway, we been here and there already. I just find it interesting = that it has come to this new manual "unfriendly" administrative policy. = It should to be codify into the integrated specs and everyone will = quickly see what needs to be done. It's true. For this list specifically, the fallout is impacting the = group's ability to address the problem... which is ironic? Also, the draft minutes = (https://www.ietf.org/proceedings/99/minutes/minutes-99-dmarc-02.txt) = mention: >Alexey: Also planning workaround that rewrites addresses, start >experimenting in September. Different rewriting than existing >patches. ..so the giant wheel is turning, albeit *slowly*. =3D- Tim From nobody Thu Jul 20 13:57:19 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBF8B126CC4 for ; Thu, 20 Jul 2017 13:57:09 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Ec7vOJg6rNB0 for ; Thu, 20 Jul 2017 13:57:08 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26D13126DC2 for ; Thu, 20 Jul 2017 13:57:08 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id e124so2767495oig.2 for ; Thu, 20 Jul 2017 13:57:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=wWR2jM2OReIoiFqELTbI2X3/W91ESc4NYoBamthMmgM=; b=vZ4Vz9B+TGrmVTwd92xEJwvOs6q+aTRh+74no5z0jexRguZOt2H1oZIZNOFGJloVuL nz758L5mOoJS3wp2q++yvn/LITwCi2rcKIwAaSstBNHEnrvoWwjbTpa5TQxyf2KJkhuM iwqY1bp95Q0v9I1HFabHNaSfVoILJBlPDd/yfGccWT1RkwwZlb8s1vAJ483ebTaEAcul IMhlqw6rfnWOANmEL4nUgLRaekmT0XS/VFIBl+JqKkgxJXYle771yydcFsZXFHosjG6X 0zPHd5LBWZLRFtEc8/7akoSY4ckLvkmUu4/K+BWj/jtSk72SGrYzkLTh8sMdDKtlHfj5 uuFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=wWR2jM2OReIoiFqELTbI2X3/W91ESc4NYoBamthMmgM=; b=iT1iWugm2cC1cacYgFG4pi9fM5vpE7JUeIsLJV0/GIaaLklznU29BUJ9k3mVLICwPu 0YlW3B1BbuK6dG2vOHx8+rNMLi/zAOdSxh3NZx3uUZJwkPJtOevYHgCfMw0pszsIfqZw 20yoD6X8DDeFZPqUsvrrQ/NYdax1+Zfx7EWOgFi11EJgYxhyBkuB1EL9Ou8UDM52kX/2 7BnUTz5rJWZKr780jTrE0C6CI3Era5g6HLDv5H0KIwLOqSLaoqokarNA8q3UqHODaXJI KASVyzxdWa81uBTXfrUq7ixJkVsKZ4tx96SmA60q4yXHDmL4kkmTVrlP+D0tWCn9oEPD EDKg== X-Gm-Message-State: AIVw111j7UIXjkc6668G8HCSumnbYHn9y+QNsLw54ANxaSBVGv8AprCN habM/OqzZzSb428qvY8= X-Received: by 10.202.244.5 with SMTP id s5mr520562oih.302.1500584227185; Thu, 20 Jul 2017 13:57:07 -0700 (PDT) Received: from ?IPv6:2602:304:cda0:8800:fdf0:484e:4bc:c50? ([2602:304:cda0:8800:fdf0:484e:4bc:c50]) by smtp.gmail.com with ESMTPSA id c205sm432966oia.42.2017.07.20.13.57.05 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jul 2017 13:57:05 -0700 (PDT) From: Dave Crocker To: "dmarc@ietf.org" Message-ID: <66a10b0b-8de0-02dc-257f-ee41cf3d9c4c@gmail.com> Date: Thu, 20 Jul 2017 13:57:03 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [dmarc-ietf] ARC Experimental goals X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 20:57:10 -0000 Folks, By way of trying to expand on the discussion about requirements for ARC to /exit/ Experimental status and enter standards status/document status... Internet Mail is a global store-and-forward service with many independent operators. Most Internet Mail is subject to rather simple operational scenarios, because most Internet Mail travels between a very small number of very large operators. Their email exchanges essentially appear to be one-hop between originating provider and receiving provider. This statistical bias is misleading and creates a perception of straightforward operational behavior and requirement. The full range of global email service has more operators and more handling complexity -- producing more interaction effects -- than the dominant environments demonstrate. Note that the expanded use of DMARC, into consumer-to-consumer mail, provides an unfortunate example of this effect: not many problems amongst the very large operators but very serious problems for some others, such as users of independent mailing lists. ARC produces a /chain/ of signatures. There is essentially no operational experience doing this in real time in the operational Internet. We need to learn what dependencies and what fragilities are relevant to its use. DKIM has demonstrated that a single signature can be broken by a number of existing handling scenarios, such as within some operational enterprises and through most mailing lists. It is therefore entirely plausible that sending a message through multiple, independent operators that are performing ARC signing will also produce breakage -- although the ARC design is explicitly intended to minimize this risk. This is worth emphasizing: email is an essential infrastructure service and ad hoc expansion of the policy scope for DMARC -- another authentication-related mechanism -- has produced significant operational problems. While it is possible that ARC will not demonstrate such problematic effects, it is also possible that it will. We should approach this issue with due caution. TIn terms of what it validates, the role of ARC signatures is quite different from the role of SPF or DKIM validations. The nature of this new role seems to be a form of 'transitive trust', which unfortunately is not encouraging: my understanding is that operational experience with mechanisms relying on transitive trust -- especially across multiple, independent administrations -- has been problematic. Integration of new types of validation information into email filtering engines has a learning curve. So far, experience is with a tiny number of very large operators. This sort of activity is amenable to special-case, manual configuration, which unfortunately does not expand into general, large-scale operation for most/all operators in the global Internet. Therefore, experimental experience with ARC needs to: 1. Demonstrate use across a 'significant' range of different email sending software, receiving software, mailing list packages, mailbox operators and mailing list operators. 2. Demonstrate robust survival of ARC signatures. 3. Demonstrate useful error reporting behaviors. 4. Demonstrate stable operational integration into mail filtering engines, subject to a 'significant' array of usage policies -- or demonstrate industry consensus on a small, stable set of policies. (Vocabulary such as significant and robust and useful are intentionally vague. Or rather, intentionally subjective. Determining the specifics that will satisfy them is up to the working group and IETF management.) When these demonstrations are made, it will be possible to write a usage BCP that has rich and useful guidance for those wishing to deploy ARC. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Jul 20 14:14:37 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20506126BF0 for ; Thu, 20 Jul 2017 14:14: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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 VM-ryk6FpQ30 for ; Thu, 20 Jul 2017 14:14:33 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003: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 CD2691201F2 for ; Thu, 20 Jul 2017 14:14:33 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id e124so3111068oig.2 for ; Thu, 20 Jul 2017 14:14:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=xGydMr4aULoyLVBLv9iM6fbOKMN96OXxVc/uY+4uVXQ=; b=ZOQ1olOtZaKwEt+yo8wOYqMmp5/8Jt1YKoug1bE5bxIbbZwF9P88vyc5vEnktfKV/3 rBZgYCjAv//oc/1KXxo3FUCK+n4x1d3d2e5ioD+U+4jXzCj0oGiwT/LhKqNMzsJqJf1l mH3kqcDRojfMiBseiEK8Zo59rprCbVYGcKo6s5jd/X99QNalNpn7k1Ele/AjIiDrg9lx AOjGpH+1PT9QcK++nvzUz4V+IwqyGDIp1uDsOekJ+yNYgHzLVxg0jD6HpMRIxgIUrAIq LAk+ImPyLTXG8AIx/x3SK0d0ggID1hsbKs/OAf8ZR+ycPEbkKNH32lvh0H9ViUbxVk6g p4BA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=xGydMr4aULoyLVBLv9iM6fbOKMN96OXxVc/uY+4uVXQ=; b=BZSlZWeoOi8CnqayRbzl1TdmvSTyaJrEmKvmEVD0+k0jlB09KDE/YPy8Rn/GNo1nj+ hkxX5RHXgTPCWeQ91WwiXxxRVt640CnbheK/57k5lIN1U9Tt3TJ6rpA9XbTBkiwtQWnZ D3WNdHFvJ5+g/kejdzr79bGeIvWUJhsmle0tl4MZn7e+BCOnnYgkqZsawie1qyCylZbU iFLMMYwPzRtiiwLcdJ2gkisvdPUAkdpWJONczxhX7KQqPGdNeUPx7gCiNHEoKAbXZwVW 8kRkLoQ2Stb/uQL22o2mdZMP8wAZsqG8J7GgsyyKllZqeVA2ZMgyb8z1++PM1EeLb90U sj9w== X-Gm-Message-State: AIVw110rDCG3bjx8Eej31+T9SU0aBCfRXL9xxv+FYhbLasVfrzp0lQf8 c+tUYjAwzexSqVWhMCs= X-Received: by 10.202.117.68 with SMTP id q65mr583370oic.140.1500585272949; Thu, 20 Jul 2017 14:14:32 -0700 (PDT) Received: from ?IPv6:2602:304:cda0:8800:fdf0:484e:4bc:c50? ([2602:304:cda0:8800:fdf0:484e:4bc:c50]) by smtp.gmail.com with ESMTPSA id r10sm483575oia.30.2017.07.20.14.14.32 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jul 2017 14:14:32 -0700 (PDT) From: Dave Crocker To: "dmarc@ietf.org" References: <09ef99af-328c-63e1-5bd5-f8774caceee5@gmail.com> Message-ID: <97173080-f5ae-bf8d-5fba-d8dd4ef0491a@gmail.com> Date: Thu, 20 Jul 2017 14:14:29 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <09ef99af-328c-63e1-5bd5-f8774caceee5@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] ARC Experimental goals X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 21:14:35 -0000 On 7/20/2017 1:53 PM, Dave Crocker wrote: > It is therefore entirely plausible that sending a message through > multiple, independent operators that are performing ARC signing will > also produce breakage, although the ARC design is expl. hmmm, nevermind signatures, even content can get corrupted in spite of repeated proof-reading. The sentence was supposed to be: It is therefore entirely plausible that sending a message through multiple, independent operators that are performing ARC signing will also produce breakage, although the ARC design is explicitly designed to minimize this risk. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Jul 20 23:57:09 2017 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 52D3A124D85; Thu, 20 Jul 2017 23:57:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dmarc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.57.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150062022230.11161.7815861997281487470@ietfa.amsl.com> Date: Thu, 20 Jul 2017 23:57:02 -0700 Archived-At: Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-07.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 06:57:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain-based Message Authentication, Reporting & Conformance WG of the IETF. Title : Authenticated Received Chain (ARC) Protocol Authors : Kurt Andersen Brandon Long Steven Jones Murray Kucherawy Filename : draft-ietf-dmarc-arc-protocol-07.txt Pages : 43 Date : 2017-07-20 Abstract: The Authenticated Received Chain (ARC) protocol creates a mechanism whereby a series of handlers of a message can conduct authentication of a message as it passes among them on the way to its destination, and record the status of that authentication at each step along the handling path, for use by the final recipient in making choices about the disposition of the message. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-protocol/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-07 https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-arc-protocol-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-arc-protocol-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 21 00:01:02 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E99712EC39 for ; Fri, 21 Jul 2017 00:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M2-2Tk4FI2A5 for ; Fri, 21 Jul 2017 00:00:58 -0700 (PDT) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::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 028F812EC23 for ; Fri, 21 Jul 2017 00:00:57 -0700 (PDT) Received: by mail-ua0-x230.google.com with SMTP id k43so2462880uaf.3 for ; Fri, 21 Jul 2017 00:00:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:from:date:message-id:subject:to; bh=h1K6TOxTnoVtc78P0Yfyw+VTo6gQ9/chEsDxRfAUGNY=; b=Z/MeBDNe18uAevLgxx/+a34P6lPKr4Wx+qMxRmZEJSw5fk5ct4YpyTgOi8Dwuk/y+z Xz7q2hbipILpBlb1lip/GbfmNcqPdOrPhUSKor/n2C2+houb68P4nUYI7/DIZj0RkbG4 2LBfSi7vV9hBr2/7FVLhjQmJFVg9B7k2dBQXs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=h1K6TOxTnoVtc78P0Yfyw+VTo6gQ9/chEsDxRfAUGNY=; b=h1lkMHbei6enfipDMs8UyE5unCxyJaa+6tU9trdC5czuoxjuptjwdMmhtajSxwtp80 9W2O6VtCp9F+NiC0EV4bGUxQhsTOq/NAFoZ8NGIaSMsxUzIsMicjC0P0KNPGBVqbuz5R qqHFnikjronHUnBMiiqbFuFkqXWuW48tqufQE2a5z+qPkGbxwMOYEeZartkq45VHqiea ugf3lfU4Xb/54V+N7R5PPhf35zGA+bVU9J7xU5yDromUZAJZHQF4cKlt552WanAaUlbn fQvdGcGHo4bRpXqs+4nRxpqHEJPTaNZEZnMO79dvxywnRbHe8EIe/pX1AXlMrOj5H2Hd hdxw== X-Gm-Message-State: AIVw113drgNblsqE5ZvxdyQVm35/l5ye7LNz5VvHY5sMJHBXsr9NvAMT /OPbHyVI/0bvuS7aykGn38sawtL/w5kUZ5HCEQ== X-Received: by 10.31.93.6 with SMTP id r6mr2728513vkb.99.1500620456638; Fri, 21 Jul 2017 00:00:56 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.176.26.39 with HTTP; Fri, 21 Jul 2017 00:00:56 -0700 (PDT) From: "Kurt Andersen (b)" Date: Fri, 21 Jul 2017 09:00:56 +0200 X-Google-Sender-Auth: tBYVISWgY5qmeteZYpxHWGjCSbI Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c09198a42d2460554ce6d09" Archived-At: Subject: [dmarc-ietf] draft-ietf-dmarc-arc-protocol-07 posted X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 07:01:00 -0000 --94eb2c09198a42d2460554ce6d09 Content-Type: text/plain; charset="UTF-8" URL: https://www.ietf.org/internet-drafts/draft-ietf-dmarc-arc-protocol-07.txt Status: https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-protocol/ Htmlized: https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-07 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-arc-protocol-07 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-arc-protocol-07 In this version, I have melded Murray's structure (and much of his language) into the previous version of the draft and sought to incorporate the results of this week's (IETF99) discussions about remaining open issues. There are a few notes in the draft about remaining work (update the examples, more explanation on migrating signing algos) but otherwise this should be largely complete. I'll be nitpicking my way through it on my flight back to the US and expect to have updated examples incorporated early next week in a follow-up version. --Kurt --94eb2c09198a42d2460554ce6d09 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
URL:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://www.ietf.org/internet-drafts/draft-ietf-dmarc-= arc-protocol-07.txt
Status:=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-pro= tocol/
Htmlized:=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0https:/= /tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-07
<= span style=3D"color:rgb(33,33,33);font-family:wf_segoe-ui_normal,"Sego= e UI","Segoe WP",Tahoma,Arial,sans-serif,serif,EmojiFont;fon= t-size:13.3333px">Htmlized:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://datatracker.ietf.or= g/doc/html/draft-ietf-dmarc-arc-protocol-07
Diff:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0https://www.ietf.= org/rfcdiff?url2=3Ddraft-ietf-dmarc-arc-protocol-07

In this version, I have melded Murray's structure (and= much of his language) into the previous version of the draft and sought to= incorporate the results of this week's (IETF99) discussions about rema= ining open issues.

There are a few notes in the dr= aft about remaining work (update the examples, more explanation on migratin= g signing algos) but otherwise this should be largely complete.
<= br>
I'll be nitpicking my way through it on my flight back to= the US and expect to have updated examples incorporated early next week in= a follow-up version.

--Kurt
--94eb2c09198a42d2460554ce6d09-- From nobody Fri Jul 21 06:17:50 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1223312F24E for ; Fri, 21 Jul 2017 06:17:49 -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=eudaemon.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROefj363ReeW for ; Fri, 21 Jul 2017 06:17:47 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B316131471 for ; Fri, 21 Jul 2017 06:17:47 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id x125so24501262ywa.0 for ; Fri, 21 Jul 2017 06:17:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eudaemon.net; s=dkey; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=tdx8UfXC3m1RSEZKiMUjSfNf5jsticZNvasOrnGpqD8=; b=Z2RI/GZ28UYLeB7FhXD4iZV51ra3+IRS6/1UTFYImEVJJJNi/PjADYxEiWoiVEHe9l /AZDlWE6NRQO7UgTunMrwrFAMnAOmtz9SR4op8VEPBj1CefgOfTLxvOgHC0C0I+TMAo/ kOvhG0rvqFIrNf5Y/XJPcbYCCXNKC9DfWbIIY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=tdx8UfXC3m1RSEZKiMUjSfNf5jsticZNvasOrnGpqD8=; b=JavirPjCrZQ2dHO1JCuY3+evTVgfRzyz0dfeRSPW5N180hyTRJxk7HFXW41yFCWlNT MqO00tLNIQ9wzGwTJOCKhs9tfoCzQgVw1+iGqJBT6pC7hr1MJ2ueQgVfjwCJ7w1yVcL8 W01GFm2iw5GXZ9BeHl8YE7Myizqounzvi0sy+29SKhCokuiP6rl8VVaputMvVGhija9E qPjkFiVnAoPCuuSASvhXghYF9cL4peT4VfxoVsQa6cpgGDsVHrX9A6hSlLknkcJaYNpF 3ODj/sinkR0eHns29D0w/PpOB8WpZ36qT8n8bgoz1YJr//7tCC49gKyMUb1qwQzkS7TF slBA== X-Gm-Message-State: AIVw112R0CZbbXhXIYVKvU2MjrbKMtqAip+QxE7csCVaJLnrhC9X624U kNqvGwJo0PuSWUEi X-Received: by 10.129.202.72 with SMTP id y8mr6068031ywk.338.1500643066503; Fri, 21 Jul 2017 06:17:46 -0700 (PDT) Received: from [192.168.103.47] ([162.255.170.6]) by smtp.gmail.com with ESMTPSA id s184sm1654478ywe.95.2017.07.21.06.17.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Jul 2017 06:17:45 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Tim Draegen In-Reply-To: <66a10b0b-8de0-02dc-257f-ee41cf3d9c4c@gmail.com> Date: Fri, 21 Jul 2017 09:17:43 -0400 Cc: "dmarc@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <8FE6DE8E-6ABF-4C6E-9C9F-984B0C066CF5@eudaemon.net> References: <66a10b0b-8de0-02dc-257f-ee41cf3d9c4c@gmail.com> To: Dave Crocker X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [dmarc-ietf] ARC Experimental goals X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 13:17:49 -0000 > On Jul 20, 2017, at 4:57 PM, Dave Crocker wrote: >=20 > ARC produces a /chain/ of signatures. There is essentially no = operational experience doing this in real time in the operational = Internet. We need to learn what dependencies and what fragilities are = relevant to its use. >=20 > Therefore, experimental experience with ARC needs to: >=20 > 1. Demonstrate use across a 'significant' range of different email = sending software, receiving software, mailing list packages, mailbox = operators and mailing list operators. >=20 > 2. Demonstrate robust survival of ARC signatures. >=20 > 3. Demonstrate useful error reporting behaviors. >=20 > 4. Demonstrate stable operational integration into mail filtering = engines, subject to a 'significant' array of usage policies -- or = demonstrate industry consensus on a small, stable set of policies. >=20 > When these demonstrations are made, it will be possible to write a = usage BCP that has rich and useful guidance for those wishing to deploy = ARC. Dave, are you saying the production of a rich and useful BCP could mark = the end of Experimental status? -=3D Tim From nobody Fri Jul 21 06:27:08 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12AAB1317D5 for ; Fri, 21 Jul 2017 06:27:07 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wN8OJqi8TvoZ for ; Fri, 21 Jul 2017 06:27:05 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCCB312EBF7 for ; Fri, 21 Jul 2017 06:27:05 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id e124so17345018oig.2 for ; Fri, 21 Jul 2017 06:27:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=vyTk9wtiCzHV5n2QC/LrIqfWwWpiKpErCL0h9iZ3rfw=; b=YXYg/pNijUFMpjAOreOkKJEW2hw8SHCjP1r4uuFuSxDNP4Cs/lMy2xiQJpcVdBVMGt uBuwrMp4LaqC8gt6Kms4Wgjy8E16B+o4xiqFNQ9XBV75YDDdruQtm0uqnmmimAc4Br0P g73GDrWAJYLmKH243EsmL/alDhuQQPrW9MV6v/C5scf5Anvn/dzlVmkc6vZhMxOI0ReD wI6JH3P8pSSkxpU2kBqyquLWlV/Cpxhyfm1jwAJabUYWeYUNG55vSY0dhQLEEUIUHgck 22e/u5/2ilHKGdDm5a9QKmMddQ2ZlDbRlKtnCb3vFcQM5YK23LWABPzYqPiFSnBrX94Z gtZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=vyTk9wtiCzHV5n2QC/LrIqfWwWpiKpErCL0h9iZ3rfw=; b=GM70f2rhS5ej1euvAA9TUMwjyBk4TDLwY3Uch6axWp1T4X4DLcjc1MYTgFiC2O1hPX u2BkMrayjxR8/lrHF6LfIUDQQ3i+VPevesaHiy8SvK8y38qCujORp6mDCgC/Pn10DSax b7w9asQXe3SRV7WFlB7b7c1TTgyOJgs63x3OXNX8Czw9DxenDOvDqgIv2uAo8wkWtJeO fNxlUc2iVfT2H+0mugD4d5av5bkG+KkBOoVP1Lwgnzf++p80LCsVMv0c3mu0Jj95wpa1 Rdg6xUP4tBIFT8vlo3/FoDlHhzJTMj66SC9ca5msMsRfeXto5jewCAHf0STfyMujjWtK nguQ== X-Gm-Message-State: AIVw112CKDaWIE7+EZyjGJJxpP3jVSNbBDgxLTK/OaqubIhrlWvwa18O 9E3gNwYXvJYJ7Ywv7oo= X-Received: by 10.202.168.145 with SMTP id r139mr1644563oie.147.1500643624905; Fri, 21 Jul 2017 06:27:04 -0700 (PDT) Received: from ?IPv6:2602:304:cda0:8800:494d:cfd0:fc39:3e7e? ([2602:304:cda0:8800:494d:cfd0:fc39:3e7e]) by smtp.gmail.com with ESMTPSA id d7sm1519781oia.10.2017.07.21.06.27.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Jul 2017 06:27:04 -0700 (PDT) To: Tim Draegen Cc: "dmarc@ietf.org" References: <66a10b0b-8de0-02dc-257f-ee41cf3d9c4c@gmail.com> <8FE6DE8E-6ABF-4C6E-9C9F-984B0C066CF5@eudaemon.net> From: Dave Crocker Message-ID: <11a0daf4-9937-6beb-8039-88764ec44d7d@gmail.com> Date: Fri, 21 Jul 2017 06:27:00 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <8FE6DE8E-6ABF-4C6E-9C9F-984B0C066CF5@eudaemon.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] ARC Experimental goals X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 13:27:07 -0000 On 7/21/2017 6:17 AM, Tim Draegen wrote: > Dave, are you saying the production of a rich and useful BCP could mark the end of Experimental status? Yes. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Jul 21 15:36:15 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9957812F3D0 for ; Fri, 21 Jul 2017 15:36:14 -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=eudaemon.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BfwWRVrnOCHi for ; Fri, 21 Jul 2017 15:36:13 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6534D128B8D for ; Fri, 21 Jul 2017 15:36:13 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id a12so29394313ywh.3 for ; Fri, 21 Jul 2017 15:36:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eudaemon.net; s=dkey; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9dChy/EoVQk3o7JVrVAGzI84Qwvd8xIQ/AhKF/tbKTs=; b=B6XK2UlDVXVBdPCGOGiVimYCCpULslecRjx7EeYg/ITEzf3ODa0qrajgY/CYg/gn/b CfGh/F8f4TB1u0unJbchiWSIftxAFB6GUZjdT85qVTxCP4hh4F4w0rwYzEJuae0cVF/m CkOisJH++lvHDXwyht01sfa6PV7EAw6k2/jHs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9dChy/EoVQk3o7JVrVAGzI84Qwvd8xIQ/AhKF/tbKTs=; b=QcjVVhjOn0wDc+NM+r9Sl6vYo6SvIG+/2lSTYpraa24p8/4v/AYAxIq0/ehLqLh/uV DGiSjVrehHQJo6XZ2goayQWQSdKSWeFD3aBx7c9S/iSSrjJjaBl/gAPSYsjkTuPmxg4Q NDh4LRTAoM5E7yMEkzpEOWIRTT8bF24EDsWDmBzpv8xiXhhaVCGkOpoEW7Tt+ESOZ8h5 dyPGJa+aO1IWOeQhBgq28uxqMgAsevWCwVOXjItQEvUkLsAP7wkbcTIw2P2p4sU+uXfL RSOzTC0BHTyMx3nWEXm8aHwASd8RbQwPopBqVnzd5/2CkwRHf5AGGYVKBDpAQXJo1few 3Fjg== X-Gm-Message-State: AIVw112HsWCbwKeGZHf42omNuCV1duBpwQXGRQFjd5hrGeei06REtgoE Thy6OgEcEBpt86xH X-Received: by 10.129.202.72 with SMTP id y8mr7379725ywk.338.1500676572644; Fri, 21 Jul 2017 15:36:12 -0700 (PDT) Received: from [192.168.0.30] (208-104-133-98.brvd.dsl.dyn.comporium.net. [208.104.133.98]) by smtp.gmail.com with ESMTPSA id y188sm2051687ywf.58.2017.07.21.15.36.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Jul 2017 15:36:12 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Tim Draegen In-Reply-To: <11a0daf4-9937-6beb-8039-88764ec44d7d@gmail.com> Date: Fri, 21 Jul 2017 18:36:11 -0400 Cc: "dmarc@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <08A58203-1CCD-4873-9BDB-505EBFCA1FB0@eudaemon.net> References: <66a10b0b-8de0-02dc-257f-ee41cf3d9c4c@gmail.com> <8FE6DE8E-6ABF-4C6E-9C9F-984B0C066CF5@eudaemon.net> <11a0daf4-9937-6beb-8039-88764ec44d7d@gmail.com> To: Dave Crocker X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [dmarc-ietf] ARC Experimental goals X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 22:36:14 -0000 > On Jul 21, 2017, at 9:27 AM, Dave Crocker wrote: >=20 > On 7/21/2017 6:17 AM, Tim Draegen wrote: >> Dave, are you saying the production of a rich and useful BCP could = mark the end of Experimental status? >=20 > Yes. Makes sense to me. Perhaps the WG should start collecting information as = new deployments are happening. Some deployers are already sharing. Why not pipe what is learned = directly into a BCP.. you know.. in real time? From nobody Fri Jul 21 18:51:13 2017 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C24031242F7; Fri, 21 Jul 2017 18:51:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dmarc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.57.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150068827075.20563.1861262041599311527@ietfa.amsl.com> Date: Fri, 21 Jul 2017 18:51:10 -0700 Archived-At: Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-08.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2017 01:51:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain-based Message Authentication, Reporting & Conformance WG of the IETF. Title : Authenticated Received Chain (ARC) Protocol Authors : Kurt Andersen Brandon Long Steven Jones Murray Kucherawy Filename : draft-ietf-dmarc-arc-protocol-08.txt Pages : 45 Date : 2017-07-21 Abstract: The Authenticated Received Chain (ARC) protocol creates a mechanism whereby a series of handlers of a message can conduct authentication of a message as it passes among them on the way to its destination, and record the status of that authentication at each step along the handling path, for use by the final recipient in making choices about the disposition of the message. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-protocol/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-08 https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-arc-protocol-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-arc-protocol-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Jul 22 00:26:42 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 085A6131BB3 for ; Sat, 22 Jul 2017 00:26:42 -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 xnxRnmU-AEtv for ; Sat, 22 Jul 2017 00:26:41 -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 14C74127010 for ; Sat, 22 Jul 2017 00:26:41 -0700 (PDT) Received: from [192.168.0.85] (assigned-77-78-82-082.casablanca.cz [77.78.82.82] (may be forged)) (authenticated bits=0) by segv.crash.com (8.14.5/8.14.5/cci-colo-1.6) with ESMTP id v6M7PuBh000192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Sat, 22 Jul 2017 00:26:05 -0700 (PDT) (envelope-from smj@crash.com) X-SenderID: Sendmail Sender-ID Filter v1.0.0 segv.crash.com v6M7PuBh000192 Authentication-Results: segv.crash.com; sender-id=permerror header.from=smj@crash.com; auth=pass (PLAIN); spf=permerror smtp.mfrom=smj@crash.com X-DKIM: OpenDKIM Filter v2.4.3 segv.crash.com v6M7PuBh000192 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=201506-2k; t=1500708366; bh=nveQkvIIPmIgiFoAdamtQYzfiEBNr4LFBI55VOEktBo=; h=Subject:To:References:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=yZ3+AhKdodFGt7VmLO/MNYpZFudzkZi6NG8Q784npGNtEmUC5RMOgQqClcTCwaWDo EwanV8iMqh0e3H7Gd10NTYVnEMyamhMMiHcmcTJ4xJShzEdqBuFlPMabjeX3urqoH1 Y2Jmy8CwNkKb1kt02lXa6M+FRLuXO0ApcN0eqbYU0VnHOnKyTqxtX8J8iwT3gyvRMu AMrB4hhJl3aQxTmDVe5W+1Ymtu29BJRZGImY4giLg60kYitk4DFKHFHq7lJIb2Ermd AYo5JSR7Pun6syWf9sQ8jWX58aCXc608hNneDnTQ9fWeNcL/AtMAe/ONfTSQydegzk O9+GqYoxERdEw== X-Authentication-Warning: segv.crash.com: Host assigned-77-78-82-082.casablanca.cz [77.78.82.82] (may be forged) claimed to be [192.168.0.85] To: dmarc@ietf.org References: <66a10b0b-8de0-02dc-257f-ee41cf3d9c4c@gmail.com> <8FE6DE8E-6ABF-4C6E-9C9F-984B0C066CF5@eudaemon.net> <11a0daf4-9937-6beb-8039-88764ec44d7d@gmail.com> <08A58203-1CCD-4873-9BDB-505EBFCA1FB0@eudaemon.net> From: Steven M Jones Message-ID: <3cf4c319-9d61-9369-bdf7-4e8d93ddd642@crash.com> Date: Sat, 22 Jul 2017 09:25:57 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0 MIME-Version: 1.0 In-Reply-To: <08A58203-1CCD-4873-9BDB-505EBFCA1FB0@eudaemon.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (segv.crash.com [72.52.75.15]); Sat, 22 Jul 2017 00:26:06 -0700 (PDT) Archived-At: Subject: Re: [dmarc-ietf] ARC Experimental goals X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2017 07:26:42 -0000 On 07/22/2017 12:36 AM, Tim Draegen wrote: > Why not pipe what is learned directly into a BCP.. you know.. in real time? Hmm, perhaps some kind of "feedback report" could be used... ;) From nobody Mon Jul 24 17:21:25 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D96B1296C9 for ; Mon, 24 Jul 2017 17:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSQMpPYTHVBu for ; Mon, 24 Jul 2017 17:21:22 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::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 04B8B128C81 for ; Mon, 24 Jul 2017 17:21:21 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id h199so42836643ith.0 for ; Mon, 24 Jul 2017 17:21:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=QbPxXbhm7x+Ez4UpY5V+b0VvThipedLQkr5qJoDjdZM=; b=XhratKnexHKIv9eIXoINhHKbTZAkZWkiK4hiudthNEoR7WT4z4MUYeVqo9zNKETucP cCkyqnTUTKWeYYDWVF6dWA5dh9yDmpWMaTZqrD6+DlW9LInyUR7deq1y0xGpL0fUUH9c xmHRBcaeeY3bfWApamPjoEZqsRXoJbxDTpmwiqWzW+fg7eCoyr1z/U0rulsI0kIDZqAa pMbBotn3urDqhRCeRVm1lRVHvynMAk1PhvdfdnEC0PvVSeKSVVxmYBQQddZNeTVOXOEM k7D/3CAuTcBg7Z7w48Md0XTeF/w0cl0J3FgkvhcWDUknYtGcQzjsUuSkDbjUNMi8uDE4 nePw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=QbPxXbhm7x+Ez4UpY5V+b0VvThipedLQkr5qJoDjdZM=; b=JsJtHPbau6oEi9oFWEhe0A7rhe7wtZEJ5rvGJj3kat//lsj3tslgyrVvCoap29gyXS albxPjgPhUDv+W40O6Tf7+WiXQNtnEXjIyNF8NtMT2yTZhlSRtxbH8xPReUlLOd+Gqr/ ViM+IxbQAQrD1LqtVHTzqWFOMd7SFXroJyEqcsQDMMTBXaA8OoMemNxsq9iBYtcBzI+9 qIOL25M5jBkqLcpw5WoEqjrCD0woYCmoJytbHXFmFPk0PKDxRO3/raLO/d5gJPOeDQGS j56IPqpngFkrUQ15OfaTgOihOkMUPKLcMkFUB/Dox21Q7NIS7Rw8MbnUwXTlUjhR+6X9 fzsQ== X-Gm-Message-State: AIVw1113gzVUa16JohEZOYeaZ/lWTQzIeTfmVqtOCZIK0+kDUhkg624/ 4MJAfER9XVzOl5WgFNpZ+FPvMdJErQ== X-Received: by 10.36.206.196 with SMTP id v187mr9241909itg.44.1500942081035; Mon, 24 Jul 2017 17:21:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.106.130 with HTTP; Mon, 24 Jul 2017 17:21:20 -0700 (PDT) From: Gene Shuman Date: Mon, 24 Jul 2017 17:21:20 -0700 Message-ID: To: dmarc@ietf.org Content-Type: multipart/alternative; boundary="94eb2c0e76f291965e0555194fc7" Archived-At: Subject: [dmarc-ietf] questions about section 5.1.1 of the new ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 00:21:24 -0000 --94eb2c0e76f291965e0555194fc7 Content-Type: text/plain; charset="UTF-8" Hi All, I'm going through the new draft. I definitely approve of the language changes, although some things wrt section 5.1.1 & the new data going into AAR's are unclear to me. So this is my best understanding, and it doesn't seem like it's right: 1. A message comes into an ADMD and does spf/dkim/etc checks & puts these into AR's as usual. At some point in there it performs an ARC validation step. First question, do the new ams1, as1, etc get added to the AR then? i.e do we get another other AR then, that looks like: Authentication-Resules: list.com; arc=pass ams1.d=domain1 ams1.s=selector1, as1.d=domain1 as1.d=selector1 Or are the additional fields only added in when the AAR is compiled? 2. The message is modified. 3. The messge is arc-sealed. All AR's(from list.com) are concatendated, and source.ip & header.s are added. Is header.s added to the dkim sections of the ARs that are getting concatenated? This is just for dkim signatures right? Is ARC code expected to parse this out of dkim signatures? Also, where does source.ip go? Into any SPF sections of the AR? Where does the ARC code get this information from? Are we expecting the earlier steps in the ADMD's processing pipeline to stick this info somewhere(in their AR's?) I'm fairly confused. Am I missing something? =Gene --94eb2c0e76f291965e0555194fc7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All, I'm going through the new draft.=C2=A0 I defin= itely approve of the language changes, although some things wrt section 5.1= .1 & the new data going into AAR's are unclear to me.

So this is my best understanding, and it doesn't seem like it'= ;s right:

1. A message comes into an ADMD and does= spf/dkim/etc checks & puts these into AR's as usual.=C2=A0 At some= point in there it performs an ARC validation step.=C2=A0 First question, d= o the new ams1, as1, etc get added to the AR then? =C2=A0i.e do we get anot= her other AR then, that looks like:

Authentication= -Resules: list.com; arc=3Dpass ams1.d=3Ddom= ain1 ams1.s=3Dselector1, as1.d=3Ddomain1 as1.d=3Dselector1

Or are the additional fields only added in when the AAR is compile= d?

2. The message is modified.

3. The messge is arc-sealed.=C2=A0 All AR's(from list.com) are concatendated, and source.ip & header.s a= re added.=C2=A0 Is header.s added to the dkim sections of the ARs that are = getting concatenated?=C2=A0 This is just for dkim signatures right?=C2=A0 I= s ARC code expected to parse this out of dkim signatures?

Also, where does source.ip go?=C2=A0 Into any SPF sections of the A= R?=C2=A0 Where does the ARC code get this information from? =C2=A0

Are we expecting the earlier steps in the ADMD's proce= ssing pipeline to stick this info somewhere(in their AR's?)
<= br>
I'm fairly confused.=C2=A0 Am I missing something?
<= div>
=3DGene
--94eb2c0e76f291965e0555194fc7-- From nobody Mon Jul 24 17:37:43 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 326ED129AD2 for ; Mon, 24 Jul 2017 17:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujHXQiF2ryQT for ; Mon, 24 Jul 2017 17:37:39 -0700 (PDT) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::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 B9C4512706D for ; Mon, 24 Jul 2017 17:37:39 -0700 (PDT) Received: by mail-ua0-x230.google.com with SMTP id 80so91306899uas.0 for ; Mon, 24 Jul 2017 17:37:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=rlypV6uY0Qnzvj56VSmX5sytGUO8Jl5b5qLSB3e0pV8=; b=LOhJ9oGZAziUM3sc7qHWUdfMyT+KtmME2E6cOSFo/oqcTJviq9Zx/CpZp3TdUZ5WMQ lK8Q4cWPxQHlkM636+fA6irdnMyVUI6mTLjTSOQ7UUKw8kRwaJowBeSJiQY1skQglyLB Lo4uvKapMb/RtIAc5CdIGr/RcHvWNVRNkbcgs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=rlypV6uY0Qnzvj56VSmX5sytGUO8Jl5b5qLSB3e0pV8=; b=qVzaZe3e8k38+IRfy8aB/FLaqQkGheJSyKIDGUF9OpX/qHL5x99s0wzAkxKCWcOECg WRyLVZl4luuwHOfKomuvCseV2VOJbtEhk83c6ZVALIRfQkUnt07MjWpRprKL9pJFNIaZ L20ExoWh/QJukokHX2t691CQzEF8fzMN1b7zV9CjGWjGsG18KoXa+8lcINOIPVV4HKvo 5k65IyYwHcMMGPbXJydxXokduYF3nFQxiMzBqyUt3WkbeXg0PDwcTBh358uMfChBD5kE OGAek9FEu4aFSLlWYtBpgRA9lpVFeueEQOMG6Kx5sZo49m0OLlgxo0xDB417aTDd2P0w RS/g== X-Gm-Message-State: AIVw111wSY2lj9jTRAVZDJNPaPauxcqzea3gBxYvEnJ4OBdElKX42n9u rWYzcU2sa+V11AmMmoIeH9hOiBGozJ+B X-Received: by 10.31.151.14 with SMTP id z14mr10075863vkd.3.1500943058740; Mon, 24 Jul 2017 17:37:38 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.176.26.39 with HTTP; Mon, 24 Jul 2017 17:37:38 -0700 (PDT) In-Reply-To: References: From: "Kurt Andersen (b)" Date: Mon, 24 Jul 2017 17:37:38 -0700 X-Google-Sender-Auth: wrZuKAPM9L9MXrrcGz8nDrgLlTY Message-ID: To: Gene Shuman Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a1141c972d83b880555198975" Archived-At: Subject: Re: [dmarc-ietf] questions about section 5.1.1 of the new ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 00:37:42 -0000 --001a1141c972d83b880555198975 Content-Type: text/plain; charset="UTF-8" On Mon, Jul 24, 2017 at 5:21 PM, Gene Shuman wrote: > So this is my best understanding, and it doesn't seem like it's right: > > 1. A message comes into an ADMD and does spf/dkim/etc checks & puts these > into AR's as usual. At some point in there it performs an ARC validation > step. First question, do the new ams1, as1, etc get added to the AR then? > That depends on whether the message as received bore ARCset-1 on receipt. If so, then the checking should record the needed info. > Or are the additional fields only added in when the AAR is compiled? > Maybe (how's that for being definitive?) - there's nothing which prevents you from sticking it in the "ingress A-R" (or any other header or offline store) and then it's up to you to consume it appropriately when sealing the message. 2. The message is modified. > > 3. The messge is arc-sealed. All AR's(from list.com) are concatendated, > and source.ip & header.s are added. Is header.s added to the dkim sections > of the ARs that are getting concatenated? This is just for dkim signatures > right? Is ARC code expected to parse this out of dkim signatures? > > Also, where does source.ip go? Into any SPF sections of the AR? Where > does the ARC code get this information from? > I think that source.ip makes the most sense within the SPF space, but it can go anywhere that you can find it when doing the sealing :-) > Are we expecting the earlier steps in the ADMD's processing pipeline to > stick this info somewhere(in their AR's?) > Yes, otherwise the info won't be available for inclusion in the ARC set upon egress. > I'm fairly confused. Am I missing something? > ARC relies upon an ADMD having some functional (secure) way to transmit information between ingress and egress with possible message changes in between. That has been one of the gaps in early implementations which I tried to address with more explicit language in section 5.3.1 ("the state of the ARC chain. . .when it arrived at the ADMD") and in the last paragraph of section 6 ("record the cv state for [use]. . .later. . .within the same trust boundary"). --Kurt --001a1141c972d83b880555198975 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Jul 24, 2017 at 5:21 PM, Gene Shuman <geneshuman@gmail.com><= /span> wrote:
So th= is is my best understanding, and it doesn't seem like it's right:

1. A message comes into an ADMD and does spf/dkim/e= tc checks & puts these into AR's as usual.=C2=A0 At some point in t= here it performs an ARC validation step.=C2=A0 First question, do the new a= ms1, as1, etc get added to the AR then? =C2=A0

That depends on whether the message as received bore ARCset= -1 on receipt. If so, then the checking should record the needed info.
=C2=A0=C2=A0
Or are the additional fields only added in when the AAR is compiled?
<= /div>

Maybe (how's that for being= definitive?) - there's nothing which prevents you from sticking it in = the "ingress A-R" (or any other header or offline store) and then= it's up to you to consume it appropriately when sealing the message.= =C2=A0

=
2. The message is modified.

3.= The messge is arc-sealed.=C2=A0 All AR's(from list.com) are concatendated, and source.ip & = header.s are added.=C2=A0 Is header.s added to the dkim sections of the ARs= that are getting concatenated?=C2=A0 This is just for dkim signatures righ= t?=C2=A0 Is ARC code expected to parse this out of dkim signatures?

Also, where does source.ip go?=C2=A0 Into any SPF section= s of the AR?=C2=A0 Where does the ARC code get this information from? =C2= =A0

I think that source.ip make= s the most sense within the SPF space, but it can go anywhere that you can = find it when doing the sealing :-)=C2=A0
=C2=A0
Are we expecting the earlier steps= in the ADMD's processing pipeline to stick this info somewhere(in thei= r AR's?)

Yes, otherwise= the info won't be available for inclusion in the ARC set upon egress.<= /div>
=C2=A0
=
I'm fairly confused.=C2=A0 Am I missing something?
=

ARC relies upon an ADMD having some = functional (secure) way to transmit information between ingress and egress = with possible message changes in between. That has been one of the gaps in = early implementations which I tried to address with more explicit language = in section 5.3.1 ("the state of the ARC chain. . .when it arrived at t= he ADMD") and in the last paragraph of section 6 ("record the cv = state for [use]. . .later. . .within the same trust boundary").
<= div>
--Kurt

--001a1141c972d83b880555198975-- From nobody Mon Jul 24 18:06:26 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0471012702E for ; Mon, 24 Jul 2017 18:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ERL-IGJXeCMn for ; Mon, 24 Jul 2017 18:06:23 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::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 23825124BE8 for ; Mon, 24 Jul 2017 18:06:23 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id h199so43193871ith.0 for ; Mon, 24 Jul 2017 18:06:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GRc8XZXPdnNYjRp5zOxuZ0SwF+YqNPrcbKxyGXNm9Kw=; b=Nl+7DWyG6CzbZ4KwByDZHoScR4Cnx0crRVna4M4/w00FGfIWtCXSSxA1NR5WvJr8IG Z1sgqtKwVK90AgDfFLj4VtVN8BwID+PTVlbZMnNtQbRL964t69YHEA16bUm1oRISUCy4 g5dxEFPKsX3k5MNGXAD3D7xr8D3XZqSr/84jfMYnO6yQNBkELSJ39DXAZ1EDAp2kbYnE N7oYeGq6gMFeSh3pQjuLQZkifB3kMjDGqZ4AWDMZTAdNwb8rmeuNdSpuInwVZ9Tmwqlh 4bJmk5+f3A9fDY2rqCw8Tl5AtUGaj0ImdlVrcA8BzdJabWqd2dXd18hXYBxVe9qNvot0 yBtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GRc8XZXPdnNYjRp5zOxuZ0SwF+YqNPrcbKxyGXNm9Kw=; b=YeWXb5dGNgtjEXZS1stHe4HOraty98OeNMbU4KyP0IkjADzgWeSgDys3DAzt5kAH2C OPvsQicvh8F+oUcmTsL9M6v+FHzwmgPMzqpdRCvfc9ALGpH/lSWM4CscJfZ0jfgQVi0J miH2xdO3+Ecf4vtlU8ffxOd0rfj0Ue0h0tCp+aXyedIkgpvwy1V7/bbGh2vco8849GUE /t+DDcEWWKa9DVHVGpbxpNZCkhp6GEV5T+a9tALENNKxeLng8LZ2w4p4X6N4wANeiZgH gTYj4MHsysW6ajoXluyNpxcf1POcV3aNYzEPJPUSIVZwcAHhdT5jqraNEtlPEYex7Pny EyEw== X-Gm-Message-State: AIVw110H6vnx6S0wGgzWYL4R5Bq7ZtB82nncLGPQqlhMPFBym0SyaV35 gkz4/RW75E7GfKeh44z4xe9ifOFi+A== X-Received: by 10.36.123.86 with SMTP id q83mr7518945itc.90.1500944782450; Mon, 24 Jul 2017 18:06:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.106.130 with HTTP; Mon, 24 Jul 2017 18:06:21 -0700 (PDT) In-Reply-To: References: From: Gene Shuman Date: Mon, 24 Jul 2017 18:06:21 -0700 Message-ID: To: "Kurt Andersen (b)" Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a11473e4295e6b8055519f0ae" Archived-At: Subject: Re: [dmarc-ietf] questions about section 5.1.1 of the new ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 01:06:25 -0000 --001a11473e4295e6b8055519f0ae Content-Type: text/plain; charset="UTF-8" OK thanks. So if I understanding this correctly, we're suggesting, within the ARC protocol, that the ways in which both DKIM & SPF stamp their info into AR's is changed, at least when they're part of an ARC aware pipeline? Or is this stamping outside of the scope of the SPF & DKIM rfcs & left up to implementors? What are the chances we can actually get these changes into popular DKIM & SPF libraries? That seems necessary, right? Unless some other part of the ADMD is going to go in, and after the fact add this info to the AR headers? Who's going to write the software/milters/etc that do that? Or am I missing something? =Gene On Mon, Jul 24, 2017 at 5:37 PM, Kurt Andersen (b) wrote: > On Mon, Jul 24, 2017 at 5:21 PM, Gene Shuman wrote: > >> So this is my best understanding, and it doesn't seem like it's right: >> >> 1. A message comes into an ADMD and does spf/dkim/etc checks & puts these >> into AR's as usual. At some point in there it performs an ARC validation >> step. First question, do the new ams1, as1, etc get added to the AR then? >> > > That depends on whether the message as received bore ARCset-1 on receipt. > If so, then the checking should record the needed info. > > >> Or are the additional fields only added in when the AAR is compiled? >> > > Maybe (how's that for being definitive?) - there's nothing which prevents > you from sticking it in the "ingress A-R" (or any other header or offline > store) and then it's up to you to consume it appropriately when sealing the > message. > > 2. The message is modified. >> >> 3. The messge is arc-sealed. All AR's(from list.com) are concatendated, >> and source.ip & header.s are added. Is header.s added to the dkim sections >> of the ARs that are getting concatenated? This is just for dkim signatures >> right? Is ARC code expected to parse this out of dkim signatures? >> >> Also, where does source.ip go? Into any SPF sections of the AR? Where >> does the ARC code get this information from? >> > > I think that source.ip makes the most sense within the SPF space, but it > can go anywhere that you can find it when doing the sealing :-) > > >> Are we expecting the earlier steps in the ADMD's processing pipeline to >> stick this info somewhere(in their AR's?) >> > > Yes, otherwise the info won't be available for inclusion in the ARC set > upon egress. > > >> I'm fairly confused. Am I missing something? >> > > ARC relies upon an ADMD having some functional (secure) way to transmit > information between ingress and egress with possible message changes in > between. That has been one of the gaps in early implementations which I > tried to address with more explicit language in section 5.3.1 ("the state > of the ARC chain. . .when it arrived at the ADMD") and in the last > paragraph of section 6 ("record the cv state for [use]. . .later. . .within > the same trust boundary"). > > --Kurt > > --001a11473e4295e6b8055519f0ae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
OK thanks.=C2=A0 So if I understanding this correctly, we&= #39;re suggesting, within the ARC protocol, that the ways in which both DKI= M & SPF stamp their info into AR's is changed, at least when they&#= 39;re part of an ARC aware pipeline?=C2=A0 Or is this stamping outside of t= he scope of the SPF & DKIM rfcs & left up to implementors?=C2=A0 Wh= at are the chances we can actually get these changes into popular DKIM &= ; SPF libraries?=C2=A0 That seems necessary, right?=C2=A0 Unless some other= part of the ADMD is going to go in, and after the fact add this info to th= e AR headers?=C2=A0 Who's going to write the software/milters/etc that = do that?=C2=A0 Or am I missing something?

=3DGene
<= /div>

On Mon, Jul = 24, 2017 at 5:37 PM, Kurt Andersen (b) <kboth@drkurt.com> wro= te:
On Mon, Jul 24, 2017 at = 5:21 PM, Gene Shuman <geneshuman@gmail.com> wrote:
So this is my best unders= tanding, and it doesn't seem like it's right:

<= div>1. A message comes into an ADMD and does spf/dkim/etc checks & puts= these into AR's as usual.=C2=A0 At some point in there it performs an = ARC validation step.=C2=A0 First question, do the new ams1, as1, etc get ad= ded to the AR then? =C2=A0

That depends on whether the message as received bore ARCset-1 on receipt= . If so, then the checking should record the needed info.
=C2=A0=C2=A0
Or are the additional fields only added in when the AAR is compiled?=

Maybe (how's th= at for being definitive?) - there's nothing which prevents you from sti= cking it in the "ingress A-R" (or any other header or offline sto= re) and then it's up to you to consume it appropriately when sealing th= e message.=C2=A0

2. The message is modified.
<= /div>

3. The messge is arc-sealed.=C2=A0 All AR's(fr= om list.com) are concaten= dated, and source.ip & header.s are added.=C2=A0 Is header.s added to t= he dkim sections of the ARs that are getting concatenated?=C2=A0 This is ju= st for dkim signatures right?=C2=A0 Is ARC code expected to parse this out = of dkim signatures?

Also, where does source.ip go?= =C2=A0 Into any SPF sections of the AR?=C2=A0 Where does the ARC code get t= his information from? =C2=A0

=
I think that source.ip makes the most sense within the SPF space, but = it can go anywhere that you can find it when doing the sealing :-)=C2=A0
=C2=A0
Are we expecting the earlier steps in the ADMD's process= ing pipeline to stick this info somewhere(in their AR's?)

Yes, otherwise the info won't= be available for inclusion in the ARC set upon egress.
=C2=A0
I'm fairly confused.=C2=A0 Am I missing something?

ARC relies upon an ADMD having = some functional (secure) way to transmit information between ingress and eg= ress with possible message changes in between. That has been one of the gap= s in early implementations which I tried to address with more explicit lang= uage in section 5.3.1 ("the state of the ARC chain. . .when it arrived= at the ADMD") and in the last paragraph of section 6 ("record th= e cv state for [use]. . .later. . .within the same trust boundary").

--Ku= rt


--001a11473e4295e6b8055519f0ae-- From nobody Tue Jul 25 08:06:00 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73C7F13167B for ; Tue, 25 Jul 2017 08:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APX5jZBiGVxv for ; Tue, 25 Jul 2017 08:05:56 -0700 (PDT) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE469127B60 for ; Tue, 25 Jul 2017 08:05:56 -0700 (PDT) Received: by mail-ua0-x229.google.com with SMTP id q25so86518576uah.1 for ; Tue, 25 Jul 2017 08:05:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=D54l6k/X+ng36umywZAwZ6fAKzPSASpuRIUhkNYsYNM=; b=Kn8ueoETvIj/loyn0/M17fRBfFCObGMK7EakHzyjAwXOKniqE1KTaNOdCEf82rK8x9 A5nhgghia/sU4zoUtR7JQk5je+z99aih2ysipicWG0ccl+tHcbsBu+wjd/txIc/K3yhp M2/W81x4zMYlPLHTZYIujazQk2/AT4Yaz/qBA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=D54l6k/X+ng36umywZAwZ6fAKzPSASpuRIUhkNYsYNM=; b=Sne+nr2OKIVsklxXMT49r/Dpvrf4NElgWeJshZWTlGZs10fTO7I11vfbQ+tvJ1uLUS 95buvNvThs+kXZ1z964xgqJgCwNc+i7zjU0beBfOl/n6UsQXqycc8yqmRh31VEWZ0ANn DCKAkGW3mPVGiO/AkCAVN3RGMMf/hwWSNd4maX5JzcNJa1JUUzVrFh0n6jXwpcSxd10c 2p3pJP3kNYz0EIq+7ZqAujfM4zEGkRKfCDNGAoxEshR1bgEew7+h8oDD8GWWIATVT5be jQRAUcSqtsu9AgzxyvKVUtS787kbSjIuJU79V3l3iEZnRrVWk4nEGM8AMPqpfR0rGQOT SVHQ== X-Gm-Message-State: AIVw113UFzb44QPejx220MDHPwAECKh2zrJ8gWwn/cHUAemeR/jQ9ldw 982GGSam2LTDJw2Pi3QG68oRSliHLxRt7Uo= X-Received: by 10.31.189.133 with SMTP id n127mr3803647vkf.45.1500995155333; Tue, 25 Jul 2017 08:05:55 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.176.26.39 with HTTP; Tue, 25 Jul 2017 08:05:54 -0700 (PDT) In-Reply-To: References: From: "Kurt Andersen (b)" Date: Tue, 25 Jul 2017 08:05:54 -0700 X-Google-Sender-Auth: 5aHVYHCyYBXsaApPTGsezF4ubuM Message-ID: To: Gene Shuman Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a114db3c40b2820055525ab85" Archived-At: Subject: Re: [dmarc-ietf] questions about section 5.1.1 of the new ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 15:05:58 -0000 --001a114db3c40b2820055525ab85 Content-Type: text/plain; charset="UTF-8" On Mon, Jul 24, 2017 at 6:06 PM, Gene Shuman wrote: > OK thanks. So if I understanding this correctly, we're suggesting, within > the ARC protocol, that the ways in which both DKIM & SPF stamp their info > into AR's is changed, at least when they're part of an ARC aware pipeline? > Or is this stamping outside of the scope of the SPF & DKIM rfcs & left up > to implementors? What are the chances we can actually get these changes > into popular DKIM & SPF libraries? That seems necessary, right? Unless > some other part of the ADMD is going to go in, and after the fact add this > info to the AR headers? Who's going to write the software/milters/etc that > do that? Or am I missing something? > > =Gene > I don't necessarily see this as telling the DKIM/SPF libraries anything per se (because that is out of scope). I do think that we have some influence over DMARC (notice the WG name :-) ) but we also don't have any official influence over the mandatory A-R content as defined in RFC7601. I think that we can suggest mechanisms for operators to use, subject to their internal architectures and that A-R and its feeder systems are a fairly natural target (or ARC sealing upon ingress and putting the enhanced content directly into the AAR). In any case, DMARC reporting will have to be able to find this information for reports generated past the first mediator. I think that this is the natural consequence of the threads that we've been having regarding getting source debugging information into the DMARC reports on mediated mail flows. Did you have something different in mind? --Kurt --001a114db3c40b2820055525ab85 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Jul 24, 2017 at 6:06 PM, Gene Shuman <geneshuman@gmail.com><= /span> wrote:
OK thanks.= =C2=A0 So if I understanding this correctly, we're suggesting, within t= he ARC protocol, that the ways in which both DKIM & SPF stamp their inf= o into AR's is changed, at least when they're part of an ARC aware = pipeline?=C2=A0 Or is this stamping outside of the scope of the SPF & D= KIM rfcs & left up to implementors?=C2=A0 What are the chances we can a= ctually get these changes into popular DKIM & SPF libraries?=C2=A0 That= seems necessary, right?=C2=A0 Unless some other part of the ADMD is going = to go in, and after the fact add this info to the AR headers?=C2=A0 Who'= ;s going to write the software/milters/etc that do that?=C2=A0 Or am I miss= ing something?

=3DGene

I d= on't necessarily see this as telling the DKIM/SPF libraries anything pe= r se (because that is out of scope). I do think that we have some influence= over DMARC (notice the WG name :-) ) but we also don't have any offici= al influence over the mandatory A-R content as defined in RFC7601. I think = that we can suggest mechanisms for operators to use, subject to their inter= nal architectures and that A-R and its feeder systems are a fairly natural = target (or ARC sealing upon ingress and putting the enhanced content direct= ly into the AAR). In any case, DMARC reporting will have to be able to find= this information for reports generated past the first mediator.
=
I think that this is the natural consequence of the threads = that we've been having regarding getting source debugging information i= nto the DMARC reports on mediated mail flows. Did you have something differ= ent in mind?

--Kurt=C2=A0
--001a114db3c40b2820055525ab85-- From nobody Tue Jul 25 09:14:59 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E82EF129A9F for ; Tue, 25 Jul 2017 09:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 9hoacs84wJO7 for ; Tue, 25 Jul 2017 09:14:57 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22DB3131D15 for ; Tue, 25 Jul 2017 09:14:56 -0700 (PDT) Received: from [10.131.108.30] (mobile-166-170-50-149.mycingular.net [166.170.50.149]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id E34A4C4005E; Tue, 25 Jul 2017 11:14:54 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1500999295; bh=iXlEHfdAtI6ROCTUIFOcUml4Xr1L/8dVc8c7M1EcaCI=; h=Date:In-Reply-To:References:Subject:To:From:From; b=rSxhsWoVrRIm+60basGgurKP+J+OnfDe2tiL2EWJUeqnx6NTYLtJdlM/qamk/JOiH di7P4V2XmrgBA4LywyD5whn+zTGXsBKJgGJaCU40liVXsJLXgMORdBcKC6OAjz9sN3 GhCu9GkGNTu8LjADJM1EIsNlXD5OJM9gzG7tLVm8= Date: Tue, 25 Jul 2017 16:14:52 +0000 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dmarc@ietf.org From: Scott Kitterman Message-ID: Archived-At: Subject: Re: [dmarc-ietf] questions about section 5.1.1 of the new ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 16:14:59 -0000 On July 25, 2017 8:05:54 AM PDT, "Kurt Andersen (b)" = wrote: >On Mon, Jul 24, 2017 at 6:06 PM, Gene Shuman >wrote: > >> OK thanks=2E So if I understanding this correctly, we're suggesting, >within >> the ARC protocol, that the ways in which both DKIM & SPF stamp their >info >> into AR's is changed, at least when they're part of an ARC aware >pipeline? >> Or is this stamping outside of the scope of the SPF & DKIM rfcs & >left up >> to implementors? What are the chances we can actually get these >changes >> into popular DKIM & SPF libraries? That seems necessary, right?=20 >Unless >> some other part of the ADMD is going to go in, and after the fact add >this >> info to the AR headers? Who's going to write the >software/milters/etc that >> do that? Or am I missing something? >> >> =3DGene >> > >I don't necessarily see this as telling the DKIM/SPF libraries anything >per >se (because that is out of scope)=2E I do think that we have some >influence >over DMARC (notice the WG name :-) ) but we also don't have any >official >influence over the mandatory A-R content as defined in RFC7601=2E I think >that we can suggest mechanisms for operators to use, subject to their >internal architectures and that A-R and its feeder systems are a fairly >natural target (or ARC sealing upon ingress and putting the enhanced >content directly into the AAR)=2E In any case, DMARC reporting will have >to >be able to find this information for reports generated past the first >mediator=2E > >I think that this is the natural consequence of the threads that we've >been >having regarding getting source debugging information into the DMARC >reports on mediated mail flows=2E Did you have something different in >mind? > >--Kurt Insisting that all results from an ADMD for SPF, DKIM, and DMARC be collap= sed into a single AR header field is a huge change from the way AR works to= day=2E AR was designed for each mechanism to be able to add new informatio= n about its results=2E Yes, AR has, from the beginning, supported integrating multiple results in= to a single field and some do it, but requiring is an entirely different th= ing=2E What this would mean is that an ARC participant would have to remove and c= onsolidate multiple fields on receipt (the original sender has no requireme= nt to be ARC aware AIUI)=2E If I'm understanding correctly, this is not a good idea=2E ARC should con= sume AR fields just like everyone else=2E Scott K From nobody Tue Jul 25 09:22:16 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71AE2131D18 for ; Tue, 25 Jul 2017 09:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fUgCPp8ZnFlc for ; Tue, 25 Jul 2017 09:22:13 -0700 (PDT) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::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 738F7131D15 for ; Tue, 25 Jul 2017 09:22:13 -0700 (PDT) Received: by mail-ua0-x230.google.com with SMTP id d29so97357954uai.2 for ; Tue, 25 Jul 2017 09:22:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=oFCxIOgefm8n4pgnHCFDqtAat3MRT91Eshga4qQNX9A=; b=AO9mBWL0gyrAjd7VZ3tCLFIsA/i5E5Ft4xOM0el3UYUI+6IcB0ljtcRoBESX9QjGTC 1ReXFEJ4l849qWnKq5khOT3DeIvOm9fqxFapAVR89Pgs2QlfqTBHjW0ZGBlhKFs3VJsg ko14qvkJApPMAObtKe+CoXIhhN72PiZcbvIeg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=oFCxIOgefm8n4pgnHCFDqtAat3MRT91Eshga4qQNX9A=; b=JsXcX+t2uO5Oo+HibA6bw1L2VatGIazDuyUvNEhFRplx7Dwve3Yum/Ln/nRWvaI0Ig w3eygpfV2Ok1ycjzWHqJCzFT7tupQN41FRi2MwDO5eXb/qPrPb614Rbm2839JHLt96RG MRM2Pbnmv1JB0bLS9BrUViTeTrLboPKcjAEGXydVgvd5LU5kGiVNOzu/gAsf5u3XoX0y t3L/+SRYP1wIEhcIFAWbNHxBk/ujCckaMQ0/3qu9bUCvoQgPKTxkMQV/tlo9TR6u6OXC wZaOXqhboWq61a0EWG2VDdnFnXbd8cAFvmA4fRL96XwT4TtuCeS1D66s/z0puT7ub5hM 33AQ== X-Gm-Message-State: AIVw111GbPquplJpdeTA7kysPjTZx6I9dvphxNyxeJkVGqqfMBLKSZ25 or2ZKDuqE8pxoFmfTung3/YMY9a6J7zqk3Y= X-Received: by 10.159.48.8 with SMTP id h8mr11639256uab.196.1500999732357; Tue, 25 Jul 2017 09:22:12 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.176.26.39 with HTTP; Tue, 25 Jul 2017 09:22:11 -0700 (PDT) In-Reply-To: References: From: "Kurt Andersen (b)" Date: Tue, 25 Jul 2017 09:22:11 -0700 X-Google-Sender-Auth: n0WvogU2XZxysBUaXQGx2pwqe-0 Message-ID: To: Scott Kitterman Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="f403045dce5edb5d33055526bbd8" Archived-At: Subject: Re: [dmarc-ietf] questions about section 5.1.1 of the new ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 16:22:15 -0000 --f403045dce5edb5d33055526bbd8 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 25, 2017 at 9:14 AM, Scott Kitterman wrote: > > Insisting that all results from an ADMD for SPF, DKIM, and DMARC be > collapsed into a single AR header field is a huge change from the way AR > works today. AR was designed for each mechanism to be able to add new > information about its results. > There is no requirement to do so. The only thing is that for the AAR, all of the *locally trustworthy* AR headers get collapsed into a single AAR. > What this would mean is that an ARC participant would have to remove and > consolidate multiple fields on receipt (the original sender has no > requirement to be ARC aware AIUI). > An ARC participant should not, upon ingress, pay any heed to AR records that might have been put there by previous ADMDs so I'm not quite sure what you are referring to (maybe the language that I used was unclear?) > If I'm understanding correctly, this is not a good idea. ARC should > consume AR fields just like everyone else. > Maybe you're thinking of ARC signing on *egress*? Somehow, the signing instance needs to know about the state of the authentication upon ingress to the ADMD. AR may work, or may not - it depends on the operator's implementation. I know of some MTAs that strip AR records without a means to tell it which ones to leave alone. If those live within the internal pathway, then AR is not a workable approach for communication from ingress to egress. --Kurt --f403045dce5edb5d33055526bbd8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Jul 25, 2017 at 9:14 AM, Scott Kitterman <sklist@kitterman.com= > wrote:
=

Insisting that all results from an ADMD for SPF, DKIM, and DMAR= C be collapsed into a single AR header field is a huge change from the way = AR works today.=C2=A0 AR was designed for each mechanism to be able to add = new information about its results.

Ther= e is no requirement to do so. The only thing is that for the AAR, all of th= e *locally trustworthy* AR headers get collapsed into a single AAR.
=C2=A0
What this would mean is that = an ARC participant would have to remove and consolidate multiple fields on = receipt (the original sender has no requirement to be ARC aware AIUI).
<= /blockquote>

An ARC participant should not, upon ingress= , pay any heed to AR records that might have been put there by previous ADM= Ds so I'm not quite sure what you are referring to (maybe the language = that I used was unclear?)
=C2=A0
If I'm understanding correctly, this is not a good idea.=C2=A0 ARC = should consume AR fields just like everyone else.

=
Maybe you're thinking of ARC signing on *egress*? Somehow, t= he signing instance needs to know about the state of the authentication upo= n ingress to the ADMD. AR may work, or may not - it depends on the operator= 's implementation. I know of some MTAs that strip AR records without a = means to tell it which ones to leave alone. If those live within the intern= al pathway, then AR is not a workable approach for communication from ingre= ss to egress.

--Kurt

--f403045dce5edb5d33055526bbd8-- From nobody Tue Jul 25 10:00:33 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3620131E05 for ; Tue, 25 Jul 2017 10:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=JaZBoV0Q; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=HkqXsOM3 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 T9wDQJgwQl2I for ; Tue, 25 Jul 2017 10:00:31 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 122D3131E0A for ; Tue, 25 Jul 2017 10:00:30 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 832BD209EE for ; Tue, 25 Jul 2017 13:00:29 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Tue, 25 Jul 2017 13:00:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=bCE5JXUwlL89mij+bdn085UrOf9S9Zp+iGKHRvO1Rvk=; b=JaZBoV0Q AmPFNHfX4Ha3UrDj/Ko97Em0g/1KBXR9r9L8ZAtiZ3iWTrdgsTchCCAk7SobJUD1 oG3VtkaeqzEBj7POQ0DWLBbH4++6rgAAOVhDdjgH83hL2IANigri9RVcivxPyBFH wEtdxDOCvOJpD0UxyDFrfEw076eH6yXPi/4gSCmgp5d0RGi1oQgOBFFULggrd0TH Ci22cQqC63PaLj7d7w8pSADOjel19QU/Dpo9L29nyesaZoejZDiwg8zkKItsuETu eenP6ih+oicVw+RdYbrp5KqpUj+UcxDhTnj9jAzb7vLcYgjHJiN/qgMF3qxCegKG EwLtiRdW2WOnOA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=bCE5JXUwlL89mij+bdn085UrOf9S9 Zp+iGKHRvO1Rvk=; b=HkqXsOM3jfE/Afg0DASSMpP3lT/bDLz/drqE3SRFTt2jd 1Wg4Bt2MJoCfKHzXYq1MJq5XmSidvF0pwrglFBRbC7yvxRE/ylbyAfFxZxqZnAzu rEHJjDHFYInx3sBQLLfOqPPT6r9IPk1MZMinvgMUU/4zv6jOodMsc85zr2YB3lya vN6WhrX4MFywasi8wk4qp2FKdYtrfzB2MxBJ+wb4mdrxwll4jXc15s+J+RaRL7IJ 746A2xJxhlsgXmMK2x9YaeX8kk2owzADgyc3J2Qnr1LteWI4JQ+Vpgm7VRUS8rvU QbEhEf+ps4dJ/l6ULV6v/FW4HqW2sQklt7GoNk4Gg== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 5C9DC9E28E; Tue, 25 Jul 2017 13:00:28 -0400 (EDT) Message-Id: <1501002028.380815.1052223552.1E89BD5D@webmail.messagingengine.com> From: Alexey Melnikov To: dmarc@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-c8af44bc Date: Tue, 25 Jul 2017 18:00:28 +0100 Archived-At: Subject: [dmarc-ietf] Review of draft-ietf-dmarc-arc-protocol-07 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 17:00:32 -0000 I've noticed that you've posted draft-ietf-dmarc-arc-protocol-08, so some of the issues identified below might no longer be relevant: 1) The new abstract doesn't even use the word "email". This needs to be fixed, because otherwise it is not possible to determine that this is related to email or DKIM from reading the abstract. The current abstract: The Authenticated Received Chain (ARC) protocol creates a mechanism whereby a series of handlers of a message can conduct authentication suggestion to insert "email" before "message" above. of a message as it passes among them on the way to its destination, and record the status of that authentication at each step along the handling path, for use by the final recipient in making choices about the disposition of the message. It might also make sense to mention DKIM and DMARC (a la original text). So I suggest to add back the following sentence from -06: Changes in the message that might break DKIM can be identified through the ARC set of header fields. But otherwise the new Abstract text is an improvement as far as people not familiar with ARC are concerned. 2) I liked "Primary Design Criteria" (section 2.1) from -06. Maybe add it back as an Appendix? It is not important for new readers, but might be of interest to more advanced readers. 3) In 5.1, first para now reads: The ARC-Authentication-Results header field is defined. It is syntactically and semantically identical to an Authentication-Results header field [RFC7601] (A-R), as is the mechanism by which it is constructed, with the following exception: I think the statement "syntactically and semantically identical" is incorrect, because the value is prefixed with "i=". I think this needs to be reworded. And adding ABNF here would resolve any remaining confusion. The instance identifier MUST be separated from the rest of the Authentication-Results value contents with a semi-colon (';', 0x3b). "Instance" is separated by ";", but its syntax in section 4 already includes terminating ";". I think you need to clarify that only one ";" is separating instance from the rest. Or alternatively just remove this sentence. 4) In 5.3.2, first paragraph: I don't think saying that ARC-Seal is "encryption" is correct, I think you should use the word "signature" here. 5). In 6, step 4.7 (I think it is 4.6 in -08): mentioning here what happens on failure to retrieve data from DNS would be good. A forward reference to Section 9.3 is probably sufficient here. 6). In 9.5 (I think it is 9.6 in -08): should the document formally register the "arc" Authentication-Results method in the IANA Considerations? 7) I am being very confused by whether subsections of 9.5 (9.6) talk about XML reporting or Authentication-Results header field. Section 9.5 seems to be very clear that you are talking about Authentication-Results, but subsections seem to talk about XML reporting format. I couldn't understand 9.5.1 without reading 9.5.2. I think you should add tag names (e.g. "ams") somewhere in 9.5.1. Best Regards, Alexey From nobody Tue Jul 25 12:31:43 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17BEB131DFE for ; Tue, 25 Jul 2017 12:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id prDJe16ruYzX for ; Tue, 25 Jul 2017 12:31:40 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D65912EBF4 for ; Tue, 25 Jul 2017 12:31:40 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id m88so51079239iod.2 for ; Tue, 25 Jul 2017 12:31:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PTIy98AGzohz84pLx+d0sb8LDN6klcA5HYdrQtgGIVg=; b=E07blz2e3bJ8FFauJjfDYYNtgBF6plvQV9IaskyRbgMa9RhmWgQv1bVVppkZJSXR1C laaR/iBM1TJuHaI/1XfmxR2esCgzW5Dd3x9kUGDBTgNxt0W6psVX4CiKfB5D5GBAyMDR YUWHdztyzMzkznVgk7y+WNS1/PL6XfTXqG0OB7X99TR4mgjaBhPzOqNqZD7w8EiiqHk9 ICcnMu7tiVaBqZ1JLsHg5n1G+0RniZZAVRieyIwefs1AxKqPn7sUeB1WTb/B16XGFvCe KYq/1DytcrgNaULhWYAawxw1rwULXbtHqkJ59CU8gO9FTOJeXffKqeu3wEt7hWRRhztZ 371w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PTIy98AGzohz84pLx+d0sb8LDN6klcA5HYdrQtgGIVg=; b=t0O0jS16afGXf3PEHBXCgjLW15hJAP5t0dtSckQNs7wERPG+6VEFh+XXEzBJzuTmuv ReFEcBBDFx7xkCejbs3kS6khDcMjrN5kIv8nL6d6romcbNpYFRguCZ9O8OtoPpRhFYiH pWuawtxH5dP54Q6bS+7v6+rOIvn9BNNEv/JnwEd8wKzvdh0hutm/TokNtr7h/HkCsYPb CNB8EnJQLaSwsOqtXgwYJc71ORjxfuUhBD/4dAx2dDmHhJkDuQLeIP61E+pWjvHXN17Q HvZNq471C4GK5HTG7ie8uPmttOJwxcZDKF5oGZL0Y3KKHqCBMPQWZIPW+cZv0jMEvaP9 1F3g== X-Gm-Message-State: AIVw110uZo+Px2dFRqYZ/kmd8czWI5MdsPKW7hZTUmUKFDNwt5emFwM4 Vp9sY31ppvDe3i9wrxK2q9X9vz/S4Q== X-Received: by 10.107.184.6 with SMTP id i6mr20064291iof.288.1501011099649; Tue, 25 Jul 2017 12:31:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.106.130 with HTTP; Tue, 25 Jul 2017 12:31:38 -0700 (PDT) In-Reply-To: References: From: Gene Shuman Date: Tue, 25 Jul 2017 12:31:38 -0700 Message-ID: To: "Kurt Andersen (b)" Cc: Scott Kitterman , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0769fa660d5f055529618b" Archived-At: Subject: Re: [dmarc-ietf] questions about section 5.1.1 of the new ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 19:31:43 -0000 --94eb2c0769fa660d5f055529618b Content-Type: text/plain; charset="UTF-8" So I think I'm still missing something. Let's imagine an ADMD setup in something like the following fashion: inbound -> policyspf(or some other spf check) -> OpenDKIM -> OpenDMARC -> OpenARC Validation -> mailing list software -> OpenArc Signature -> outbound. Or something like this. Lets say policyspf, OpenDKIM, OpenDMARC, OpenARC, all stamp the standard info into various AR headers on ingress. On egress, in the OpenARC signature milter, we then consolidate all AR's into the AAR. In this stage we also need source.ip & header.s for DKIM signatures. Where is this information coming from? Who is recording the source.ip in this chain? It's not policy-spf, or anybody further down the chain, as I don't believe this information is propagated. Would this need to be a new piece of software somewhere in the chain adding this information to an additional AR header, or modifying the one added by policy-spf? And who is responsible for parsing header.s out of DKIM signatures? OpenARC? Or an additional piece of software? And in addition, it will need to be put in the dkim, or one of the dkim, sections of the newly aggregated AAR, which will require more software. This situation seems very complicated to me, which makes me think that I don't understand it. Either that or it is complicated, and possibly unreasonably so. I'm not sure. I do understand, and entirely support, the need/desire for this information. But the practical details of how we're doing this elude me. -Gene On Tue, Jul 25, 2017 at 9:22 AM, Kurt Andersen (b) wrote: > On Tue, Jul 25, 2017 at 9:14 AM, Scott Kitterman > wrote: > >> >> Insisting that all results from an ADMD for SPF, DKIM, and DMARC be >> collapsed into a single AR header field is a huge change from the way AR >> works today. AR was designed for each mechanism to be able to add new >> information about its results. >> > > There is no requirement to do so. The only thing is that for the AAR, all > of the *locally trustworthy* AR headers get collapsed into a single AAR. > > >> What this would mean is that an ARC participant would have to remove and >> consolidate multiple fields on receipt (the original sender has no >> requirement to be ARC aware AIUI). >> > > An ARC participant should not, upon ingress, pay any heed to AR records > that might have been put there by previous ADMDs so I'm not quite sure what > you are referring to (maybe the language that I used was unclear?) > > >> If I'm understanding correctly, this is not a good idea. ARC should >> consume AR fields just like everyone else. >> > > Maybe you're thinking of ARC signing on *egress*? Somehow, the signing > instance needs to know about the state of the authentication upon ingress > to the ADMD. AR may work, or may not - it depends on the operator's > implementation. I know of some MTAs that strip AR records without a means > to tell it which ones to leave alone. If those live within the internal > pathway, then AR is not a workable approach for communication from ingress > to egress. > > --Kurt > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --94eb2c0769fa660d5f055529618b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So I think I'm still missing something.=C2=A0 Let'= s imagine an ADMD setup in something like the following fashion:

inbound -> policyspf(or some other spf check) =C2=A0-> OpenD= KIM -> OpenDMARC -> OpenARC Validation -> mailing list software -&= gt; OpenArc Signature -> outbound. =C2=A0

Or so= mething like this.=C2=A0 Lets say policyspf, OpenDKIM, OpenDMARC, OpenARC, = all stamp the standard info into various AR headers on ingress.=C2=A0 On eg= ress, in the OpenARC signature milter, we then consolidate all AR's int= o the AAR.=C2=A0 In this stage we also need source.ip & header.s for DK= IM signatures.=C2=A0 Where is this information coming from?=C2=A0 Who is re= cording the source.ip in this chain?=C2=A0 It's not policy-spf, or anyb= ody further down the chain, as I don't believe this information is prop= agated.=C2=A0 Would this need to be a new piece of software somewhere in th= e chain adding this information to an additional AR header, or modifying th= e one added by policy-spf?

And who is responsible = for parsing header.s out of DKIM signatures?=C2=A0 OpenARC?=C2=A0 Or an add= itional piece of software?=C2=A0 And in addition, it will need to be put in= the dkim, or one of the dkim, sections of the newly aggregated AAR, which = will require more software.

This situation seems v= ery complicated to me, which makes me think that I don't understand it.= =C2=A0 Either that or it is complicated, and possibly unreasonably so.=C2= =A0 I'm not sure.

I do understand, and entirel= y support, the need/desire for this information.=C2=A0 But the practical de= tails of how we're doing this elude me.

-Gene<= /div>

On Tue= , Jul 25, 2017 at 9:22 AM, Kurt Andersen (b) <kboth@drkurt.com> wrote:
On Tue, Jul 25, 2= 017 at 9:14 AM, Scott Kitterman <sklist@kitterman.com> wr= ote:

Insisting that all results from an ADMD for SPF, DKIM, and DMAR= C be collapsed into a single AR header field is a huge change from the way = AR works today.=C2=A0 AR was designed for each mechanism to be able to add = new information about its results.

There is no requirement to do so. The only thing is that for the AAR, al= l of the *locally trustworthy* AR headers get collapsed into a single AAR.<= /div>
=C2=A0
What = this would mean is that an ARC participant would have to remove and consoli= date multiple fields on receipt (the original sender has no requirement to = be ARC aware AIUI).

An ARC parti= cipant should not, upon ingress, pay any heed to AR records that might have= been put there by previous ADMDs so I'm not quite sure what you are re= ferring to (maybe the language that I used was unclear?)
=C2=A0
If I'm understand= ing correctly, this is not a good idea.=C2=A0 ARC should consume AR fields = just like everyone else.

Maybe y= ou're thinking of ARC signing on *egress*? Somehow, the signing instanc= e needs to know about the state of the authentication upon ingress to the A= DMD. AR may work, or may not - it depends on the operator's implementat= ion. I know of some MTAs that strip AR records without a means to tell it w= hich ones to leave alone. If those live within the internal pathway, then A= R is not a workable approach for communication from ingress to egress.

--Kurt<= /div>


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


--94eb2c0769fa660d5f055529618b-- From nobody Tue Jul 25 14:44:27 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A472D12ECBD for ; Tue, 25 Jul 2017 14:44: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 (2048-bit key) header.d=sapienti-sat.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 3N9xh1RcovyN for ; Tue, 25 Jul 2017 14:44:23 -0700 (PDT) Received: from batleth.sapienti-sat.org (batleth.sapienti-sat.org [88.198.49.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C74B01252BA for ; Tue, 25 Jul 2017 14:44:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sapienti-sat.org; h=content-transfer-encoding:content-language:content-type :content-type:in-reply-to:mime-version:user-agent:date:date :message-id:from:from:references:subject:subject; s= dkim20170413; t=1501019061; bh=yKBURjMv0IH8bpQCYD+Nv6pvwzBEO2g63 CtoYiPoJ/Q=; b=USFWlr65HUNud0xpraJdFNGzQRPGsXvMytf9XJd2RZzhSttDh 02P0/AU1/pxRerW0u7zFt0oj58a9gee5DB7DTD/3iHHpa2/uOxe77qZuWPYWBcOd or5xQagepY3hb0gDg85lp3ylvH18XPM1RcJNayymHIRfna15OqU072WsLsdPevHI 07kQScsZQE9Rm78kEuqfhS67ItvmlK1UrbXPMxwy1y2rwQy8204RZD6l5TJu9XYG r+yAiE+gGWVRWUxaekvzLtwoSns75xW4pHu6Wk0iUbRMcP1VBuK9Mts88mOAymO4 THiIuZbIi8OftXBAbs9njwXq2EMAPdRz19RbA== X-Virus-Scanned: Debian amavisd-new at sapienti-sat.org Received: from [IPv6:2001:470:6d:e38::21] (stargazer.home.sapienti-sat.org [IPv6:2001:470:6d:e38::21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: juri@sapienti-sat.org) by batleth.sapienti-sat.org (Postfix) with ESMTPSA id CDD6933E0803 for ; Tue, 25 Jul 2017 23:44:21 +0200 (CEST) To: dmarc@ietf.org References: From: Juri Haberland Message-ID: Date: Tue, 25 Jul 2017 23:44:20 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] questions about section 5.1.1 of the new ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 21:44:26 -0000 On 25.07.2017 21:31, Gene Shuman wrote: > So I think I'm still missing something. Let's imagine an ADMD setup in > something like the following fashion: > > inbound -> policyspf(or some other spf check) -> OpenDKIM -> OpenDMARC -> > OpenARC Validation -> mailing list software -> OpenArc Signature -> > outbound. Well, OpenARC validation should be before OpenDMARC... > Or something like this. Lets say policyspf, OpenDKIM, OpenDMARC, OpenARC, > all stamp the standard info into various AR headers on ingress. On egress, > in the OpenARC signature milter, we then consolidate all AR's into the > AAR. In this stage we also need source.ip & header.s for DKIM signatures. > Where is this information coming from? Who is recording the source.ip in > this chain? It's not policy-spf, or anybody further down the chain, as I > don't believe this information is propagated. Would this need to be a new > piece of software somewhere in the chain adding this information to an > additional AR header, or modifying the one added by policy-spf? All milter see the original IP and port, so OpenArc could report that. > And who is responsible for parsing header.s out of DKIM signatures? > OpenARC? Or an additional piece of software? And in addition, it will > need to be put in the dkim, or one of the dkim, sections of the newly > aggregated AAR, which will require more software. In my understanding OpenArc would validate the ARC set. OpenDMARC would need to parse the first AAR if DKIM and SPF fail and ARC passes. Um, right? Juri From nobody Tue Jul 25 15:01:39 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD91131F27 for ; Tue, 25 Jul 2017 15:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jGcP4aktODD for ; Tue, 25 Jul 2017 15:01:33 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::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 7CAB4131CDE for ; Tue, 25 Jul 2017 15:01:33 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id u207so15484798ywc.3 for ; Tue, 25 Jul 2017 15:01:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jmLRKGyyrlFJSZ5iYmnG5MNJKZsiOKYwEiuIhnjBcv8=; b=NlHuXlnR0csORHrmO67/GvJBhB1/zAQeZhZU3LCd5AP/z9d2aYB8BPWMH1DLsvGUsM msncAirAOh30V6vKOhEH16KQ3GvoQ6nf2KpDDeN29nKThRhCtP1WPzb85ASQE7u/FODQ qAKzuaqPetT8ixn251uzTi06Mr1dGmEAbWGFX1M/lrmPqzsi4FgRx7AuO9cWGRdxvX9a GWboLarc+miJaNif3P/L8oH/pb6w9bUsqnE57JSoRrPgkunDs0XkUXQi9EPH4hNFrf4B q9NOWP4xCRS0YU9hvQogS8/Y1NBQjwcjLMiwSF13BGrcdKDknCMOv1k9CsRbybgeToqc ShIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jmLRKGyyrlFJSZ5iYmnG5MNJKZsiOKYwEiuIhnjBcv8=; b=A6B8PQ01r745PPm9wN1X/A73vTrAD44HFmAAXK6UGBAmw4oRpnsZPP5n66vHdBOxCx EUh/f3WIdQvWIrGJQR/8UiDpmRxpVw8K4Ry1LSnKcka7mn6vl8SDMZxngHjaE1ISEGl/ gFJJ1Wu//XNlAR82NKHatYwA1PRHRuBnj86Do9INtXWsO50V5YagjtgGd4wP1XyUtmQS tPqeJTwR20VjalUASj9vcLJU6ELm7swabUGlEgZHMdpwKOcT9ieu4+BZvOQ9tt7DYmZu 0G9oejUfNhpZmT/KmKcdsXUgjQcIuFBZQObScgeFDl7ReTU7OYcFmtBZsSwZpKU9NWoJ VzkA== X-Gm-Message-State: AIVw112vYWLtgVcLpL5tGb7FeSv9mDzbce5e0jBpDL4u+yt7b5y9XNy/ 3swtX4V8aP+hgp/BRh0dBP81+qqDz4akVNnz3Q== X-Received: by 10.37.59.200 with SMTP id i191mr17294842yba.291.1501020092138; Tue, 25 Jul 2017 15:01:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.61.3 with HTTP; Tue, 25 Jul 2017 15:01:31 -0700 (PDT) In-Reply-To: References: From: Gene Shuman Date: Tue, 25 Jul 2017 15:01:31 -0700 Message-ID: To: Juri Haberland Cc: dmarc@ietf.org Content-Type: multipart/alternative; boundary="001a114f512264bb2d05552b798e" Archived-At: Subject: Re: [dmarc-ietf] questions about section 5.1.1 of the new ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 22:01:37 -0000 --001a114f512264bb2d05552b798e Content-Type: text/plain; charset="UTF-8" > All milter see the original IP and port, so OpenArc could report that. OK that's good to know. Still, it needs to be parsing an SPF AR & inserting the source.ip, which is doable, but work. > In my understanding OpenArc would validate the ARC set. OpenDMARC would need to parse the first AAR if DKIM and SPF fail and ARC passes. OpenARC validation is creating no signatures. Therefore OpenDMARC will have no access to an new AARs(from the current hop) OpenARC though, is now expected to parse incoming DKIM signatures as well, and extract the s= tag,, right? And then rebuild & reinsert this tag into the AR generated by OpenDKIM? This is possible, but again, a very non trivial amount of work, as it's very much outside of the scope of what we're doing currently. And also seems kind of crazy. The situation with non-milter based approaches is even worse. dkimpy & mailman don't even have access to source.ip, so that's definitely out. And again, dkimpy would need to parse DKIM signatures, extract info & stick it somewhere. Again, a bit convoluted. Brandon, have you thought about this much? =Gene On Tue, Jul 25, 2017 at 2:44 PM, Juri Haberland wrote: > On 25.07.2017 21:31, Gene Shuman wrote: > > So I think I'm still missing something. Let's imagine an ADMD setup in > > something like the following fashion: > > > > inbound -> policyspf(or some other spf check) -> OpenDKIM -> OpenDMARC > -> > > OpenARC Validation -> mailing list software -> OpenArc Signature -> > > outbound. > > Well, OpenARC validation should be before OpenDMARC... > > > Or something like this. Lets say policyspf, OpenDKIM, OpenDMARC, > OpenARC, > > all stamp the standard info into various AR headers on ingress. On > egress, > > in the OpenARC signature milter, we then consolidate all AR's into the > > AAR. In this stage we also need source.ip & header.s for DKIM > signatures. > > Where is this information coming from? Who is recording the source.ip in > > this chain? It's not policy-spf, or anybody further down the chain, as I > > don't believe this information is propagated. Would this need to be a > new > > piece of software somewhere in the chain adding this information to an > > additional AR header, or modifying the one added by policy-spf? > > All milter see the original IP and port, so OpenArc could report that. > > > And who is responsible for parsing header.s out of DKIM signatures? > > OpenARC? Or an additional piece of software? And in addition, it will > > need to be put in the dkim, or one of the dkim, sections of the newly > > aggregated AAR, which will require more software. > > In my understanding OpenArc would validate the ARC set. OpenDMARC would > need to parse the first AAR if DKIM and SPF fail and ARC passes. > > Um, right? > > Juri > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --001a114f512264bb2d05552b798e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> All milter see the o= riginal IP and port, so OpenArc could report that.

OK that's good to know.=C2=A0 Still, it needs to be parsing an SPF = AR & inserting the source.ip, which is doable, but work.

>=C2=A0In my und= erstanding OpenArc would validate the ARC set. OpenDMARC would
need to parse the first AAR if DKIM and SPF fail and ARC passes.
OpenARC validation is creating no signatures.=C2=A0 Therefo= re OpenDMARC will have no access to an new AARs(from the current hop)

OpenARC though, is now expected to parse incoming = DKIM signatures as well, and extract the s=3D tag,, right? And then rebuild= & reinsert this tag into the AR generated by OpenDKIM?=C2=A0 This is p= ossible, but again, a very non trivial amount of work, as it's very muc= h outside of the scope of what we're doing currently.=C2=A0 And also se= ems kind of crazy. =C2=A0

The situation with = non-milter based approaches is even worse. =C2=A0dkimpy & mailman don&#= 39;t even have access to source.ip, so that's definitely out.=C2=A0 And= again, dkimpy would need to parse DKIM signatures, extract info & stic= k it somewhere.=C2=A0 Again, a bit convoluted. =C2=A0

Brandon, have you thought about this much?

=3DGene

On Tue, Jul 25, 2017 at 2:44 PM, Juri Haberland <jur= i@sapienti-sat.org> wrote:
= On = 25.07.2017 21:31, Gene Shuman wrote:
> So I think I'm still missing something.=C2=A0 Let's imagine an= ADMD setup in
> something like the following fashion:
>
> inbound -> policyspf(or some other spf check)=C2=A0 -> OpenDKIM = -> OpenDMARC ->
> OpenARC Validation -> mailing list software -> OpenArc Signature= ->
> outbound.

Well, OpenARC validation should be before OpenDMARC...

> Or something like this.=C2=A0 Lets say policyspf, OpenDKIM, OpenDMARC,= OpenARC,
> all stamp the standard info into various AR headers on ingress.=C2=A0 = On egress,
> in the OpenARC signature milter, we then consolidate all AR's into= the
> AAR.=C2=A0 In this stage we also need source.ip & header.s for DKI= M signatures.
> Where is this information coming from?=C2=A0 Who is recording the sour= ce.ip in
> this chain?=C2=A0 It's not policy-spf, or anybody further down the= chain, as I
> don't believe this information is propagated.=C2=A0 Would this nee= d to be a new
> piece of software somewhere in the chain adding this information to an=
> additional AR header, or modifying the one added by policy-spf?

All milter see the original IP and port, so OpenArc could report tha= t.

> And who is responsible for parsing header.s out of DKIM signatures? > OpenARC?=C2=A0 Or an additional piece of software?=C2=A0 And in additi= on, it will
> need to be put in the dkim, or one of the dkim, sections of the newly<= br> > aggregated AAR, which will require more software.

In my understanding OpenArc would validate the ARC set. OpenDMARC wo= uld
need to parse the first AAR if DKIM and SPF fail and ARC passes.

Um, right?

=C2=A0 Juri

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

--001a114f512264bb2d05552b798e-- From nobody Tue Jul 25 15:09:44 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A30D5131F4C for ; Tue, 25 Jul 2017 15:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fV4NSs1DSlud for ; Tue, 25 Jul 2017 15:09:40 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::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 03B56131CEF for ; Tue, 25 Jul 2017 15:09:40 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id v127so58999903itd.0 for ; Tue, 25 Jul 2017 15:09:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=m+7uQxH2saUehcfT7B6sUY7Rlz6fZfPby/WX8WMgbj8=; b=qUnymt0K83Tf+tOIj7lbpPlon4P6QisoS399BZleKK8IIpwT9qNmxZBVlm7gwGq5fC cGLvdREqo1WvcZXlSuGRcibyCnk1igGieWfGEkpwhj/wxcGjEXYJsa+7CLsWztUtf6kY csRZvvdFm0+zbLE9qbv7ZEZ0iIni8pfVXxYS6lLS5Y672ExhtbWtDbtee+h9w+G1bGq6 J0D7q0M8OI+1hOsRcpxsLYEcpSHPxP29zc7car6JX9XPs8YytFit7cX3eI4X3wQwhgBz j49/UQxjnp+JEP1ZuDGhakSc9J22B09dVLgjWvSmHIW9NoXOHbIncbJWrV7yi2VkUmdm gi3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=m+7uQxH2saUehcfT7B6sUY7Rlz6fZfPby/WX8WMgbj8=; b=a/kR/W1VkJaPw3N0rrk7Bj6EnybbxuXGAWtz6HnTVsKeFBInIe/bc94Q19wR4s6qdI 1KBEpLNCTxOqsbVEEmOqn7z4NxgGIERwL0JA6rnckOjWKctSrfTG67C0d8n+BNmeuTZy /wnqoQdvvGpU3SZF0doQwRkBWnKxEwrAyzx6kUNsXDcCEWf+CcN+Mg65F6iaGSdg2YWZ EppTAjcsQVgb3pjZDE1e/P4vbZDp3I/KUMErseU19t+KpGa2k5kmZVZq2+rw+B+OO+vX JePMnE7GZV8DU1Gm3iFb1KAWR+QpbUvaRNSqA/6j1JniOpKB0P/tUPGe20JsK8gcODwb SWKQ== X-Gm-Message-State: AIVw112SrsVA155CigLP+GhKIsDssGh7uG672LnFtWI4g7eiGlts+hcb 8U9MB1FoGYGyQQ4NMXJ4ayN5H4raVBa0 X-Received: by 10.36.17.142 with SMTP id 136mr12769784itf.90.1501020579278; Tue, 25 Jul 2017 15:09:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.106.130 with HTTP; Tue, 25 Jul 2017 15:09:38 -0700 (PDT) In-Reply-To: References: From: Gene Shuman Date: Tue, 25 Jul 2017 15:09:38 -0700 Message-ID: To: Juri Haberland Cc: dmarc@ietf.org Content-Type: multipart/alternative; boundary="001a1143e0186db6ab05552b96e2" Archived-At: Subject: Re: [dmarc-ietf] questions about section 5.1.1 of the new ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 22:09:42 -0000 --001a1143e0186db6ab05552b96e2 Content-Type: text/plain; charset="UTF-8" Sorry, sent from wrong email address. Resending: > All milter see the original IP and port, so OpenArc could report that. OK that's good to know. Still, it needs to be parsing an SPF AR & inserting the source.ip, which is doable, but work. > In my understanding OpenArc would validate the ARC set. OpenDMARC would need to parse the first AAR if DKIM and SPF fail and ARC passes. OpenARC validation is creating no signatures. Therefore OpenDMARC will have no access to an new AARs(from the current hop) OpenARC though, is now expected to parse incoming DKIM signatures as well, and extract the s= tag,, right? And then rebuild & reinsert this tag into the AR generated by OpenDKIM? This is possible, but again, a very non trivial amount of work, as it's very much outside of the scope of what we're doing currently. And also seems kind of crazy. The situation with non-milter based approaches is even worse. dkimpy & mailman don't even have access to source.ip, so that's definitely out. And again, dkimpy would need to parse DKIM signatures, extract info & stick it somewhere. Again, a bit convoluted. Brandon, have you thought about this much? On Tue, Jul 25, 2017 at 2:44 PM, Juri Haberland wrote: > On 25.07.2017 21:31, Gene Shuman wrote: > > So I think I'm still missing something. Let's imagine an ADMD setup in > > something like the following fashion: > > > > inbound -> policyspf(or some other spf check) -> OpenDKIM -> OpenDMARC > -> > > OpenARC Validation -> mailing list software -> OpenArc Signature -> > > outbound. > > Well, OpenARC validation should be before OpenDMARC... > > > Or something like this. Lets say policyspf, OpenDKIM, OpenDMARC, > OpenARC, > > all stamp the standard info into various AR headers on ingress. On > egress, > > in the OpenARC signature milter, we then consolidate all AR's into the > > AAR. In this stage we also need source.ip & header.s for DKIM > signatures. > > Where is this information coming from? Who is recording the source.ip in > > this chain? It's not policy-spf, or anybody further down the chain, as I > > don't believe this information is propagated. Would this need to be a > new > > piece of software somewhere in the chain adding this information to an > > additional AR header, or modifying the one added by policy-spf? > > All milter see the original IP and port, so OpenArc could report that. > > > And who is responsible for parsing header.s out of DKIM signatures? > > OpenARC? Or an additional piece of software? And in addition, it will > > need to be put in the dkim, or one of the dkim, sections of the newly > > aggregated AAR, which will require more software. > > In my understanding OpenArc would validate the ARC set. OpenDMARC would > need to parse the first AAR if DKIM and SPF fail and ARC passes. > > Um, right? > > Juri > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --001a1143e0186db6ab05552b96e2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry, sent from wrong email address.=C2=A0 Resending:
> All milter see the original IP and port, so = OpenArc could report that.
=
OK that's good to know.=C2=A0 Still, it needs to be parsi= ng an SPF AR & inserting the source.ip, which is doable, but work.

>=C2=A0In my understanding Op= enArc would validate the ARC set. OpenDMARC would
need to par= se the first AAR if DKIM and SPF fail and ARC passes.

OpenARC validation is creating no sign= atures.=C2=A0 Therefore OpenDMARC will have no access to an new AARs(from t= he current hop)

OpenARC though, is now expected to parse incoming = DKIM signatures as well, and extract the s=3D tag,, right? And then rebuild= & reinsert this tag into the AR generated by OpenDKIM?=C2=A0 This is p= ossible, but again, a very non trivial amount of work, as it's very muc= h outside of the scope of what we're doing currently.=C2=A0 And also se= ems kind of crazy. =C2=A0

The situation with non-milter based appr= oaches is even worse. =C2=A0dkimpy & mailman don't even have access= to source.ip, so that's definitely out.=C2=A0 And again, dkimpy would = need to parse DKIM signatures, extract info & stick it somewhere.=C2=A0= Again, a bit convoluted. =C2=A0

Brandon, have you thought about t= his much?

On Tue, Jul 25, 2017 at 2:44 PM, Juri Haberland <jur= i@sapienti-sat.org> wrote:
= On = 25.07.2017 21:31, Gene Shuman wrote:
> So I think I'm still missing something.=C2=A0 Let's imagine an= ADMD setup in
> something like the following fashion:
>
> inbound -> policyspf(or some other spf check)=C2=A0 -> OpenDKIM = -> OpenDMARC ->
> OpenARC Validation -> mailing list software -> OpenArc Signature= ->
> outbound.

Well, OpenARC validation should be before OpenDMARC...

> Or something like this.=C2=A0 Lets say policyspf, OpenDKIM, OpenDMARC,= OpenARC,
> all stamp the standard info into various AR headers on ingress.=C2=A0 = On egress,
> in the OpenARC signature milter, we then consolidate all AR's into= the
> AAR.=C2=A0 In this stage we also need source.ip & header.s for DKI= M signatures.
> Where is this information coming from?=C2=A0 Who is recording the sour= ce.ip in
> this chain?=C2=A0 It's not policy-spf, or anybody further down the= chain, as I
> don't believe this information is propagated.=C2=A0 Would this nee= d to be a new
> piece of software somewhere in the chain adding this information to an=
> additional AR header, or modifying the one added by policy-spf?

All milter see the original IP and port, so OpenArc could report tha= t.

> And who is responsible for parsing header.s out of DKIM signatures? > OpenARC?=C2=A0 Or an additional piece of software?=C2=A0 And in additi= on, it will
> need to be put in the dkim, or one of the dkim, sections of the newly<= br> > aggregated AAR, which will require more software.

In my understanding OpenArc would validate the ARC set. OpenDMARC wo= uld
need to parse the first AAR if DKIM and SPF fail and ARC passes.

Um, right?

=C2=A0 Juri

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

--001a1143e0186db6ab05552b96e2-- From nobody Tue Jul 25 15:27:55 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47ADB131F7B for ; Tue, 25 Jul 2017 15:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pjrG_H73wR4x for ; Tue, 25 Jul 2017 15:27:51 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::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 E90E2131F71 for ; Tue, 25 Jul 2017 15:27:50 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id 80so110514666uas.0 for ; Tue, 25 Jul 2017 15:27:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=cMxmfBNwrHDmuZASwlBRGmzyj+q3M9sWfWz615knaUM=; b=fyy4acvBjQLVKU3CQkEuJIsLWfUnc1PXJoK3nqv7tbtv+oa6+iQQHKYjiwnPfAeoMT L4JAJw5hPsrwxIPOxVhfuysbf995RThATPYf2qnPBUZP62ZMd3Yiw4B1Cg5lChl4Avw4 nFNPhAhiz0TPAoX6it6S7JPOtw3zs9mAPiXJs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=cMxmfBNwrHDmuZASwlBRGmzyj+q3M9sWfWz615knaUM=; b=j0lccd169A/tNbmQ2gn9L7JAJA4E8moOkW9tiy/OWsKHD/xu6Ir5lSjiRWL6i7r0JL UAHjyJUUQBd6oB18dx099WMR8yFwpRG4H62L+5JeyoebW9pQdNO0OyJCati8Z+riRC8D BsPsXo6bv3kPX019BHjxwKjxdHPqke5FkA5K5mYTJBr3PWg2BgkFIQb6B1mEQkdVsRo9 407x48AkHDf3vrvXdb16OtxMRu/dDfjzKNYuQBYZtCavjJfpXqujo0Td6PcXcfgjvaNL fwH7lTafCzjwRTyyDCL/qoRaInGlqAxAlFc0XroLaNzoXAomAs8ivkGq4mdRude1YmvE VP6A== X-Gm-Message-State: AIVw110MznVJ4H+bN0nP96ft2VswmMqYZ6KZglSjqOyBWlx8Tj4uC7gr 4Sv0XMSft+1Z70mQlPNfiLTsvIgtUubl X-Received: by 10.176.71.82 with SMTP id i18mr14854784uac.171.1501021669836; Tue, 25 Jul 2017 15:27:49 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.176.26.39 with HTTP; Tue, 25 Jul 2017 15:27:49 -0700 (PDT) In-Reply-To: References: From: "Kurt Andersen (b)" Date: Tue, 25 Jul 2017 15:27:49 -0700 X-Google-Sender-Auth: 794CZNljVfU4tTRjRNGn0__T6fQ Message-ID: To: Gene Shuman Cc: Scott Kitterman , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="f403045e63286ebb1705552bd714" Archived-At: Subject: Re: [dmarc-ietf] questions about section 5.1.1 of the new ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 22:27:53 -0000 --f403045e63286ebb1705552bd714 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 25, 2017 at 12:31 PM, Gene Shuman wrote: > > This situation seems very complicated to me, which makes me think that I > don't understand it. Either that or it is complicated, and possibly > unreasonably so. I'm not sure. > > I do understand, and entirely support, the need/desire for this > information. But the practical details of how we're doing this elude me. > If you have a clearer, cleaner, and less convoluted mechanism to obtain this information and pass it through the series of intermediaries to get into the DMARC report, I'm happy to update the spec along those lines :-) --Kurt --f403045e63286ebb1705552bd714 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Jul 25, 2017 at 12:31 PM, Gene Shuman <geneshuman@gmail.com>= wrote:

=
This situation seems very complicated to me, which makes me thin= k that I don't understand it.=C2=A0 Either that or it is complicated, a= nd possibly unreasonably so.=C2=A0 I'm not sure.

I do understand, and entirely support, the need/desire for this informat= ion.=C2=A0 But the practical details of how we're doing this elude me.<= /div>

If you have a clearer, cleaner,= and less convoluted mechanism to obtain this information and pass it throu= gh the series of intermediaries to get into the DMARC report, I'm happy= to update the spec along those lines :-)

--Kurt= =C2=A0

--f403045e63286ebb1705552bd714-- From nobody Tue Jul 25 15:29:53 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2F4131FA4 for ; Tue, 25 Jul 2017 15:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9wrJcvDfnEs for ; Tue, 25 Jul 2017 15:29:49 -0700 (PDT) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56C54131F71 for ; Tue, 25 Jul 2017 15:29:49 -0700 (PDT) Received: by mail-ua0-x232.google.com with SMTP id q25so91891664uah.1 for ; Tue, 25 Jul 2017 15:29:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=mrF4B5Sy3ck9GDyktN0wFMfCwndOe6/ZQ9oemYsb5QM=; b=W3MOh9mjmDkbwjxyPxsybX2J8X7Ln6tDqOR6Q+Nff+xIeecEc6ksCA/D791eP/ealE k0YxysnYsbJNX9fmVeNj1lsm5v2B8Ooz5xGI0euKSIjR997PgW0h2SvTd8BAT6wiWyXc 5nX6ubw9cvZ7qR6Z5pGWlXsLk+axx+SM2ganc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=mrF4B5Sy3ck9GDyktN0wFMfCwndOe6/ZQ9oemYsb5QM=; b=iOddBeDY08G/zuESZJ2OahSGmD/zkbYbk10kSx8kGgkYM7z30MLEIJInitC99+Wppp c9giff26E3dYN7Q86bKmhSmOp1Pqy0xpOw7BfNY8lCtnFeASwrcU4kBING7o/jAYZgDk V7na1MRXjPs4PHvx3ExOiw3PwYBv8jqlVuZD4ChS5qXmYCsTzM2RBEf258dFIpywLMYc 9JuHtCVtYqIiqONikghbNhc/GHbnZ+SBDZNUtW4IaSTiFYGJeEUlTXWNU+3Jhc0TKv3C xvf0ZONkkqfoKgj0uBr/2PEnksXInMCpS/+cxACGIFmCIy1tTvq7VV7VIgKuJMmpSCFR Dm0w== X-Gm-Message-State: AIVw111/a01zEEc2NEcs8fob9n++h9313AdiQcEqlNxINbRTDAUFACkw b5uIndzyQpq0pgf3Z9t2PaTVN/7VsmLerRQ= X-Received: by 10.176.80.139 with SMTP id c11mr12753840uaa.159.1501021788377; Tue, 25 Jul 2017 15:29:48 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.176.26.39 with HTTP; Tue, 25 Jul 2017 15:29:47 -0700 (PDT) In-Reply-To: References: From: "Kurt Andersen (b)" Date: Tue, 25 Jul 2017 15:29:47 -0700 X-Google-Sender-Auth: 4vaZRKKXXc5TmHF_P9xKQeFqIcE Message-ID: To: Juri Haberland Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0cc3f47f81bb05552bde7d" Archived-At: Subject: Re: [dmarc-ietf] questions about section 5.1.1 of the new ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 22:29:52 -0000 --94eb2c0cc3f47f81bb05552bde7d Content-Type: text/plain; charset="UTF-8" On Tue, Jul 25, 2017 at 2:44 PM, Juri Haberland wrote: > On 25.07.2017 21:31, Gene Shuman wrote: > > So I think I'm still missing something. Let's imagine an ADMD setup in > > something like the following fashion: > > > > inbound -> policyspf(or some other spf check) -> OpenDKIM -> OpenDMARC > -> > > OpenARC Validation -> mailing list software -> OpenArc Signature -> > > outbound. > > Well, OpenARC validation should be before OpenDMARC... Well, that depends on your implementation. If you generally evaluate local policy conditions before checking the primary DMARC mechanisms, then yes; otherwise, ARC only needs to be evaluated if DMARC does not achieve a PASS from the primary mechanism or if you expect to break the message's authentication. --Kurt --94eb2c0cc3f47f81bb05552bde7d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Jul 25, 2017 at 2:44 PM, Juri Haberland <juri@sapienti-sat.org> wrote:
On = 25.07.2017 21:31= , Gene Shuman wrote:
> So I think I'm still missing something.=C2=A0 Let's imagine an= ADMD setup in
> something like the following fashion:
>
> inbound -> policyspf(or some other spf check)=C2=A0 -> OpenDKIM = -> OpenDMARC ->
> OpenARC Validation -> mailing list software -> OpenArc Signature= ->
> outbound.

Well, OpenARC validation should be before OpenDMARC...
<= div>
Well, that depends on your implementation. If you genera= lly evaluate local policy conditions before checking the primary DMARC mech= anisms, then yes; otherwise, ARC only needs to be evaluated if DMARC does n= ot achieve a PASS from the primary mechanism or if you expect to break the = message's authentication.

--Kurt=C2=A0
--94eb2c0cc3f47f81bb05552bde7d-- From nobody Tue Jul 25 15:30:44 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45DA4131FA1 for ; Tue, 25 Jul 2017 15:30:43 -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 (2048-bit key) header.d=sapienti-sat.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 nNXVo4K2uWAS for ; Tue, 25 Jul 2017 15:30:41 -0700 (PDT) Received: from batleth.sapienti-sat.org (batleth.sapienti-sat.org [88.198.49.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C6F5131F9F for ; Tue, 25 Jul 2017 15:30:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sapienti-sat.org; h=content-transfer-encoding:content-language:content-type :content-type:in-reply-to:mime-version:user-agent:date:date :message-id:from:from:references:subject:subject; s= dkim20170413; t=1501021839; bh=SJTElGkzO4cBtOTGdmpYEs8j9GGUGAtYT 7bOD0mioDI=; b=aCUIKbpEenNULNW6FQIQEsQyJjh+Sleq6PlzGUsMquO5WdPxi oY0Bg9wJn0hu2EZQidC+9Hn/l8XD5AJ5sNpSnKjWEaxVjNR/9p4pU5RhhmcuPSgs k6gzBfUZi45scMj8xqbRgWst+7x3hgYRqoGO70pdWPFrlAL79G7aLJWDlBNaBz7q ReldnmqSL4bHxBbMExxDu7hFdQIMBcIg7bKxIuNgYT/EvtYo5APd8RqU817/o9Yw Tlr/Zkb8z78I3ZEKOo1guha93dt13TVZUJMmlqfvubxm+W2fcIFsi3YOtOd/1sRu v94SHeMa/IefnaNhz0hxP86Oe3FUuS3WzTBJg== X-Virus-Scanned: Debian amavisd-new at sapienti-sat.org Received: from [IPv6:2001:470:6d:e38::21] (stargazer.home.sapienti-sat.org [IPv6:2001:470:6d:e38::21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: juri@sapienti-sat.org) by batleth.sapienti-sat.org (Postfix) with ESMTPSA id 68F3433E0A14 for ; Wed, 26 Jul 2017 00:30:39 +0200 (CEST) To: dmarc@ietf.org References: From: Juri Haberland Message-ID: Date: Wed, 26 Jul 2017 00:30:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] questions about section 5.1.1 of the new ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 22:30:43 -0000 On 26.07.2017 00:01, Gene Shuman wrote: >> All milter see the original IP and port, so OpenArc could report that. > > OK that's good to know. Still, it needs to be parsing an SPF AR & > inserting the source.ip, which is doable, but work. > >> In my understanding OpenArc would validate the ARC set. OpenDMARC would > need to parse the first AAR if DKIM and SPF fail and ARC passes. > > OpenARC validation is creating no signatures. Therefore OpenDMARC will > have no access to an new AARs(from the current hop) OpenARC will create an A-R header, which can be parsed by OpenDMARC. > OpenARC though, is now expected to parse incoming DKIM signatures as well, > and extract the s= tag,, right? And then rebuild & reinsert this tag into > the AR generated by OpenDKIM? This is possible, but again, a very non > trivial amount of work, as it's very much outside of the scope of what > we're doing currently. And also seems kind of crazy. I don't see the problem: OpenARC (or whatever) checks the ARC chain and if it passes, the first AAR header should be parsed by OpenDMARC (or somesuch). That's all. Reporting (DMARC) is a different matter, though, but let's concentrate on one problem after the other... Juri From nobody Tue Jul 25 15:36:33 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A240E131FBB for ; Tue, 25 Jul 2017 15:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sapienti-sat.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 bHBOY2lYw_-G for ; Tue, 25 Jul 2017 15:36:30 -0700 (PDT) Received: from batleth.sapienti-sat.org (batleth.sapienti-sat.org [88.198.49.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E121131FB4 for ; Tue, 25 Jul 2017 15:36:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sapienti-sat.org; h=content-transfer-encoding:content-language:content-type :content-type:in-reply-to:mime-version:user-agent:date:date :message-id:from:from:references:subject:subject; s= dkim20170413; t=1501022188; bh=a6lNlZ5OCbVXQqD5NTm+8YG6kOgzUyqt2 rjtF5vo6rA=; b=NTY8mJQnkieK0l55rBNYSDVNkNl3v3ewM8kW7hscMSepMuQ8i SBMJhAw+O0BRg/esvyQ/bs5O1jzk3lH3ljN4I6idFHanTFs3rXJbN9e2Fk7Px+/w 90Dw+5Stn+DyQ+jh70Tf6z60NhrhP/HuAPIOO6XvqyFFrFJP27iGivn4uLDq0Qkk sYHhGE41IEOu3ae7bmTkgbXp2P07X/CY0Xow7f5H/Pgdus+pnw3bWup3Pw3P6m9e GO2u60gHt8kx3UzvK3fn0XG2RiBBV4RrpkT+e8BVQW6zQEtvdvkNo3HjxM7sv5GQ zx7pGmhnNJxy0CIQm6iMXhkDfM40n9Oe0jZgQ== X-Virus-Scanned: Debian amavisd-new at sapienti-sat.org Received: from [IPv6:2001:470:6d:e38::21] (stargazer.home.sapienti-sat.org [IPv6:2001:470:6d:e38::21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: juri@sapienti-sat.org) by batleth.sapienti-sat.org (Postfix) with ESMTPSA id C1D2A33E151B for ; Wed, 26 Jul 2017 00:36:28 +0200 (CEST) To: dmarc@ietf.org References: From: Juri Haberland Message-ID: <9f93d9c9-5c84-9f78-6b22-2c637efdd09f@sapienti-sat.org> Date: Wed, 26 Jul 2017 00:36:28 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] questions about section 5.1.1 of the new ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 22:36:32 -0000 On 26.07.2017 00:29, Kurt Andersen (b) wrote: > On Tue, Jul 25, 2017 at 2:44 PM, Juri Haberland > wrote: >> On 25.07.2017 21:31, Gene Shuman wrote: >> > inbound -> policyspf(or some other spf check) -> OpenDKIM -> OpenDMARC >> -> >> > OpenARC Validation -> mailing list software -> OpenArc Signature -> >> > outbound. >> >> Well, OpenARC validation should be before OpenDMARC... > > Well, that depends on your implementation. If you generally evaluate local > policy conditions before checking the primary DMARC mechanisms, then yes; > otherwise, ARC only needs to be evaluated if DMARC does not achieve a PASS > from the primary mechanism or if you expect to break the message's > authentication. Granted, both ways are possible :) Juri From nobody Tue Jul 25 15:48:25 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10075131FE3 for ; Tue, 25 Jul 2017 15:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WcGxC80ZvQ7 for ; Tue, 25 Jul 2017 15:48:20 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65D2E131FDE for ; Tue, 25 Jul 2017 15:48:20 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id j32so40861937iod.0 for ; Tue, 25 Jul 2017 15:48:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RZDQDS7lnK9cq6AXDL/rnNy2OZkQSKtdvYv71VNPbUk=; b=LYOfnoD0rWWskMl4aLBu6lwfqfDdOSDBBo1uHAg6H2uNBuEwGOMjL8fmhqKnvbJlpX eCGeK082k3YyBojH1m+e52zVLLFtCcFWpPcnsiHMZv02CcakRBk4gAA0HF0hMFu9OtOM RZSbYmPOGPShPNtTxd4vVj/yqseBHdFh2HsWIKC9uhSN306FSb6WpJAasFfL6LD7wSav xNOzn3xS8wcTJhrbu82OgmV6zg/MJu3Hhqvz7CmRtMEzLdNODU18Rpvv0G1Ru0RUQBDb /rvGXu8Q85D86M8LzdWc2cAotjDNjHaXDvNXzLIWJVbKVUt5myJVfZYk+DP/b9Zlootk GbuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RZDQDS7lnK9cq6AXDL/rnNy2OZkQSKtdvYv71VNPbUk=; b=Wr6mvfD/vPjumkGx5SMBqa4miyFb6330LQNY9TnjL2yFW7FLQFaiCy3OV4m1HgFWCN 9IQt5XMRfFtw3FQs8HU/pI2YyjxwE98MWPo4eGZhV/iB8ktWSv93g+ygwav+pT48cSPn 9f9oT4GQefX03ABl3i49iIFAl3Fa4hBzrnbLdcukTsnCpDF4Oc66NKhz54LlN31tbbpo vWtDDVXlwLYGPnMyq5Z/ramEuT1bAL/SEyivYhczecT+Hjy5ZZNvr9DvYxQdcb+9LWK+ LHxSjcpRTVPbKum/3804AvtM3+AZTPcbowL1MOjkeInQeIwmrnfcYtiJj/wkI70K8LrM 9Vrw== X-Gm-Message-State: AIVw113WvQFQf9LGMh3dXWVB/qgoZbtM1+Zl3DZgjJGjl4+sIH69gp8J PoLIMrHnOTFdMK8E6wX8wbUoJ1lEpw== X-Received: by 10.107.192.135 with SMTP id q129mr20794888iof.63.1501022899731; Tue, 25 Jul 2017 15:48:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.106.130 with HTTP; Tue, 25 Jul 2017 15:48:19 -0700 (PDT) In-Reply-To: <9f93d9c9-5c84-9f78-6b22-2c637efdd09f@sapienti-sat.org> References: <9f93d9c9-5c84-9f78-6b22-2c637efdd09f@sapienti-sat.org> From: Gene Shuman Date: Tue, 25 Jul 2017 15:48:19 -0700 Message-ID: To: Juri Haberland Cc: dmarc@ietf.org Content-Type: multipart/alternative; boundary="001a114f1d2ebd16a205552c204a" Archived-At: Subject: Re: [dmarc-ietf] questions about section 5.1.1 of the new ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 22:48:24 -0000 --001a114f1d2ebd16a205552c204a Content-Type: text/plain; charset="UTF-8" I do not have any better ideas. I just wanted to make sure I understood the situation correctly atm. On Tue, Jul 25, 2017 at 3:36 PM, Juri Haberland wrote: > On 26.07.2017 00:29, Kurt Andersen (b) wrote: > > On Tue, Jul 25, 2017 at 2:44 PM, Juri Haberland > > wrote: > >> On 25.07.2017 21:31, Gene Shuman wrote: > > >> > inbound -> policyspf(or some other spf check) -> OpenDKIM -> > OpenDMARC > >> -> > >> > OpenARC Validation -> mailing list software -> OpenArc Signature -> > >> > outbound. > >> > >> Well, OpenARC validation should be before OpenDMARC... > > > > Well, that depends on your implementation. If you generally evaluate > local > > policy conditions before checking the primary DMARC mechanisms, then yes; > > otherwise, ARC only needs to be evaluated if DMARC does not achieve a > PASS > > from the primary mechanism or if you expect to break the message's > > authentication. > > Granted, both ways are possible :) > > Juri > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --001a114f1d2ebd16a205552c204a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I do not have any better ideas.=C2=A0 I just wanted to mak= e sure I understood the situation correctly atm. =C2=A0

On Tue, Jul 25, 2017 at 3:36 PM= , Juri Haberland <juri@sapienti-sat.org> wrote:
On 26.07.2017 00:29, Kurt Andersen (b) wrote: > On Tue, Jul 25, 2017 at 2:44 PM, Juri Haberland <juri@sapienti-sat.org>
> wrote:
>> On 25.07.20= 17 21:31, Gene Shuman wrote:

>> > inbound -> policyspf(or some other= spf check)=C2=A0 -> OpenDKIM -> OpenDMARC
>> ->
>> > OpenARC Validation -> mailing list software -> OpenArc = Signature ->
>> > outbound.
>>
>> Well, OpenARC validation should be before OpenDMARC...
>
> Well, that depends on your implementation. If you generally evaluate l= ocal
> policy conditions before checking the primary DMARC mechanisms, then y= es;
> otherwise, ARC only needs to be evaluated if DMARC does not achieve a = PASS
> from the primary mechanism or if you expect to break the message's=
> authentication.

Granted, both ways are possible :)

=C2=A0 Juri

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

--001a114f1d2ebd16a205552c204a-- From nobody Thu Jul 27 18:19:47 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1198131ED3 for ; Thu, 27 Jul 2017 18:19:44 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 0aszLCiGlI43 for ; Thu, 27 Jul 2017 18:19:40 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B70B131ED2 for ; Thu, 27 Jul 2017 18:19:40 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id a9so121788566oih.0 for ; Thu, 27 Jul 2017 18:19:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=54lPPOxfgOzy8xRpqtGQxVBlurqcAB6GZqcT2093jK8=; b=E5lktl6edQlAOxUtcUc9g3+T/GDTI2xgjMUXGFdhBi68FRT87F2YsWgysKFcpiZjGH RbAm+2KJHAIlYLmORbbO5izG0wOGzytWLz3OZd1GaQ1F/ZVbSc2DYCVxjRMjEMI4gAXS 5ny4OTA62/sWTYKFRU7Yum9dVvX0+zeck7VWGRiFeJ2iidvUrxgj1etPSq0pbFoDksoe xOZ5oYrZb93NSWBdwEjMySAal2vbzvFBt6GUm5lDoyvqi5gQTw/G4pqV2bE2225bIkEw pLvstgxniY0Q9LjqlqZbaNFwVgMi41vB/+Fgd0jjj02PTsbsTPvYhEV1nUSv1rQrQ0n2 NUTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=54lPPOxfgOzy8xRpqtGQxVBlurqcAB6GZqcT2093jK8=; b=a3XyukEgGBOQAcW3bb7v+3iL/2fHCT9QMboYEuPBkDtoqktAeN5XnspXF6bufORNhy ER/K4ZChMZIcBoIqiyKfXL8O1ZuBykTeoQq9qev7cTBW3SqC9Li80wb+4/EZvbmRtorr wm2SaMZ1MoRdW+fiuilBwhF74XU7XXOe0diP2mlHhXASfQTPq0n03yQX8TvXZuDP7Bw0 J/3It4WGu3WjEkxh1QJdlaaj9nViRVI3K9Cz+YxsLxl9VyHxErSj31owl0pVjuhyXJRx 22bkDBAvWWwDKbAhYXFnljxshVzBq3GnHvpV7AAmK00PNeINpKXv9trUaHRbibxmlkoc jcYQ== X-Gm-Message-State: AIVw111xQ3BJcwXURuj7FIKJ5fxYuy6X41Cgpa4H4ah6SUovKmhfm0ao uaiOaQGNZAYEab21R/s= X-Received: by 10.202.223.194 with SMTP id w185mr4761230oig.108.1501204777801; Thu, 27 Jul 2017 18:19:37 -0700 (PDT) Received: from ?IPv6:2602:304:cda0:8800:17b:a984:ed61:bea9? ([2602:304:cda0:8800:17b:a984:ed61:bea9]) by smtp.gmail.com with ESMTPSA id g138sm11115100oic.11.2017.07.27.18.19.35 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Jul 2017 18:19:36 -0700 (PDT) From: Dave Crocker To: "dmarc@ietf.org" Message-ID: Date: Thu, 27 Jul 2017 18:19:34 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [dmarc-ietf] Review of: draft-ietf-dmarc-arc-protocol-08 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 01:19:45 -0000 Review of: draft-ietf-dmarc-arc-protocol-08 Reviewed by: D. Crocker Review date: 27 July 2017 Summary: ARC essentially takes the basic technology of DKIM and modifies it to support an integrated sequence (ordered chain) of signatures by successive message handling intermediaries. The essential purpose of ARC is to develop a secondary foundation of message accountability, if the primary foundation -- authentication of the originating service -- fails. The overall structure of the specification seems reasonable, except that signing should be covered before verifying, and the 'implementation status' section should be in the appendix (even though it's marked for removal.) The document suffers a predictable problem, given that it builds upon existing documentation: it forces the reader to jump back and forth between the existing documents and the current specifications. Worse, it often does not supply enough detail in references to make this cross-referencing easy. Also worse is that it sometimes seeks to summarize or re-state normative text from the existing documentation, thereby running the risk of inaccuracies or divergence. Sometimes the document contains language purporting to be normative but lacking technical detail. Typically, these really are mild advisories and should be altered to softer language or even removed. The basic question that needs to be asked repeatedly throughout the text is: how will a new implementer be able to use this text to produce reliably interoperable software? The document seems to mix protocol specification with development guidance and operations guidance. It needs to separate these much better and distinguish them more carefully. I thought an essential motivation for ARC was to create a signature that would be more survivable than a simple DKIM signature. Perhaps that's no longer the case and that, rather, the goal is simply to create a /replacement/ (set of) signature(s), after breaking the original. The intro to the spec should make a clear, direct, simple statement about this. There are some portions of the document that seems to be modifying DKIM or SMTP, such as specifying SMTP response behavior. While I know that DKIM did this about SMTP, too, I suggest refraining from it here: Specify and ARC engine and an overall ARC service that has inputs, processing and output. Don't specify how those outputs are used. d/ Detailed Comments: (these are, essentially, stream of conscious and include high-level and nit-picking detailed comments mixed together, essential and trivial. /d) > Abstract > > The Authenticated Received Chain (ARC) protocol creates a mechanism > whereby a series of handlers of a message can conduct authentication > of a message as it passes among them on the way to its destination, > and record the status of that authentication at each step along the > handling path, for use by the final recipient in making choices about > the disposition of the message. 'authentication of a message' has a formal correctness but problematic effect. It encourages misinterpreting the mechanism as 'validating' message content. We already see this regularly, such as about DKIM, so we should avoid language that encourages more of it. The summary should provide a careful, constrained statement of the narrow functionality that ARC provides. I suggest something along the lines of what I offer, below, as "Replace An Authenticated with:". > Table of Contents Overall, the organization looks reasonable. > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 > 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 > 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 > 4. Instance ('i=') Tags . . . . . . . . . . . . . . . . . . . . 5 > 4.1. Valid Range for Instance Tags . . . . . . . . . . . . . . 6 > 5. The ARC Header Fields . . . . . . . . . . . . . . . . . . . . 6 > 5.1. ARC-Authentication-Results (AAR) . . . . . . . . . . . . 6 > 5.1.1. Additional Information for the AAR Header . . . . . . 7 > 5.2. ARC-Message-Signature (AMS) . . . . . . . . . . . . . . . 7 > 5.3. ARC-Seal (AS) . . . . . . . . . . . . . . . . . . . . . . 8 > 5.3.1. The 'cv' Tag . . . . . . . . . . . . . . . . . . . . 9 > 5.3.2. Selected Header Fields . . . . . . . . . . . . . . . 9 > 6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . 9 Seems odd to have verifier before signer. > 7. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . 11 > 8. Key Management . . . . . . . . . . . . . . . . . . . . . . . 12 > 9. Usage of ARC and Chain Validity . . . . . . . . . . . . . . . 12 > 9.1. Relationship between DKIM-Signature and AMS signing > scopes . . . . . . . . . . . . . . . . . . . . . . . . . 12 > 9.2. Assessing Chain Validity Violations . . . . . . . . . . . 12 > 9.3. Marking and Sealing "cv=fail" (Invalid) Chains . . . . . 12 > 9.4. Handling DNS Problems While Validating ARC . . . . . . . 13 > 9.5. Responding to ARC Validity Violations . . . . . . . . . . 13 > 9.6. Recording the Results of ARC Evaluation . . . . . . . . . 13 > 9.6.1. Output Information from an ARC Evaluation . . . . . . 13 > 9.6.2. Reporting ARC Effects for DMARC Local Policy - > Interim . . . . . . . . . . . . . . . . . . . . . . . 14 > 10. Supporting Alternate Signing Algorithms . . . . . . . . . . . 14 > 10.1. Introductory Period . . . . . . . . . . . . . . . . . . 15 > 10.2. Co-Existence Period . . . . . . . . . . . . . . . . . . 15 > 10.3. Deprecation Period . . . . . . . . . . . . . . . . . . . 15 > 10.4. Obsolescence Period . . . . . . . . . . . . . . . . . . 15 > 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15 > 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 > 12.1. Authentication-Results Method Registry Update . . . . . 15 > 12.2. Definitions of the ARC header fields . . . . . . . . . . 16 > 13. Implementation Status . . . . . . . . . . . . . . . . . . . . 17 This section should be moved to an Appendix, even though it's marked for removal upon publication. > 13.1. GMail test reflector and incoming validation . . . . . . 17 > 13.2. AOL test reflector and internal tagging . . . . . . . . 18 > 13.3. dkimpy . . . . . . . . . . . . . . . . . . . . . . . . . 18 > 13.4. OpenARC . . . . . . . . . . . . . . . . . . . . . . . . 18 > > > > Andersen, et al. Expires January 22, 2018 [Page 2] > > Internet-Draft ARC-Protocol July 2017 > > > 13.5. Mailman 3.1+ patch . . . . . . . . . . . . . . . . . . . 19 > 13.6. Copernica/MailerQ web-based validation . . . . . . . . . 20 > 13.7. Rspamd . . . . . . . . . . . . . . . . . . . . . . . . . 20 > 13.8. PERL Mail::Milter::Authentication module . . . . . . . . 21 > 14. Security Considerations . . . . . . . . . . . . . . . . . . . 21 > 14.1. Message Content Suspicion . . . . . . . . . . . . . . . 22 > 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 > 15.1. Normative References . . . . . . . . . . . . . . . . . . 22 > 15.2. Informative References . . . . . . . . . . . . . . . . . 24 > 15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 25 > Appendix A. Appendix A - Example Usage (Obsolete but retained > for illustrative purposes) . . . . . . . . . . . . . 25 > A.1. Example 1: Simple mailing list . . . . . . . . . . . . . 25 > A.1.1. Here's the message as it exits the Origin: . . . . . 25 > A.1.2. Message is then received at example.org . . . . . . . 26 > A.1.3. Example 1: Message received by Recipient . . . . . . 28 > A.2. Example 2: Mailing list to forwarded mailbox . . . . . . 29 > A.2.1. Here's the message as it exits the Origin: . . . . . 29 > A.2.2. Message is then received at example.org . . . . . . . 30 > A.2.3. Example 2: Message received by Recipient . . . . . . 34 > A.3. Example 3: Mailing list to forwarded mailbox with source 36 > A.3.1. Here's the message as it exits the Origin: . . . . . 36 > A.3.2. Message is then received at example.org . . . . . . . 37 > A.3.3. Example 3: Message received by Recipient . . . . . . 42 > Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 44 > Appendix C. Comments and Feedback . . . . . . . . . . . . . . . 45 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 > > 1. Introduction > > Modern email authentication techniques such as the Sender Policy > Framework (SPF) [RFC7208] and DomainKeys Identified Mail (DKIM) > [RFC6376] have become ubiquitious. However, they are stymied by a ubiquitous > small number of common applications, most notably mailing list > managers, as these applications have handling properties that prevent > these authentication schemes from universal effectiveness. These Replace the However sentence with: However, their end-to-end utility is limited by the effects of intermediaries along the transmission path, which either are not registered (for SPF) or which break digital signatures (for DKIM). > issues are described in substantial detail in those protocols' > defining documents as well as in [RFC6377] and [RFC7960]. > > In an effort to reduce the success of fraudulent email campaigns, > there has been an effort to develop and deploy technologies that use > SPF and DKIM to assure legitimate use of the identity of the apparent > message author, i.e., the visible "From:" field in a message. To Replace first and second sentences with: Technologies that build upon the use of SPF and DKIM can reduce the success of fraudulent email campaigns. To this end, Domain-based Mail Authentication, Reporting and Compliance (DMARC) [RFC7489], ensures legitimate use of the rfc5322.From author header field, by validating the domain name used in its address. > this end, Domain-based Mail Authentication, Reporting and Compliance > (DMARC) [RFC7489] has been developed and deployed. However, its > deployment in environments where mailing lists are used has had the > negative impacts predicted in the documents listed above. Consider replacing However with: However its use along email transmission paths that have independent intermediaries, such as some forwarders and essentially all mailing list services, produces false positive rejections that are problematic, both for the message authors and for those they are interacting with. > > > Andersen, et al. Expires January 22, 2018 [Page 3] > > Internet-Draft ARC-Protocol July 2017 > > > What is needed is a mechanism by which legitimate alteration of a > message, invalidating SPF and DKIM, does not ultimately result in a invalidating SPF and DKIM -> which invalidates associated SPF and DKIM information > rejection of an email message on delivery. An Authenticated Received > Chain (ARC), described here, provides a superset of the functionality > of DKIM in order to provide to the message recipient system(s) a more > complete view into the handling chain of a message and the points in > that chain where alterations of the content may have occurred. Replace An Authenticated with: Authenticated Receive Chain (ARC) builds upon DKIM mechanisms, to provide a sequence of signatures that are more survivable than DKIM's and that provide a view of the handling sequence for a message, especially the points where alterations of the content might have occurred. > Equipped with this more complete information, the recipient system(s) > can make a more informed handling choice, reducing or eliminating the > false postives inherent in use of DKIM and/or SPF themselves. positives > 2. Overview > > In DKIM, every participating signing agent attaches a signature that content -> some content (there continues to be a misunderstanding of what the signature covers; so a bit of qualifying language is needed.) > is based on the content of the message, local policy, and the domain > name of the participating Administrative Management Domain (ADMD). > Any verifier can process such a signature; a verified signature means ...a verified signature means that the domain referenced in the DKIM-Signture: "d=" parameter has some responsibility for handling the message. An artifact of using digital signature technology for this means that verification also ensures that... > the message content that was "covered" by the signature has not been > altered since the signature was applied. The signatures themselves > are generally independent of one another. That last sentence is true, of course, but I think I don't know what it actually means or, more importantly, what it intends to imply. > > By contrast, this protocol seeks to have each signature be able to this protocol seeks to have each signature be able to convey -> an ARC signature conveys > convey the following pieces of information: > > 1. An assertion that, at the time that the intermediary ADMD > processed the message, the various assertions already attached to > the message by other ADMDs were or were not valid; "the various assertions" hmmm. Too vague and broad, since it won't cover random other specifications that are created later. So while it's a pain, this text needs to be more specific. I that what is meant here is only and specifically that a particular DKIM signature, which now is probably broken, validated. I'm not clear about precise, formal security geek language, but I think that a signature is not an 'assertion'...? (This is a nit-picky concern about overloading a term of art.) > > 2. As with DKIM, an assertion that, for a passing signature, the passing -> validated > domain name in the signature takes some responsibility for > handling of the message and that the message is unchanged since > that signature was applied; > > 3. A further assertion that combines and protects the above against > alteration by later handlers. I think I don't know what this means, especially the idea than an assertion can create protection. > > This protocol accomplishes each of these by adding a new header field > to the message for each of them, as follows: "of them"? who is being referenced? Perhaps: ARC accomplishes these by having each later handler add a new header field to the message. (except that it doesn't have to be each new handler, does it? only some... hmmm... ) > > o ARC-Authentication-Results (referred to below as "AAR"): virtually > identical in syntax to an Authentication-Results field [RFC7601], > this field records the results of all message authentication > checks done by the recording ADMD at the time the message arrived. > Additional information is added to this field compared to a > standard Authentication-Results field in order to support a more > complete DMARC report (see Section 5.1); added to this field compared to a standard Authentication-Results -> placed in this field > > > > > > Andersen, et al. Expires January 22, 2018 [Page 4] > > Internet-Draft ARC-Protocol July 2017 > > > o ARC-Message-Signature (referred to below as "AMS"): virtually > identical in syntax to DKIM-Signature, this field contains the > assertions about the message header and body as they existed at > the time of handling by the ADMD adding it; and assertions? > > o ARC-Seal (referred to below as "AS"): highly similar in structure > and format to a DKIM-Signature, this field applies a digital > signature that protects the integrity of all three of these new > fields when they are added by an ADMD, plus all instances of these > fields added by prior ADMDs. > > A distinguishing feature of all of these is that an ARC participant participant -> signer > always adds all of them before relaying a message to the next I don't understand what is being distinguished here, since they aren't going to add the fields /after/ relaying. > handling agent en route to its destination. Moreover, as described > in Section 4, they each have an "instance" number that increases with > each ADMD in the handling chain so that their original order can be > preserved and the three of them can be processed as a group. of them -> related header fields Hmmm. DKIM does it's signing with only a single field. ARC requires -Seal and -Message-Signature. It isn't clear why two different signature fields are required. > > 3. Terminology In this case, the section should be "Definitions and Terminology" since it's also the place for importing spec details from other specs. For a specification like this, that builds upon a number of existing documents, the challenge for the writer is to avoid creating redundant text that risks divergence from the original specification. The challenge for the reader is to find the definition of a term, without having to search across the multiple, underlying documents. To this end, I suggest listing here the terms that are being imported, citing what document (and section) they come from, but without re-defining them. So, for example: ADMD - [RFC5598], Section 2.3 MTA - [RFC5598], Section 4.3.2 MSA - [RFC5598], Section 4.3.1 MDA - [RFC5598], Section 4.3.3 > This section defines terms used in the rest of the document. > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119]. > > Readers are encouraged to be familiar with the contents of [RFC5598], > and in particular, the potential roles of intermediaries in the > delivery of email. The doc relies on terminology from 5598, so you are doing more than encouraging. > > Syntax descriptions use Augmented BNF (ABNF) [RFC5234]. > > A single group of the header fields introduced in Section 2 is called > an "ARC set", and the complete sequence of these groups is called an > "Authenticated Received Chain" or merely an "ARC chain". Although > the "Received" header field is typically not included in the signed > content, the name is based on the notion that this is in essence a > cryptographically signed series of header fields that attest to the > handling chain of a message much as Received fields always have. Stylistic nit: When defining/explaining terms, use a hanging indent format, starting with the term, so the terms being defined stand out visually. This spec imports language, syntax, and other details from DKIM. That importation should be specified here. (RFC6376). > 4. Instance ('i=') Tags > > The header fields comprising a single ARC set are identified by the > presence of a string in the value portion of the header field that > complies with the "tag-spec" ABNF found in Section 3.2 of [RFC6376]. > The tag-name is always the single character "i" and the value is the > text representation of a positive integer, indicating the position in Tags -> Tag (?) The 'is always' phrasing is odd. Rather: The tag-name is "i" and the value is the ... > > > > Andersen, et al. Expires January 22, 2018 [Page 5] > > Internet-Draft ARC-Protocol July 2017 > > > the ARC sequence this set occupies, where the first ARC set is > numbered 1. In ABNF terms: > > instance = [FWS] %x69 [FWS] "=" [FWS] 1*DIGIT [FWS] ";" For referential benefit, I'm be inclined to suggest: instance = [FWS] %x69 [FWS] "=" [FWS] position [FWS] ";" position = 1*DIGIT > At any delivery stage, it is an error if any ARC set is invalid > (i.e., does not contain exactly one of the three header fields This sentence is out of place and it's import is unclear. It refers to the set rather than to i=; so it shouldn't be in this section. And there's no basis, yet, for knowing what 'an error' means in terms of processing ARC. The essential point here is simply that a valid set MUST contain all three header fields. > defined by this protocol). (Note that when multiple algorithms are > supported, there is some nuance to this statement - see Section 10.) > > Note that because the AMS and AS header field values are made up of > tag-spec constructs, the i= tag may be found anywhere within the > header field value, but is represented throughout this spec in the > initial position for convenience. Implementers SHOULD seek to start > with the i= tag to facilitate human inspection o f the headers. The SHOULD is formally inappropriate, since the behavior is, by the earlier language, not normative. So, downgrade the language to 'encouraged' or somesuch. > > 4.1. Valid Range for Instance Tags > > The 'i' tag value can range from 1-1024 (inclusive). Why 1024? > ARC implementations MUST support at least ten (10) intermediary > steps. I think this is meant to say 'ten (10) ARC sets.' > More than fifty (50) intermediaries is considered extremely unlikely > so ARC chains with more than fifty intermediaries may be marked with > "cv=fail". may -> MAY Still, this is odd language for a specification, since its non-determinimism ensures inconsistent behavior across implementation. That always produces non-interoperability. Define a firm limit. Enforce it. Or... Absent the ability to agree on that limit, indicate that the operational limit, if any, will be developed through field experience and documented separately. Or somesuch. > 5. The ARC Header Fields > > The three header fields that are part of this specification borrow > heavily from existing specifications. Rather than repeating all of > the formal definitions that are being reused in ARC, this document > only describes and specifies changes in syntax and semantics. This paragraph belongs in terminology and definitions, listing the specs that are drawn from. That provides enough context so the details, below, just need to cite their base document as is done. > > 5.1. ARC-Authentication-Results (AAR) > > The ARC-Authentication-Results header field is defined. It is [defined. It is] remove > syntactically and semantically identical to an Authentication-Results > header field [RFC7601] (A-R), as is the mechanism by which it is > constructed, with the following exception: IETF specs do not dictate implementation and therefore do not specify mechanisms for construction. So I don't know what is meant by such phrasing here. I suspect that the 'as is' clause should be removed. > o There is an "i" tag, as described in Section 4; and > > o Two (or more) additional pieces of information MAY be added (see > Section 5.1.1). > > The instance identifier MUST be separated from the rest of the > Authentication-Results value contents with a semi-colon (';', 0x3b). > > > > Andersen, et al. Expires January 22, 2018 [Page 6] > > Internet-Draft ARC-Protocol July 2017 > > > The purpose of this header field is to incorporate into the record > the success or failure of any authentication done on the message > upstream of the participating ADMD, to validate and continue the > authentication chain. the participating ADMD, to validate and continue -> the participating ADMD that is validating and continuing > > In processing, some architectures will generate multiple A-R records "some architectures" ? What does this mean? Perhaps simply some participating ADMDs? > for the same authserv-id. In such cases, the resinfo value from each > of the A-R records should be concatenated into a single record just > as they would have been if they were generated in a single A-R > record. 'should'? is that meant normatively? if not, this would be a good place for a different word. > > 5.1.1. Additional Information for the AAR Header > > An ARC signer generates this field in the same way that a > conventional A-R field would be generated. Because the AAR is "the same way"? what does this mean? sounds implementation-ish and in any event provides no specification (or even implementation) detail. > designed for machine-based consumption over the course of a message's > transit through a series of mediators and to facilitate > troubleshooting of problematic sources by sending organizations, This 'because' statement appears to be asserting justification that has no foundation in the document (or at least not so far.) Also reference to machine consumption isn't very helpful, since nearly all of these specs are to produce machine-processable data. The phrase 'troubleshooting of problematic sources by sending organizations' is confusing, since sources do sending. My best guess for improving this: 1. In the intro to AAR, explain what its purpose(s) is (are). 2. In 5.1 explain how it is achieves those purposes. 3. In 5.1.1 simply say something like: Troubleshooting problematic ADMDs that are participating in ARC is aided by including the following trace information: > three additional fields of data SHOULD be added to the normal A-R > content, dependent on the presence of DKIM-Signature and/or ARC > set(s) and if available to the ADMD which is recording the A-R: > > o source.ip - The connecting client IP address from which the > message is received; and if you want to save a couple of characters: source -> src > o header.s - The selector value associated with each dkim signature > (added to the dkim data sections of the A-R/AAR record) That's far too generic. I suggest naming this more meaningfully and intuitively, such as: dkim.sel > o ARC-related data (added to the arc data sections of the A-R/AAR > record): > > * ams[N].d - The domain value associated with the 'N'th ARC set's > AMS header > > * ams[N].s - The selector associated with the 'N'th ARC set's AMS > header > > * as[N].d - The domain value associated with the 'N'th ARC set's > AS header > > * as[N].s - The selector associated with the 'N'th ARC set's AS > header header -> header field > 5.2. ARC-Message-Signature (AMS) > > The ARC-Message-Signature header field is defined. It is > syntactically and semantically identical to a DKIM-Signature header The ARC-Message-Signature header field is defined. It is -> The ARC-Message-Signature header field is > > > Andersen, et al. Expires January 22, 2018 [Page 7] > > Internet-Draft ARC-Protocol July 2017 > > > field [RFC6376], as is the mechanism by which it is constructed, with > the following exceptions: [as is the mechanism by which it is constructed,] delete > o There is an "i" tag, as described in Section 4. > > o There is no "v" tag. > > ARC-Seal header fields MUST never be included in the content covered > by the signature in this header field. MUST never -> MUST NOT > The AMS SHOULD include any DKIM-Signature header fields already > present on the message in the header fields covered by this > signature. > > The AMS header field MAY inclue (sign) the AAR header field(s). inclue -> include > Authentication-Results header fields SHOULD NOT be included since > they are likely to be deleted by downstream ADMDs (per Section XXX of > [RFC7601]), thereby breaking the AMS signature. > > As with a DKIM-Signature, the purpose of this header field is to > allow the ADMD generating it to take some responsibility for handling > this message as it progresses toward delivery. What is the logic for the various MUST, SHOULD and MAY directives about inclusion? What are the downsides of not following the SHOULD or MAY? > 5.3. ARC-Seal (AS) > > The ARC-Seal header field is defined. It is syntactically and > semantically similar to a DKIM-Signature field, with the following > exceptions: The ARC-Seal header field is defined. It is -> The ARC-Seal header field is > o There is an "i" tag, as described in Section 4. > > o The ARC-Seal covers none of the body content of the message. It > only covers specific header fields. (See below: Section 5.3.2.) > As a result, no body canonicalization is done. Further, only > "relaxed" header canonicalization (Section 3.4.2 of [RFC6376]) is > used. > > o The only supported tags are "i" (Section 4 supercedes the > [RFC6376] definition), and "a", "b", "d, "s", "t". The latter 5 > tag definitions are copied from Section 3.5 of [RFC6376]. > > o An additional tag, "cv" is defined. (See below: Section 5.3.1) > > The purpose of this field is to assure the integrity of the ARC set > being added by the ADMD generating this header field, and moreover to > ensure no tampering with the ARC overall. This explanation is redundant with the explanation in the defining 5.3.1 section (or, at least, it should be) and hence is not needed. Remove it. Redundant text invites divergence. > Andersen, et al. Expires January 22, 2018 [Page 8] > > Internet-Draft ARC-Protocol July 2017 > > > 5.3.1. The 'cv' Tag > > A new tag "cv" (chain validation) is defined, which indicates the > state of the ARC chain as evaluated when it arrived at the ADMD > adding this header field. It accepts one of three possible values: A new tag "cv" (chain validation) is defined, which indicates -> The tag "cv" (chain validation) indicates the state of the ARC chain as evaluated when it arrived at the ADMD adding this header field. -> the outcome of evaluating the existing ARC chain upon arrival at the ADMD that is adding this header field. > o none: There was no chain on the message when it arrived for > validation; typically occurs when the message arrives at a Message > Transfer Agent (MTA) from a Message Submission Agent (MSA) or when > any upstream MTAs may not be participating in ARC handling; > > o fail: The message has a chain whose validation failed; > > o pass: The message has a chain whose validation succeeded. > > In ABNF terms: > > seal-cv-tag = %x63.76 [FWS] "=" [FWS] ("none" / "fail" / "pass") > > 5.3.2. Selected Header Fields > > The ARC-Seal signature is an encryption of the hash of the > concatenation of the canonicalized form of the ARC sets present on > the message at the time of sealing, in increasing instance order, > starting at 1, including the one being added at the time of sealing > the message. The above paragraph appears to be the only actual 'detailed' specification of what an ARC signature is, and it is both obscure and too dense. It needs to be re-formed into an algorithm specification. I suspect it also needs to be moved to the section on signing. > > Within a set, the header fields are presented in the following order: presented -> listed > 1. ARC-Authentication-Results > > 2. ARC-Message-Signature > > 3. ARC-Seal > > Where the ARC-Seal is the one being generated, it is presented to the > hash function in its final form except with an empty "b=" value, in > the same manner by which a DKIM-Signature signs itself. presented -> added (or input) > Note that the signing scope for the ARC-Seal is modified in the > situation where a chain has failed validation (see Section 9.3). > > 6. Verifier Actions > > The verifier takes the following steps to determine the current state > of the ARC on the message: state of the ARC? perhaps ARC /chain/ or ARC signature chain? > > > > Andersen, et al. Expires January 22, 2018 [Page 9] > > Internet-Draft ARC-Protocol July 2017 > > > 1. Collect all ARC sets currently on the message. If there were > none, the ARC state is "none" and the algorithm stops here. > > 2. If any ARC set is invalid (e.g., does not contain exactly one of > each of the three ARC-specific header fields), then the chain > state is "fail" and the algorithm stops here. If any ARC set -> If the form of any ARC set This step is not doing computational validation; that's steps 3 & 4. So I assume this step is for basic, structural validation. Essentially a kind of syntax check. > > 1. To bypass all cryto and DNS operations, the cv value for all > ARC-Seal(s) MAY be checked at this point. If any of the > values are "fail", then the overall state of the chain is > "fail" and the algorithm stops here. cryto -> crypto The 'bypass' sentence confused me a bit. I think what is intended is something like: To avoid the overhead of unnecessary computation and delay, the cv= value for all existing ARC-Seals MAY be checked at this point. If ... > 3. Conduct verification of the ARC-Message-Signature header field > bearing the highest instance number. If this verification fails, > then the chain state is "fail" and the algorithm stops here. > > 4. For each ARC-Seal from the "N"th instance to the first, apply the > following logic: Having subordinate numbering be the same style as the superior could be confusing. Readability would be improved by using a different style. I suggest switching to lower case letters. An alternative would be two-part numbering. So the one below here would be 4.1. (And I see that that's the notation already in use in this next entry...) > 1. If the value of the "cv" tag on that seal is "fail", the > chain state is "fail" and the algorithm stops here. (note > that this duplicates step 2.1) I suggest replacing the 'note' text with: This step MAY be skipped, if the earlier, step 2.1 was performed. (And the MAY probably should be SHOULD...) > > 2. In Boolean nomenclature: if ((i == 1 && cv != "none") or (cv > == "none" && i != 1)) then the chain state is "fail" and the > algorithm stops here. Why is the i/cv ordering swapped for the two tests? > 3. Prepare a hash function corresponding to the "a" tag of the > ARC-Seal. Where are the technical details for producing the hash formally supplied? Cite them here. And what does the 'corresponding to the "a" tag of the ARC-Seal' mean? > 4. Compute the canonicalized form of the ARC header fields, in > the order described in Section 5.3.2, using the "relaxed" > header canonicalization defined in Section 3.4.2 of > [RFC6376]. Pass them to the hash function. "Pass them to the hash function."? This appears to be specifying input to a function that was performed (and presumably finished) in the preceding step. > 5. Retrieve the final digest from the hash function. So I'm guessing that steps 4.3 - 4.5 are meant as a sub-function, but nothing makes that explicit. At the least, 4.3 should say 'Start' rather than 'Prepare" and possibly the substeps should have sub-numbering. > 6. Retrieve the public key identified by the "s" and "d" tags in > the ARC-Seal, as described in Section 8. > > 7. Determine whether the signature portion ("b" tag) of the ARC- > Seal and the digest computed above are valid according to the > public key. How is this to be determined? > 8. If the signature is not valid, the chain state is "fail" and > the algorithm stops here. > > > > > > Andersen, et al. Expires January 22, 2018 [Page 10] > > Internet-Draft ARC-Protocol July 2017 > > > 5. If all seals pass validation, then the chain state is "pass", and > the algorithm is complete. > > The verifier should record the cv state for subsequent use by any > sealing which may be done later (potentially after message > modification) within the same trust boundary. The cv state may be > recorded by sealing at the time of verification in an initial ARC set > (for the ADMD) or may be recorded out of band depending on the > architecture of the ADMD. To avoid misunderstanding, I suggest altering the first sentence to something like: Save the cv state, for possible use by... The cv state may be -> The cv state MAY be But really, that entire sentence should be deleted. It is not provided specification detail and the implementation guidance is minimal at best. > 7. Signer Actions This section appears to be the very broad strokes of implementation guidance, rather than the details of a protocol specification. It's not clear what benefit this is supposed to provide, but it doesn't seem to have much to do with the semantics or interoperability of ARC. > This section includes a walk-through of the actions an ARC signing > implementation takes when presented with a message. walk-through -> specification Except that this doesn't really read like a formal specification, yet one is needed. signing implementation -> signer > The signing agent should undertake the following steps: should ->? SHOULD but why not MUST? > 1. Do any authentication steps that the ADMD normally does: huh? /any/? What does this mean? Why is it relevant to this specification? How is it used? > 1. If a message is traveling within the same trust boundary, > this would include any internal trust conveyed with the > message; ; -> . > 2. If a message is coming from outside the same trust boundary, > this would include any SPF / DKIM / DMARC / other > authentication evaluation steps. This document is not a specification or BCP for ADMD authentication. So 1.1 and 1.2 really are out of scope (as well as providing inadequate technical detail to be useful.) > 2. Do any DKIM signing or authentication assertion steps that the > ADMD normally does. I suspect that 1 and 2, above, should be replaced with some simple introductory text that says something like: Before creating an ARC signature, perform any other, normal authentication and/or signing, so that the ARC signature can cover the results with this additional information. > 3. Generate and optionally attach to the message an Authentication- > Results header field using the ADMD's authserv-id (see > Section 2.5 of [RFC7601]) indicating whatever authentication > might have been done by the MTA, or possibly indicate that none > was done. optionally? I suspect it's not optional, if they are participating in ARC (and especially not if it's been generated. What benefit is there in generating it if it is not then attached?) same concern for 'possibly'. This text needs to be cast into normative specification language appropriate to a participant in ARC. > 4. Build and attach the new ARC set: > > 1. If an ARC chain exists on the message, then set "N" equal to > the highest instance number found on the chain (i=); > otherwise set "N" equal to zero for the following steps. > > 2. Generate and attach to the message an ARC-Authentication- > Results header field using instance number N+1 and the same > content from the previous step. > > 3. Generate and attach to the message an ARC-Message-Signature > header field using the general algorithm described in [general] delete > > > Andersen, et al. Expires January 22, 2018 [Page 11] > > Internet-Draft ARC-Protocol July 2017 > > > Section 5 of [RFC6376] and as modified in Section 5.1 above, > using instance number N+1. and -> , > 4. Generate and attach to the message an ARC-Seal header field > using the general algorithm described in Section 5.3 above, > the chain validation status as determined in Section 6, and > instance number N+1. [general] delete > 8. Key Management > > The public keys for ARC header fields follow the same requirements, > syntax and semantics as those for DKIM signatures, described in > Section 3.6 of [RFC6376]. Operators may use distinct selectors and/ > or domains for the ARC header fields at their own discretion. Just to avoid the reader's thinking that the 'operators' sentence is normative specification, perhaps modify the last sentence to something like: For operational convenience, signers can choose to use selectors and/or domains for the ARC header field signatures that are distinct from those used in DKIM signing. > 9. Usage of ARC and Chain Validity > > 9.1. Relationship between DKIM-Signature and AMS signing scopes > > DKIM-Signatures SHOULD never sign any ARC header fields. Oh boy. That normative statements constitutes a formal modification to the DKIM specification. While I understand the desire, I recommend against pursuing it this way. Besides, I do not see the actual need for such a normative specification. What is the harm in having a DKIM signature cover any ARC header fields? > 9.2. Assessing Chain Validity Violations > > There are a wide variety of ways in which the ARC set of header are -> is > fields can be broken. Receivers need to be wary of ascribing motive > to such breakage although patterns of common behaviour may provide > some basis for adjusting local policy decisions. If a reader needs this instruction, the probably need a bit more background that the first sentence gives. Perhaps: Email transit can produce broken signatures for a wide variety of benign reasons. This includes possibly breaking one or more ARC signatures. Therefore, receivers need to be wary of ascribing malign motives to such breakable... > This specification is exclusively focused on well-behaved, > participating intermediaries that result in a valid chain of ARC- > related header fields. The value of such a well-formed, valid chain > needs to be interpreted with care since malicious content can be > easily introduced by otherwise well-intended senders through machine > or account compromises. All normal content-based analysis still > needs to be performed on any messages bearing a valid chain of ARC > header sets. First, the paragraph is self-contradictory, since it concern non-well-behaved activities. Second, this is problematic text. Not because it's wrong but because it says far too little. It raises a concern, without really explaining its basis and without giving useful guidance about what to do to compensate for the (possible) problem. I'm guessing about what the underlying issues are, here, but here's an attempt: ARC does not attempt to protect and entire message. There are various ways that a message can still be problematic, in spite of having a valid ARC chain. Consequently, all normal, content-based analysis SHOULD still be performed on any message having a valid chain of ARC header sets. > > 9.3. Marking and Sealing "cv=fail" (Invalid) Chains > > The header fields signed by the AS header field b= value in the case > of a chain failure MUST be only the matching 'i=' instance headers > created by the MTA which detected the malformed chain, as if this > newest ARC set was the only set present. Hmmm. is 'signed by' the correct characterization? I'm asking this as a real question and as a nit about formal language, not really a major concern about reader understanding. > > > > > > > Andersen, et al. Expires January 22, 2018 [Page 12] > > Internet-Draft ARC-Protocol July 2017 > > > 9.4. Handling DNS Problems While Validating ARC > > DNS failures to resolve or return data which is needed for ARC > validation SHOULD result in a 421 tempfail during the SMTP > conversation with the sending system. Temporary or intermittent DNS > problems will generally not be sufficiently transitory to allow a > mediator to obtain a different result during the ordinary transit > duration so it is better to have the source system queue the > problematic message(s) than to generate (potential) backscatter. > > Operators of systems which mediate mail should be aware that broken > DNS records (or malfunctioning name servers) will result in > undeliverable mail to any downstream ARC-verifying ADMDs. > > DNS-based failures to verify a chain are treated no differently than > any other ARC violation. They result in a "cv=fail" verdict. Hmmm. This section seems to be inviting two kinds of problems: directing SMTP behavior and directing interpretation of DNS behaviors. I suggest, instead that the ARC protocol engine be defined in terms of temporary failures and permanent failures and then specify what causes each. How the containing email system should handle those two types of failures should be out of scope for this specification. (I'm suggesting something different and more constrained than the DKIM spec does.) > > 9.5. Responding to ARC Validity Violations > > If a receiver determines that the ARC chain has failed, the receiver > MAY signal the breakage through the extended SMTP response code 5.7.7 > [RFC3463] "message integrity failure" [ENHANCED-STATUS] and > corresponding SMTP response code. > > 9.6. Recording the Results of ARC Evaluation > > Receivers MAY add an "arc=[pass|fail|policy]" method annotation into > a locally-affixed Authentication-Results [RFC7601] header field along > with any salient comment(s). This seems to be augmenting RFC7601? > 9.6.1. Output Information from an ARC Evaluation > > The evaluation of a series of ARC sets results in the following data > which MAY be used to inform local-policy decisions: This is an example of a gratuitous normative statement. First, it has no real substance. Second, it is out of scope of the specification. The spec is defining the ARC engine, input and output. It is /not/ defining how the output is used. So: [which MAY be used to inform local-policy decisions] delete Given that it is the essence of ARC semantics, it might be useful for general consumption, to give a prose summary of this output: Perhaps something like "ARC Chain evaluation produces a list of domain names for intermediaries that handled the message." Or somesuch. > o A list of the "d=" domains found in the validated ARC-Seal header > fields; [;] delete > o The "d=" domain found in the most recent (highest instance number) > AMS header field (since that is the only one necessarily > validated) > > In the case of a failed chain, only the terminal ARC set is covered > by the ARC-Seal so the reporting is limited to the findings in that > terminal ARC set. > > > > > > > Andersen, et al. Expires January 22, 2018 [Page 13] > > Internet-Draft ARC-Protocol July 2017 > > > 9.6.2. Reporting ARC Effects for DMARC Local Policy - Interim I strongly urge moving all discussion of ARC use for DMARC into an independent document. Keep the basic ARC specification a basic ARC specification. Make DMARC policy discussion separate. > [[ Note: Discussion on the IETF DMARC-WG list has indicated some > interest in more substantial reporting for analytic purposes. To > support that effort, the following guidance is provided only as an > interim, minimal data set. A more complete reporting construct will > be specified in a related spec - TBD. (see the additional fields > specified in Section 5.1.1) ]] > > Receivers SHOULD indicate situations in which ARC evaluation > influenced the results of their local policy determination. DMARC > reporting of ARC-informed decisions is augmented by adding a > local_policy comment explanation containing the list of data > discovered in the ARC evaluation (Section 9.6.1 and Section 5.1.1): > > > delivered > fail > fail source.ip=10.0.0.1 > > local_policy > arc=pass ams[2].d=d2.example ams[2].s=s1 as[2].d=d2.example > as[2].s=s2 as[1].d=d1.example as[1].s=s3 > > > > In the suggested sample, d2.example is the sealing domain for ARC[2] > and d1.example is the sealing domain for ARC[1]. > > Mediators SHOULD generate DMARC reports on messages which transit > their system just like any other message which they receive. This > will result in multiple reports for each mediated message as they > transit the series of handlers. DMARC report consumers should be > aware of this behaviour and make the necessary accommodations. > > 10. Supporting Alternate Signing Algorithms > > [[ Note: Some additional development of this section is needed. ]] > > In the following branch diagrams, each algorithm is represented by an > 'A' or 'B' at each hop to depict the ARC chain that develops over a > five hop scenario. 'x' represents a hop that does not support that > algorithm. > > Note that during a transitional period where multiple algorithms are > allowed, all of the statements in this spec which refer to "exactly > one set of ARC headers per instance" need to be understood as "at > > > > > Andersen, et al. Expires January 22, 2018 [Page 14] > > Internet-Draft ARC-Protocol July 2017 > > > least one set per instance and no more than one instance-set per > algorithm". This is an essential restriction/capability and need to be moved to be part of the original specification. There are a few different ways to phrase this and I'm not sure which would work best. > > 10.1. Introductory Period > > Intermediaries MUST be able to validate ARC chains build with either > algorithm but MAY create ARC sets with either (or both) algorithm. build -> built > The introductory period should be at least six (6) months. This has no context nor justification. I assume the section is attempting to talk about the introduction of new signing algorithms and the need to support overlapping use of old and new and the fact that transitions on the Internet take a long time and a signer using a new algorithm needs to assume it might take awhile for all of their receivers to also support it and... > 10.2. Co-Existence Period > > Intermediaries MUST be able to validate ARC chains build with either > algorithm and MUST create ARC sets with both algorithms. Chains > ending with either algorithm may be used for the result. Take this out of normative mode, since it's impractical. The whole reason that an extended transition period is needed is because a requirement like the above won't happen (and in fact can't.) > 10.3. Deprecation Period > > ARC sets built with algorithms that are being deprecated MAY be > considered valid within an ARC chain, however, intermediaries MUST > NOT create additional sets with the deprecated algorithm. Where are the specifications for the procedures to register and deprecate algorithms? Why aren't they cited here? > The deprecation period should be at least two (2) years. I fear that this section is mostly gratuitous, since it doesn't have much import. If someone thinks otherwise, would they please explain what effect any of this will have on developers or operators? > 10.4. Obsolescence Period > > ARC sets built with algorithms that are obsolete MUST NOT be > considered valid within an ARC chain. Intermediaries MUST NOT create > any sets with any obsoleted algorithm. > > 11. Privacy Considerations > > The ARC chain provides a verifiable record of the handlers for a > message. Anonymous remailers will probably not find this to match > their operating goals. to match -> compatible with ... -- Dave Crocker Brandenburg InternetWorking bbiw.net -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Jul 31 10:52:25 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3C5C132739 for ; Mon, 31 Jul 2017 10:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Il0Zme0PMDrP for ; Mon, 31 Jul 2017 10:52:05 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65D5913262A for ; Mon, 31 Jul 2017 10:52:05 -0700 (PDT) Received: (qmail 70918 invoked from network); 31 Jul 2017 17:52:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent; s=11504.597f6e44.k1707; bh=2RiTcoeguCNm5al82aAoB0VgWWWFPBzVdifSBAQxAbY=; b=SzJYZiSXPpg44FL0TyfnBFGphF2ZCX9vh+S0sTs3BVg6Fmc5GabUpmZlsKgIZnE3Fh48AdvC34noZrJUKJtCtfnSB+YZUVQ105tKYIQ3Cr7CjNH/ctefw3iSKbxeYQM0qvrjUsqkBKpIBLaTfrgaRqZ2IXGU4Xrgl+1+ZkbEC1C61NK1Kv6WjUivUy1/QaMv9MOzhwboZGft25D3jdsBCFnNDe+SGlb1Tuup2hIWKNVwcmfqj7J6OudVuoPg6pUt Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 31 Jul 2017 17:52:04 -0000 Date: 31 Jul 2017 13:52:03 -0400 Message-ID: From: "John R. Levine" To: dcrup@ietf.org, dmarc@ietf.org User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: [dmarc-ietf] Did you get survey spam from VT students? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 17:52:12 -0000 I just got spam from a couple of Virginia Tech students with an impressively clueless "survey" about DKIM and DMARC usage. If you got it, could you instead reply to their professor and the VT IRB pointing out that scraping people's addresses from mailing lists is unethical and, in many countries, illegal. The multiple-choice question about DMARC usage did not include any options about DMARC causing more problems than it solved which (whether or not you agree that's the problem) tells us that they didn't do their homework. I could just barely tolerate a survey sent to the relevant mailing lists, but scraping individual addresses is way beyond the pale. Professor: gangwang@vt.edu IRB: moored@vt.edu, terrysparks@vt.edu, ctgreen@vt.edu Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Mon Jul 31 16:20:41 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48AFD1270B4 for ; Mon, 31 Jul 2017 16:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 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, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fiction.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JEcfh9ksXDCp for ; Mon, 31 Jul 2017 16:20:30 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D38AB1327EF for ; Mon, 31 Jul 2017 16:20:29 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id x3so586341oia.1 for ; Mon, 31 Jul 2017 16:20:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fiction.net; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jCAcpCWRuJz1ZfhKdDmVy2b9gJfpiu3yfhogIO0PPes=; b=GeN5WN7HlPq6UAeDmwxlxvl3UwFICjfH0XO/m+JrhhaujjniSzxwC77l0Gly5s2UH2 coaoaG9YU7mFFYETSdxw9FKekdVIUNTMXuxPoDxfCPogJvgeckJEFN9mGtKc1EEO4efr wzBSfJUDqQF2csfl/zC8YwUSQqRgQ22gzb2MzhX03nyMrcHUvLZMLm7zzt73awTZ1eMC tvAGgyfU6MZYIPUjrpiy5nBBBa1I3hfZdenU9C+2BnPDXAJhFpt8BuEHsHxP1iPA4Ewz p2Xvzoxc4upr/yubNP0Yrm/wU1Nlu6EiXjSjk2uw/U1Tsv/zRczF2w0ALpfOjqsCo8CK 7CpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jCAcpCWRuJz1ZfhKdDmVy2b9gJfpiu3yfhogIO0PPes=; b=ugEMyCiUZCnjeUVsu+Udw93akVmx/p3S8NM7+NJqy0YGpOllPlbTi4qU9Y2PsQ00aM CfUIJ5RG6ZW9NQo9xfoPAcUpMgkOSMqZvx1I0rg6tUKLwGay1bDxZsVkvCK5Z2JCwy0T k+56FeePHF/gXoQY5jrzLUmGBzSl4hP/VGb/8gllNQeARaZC8uUKiki4YBRjonL5yYku VrEnX+FoOzbeTGohVmsPW+QStIzk9wSY/Dm49PXN8RTwfQZ53qULfBH7UuhN6hYa7Rwb TqV4qTsPXZ96ScrzQXVIed6En5HlDkTWjuEZUWhMCYjkBTbe+CAeepyETN2SsRcQzhYn eSSQ== X-Gm-Message-State: AIVw110Qhag5jxU7YzTnklsV5KzS2cdLBg9zzPYBnQspRKG7o3Luvmjm JMiu6O6HSXQs0Kxv4zM= X-Received: by 10.202.195.66 with SMTP id t63mr16605247oif.14.1501543228786; Mon, 31 Jul 2017 16:20:28 -0700 (PDT) Received: from mail-oi0-f53.google.com (mail-oi0-f53.google.com. [209.85.218.53]) by smtp.gmail.com with ESMTPSA id t72sm27352654oih.55.2017.07.31.16.20.26 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 31 Jul 2017 16:20:26 -0700 (PDT) Received: by mail-oi0-f53.google.com with SMTP id g131so362533oic.3 for ; Mon, 31 Jul 2017 16:20:26 -0700 (PDT) X-Received: by 10.202.53.195 with SMTP id c186mr16043796oia.46.1501543226255; Mon, 31 Jul 2017 16:20:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.154.51 with HTTP; Mon, 31 Jul 2017 16:20:25 -0700 (PDT) In-Reply-To: References: <9f93d9c9-5c84-9f78-6b22-2c637efdd09f@sapienti-sat.org> From: Brandon Long Date: Mon, 31 Jul 2017 16:20:25 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Gene Shuman Cc: Juri Haberland , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a113cf57c9e25cc0555a5466d" Archived-At: Subject: Re: [dmarc-ietf] questions about section 5.1.1 of the new ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 23:20:38 -0000 --001a113cf57c9e25cc0555a5466d Content-Type: text/plain; charset="UTF-8" Catching up here... Perhaps the traditional separation of all of the mail authenticators is what should change, ie if we combined the various handlers into one, then it becomes much more obvious how the information flow would occur. For our impl, it's just various calls within the single process, hence why it's easy to issue a single authres header as well. Looking at the 5.1.1 section, I do think we should specify that the source.ip is either in the arc section or the spf section, and not leave that to random choice. I also do not like the arc related data as specified. If the arc chain is intact, then the information is trivially extracted from the chain, if it's not intact, then who cares. Even if we want to include this data, I think the fact that we have a chain of data could be used, and therefore we would only include the i-1 hop data in the single aar. Arc-Authentication-Results: i=3; mx.google.com; arc=pass ams.d=google.com ams.s=arc as.d=google.com as.s=arc The spec currently says i can go up to 1024 but unlikely over 50, are we going to generate: Arc-Authentication-Results: i=50; mx.google.com; arc=pass ams49.d=google.com ams49.s=arc-20160816 as49.d=google.com ams49.s=arc-20160816 ams48.d=google.com ams48.s=arc-20160816 as48.d=google.com ams48.s=arc-20160816 ams47.d=google.com ams47.s=arc-20160816 as47.d=google.com ams47.s=arc-20160816 ams46.d=google.com ams46.s=arc-20160816 as46.d=google.com ams46.s=arc-20160816 ams45.d=google.com ams45.s=arc-20160816 as45.d=google.com ams45.s=arc-20160816 ams44.d=google.com ams44.s=arc-20160816 as44.d=google.com ams44.s=arc-20160816 ams43.d=google.com ams43.s=arc-20160816 as43.d=google.com ams43.s=arc-20160816 ams42.d=google.com ams42.s=arc-20160816 as42.d=google.com ams42.s=arc-20160816 ams41.d=google.com ams41.s=arc-20160816 as41.d=google.com ams41.s=arc-20160816 ams40.d=google.com ams40.s=arc-20160816 as40.d=google.com ams40.s=arc-20160816 ams39.d=google.com ams39.s=arc-20160816 as39.d=google.com ams39.s=arc-20160816 ams38.d=google.com ams38.s=arc-20160816 as38.d=google.com ams38.s=arc-20160816 ams37.d=google.com ams37.s=arc-20160816 as37.d=google.com ams37.s=arc-20160816 ams36.d=google.com ams36.s=arc-20160816 as36.d=google.com ams36.s=arc-20160816 ams35.d=google.com ams35.s=arc-20160816 as35.d=google.com ams35.s=arc-20160816 ams34.d=google.com ams34.s=arc-20160816 as34.d=google.com ams34.s=arc-20160816 ams33.d=google.com ams33.s=arc-20160816 as33.d=google.com ams33.s=arc-20160816 ams32.d=google.com ams32.s=arc-20160816 as32.d=google.com ams32.s=arc-20160816 ams31.d=google.com ams31.s=arc-20160816 as31.d=google.com ams31.s=arc-20160816 ams30.d=google.com ams30.s=arc-20160816 as30.d=google.com ams30.s=arc-20160816 ams29.d=google.com ams29.s=arc-20160816 as29.d=google.com ams29.s=arc-20160816 ams28.d=google.com ams28.s=arc-20160816 as28.d=google.com ams28.s=arc-20160816 ams27.d=google.com ams27.s=arc-20160816 as27.d=google.com ams27.s=arc-20160816 ams26.d=google.com ams26.s=arc-20160816 as26.d=google.com ams26.s=arc-20160816 ams25.d=google.com ams25.s=arc-20160816 as25.d=google.com ams25.s=arc-20160816 ams24.d=google.com ams24.s=arc-20160816 as24.d=google.com ams24.s=arc-20160816 ams23.d=google.com ams23.s=arc-20160816 as23.d=google.com ams23.s=arc-20160816 ams22.d=google.com ams22.s=arc-20160816 as22.d=google.com ams22.s=arc-20160816 ams21.d=google.com ams21.s=arc-20160816 as21.d=google.com ams21.s=arc-20160816 ams20.d=google.com ams20.s=arc-20160816 as20.d=google.com ams20.s=arc-20160816 ams19.d=google.com ams19.s=arc-20160816 as19.d=google.com ams19.s=arc-20160816 ams18.d=google.com ams18.s=arc-20160816 as18.d=google.com ams18.s=arc-20160816 ams17.d=google.com ams17.s=arc-20160816 as17.d=google.com ams17.s=arc-20160816 ams16.d=google.com ams16.s=arc-20160816 as16.d=google.com ams16.s=arc-20160816 ams15.d=google.com ams15.s=arc-20160816 as15.d=google.com ams15.s=arc-20160816 ams14.d=google.com ams14.s=arc-20160816 as14.d=google.com ams14.s=arc-20160816 ams13.d=google.com ams13.s=arc-20160816 as13.d=google.com ams13.s=arc-20160816 ams12.d=google.com ams12.s=arc-20160816 as12.d=google.com ams12.s=arc-20160816 ams11.d=google.com ams11.s=arc-20160816 as11.d=google.com ams11.s=arc-20160816 ams10.d=google.com ams10.s=arc-20160816 as10.d=google.com ams10.s=arc-20160816 ams9.d=google.com ams9.s=arc-20160816 as9.d=google.com ams9.s=arc-20160816 ams8.d=google.com ams8.s=arc-20160816 as8.d=google.com ams8.s=arc-20160816 ams7.d=google.com ams7.s=arc-20160816 as7.d=google.com ams7.s=arc-20160816 ams6.d=google.com ams6.s=arc-20160816 as6.d=google.com ams6.s=arc-20160816 ams5.d=google.com ams5.s=arc-20160816 as5.d=google.com ams5.s=arc-20160816 ams4.d=google.com ams4.s=arc-20160816 as4.d=google.com ams4.s=arc-20160816 ams3.d=google.com ams3.s=arc-20160816 as3.d=google.com ams3.s=arc-20160816 ams2.d=google.com ams2.s=arc-20160816 as2.d=google.com ams2.s=arc-20160816 ams1.d=google.com ams1.s=arc-20160816 as1.d=google.com ams1.s=arc-20160816 I'd also point out that this is iterative, so the i=49 one is only slightly smaller and so on. Brandon On Tue, Jul 25, 2017 at 3:48 PM, Gene Shuman wrote: > I do not have any better ideas. I just wanted to make sure I understood > the situation correctly atm. > > On Tue, Jul 25, 2017 at 3:36 PM, Juri Haberland > wrote: > >> On 26.07.2017 00:29, Kurt Andersen (b) wrote: >> > On Tue, Jul 25, 2017 at 2:44 PM, Juri Haberland >> > wrote: >> >> On 25.07.2017 21:31, Gene Shuman wrote: >> >> >> > inbound -> policyspf(or some other spf check) -> OpenDKIM -> >> OpenDMARC >> >> -> >> >> > OpenARC Validation -> mailing list software -> OpenArc Signature -> >> >> > outbound. >> >> >> >> Well, OpenARC validation should be before OpenDMARC... >> > >> > Well, that depends on your implementation. If you generally evaluate >> local >> > policy conditions before checking the primary DMARC mechanisms, then >> yes; >> > otherwise, ARC only needs to be evaluated if DMARC does not achieve a >> PASS >> > from the primary mechanism or if you expect to break the message's >> > authentication. >> >> Granted, both ways are possible :) >> >> Juri >> >> _______________________________________________ >> 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 > > --001a113cf57c9e25cc0555a5466d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Catching up here...

Perhaps the traditi= onal separation of all of the mail authenticators is what should change, ie= if we combined the various handlers into one, then it becomes much more ob= vious how the information flow would occur.

For ou= r impl, it's just various calls within the single process, hence why it= 's easy to issue a single authres header as well.

<= div>Looking at the 5.1.1 section, I do think we should specify that the sou= rce.ip is either in the arc section or the spf section, and not leave that = to random choice.

I also do not like the arc relat= ed data as specified.=C2=A0 If the arc chain is intact, then the informatio= n is trivially extracted from the chain, if it's not intact, then who c= ares.
Even if we want to include this data, I think the fact that= we have a chain of data could be used, and therefore we would only include= the i-1 hop data in the single aar.

Arc-Authentic= ation-Results: i=3D3; mx.google.com; a= rc=3Dpass ams.d=3Dgoogle.com ams.s=3Darc = as.d=3Dgoogle.com as.s=3Darc
The spec currently says i can go up to 1024 but unlikely over = 50, are we going to generate:
Arc-Authentication-Results: i=3D50;= mx.google.com;
=C2=A0 =C2= =A0 arc=3Dpass ams49.d=3Dgoogle.com ams49= .s=3Darc-20160816 as49.d=3Dgoogle.com ams= 49.s=3Darc-20160816
=C2=A0 =C2=A0 ams48.d=3Dgoogle.com ams48.s=3Darc-20160816 as48.d=3Dgoogle.com ams48.s=3Darc-20160816
=C2=A0 =C2= =A0 ams47.d=3Dgoogle.com ams47.s=3Darc-20= 160816 as47.d=3Dgoogle.com ams47.s=3Darc-= 20160816
=C2=A0 =C2=A0 ams46.d=3Dgo= ogle.com ams46.s=3Darc-20160816 as46.d=3D= google.com ams46.s=3Darc-20160816
=C2=A0 =C2=A0 ams45.d=3Dgoogle.com ams45.s=3Darc-20160816 as45.d=3D<= a href=3D"http://google.com">google.com ams45.s=3Darc-20160816
=C2=A0 =C2=A0 ams44.d=3Dgoogle.com ams4= 4.s=3Darc-20160816 as44.d=3Dgoogle.com am= s44.s=3Darc-20160816
=C2=A0 =C2=A0 ams43.d=3Dgoogle.com ams43.s=3Darc-20160816 as43.d=3Dgoogle.com ams43.s=3Darc-20160816
=C2=A0 =C2=A0 a= ms42.d=3Dgoogle.com ams42.s=3Darc-2016081= 6 as42.d=3Dgoogle.com ams42.s=3Darc-20160= 816
=C2=A0 =C2=A0 ams41.d=3Dgoogle.= com ams41.s=3Darc-20160816 as41.d=3Dgoogl= e.com ams41.s=3Darc-20160816
=C2=A0 =C2=A0 ams40.d=3Dgoogle.com ams40.s=3Darc-20160816 as40.d=3Dgoogle.com ams40.s=3Darc-20160816
= =C2=A0 =C2=A0 ams39.d=3Dgoogle.com ams39.= s=3Darc-20160816 as39.d=3Dgoogle.com ams3= 9.s=3Darc-20160816
=C2=A0 =C2=A0 ams38.d=3Dgoogle.com ams38.s=3Darc-20160816 as38.d=3Dgoogle.com ams38.s=3Darc-20160816
=C2=A0 =C2=A0 ams= 37.d=3Dgoogle.com ams37.s=3Darc-20160816 = as37.d=3Dgoogle.com ams37.s=3Darc-2016081= 6
=C2=A0 =C2=A0 ams36.d=3Dgoogle.co= m ams36.s=3Darc-20160816 as36.d=3Dgoogle.= com ams36.s=3Darc-20160816
=C2=A0 =C2=A0 ams35.d=3Dgoogle.com ams35.s=3Darc-20160816 as35.d=3Dgoogle.com ams35.s=3Darc-20160816
=C2= =A0 =C2=A0 ams34.d=3Dgoogle.com ams34.s= =3Darc-20160816 as34.d=3Dgoogle.com ams34= .s=3Darc-20160816
=C2=A0 =C2=A0 ams33.d=3Dgoogle.com ams33.s=3Darc-20160816 as33.d=3Dgoogle.com ams33.s=3Darc-20160816
=C2=A0 =C2=A0 ams3= 2.d=3Dgoogle.com ams32.s=3Darc-20160816 a= s32.d=3Dgoogle.com ams32.s=3Darc-20160816=
=C2=A0 =C2=A0 ams31.d=3Dgoogle.com= ams31.s=3Darc-20160816 as31.d=3Dgoogle.c= om ams31.s=3Darc-20160816
=C2=A0 =C2=A0 ams30.d=3Dgoogle.com ams30.s=3Darc-20160816 as30.d=3Dgoogle.com ams30.s=3Darc-20160816
=C2= =A0 =C2=A0 ams29.d=3Dgoogle.com ams29.s= =3Darc-20160816 as29.d=3Dgoogle.com ams29= .s=3Darc-20160816
=C2=A0 =C2=A0 ams28.d=3Dgoogle.com ams28.s=3Darc-20160816 as28.d=3Dgoogle.com ams28.s=3Darc-20160816
=C2=A0 =C2=A0 ams2= 7.d=3Dgoogle.com ams27.s=3Darc-20160816 a= s27.d=3Dgoogle.com ams27.s=3Darc-20160816=
=C2=A0 =C2=A0 ams26.d=3Dgoogle.com= ams26.s=3Darc-20160816 as26.d=3Dgoogle.c= om ams26.s=3Darc-20160816
=C2=A0 =C2=A0 ams25.d=3Dgoogle.com ams25.s=3Darc-20160816 as25.d=3Dgoogle.com ams25.s=3Darc-20160816
=C2= =A0 =C2=A0 ams24.d=3Dgoogle.com ams24.s= =3Darc-20160816 as24.d=3Dgoogle.com ams24= .s=3Darc-20160816
=C2=A0 =C2=A0 ams23.d=3Dgoogle.com ams23.s=3Darc-20160816 as23.d=3Dgoogle.com ams23.s=3Darc-20160816
=C2=A0 =C2=A0 ams2= 2.d=3Dgoogle.com ams22.s=3Darc-20160816 a= s22.d=3Dgoogle.com ams22.s=3Darc-20160816=
=C2=A0 =C2=A0 ams21.d=3Dgoogle.com= ams21.s=3Darc-20160816 as21.d=3Dgoogle.c= om ams21.s=3Darc-20160816
=C2=A0 =C2=A0 ams20.d=3Dgoogle.com ams20.s=3Darc-20160816 as20.d=3Dgoogle.com ams20.s=3Darc-20160816
=C2= =A0 =C2=A0 ams19.d=3Dgoogle.com ams19.s= =3Darc-20160816 as19.d=3Dgoogle.com ams19= .s=3Darc-20160816
=C2=A0 =C2=A0 ams18.d=3Dgoogle.com ams18.s=3Darc-20160816 as18.d=3Dgoogle.com ams18.s=3Darc-20160816
=C2=A0 =C2=A0 ams1= 7.d=3Dgoogle.com ams17.s=3Darc-20160816 a= s17.d=3Dgoogle.com ams17.s=3Darc-20160816=
=C2=A0 =C2=A0 ams16.d=3Dgoogle.com= ams16.s=3Darc-20160816 as16.d=3Dgoogle.c= om ams16.s=3Darc-20160816
=C2=A0 =C2=A0 ams15.d=3Dgoogle.com ams15.s=3Darc-20160816 as15.d=3Dgoogle.com ams15.s=3Darc-20160816
=C2= =A0 =C2=A0 ams14.d=3Dgoogle.com ams14.s= =3Darc-20160816 as14.d=3Dgoogle.com ams14= .s=3Darc-20160816
=C2=A0 =C2=A0 ams13.d=3Dgoogle.com ams13.s=3Darc-20160816 as13.d=3Dgoogle.com ams13.s=3Darc-20160816
=C2=A0 =C2=A0 ams1= 2.d=3Dgoogle.com ams12.s=3Darc-20160816 a= s12.d=3Dgoogle.com ams12.s=3Darc-20160816=
=C2=A0 =C2=A0 ams11.d=3Dgoogle.com= ams11.s=3Darc-20160816 as11.d=3Dgoogle.c= om ams11.s=3Darc-20160816
=C2=A0 =C2=A0 ams10.d=3Dgoogle.com ams10.s=3Darc-20160816 as10.d=3Dgoogle.com ams10.s=3Darc-20160816
=C2= =A0 =C2=A0 ams9.d=3Dgoogle.com ams9.s=3Da= rc-20160816 as9.d=3Dgoogle.com ams9.s=3Da= rc-20160816
=C2=A0 =C2=A0 ams8.d=3D= google.com ams8.s=3Darc-20160816 as8.d=3D= google.com ams8.s=3Darc-20160816
=C2=A0 =C2=A0 ams7.d=3Dgoogle.com ams7.s=3Darc-20160816 as7.d=3Dgoogle.com ams7.s=3Darc-20160816
=C2= =A0 =C2=A0 ams6.d=3Dgoogle.com ams6.s=3Da= rc-20160816 as6.d=3Dgoogle.com ams6.s=3Da= rc-20160816
=C2=A0 =C2=A0 ams5.d=3D= google.com ams5.s=3Darc-20160816 as5.d=3D= google.com ams5.s=3Darc-20160816
=C2=A0 =C2=A0 ams4.d=3Dgoogle.com ams4.s=3Darc-20160816 as4.d=3Dgoogle.com ams4.s=3Darc-20160816
=C2= =A0 =C2=A0 ams3.d=3Dgoogle.com ams3.s=3Da= rc-20160816 as3.d=3Dgoogle.com ams3.s=3Da= rc-20160816
=C2=A0 =C2=A0 ams2.d=3D= google.com ams2.s=3Darc-20160816 as2.d=3D= google.com ams2.s=3Darc-20160816
=C2=A0 =C2=A0 ams1.d=3Dgoogle.com ams1.s=3Darc-20160816 as1.d=3Dgoogle.com ams1.s=3Darc-20160816

I'd also point out that this is iterative, so the i= =3D49 one is only slightly smaller and so on.

Bran= don

On= Tue, Jul 25, 2017 at 3:48 PM, Gene Shuman <geneshuman@gmail.com>= ; wrote:
I do not= have any better ideas.=C2=A0 I just wanted to make sure I understood the s= ituation correctly atm. =C2=A0

On Tue, Jul 25, = 2017 at 3:36 PM, Juri Haberland <juri@sapienti-sat.org> = wrote:
On 26.07.2017 00:29, Kurt = Andersen (b) wrote:
> On Tue, Jul 25, 2017 at 2:44 PM, Juri Haberland <juri@sapienti-sat.org>
> wrote:
>> On 25.07.2017 21:31, Gene Shuman wrote:

>> > inbound -> policyspf(or some other spf check)= =C2=A0 -> OpenDKIM -> OpenDMARC
>> ->
>> > OpenARC Validation -> mailing list software -> OpenArc = Signature ->
>> > outbound.
>>
>> Well, OpenARC validation should be before OpenDMARC...
>
> Well, that depends on your implementation. If you generally evaluate l= ocal
> policy conditions before checking the primary DMARC mechanisms, then y= es;
> otherwise, ARC only needs to be evaluated if DMARC does not achieve a = PASS
> from the primary mechanism or if you expect to break the message's=
> authentication.

Granted, both ways are possible :)

=C2=A0 Juri

_______________________________________________
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


--001a113cf57c9e25cc0555a5466d-- From nobody Mon Jul 31 16:25:33 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75301132122 for ; Mon, 31 Jul 2017 16:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oj4MleA0mOO9 for ; Mon, 31 Jul 2017 16:25:27 -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 0A133131473 for ; Mon, 31 Jul 2017 16:25:27 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id o9so1997010iod.1 for ; Mon, 31 Jul 2017 16:25:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=y1XxbjMSOauTAfJ1QV+yX/KLu11bKbl9EW1L7i2onTQ=; b=VaBt3bpsVBrRoIgyszCXYTOjxvaQGakLWlPrRPeMK8mNxd07Bm4mjI0fqGOhyhhRgP UOoVGhi7Tg1ZkdmTc59gFzcRBWsuPYLftCXVId35j1EvMBeJfW++ybEWJW5BeSMgXSvn zHw++/7JNEkOKbevjGyG7WKB4yXriBgAplioIJXWN6AW/a2I5I72bBHThzM2bqQLpgLh SdZqoc1vY85TdJd2K81H6lF3iIXMzp0cr1CMqe6YIBiLwJDsoa3h2+3oZe3UwFhDOuR8 ZNA9MGawbT8+Nu6zYtpJ7XBBRmcKpTI3Z2ndSfM2Y2J0/NPa/f6yl2q4AwbA5+Gh+ouG PDqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=y1XxbjMSOauTAfJ1QV+yX/KLu11bKbl9EW1L7i2onTQ=; b=YNm9i1UtjgZn6rlDov8tRTmetWFqPgjDtlrETgWhkj0K8M7DiV0AQKalbAEDk1fmMQ TRHFAAH5Od5E/HDCEsSFBZ6q9kGXCsY3NESPgVZPOlSR0kJTHB81oL3EM8KsF2fOq28F 8qdqUYhIQCz8OPwnRVYy+KNr8wdVNpbHvd8nxA8fN11RN/PSC/nh/2y9LMFO2Ga2orbv HbxeYCLEUaGIiu4IGygYWN+3DZ0WuJCf4//CbyHP8cpjWq1nHA+HzbesvOpHY4sEFYDC hsh8cEOY/IXAJ6dPuAOzbtE7SL5LFBi2FQrgZKOTGG44Hb5+vUrNBbC/MMMfMfhv8MQq 208A== X-Gm-Message-State: AIVw1108DEWKcWLQVE+dPkuqUhGLGcJfedECBpg+VWuHfrOPkN4cJi8+ t+kSLO1cszpMN3UXmF7nQz9AMTqAiQ== X-Received: by 10.107.15.16 with SMTP id x16mr16639786ioi.288.1501543526284; Mon, 31 Jul 2017 16:25:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.106.1 with HTTP; Mon, 31 Jul 2017 16:25:25 -0700 (PDT) In-Reply-To: References: <9f93d9c9-5c84-9f78-6b22-2c637efdd09f@sapienti-sat.org> From: Gene Shuman Date: Mon, 31 Jul 2017 16:25:25 -0700 Message-ID: To: Brandon Long Cc: Juri Haberland , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a113f19a27fc61d0555a5581d" Archived-At: Subject: Re: [dmarc-ietf] questions about section 5.1.1 of the new ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 23:25:31 -0000 --001a113f19a27fc61d0555a5581d Content-Type: text/plain; charset="UTF-8" I was just talking with Seth about this. I think the language was poorly worded, and the intention is not to have a million ams.s, ams.ds in the aar, but just the ones from the most recent hop. Is this correct? Also, I still dont like ARC implementations being asked to parse DKIM signatures to get header.s. Nor do I really understand why we want that info. On Mon, Jul 31, 2017 at 4:20 PM, Brandon Long wrote: > Catching up here... > > Perhaps the traditional separation of all of the mail authenticators is > what should change, ie if we combined the various handlers into one, then > it becomes much more obvious how the information flow would occur. > > For our impl, it's just various calls within the single process, hence why > it's easy to issue a single authres header as well. > > Looking at the 5.1.1 section, I do think we should specify that the > source.ip is either in the arc section or the spf section, and not leave > that to random choice. > > I also do not like the arc related data as specified. If the arc chain is > intact, then the information is trivially extracted from the chain, if it's > not intact, then who cares. > Even if we want to include this data, I think the fact that we have a > chain of data could be used, and therefore we would only include the i-1 > hop data in the single aar. > > Arc-Authentication-Results: i=3; mx.google.com; arc=pass ams.d=google.com > ams.s=arc as.d=google.com as.s=arc > > The spec currently says i can go up to 1024 but unlikely over 50, are we > going to generate: > Arc-Authentication-Results: i=50; mx.google.com; > arc=pass ams49.d=google.com ams49.s=arc-20160816 as49.d=google.com > ams49.s=arc-20160816 > ams48.d=google.com ams48.s=arc-20160816 as48.d=google.com > ams48.s=arc-20160816 > ams47.d=google.com ams47.s=arc-20160816 as47.d=google.com > ams47.s=arc-20160816 > ams46.d=google.com ams46.s=arc-20160816 as46.d=google.com > ams46.s=arc-20160816 > ams45.d=google.com ams45.s=arc-20160816 as45.d=google.com > ams45.s=arc-20160816 > ams44.d=google.com ams44.s=arc-20160816 as44.d=google.com > ams44.s=arc-20160816 > ams43.d=google.com ams43.s=arc-20160816 as43.d=google.com > ams43.s=arc-20160816 > ams42.d=google.com ams42.s=arc-20160816 as42.d=google.com > ams42.s=arc-20160816 > ams41.d=google.com ams41.s=arc-20160816 as41.d=google.com > ams41.s=arc-20160816 > ams40.d=google.com ams40.s=arc-20160816 as40.d=google.com > ams40.s=arc-20160816 > ams39.d=google.com ams39.s=arc-20160816 as39.d=google.com > ams39.s=arc-20160816 > ams38.d=google.com ams38.s=arc-20160816 as38.d=google.com > ams38.s=arc-20160816 > ams37.d=google.com ams37.s=arc-20160816 as37.d=google.com > ams37.s=arc-20160816 > ams36.d=google.com ams36.s=arc-20160816 as36.d=google.com > ams36.s=arc-20160816 > ams35.d=google.com ams35.s=arc-20160816 as35.d=google.com > ams35.s=arc-20160816 > ams34.d=google.com ams34.s=arc-20160816 as34.d=google.com > ams34.s=arc-20160816 > ams33.d=google.com ams33.s=arc-20160816 as33.d=google.com > ams33.s=arc-20160816 > ams32.d=google.com ams32.s=arc-20160816 as32.d=google.com > ams32.s=arc-20160816 > ams31.d=google.com ams31.s=arc-20160816 as31.d=google.com > ams31.s=arc-20160816 > ams30.d=google.com ams30.s=arc-20160816 as30.d=google.com > ams30.s=arc-20160816 > ams29.d=google.com ams29.s=arc-20160816 as29.d=google.com > ams29.s=arc-20160816 > ams28.d=google.com ams28.s=arc-20160816 as28.d=google.com > ams28.s=arc-20160816 > ams27.d=google.com ams27.s=arc-20160816 as27.d=google.com > ams27.s=arc-20160816 > ams26.d=google.com ams26.s=arc-20160816 as26.d=google.com > ams26.s=arc-20160816 > ams25.d=google.com ams25.s=arc-20160816 as25.d=google.com > ams25.s=arc-20160816 > ams24.d=google.com ams24.s=arc-20160816 as24.d=google.com > ams24.s=arc-20160816 > ams23.d=google.com ams23.s=arc-20160816 as23.d=google.com > ams23.s=arc-20160816 > ams22.d=google.com ams22.s=arc-20160816 as22.d=google.com > ams22.s=arc-20160816 > ams21.d=google.com ams21.s=arc-20160816 as21.d=google.com > ams21.s=arc-20160816 > ams20.d=google.com ams20.s=arc-20160816 as20.d=google.com > ams20.s=arc-20160816 > ams19.d=google.com ams19.s=arc-20160816 as19.d=google.com > ams19.s=arc-20160816 > ams18.d=google.com ams18.s=arc-20160816 as18.d=google.com > ams18.s=arc-20160816 > ams17.d=google.com ams17.s=arc-20160816 as17.d=google.com > ams17.s=arc-20160816 > ams16.d=google.com ams16.s=arc-20160816 as16.d=google.com > ams16.s=arc-20160816 > ams15.d=google.com ams15.s=arc-20160816 as15.d=google.com > ams15.s=arc-20160816 > ams14.d=google.com ams14.s=arc-20160816 as14.d=google.com > ams14.s=arc-20160816 > ams13.d=google.com ams13.s=arc-20160816 as13.d=google.com > ams13.s=arc-20160816 > ams12.d=google.com ams12.s=arc-20160816 as12.d=google.com > ams12.s=arc-20160816 > ams11.d=google.com ams11.s=arc-20160816 as11.d=google.com > ams11.s=arc-20160816 > ams10.d=google.com ams10.s=arc-20160816 as10.d=google.com > ams10.s=arc-20160816 > ams9.d=google.com ams9.s=arc-20160816 as9.d=google.com > ams9.s=arc-20160816 > ams8.d=google.com ams8.s=arc-20160816 as8.d=google.com > ams8.s=arc-20160816 > ams7.d=google.com ams7.s=arc-20160816 as7.d=google.com > ams7.s=arc-20160816 > ams6.d=google.com ams6.s=arc-20160816 as6.d=google.com > ams6.s=arc-20160816 > ams5.d=google.com ams5.s=arc-20160816 as5.d=google.com > ams5.s=arc-20160816 > ams4.d=google.com ams4.s=arc-20160816 as4.d=google.com > ams4.s=arc-20160816 > ams3.d=google.com ams3.s=arc-20160816 as3.d=google.com > ams3.s=arc-20160816 > ams2.d=google.com ams2.s=arc-20160816 as2.d=google.com > ams2.s=arc-20160816 > ams1.d=google.com ams1.s=arc-20160816 as1.d=google.com > ams1.s=arc-20160816 > > I'd also point out that this is iterative, so the i=49 one is only > slightly smaller and so on. > > Brandon > > On Tue, Jul 25, 2017 at 3:48 PM, Gene Shuman wrote: > >> I do not have any better ideas. I just wanted to make sure I understood >> the situation correctly atm. >> >> On Tue, Jul 25, 2017 at 3:36 PM, Juri Haberland >> wrote: >> >>> On 26.07.2017 00:29, Kurt Andersen (b) wrote: >>> > On Tue, Jul 25, 2017 at 2:44 PM, Juri Haberland >> > >>> > wrote: >>> >> On 25.07.2017 21:31, Gene Shuman wrote: >>> >>> >> > inbound -> policyspf(or some other spf check) -> OpenDKIM -> >>> OpenDMARC >>> >> -> >>> >> > OpenARC Validation -> mailing list software -> OpenArc Signature -> >>> >> > outbound. >>> >> >>> >> Well, OpenARC validation should be before OpenDMARC... >>> > >>> > Well, that depends on your implementation. If you generally evaluate >>> local >>> > policy conditions before checking the primary DMARC mechanisms, then >>> yes; >>> > otherwise, ARC only needs to be evaluated if DMARC does not achieve a >>> PASS >>> > from the primary mechanism or if you expect to break the message's >>> > authentication. >>> >>> Granted, both ways are possible :) >>> >>> Juri >>> >>> _______________________________________________ >>> 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 >> >> > --001a113f19a27fc61d0555a5581d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I was just talking with Seth about this.=C2=A0 I think the= language was poorly worded, and the intention is not to have a million ams= .s, ams.ds in the aar, but just the ones from the most recent hop.=C2=A0 Is= this correct?

Also, I still dont like ARC implementatio= ns being asked to parse DKIM signatures to get header.s.=C2=A0 Nor do I rea= lly understand why we want that info.

On Mon, Jul 31, 2017 at 4:20 PM, Brandon Lo= ng <blong@fiction.net> wrote:
Catching up here...

Perhaps the tra= ditional separation of all of the mail authenticators is what should change= , ie if we combined the various handlers into one, then it becomes much mor= e obvious how the information flow would occur.

Fo= r our impl, it's just various calls within the single process, hence wh= y it's easy to issue a single authres header as well.

Looking at the 5.1.1 section, I do think we should specify that the= source.ip is either in the arc section or the spf section, and not leave t= hat to random choice.

I also do not like the arc r= elated data as specified.=C2=A0 If the arc chain is intact, then the inform= ation is trivially extracted from the chain, if it's not intact, then w= ho cares.
Even if we want to include this data, I think the fact = that we have a chain of data could be used, and therefore we would only inc= lude the i-1 hop data in the single aar.

Arc-Authe= ntication-Results: i=3D3; mx.google.com; arc=3Dpass ams.d=3Dgoogle.com ams.s=3Darc as.d=3Dgoogle.com as.s=3Darc

The = spec currently says i can go up to 1024 but unlikely over 50, are we going = to generate:
Arc-Authentication-Results: i=3D50; mx.google.com;
=C2=A0 =C2= =A0 arc=3Dpass ams49.d=3Dgo= ogle.com ams49.s=3Darc-20160816 as49.d=3Dgoogle.com ams49.s=3Darc-20160816
=C2= =A0 =C2=A0 ams48.d=3Dgoogle= .com ams48.s=3Darc-20160816 as48.d=3Dgoogle.com ams48.s=3Darc-20160816
=C2=A0 =C2=A0= ams47.d=3Dgoogle.com a= ms47.s=3Darc-20160816 as47.d=3Dgoogle.com ams47.s=3Darc-20160816
=C2=A0 =C2=A0 ams46.d= =3Dgoogle.com ams46.s= =3Darc-20160816 as46.d=3Dgo= ogle.com ams46.s=3Darc-20160816
=C2=A0 =C2=A0 ams45.d=3Dgoogle.com ams45.s=3Darc-201= 60816 as45.d=3Dgoogle.com ams45.s=3Darc-20160816
=C2=A0 =C2=A0 ams44.d=3Dgoogle.com ams44.s=3Darc-20160816 as44= .d=3Dgoogle.com ams44.s= =3Darc-20160816
=C2=A0 =C2=A0 ams43.d=3Dgoogle.com ams43.s=3Darc-20160816 as43.d=3Dgoogle.com ams43.s=3Darc-201= 60816
=C2=A0 =C2=A0 ams42.d=3Dgoogle.com ams42.s=3Darc-20160816 as42.d=3Dgoogle.com ams42.s=3Darc-20160816
=C2=A0 =C2=A0 ams41.d=3Dgoogle.com ams41.s=3Darc-20160816 as41.d=3Dgoogle.com ams41.s=3Darc-20160816
=C2= =A0 =C2=A0 ams40.d=3Dgoogle= .com ams40.s=3Darc-20160816 as40.d=3Dgoogle.com ams40.s=3Darc-20160816
=C2=A0 =C2=A0= ams39.d=3Dgoogle.com a= ms39.s=3Darc-20160816 as39.d=3Dgoogle.com ams39.s=3Darc-20160816
=C2=A0 =C2=A0 ams38.d= =3Dgoogle.com ams38.s= =3Darc-20160816 as38.d=3Dgo= ogle.com ams38.s=3Darc-20160816
=C2=A0 =C2=A0 ams37.d=3Dgoogle.com ams37.s=3Darc-201= 60816 as37.d=3Dgoogle.com ams37.s=3Darc-20160816
=C2=A0 =C2=A0 ams36.d=3Dgoogle.com ams36.s=3Darc-20160816 as36= .d=3Dgoogle.com ams36.s= =3Darc-20160816
=C2=A0 =C2=A0 ams35.d=3Dgoogle.com ams35.s=3Darc-20160816 as35.d=3Dgoogle.com ams35.s=3Darc-201= 60816
=C2=A0 =C2=A0 ams34.d=3Dgoogle.com ams34.s=3Darc-20160816 as34.d=3Dgoogle.com ams34.s=3Darc-20160816
=C2=A0 =C2=A0 ams33.d=3Dgoogle.com ams33.s=3Darc-20160816 as33.d=3Dgoogle.com ams33.s=3Darc-20160816
=C2= =A0 =C2=A0 ams32.d=3Dgoogle= .com ams32.s=3Darc-20160816 as32.d=3Dgoogle.com ams32.s=3Darc-20160816
=C2=A0 =C2=A0= ams31.d=3Dgoogle.com a= ms31.s=3Darc-20160816 as31.d=3Dgoogle.com ams31.s=3Darc-20160816
=C2=A0 =C2=A0 ams30.d= =3Dgoogle.com ams30.s= =3Darc-20160816 as30.d=3Dgo= ogle.com ams30.s=3Darc-20160816
=C2=A0 =C2=A0 ams29.d=3Dgoogle.com ams29.s=3Darc-201= 60816 as29.d=3Dgoogle.com ams29.s=3Darc-20160816
=C2=A0 =C2=A0 ams28.d=3Dgoogle.com ams28.s=3Darc-20160816 as28= .d=3Dgoogle.com ams28.s= =3Darc-20160816
=C2=A0 =C2=A0 ams27.d=3Dgoogle.com ams27.s=3Darc-20160816 as27.d=3Dgoogle.com ams27.s=3Darc-201= 60816
=C2=A0 =C2=A0 ams26.d=3Dgoogle.com ams26.s=3Darc-20160816 as26.d=3Dgoogle.com ams26.s=3Darc-20160816
=C2=A0 =C2=A0 ams25.d=3Dgoogle.com ams25.s=3Darc-20160816 as25.d=3Dgoogle.com ams25.s=3Darc-20160816
=C2= =A0 =C2=A0 ams24.d=3Dgoogle= .com ams24.s=3Darc-20160816 as24.d=3Dgoogle.com ams24.s=3Darc-20160816
=C2=A0 =C2=A0= ams23.d=3Dgoogle.com a= ms23.s=3Darc-20160816 as23.d=3Dgoogle.com ams23.s=3Darc-20160816
=C2=A0 =C2=A0 ams22.d= =3Dgoogle.com ams22.s= =3Darc-20160816 as22.d=3Dgo= ogle.com ams22.s=3Darc-20160816
=C2=A0 =C2=A0 ams21.d=3Dgoogle.com ams21.s=3Darc-201= 60816 as21.d=3Dgoogle.com ams21.s=3Darc-20160816
=C2=A0 =C2=A0 ams20.d=3Dgoogle.com ams20.s=3Darc-20160816 as20= .d=3Dgoogle.com ams20.s= =3Darc-20160816
=C2=A0 =C2=A0 ams19.d=3Dgoogle.com ams19.s=3Darc-20160816 as19.d=3Dgoogle.com ams19.s=3Darc-201= 60816
=C2=A0 =C2=A0 ams18.d=3Dgoogle.com ams18.s=3Darc-20160816 as18.d=3Dgoogle.com ams18.s=3Darc-20160816
=C2=A0 =C2=A0 ams17.d=3Dgoogle.com ams17.s=3Darc-20160816 as17.d=3Dgoogle.com ams17.s=3Darc-20160816
=C2= =A0 =C2=A0 ams16.d=3Dgoogle= .com ams16.s=3Darc-20160816 as16.d=3Dgoogle.com ams16.s=3Darc-20160816
=C2=A0 =C2=A0= ams15.d=3Dgoogle.com a= ms15.s=3Darc-20160816 as15.d=3Dgoogle.com ams15.s=3Darc-20160816
=C2=A0 =C2=A0 ams14.d= =3Dgoogle.com ams14.s= =3Darc-20160816 as14.d=3Dgo= ogle.com ams14.s=3Darc-20160816
=C2=A0 =C2=A0 ams13.d=3Dgoogle.com ams13.s=3Darc-201= 60816 as13.d=3Dgoogle.com ams13.s=3Darc-20160816
=C2=A0 =C2=A0 ams12.d=3Dgoogle.com ams12.s=3Darc-20160816 as12= .d=3Dgoogle.com ams12.s= =3Darc-20160816
=C2=A0 =C2=A0 ams11.d=3Dgoogle.com ams11.s=3Darc-20160816 as11.d=3Dgoogle.com ams11.s=3Darc-201= 60816
=C2=A0 =C2=A0 ams10.d=3Dgoogle.com ams10.s=3Darc-20160816 as10.d=3Dgoogle.com ams10.s=3Darc-20160816
=C2=A0 =C2=A0 ams9.d=3Dgoogle.com ams9.s=3Darc-20160816 as9.d=3Dgoogle.com ams9.s=3Darc-20160816
=C2=A0 = =C2=A0 ams8.d=3Dgoogle.com<= /a> ams8.s=3Darc-20160816 as8.d=3Dgoogle.com ams8.s=3Darc-20160816
=C2=A0 =C2=A0 ams7.d= =3Dgoogle.com ams7.s=3D= arc-20160816 as7.d=3Dgoogle= .com ams7.s=3Darc-20160816
=C2=A0 =C2=A0 ams6.d=3Dgoogle.com ams6.s=3Darc-20160816 a= s6.d=3Dgoogle.com ams6.= s=3Darc-20160816
=C2=A0 =C2=A0 ams5.d=3Dgoogle.com ams5.s=3Darc-20160816 as5.d=3Dgoogle.com ams5.s=3Darc-201608= 16
=C2=A0 =C2=A0 ams4.d=3Dgoogle.com ams4.s=3Darc-20160816 as4.d=3Dgoogle.com ams4.s=3Darc-20160816
= =C2=A0 =C2=A0 ams3.d=3Dgoog= le.com ams3.s=3Darc-20160816 as3.d=3Dgoogle.com ams3.s=3Darc-20160816
=C2=A0 =C2=A0 = ams2.d=3Dgoogle.com ams= 2.s=3Darc-20160816 as2.d=3D= google.com ams2.s=3Darc-20160816
=C2=A0 =C2=A0 ams1.d=3Dgoogle.com ams1.s=3Darc-2016= 0816 as1.d=3Dgoogle.com= ams1.s=3Darc-20160816

I'd also point ou= t that this is iterative, so the i=3D49 one is only slightly smaller and so= on.

Brandon
=

On Tue, Jul 25, 2= 017 at 3:48 PM, Gene Shuman <geneshuman@gmail.com> wrote:=
I do not have any bette= r ideas.=C2=A0 I just wanted to make sure I understood the situation correc= tly atm. =C2=A0

On Tue, Jul 25, 2017 at 3:36 PM, Juri Haberland <juri@sapi= enti-sat.org> wrote:
= On 26.07.2017 00:29, Kurt Andersen (b) wrote:
> On Tue, Jul 25, 2017 at 2:44 PM, Juri Haberland <juri@sapienti-sat.org>
> wrote:
>> On 25.07.2017 21:31, Gene Shuman wrote:

>> > inbound -> policyspf(or some other spf check)= =C2=A0 -> OpenDKIM -> OpenDMARC
>> ->
>> > OpenARC Validation -> mailing list software -> OpenArc = Signature ->
>> > outbound.
>>
>> Well, OpenARC validation should be before OpenDMARC...
>
> Well, that depends on your implementation. If you generally evaluate l= ocal
> policy conditions before checking the primary DMARC mechanisms, then y= es;
> otherwise, ARC only needs to be evaluated if DMARC does not achieve a = PASS
> from the primary mechanism or if you expect to break the message's=
> authentication.

Granted, both ways are possible :)

=C2=A0 Juri

_______________________________________________
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



--001a113f19a27fc61d0555a5581d-- From nobody Mon Jul 31 16:31:12 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9062A131919 for ; Mon, 31 Jul 2017 16:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 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, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fiction.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0RHHnIIn2y-L for ; Mon, 31 Jul 2017 16:31:08 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A62D41277BB for ; Mon, 31 Jul 2017 16:31:08 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id a9so813383oih.0 for ; Mon, 31 Jul 2017 16:31:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fiction.net; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7Oyvif1JoXpl0twOlY/odIPOMrL+WaalQMRs7AauF/w=; b=L1md7hyJWCexSwlAk3zytjCQpvi4JKPjZZ9PL286+jf7ytHz92ISdSd4vd5DU1SDk6 IhwaAlZkpYB90BHvy6vW3P5Krdg3+cC2G9Q/zwQhIBb9l5BvEQXvkS3otTVlQxj05MyI fiLs7C1LM2f1uhSnY0nEbztTN/UGaRtRGiFeKs2spXFXkLYYILHYooTODisT1Ht+SAwB Uud8nPoRMLv/L/ZXMs2jR8rnORZSYFkw70s2AVKfQDZjxe86dS/6RmwM04BB0zrE0ZWj /oBSBBv4N1YfRNmKaqygfni0PnRrb4uJhCT4ov/nQ38RYfP2gIQtVuHypgmQ3TRNw1JT BeAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7Oyvif1JoXpl0twOlY/odIPOMrL+WaalQMRs7AauF/w=; b=txImUm7Co6cdncDK+qEho0kFszN+x2234H0fa0tCFLX+dLH8FdtxMFKK0LtdzU9PGr HQW/rxVwgWBI7zWfnk0dsU0DSCS0OlngkiqIsXu66TxGf71IkUGHJhNe30RprQfAuCkJ c4Ppax/zIDvlqJ9kRyJKNs7CB+1N5ZW/cDEQ7vwTZL9TijEGmKrV2TKZsqJYApqEM3W6 H1MpuoChz8tUMdJ9S94/sFMIf/aTBi59ZdKzxJ6PrYvrfjB5r/S5n/rRiythxh33Wzzf +8A3GOGDlT6fy/C+1j5E3uc6chzyLLHyuuZvGNKLXZ/yqzu86C7VQranYRUfz3UIrbTs Z5bw== X-Gm-Message-State: AIVw112HoVWWQ49jz1gEwFRHhJGmbEfCJtmVsU/dikPA49AJQ1kLN63v maaY4BdLMX0+/ULjhrc= X-Received: by 10.202.212.65 with SMTP id l62mr18719007oig.78.1501543867790; Mon, 31 Jul 2017 16:31:07 -0700 (PDT) Received: from mail-oi0-f41.google.com (mail-oi0-f41.google.com. [209.85.218.41]) by smtp.gmail.com with ESMTPSA id n204sm25586751oia.12.2017.07.31.16.31.06 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 31 Jul 2017 16:31:07 -0700 (PDT) Received: by mail-oi0-f41.google.com with SMTP id x3so748768oia.1 for ; Mon, 31 Jul 2017 16:31:06 -0700 (PDT) X-Received: by 10.202.184.8 with SMTP id i8mr11252549oif.266.1501543866601; Mon, 31 Jul 2017 16:31:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.154.51 with HTTP; Mon, 31 Jul 2017 16:31:05 -0700 (PDT) In-Reply-To: References: <9f93d9c9-5c84-9f78-6b22-2c637efdd09f@sapienti-sat.org> From: Brandon Long Date: Mon, 31 Jul 2017 16:31:05 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Gene Shuman Cc: "dmarc@ietf.org" , Juri Haberland Content-Type: multipart/alternative; boundary="001a113ce0bac93a660555a56ce7" Archived-At: Subject: Re: [dmarc-ietf] questions about section 5.1.1 of the new ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 23:31:11 -0000 --001a113ce0bac93a660555a56ce7 Content-Type: text/plain; charset="UTF-8" In that case, I dislike specifying the hop number in the ptype, given the registry nature of the ptype and property, it seems like they should be specific and not an enumerated value. Brandon On Mon, Jul 31, 2017 at 4:25 PM, Gene Shuman wrote: > I was just talking with Seth about this. I think the language was poorly > worded, and the intention is not to have a million ams.s, ams.ds in the > aar, but just the ones from the most recent hop. Is this correct? > > Also, I still dont like ARC implementations being asked to parse DKIM > signatures to get header.s. Nor do I really understand why we want that > info. > > On Mon, Jul 31, 2017 at 4:20 PM, Brandon Long wrote: > >> Catching up here... >> >> Perhaps the traditional separation of all of the mail authenticators is >> what should change, ie if we combined the various handlers into one, then >> it becomes much more obvious how the information flow would occur. >> >> For our impl, it's just various calls within the single process, hence >> why it's easy to issue a single authres header as well. >> >> Looking at the 5.1.1 section, I do think we should specify that the >> source.ip is either in the arc section or the spf section, and not leave >> that to random choice. >> >> I also do not like the arc related data as specified. If the arc chain >> is intact, then the information is trivially extracted from the chain, if >> it's not intact, then who cares. >> Even if we want to include this data, I think the fact that we have a >> chain of data could be used, and therefore we would only include the i-1 >> hop data in the single aar. >> >> Arc-Authentication-Results: i=3; mx.google.com; arc=pass ams.d=google.com >> ams.s=arc as.d=google.com as.s=arc >> >> The spec currently says i can go up to 1024 but unlikely over 50, are we >> going to generate: >> Arc-Authentication-Results: i=50; mx.google.com; >> arc=pass ams49.d=google.com ams49.s=arc-20160816 as49.d=google.com >> ams49.s=arc-20160816 >> ams48.d=google.com ams48.s=arc-20160816 as48.d=google.com >> ams48.s=arc-20160816 >> ams47.d=google.com ams47.s=arc-20160816 as47.d=google.com >> ams47.s=arc-20160816 >> ams46.d=google.com ams46.s=arc-20160816 as46.d=google.com >> ams46.s=arc-20160816 >> ams45.d=google.com ams45.s=arc-20160816 as45.d=google.com >> ams45.s=arc-20160816 >> ams44.d=google.com ams44.s=arc-20160816 as44.d=google.com >> ams44.s=arc-20160816 >> ams43.d=google.com ams43.s=arc-20160816 as43.d=google.com >> ams43.s=arc-20160816 >> ams42.d=google.com ams42.s=arc-20160816 as42.d=google.com >> ams42.s=arc-20160816 >> ams41.d=google.com ams41.s=arc-20160816 as41.d=google.com >> ams41.s=arc-20160816 >> ams40.d=google.com ams40.s=arc-20160816 as40.d=google.com >> ams40.s=arc-20160816 >> ams39.d=google.com ams39.s=arc-20160816 as39.d=google.com >> ams39.s=arc-20160816 >> ams38.d=google.com ams38.s=arc-20160816 as38.d=google.com >> ams38.s=arc-20160816 >> ams37.d=google.com ams37.s=arc-20160816 as37.d=google.com >> ams37.s=arc-20160816 >> ams36.d=google.com ams36.s=arc-20160816 as36.d=google.com >> ams36.s=arc-20160816 >> ams35.d=google.com ams35.s=arc-20160816 as35.d=google.com >> ams35.s=arc-20160816 >> ams34.d=google.com ams34.s=arc-20160816 as34.d=google.com >> ams34.s=arc-20160816 >> ams33.d=google.com ams33.s=arc-20160816 as33.d=google.com >> ams33.s=arc-20160816 >> ams32.d=google.com ams32.s=arc-20160816 as32.d=google.com >> ams32.s=arc-20160816 >> ams31.d=google.com ams31.s=arc-20160816 as31.d=google.com >> ams31.s=arc-20160816 >> ams30.d=google.com ams30.s=arc-20160816 as30.d=google.com >> ams30.s=arc-20160816 >> ams29.d=google.com ams29.s=arc-20160816 as29.d=google.com >> ams29.s=arc-20160816 >> ams28.d=google.com ams28.s=arc-20160816 as28.d=google.com >> ams28.s=arc-20160816 >> ams27.d=google.com ams27.s=arc-20160816 as27.d=google.com >> ams27.s=arc-20160816 >> ams26.d=google.com ams26.s=arc-20160816 as26.d=google.com >> ams26.s=arc-20160816 >> ams25.d=google.com ams25.s=arc-20160816 as25.d=google.com >> ams25.s=arc-20160816 >> ams24.d=google.com ams24.s=arc-20160816 as24.d=google.com >> ams24.s=arc-20160816 >> ams23.d=google.com ams23.s=arc-20160816 as23.d=google.com >> ams23.s=arc-20160816 >> ams22.d=google.com ams22.s=arc-20160816 as22.d=google.com >> ams22.s=arc-20160816 >> ams21.d=google.com ams21.s=arc-20160816 as21.d=google.com >> ams21.s=arc-20160816 >> ams20.d=google.com ams20.s=arc-20160816 as20.d=google.com >> ams20.s=arc-20160816 >> ams19.d=google.com ams19.s=arc-20160816 as19.d=google.com >> ams19.s=arc-20160816 >> ams18.d=google.com ams18.s=arc-20160816 as18.d=google.com >> ams18.s=arc-20160816 >> ams17.d=google.com ams17.s=arc-20160816 as17.d=google.com >> ams17.s=arc-20160816 >> ams16.d=google.com ams16.s=arc-20160816 as16.d=google.com >> ams16.s=arc-20160816 >> ams15.d=google.com ams15.s=arc-20160816 as15.d=google.com >> ams15.s=arc-20160816 >> ams14.d=google.com ams14.s=arc-20160816 as14.d=google.com >> ams14.s=arc-20160816 >> ams13.d=google.com ams13.s=arc-20160816 as13.d=google.com >> ams13.s=arc-20160816 >> ams12.d=google.com ams12.s=arc-20160816 as12.d=google.com >> ams12.s=arc-20160816 >> ams11.d=google.com ams11.s=arc-20160816 as11.d=google.com >> ams11.s=arc-20160816 >> ams10.d=google.com ams10.s=arc-20160816 as10.d=google.com >> ams10.s=arc-20160816 >> ams9.d=google.com ams9.s=arc-20160816 as9.d=google.com >> ams9.s=arc-20160816 >> ams8.d=google.com ams8.s=arc-20160816 as8.d=google.com >> ams8.s=arc-20160816 >> ams7.d=google.com ams7.s=arc-20160816 as7.d=google.com >> ams7.s=arc-20160816 >> ams6.d=google.com ams6.s=arc-20160816 as6.d=google.com >> ams6.s=arc-20160816 >> ams5.d=google.com ams5.s=arc-20160816 as5.d=google.com >> ams5.s=arc-20160816 >> ams4.d=google.com ams4.s=arc-20160816 as4.d=google.com >> ams4.s=arc-20160816 >> ams3.d=google.com ams3.s=arc-20160816 as3.d=google.com >> ams3.s=arc-20160816 >> ams2.d=google.com ams2.s=arc-20160816 as2.d=google.com >> ams2.s=arc-20160816 >> ams1.d=google.com ams1.s=arc-20160816 as1.d=google.com >> ams1.s=arc-20160816 >> >> I'd also point out that this is iterative, so the i=49 one is only >> slightly smaller and so on. >> >> Brandon >> >> On Tue, Jul 25, 2017 at 3:48 PM, Gene Shuman >> wrote: >> >>> I do not have any better ideas. I just wanted to make sure I understood >>> the situation correctly atm. >>> >>> On Tue, Jul 25, 2017 at 3:36 PM, Juri Haberland >>> wrote: >>> >>>> On 26.07.2017 00:29, Kurt Andersen (b) wrote: >>>> > On Tue, Jul 25, 2017 at 2:44 PM, Juri Haberland < >>>> juri@sapienti-sat.org> >>>> > wrote: >>>> >> On 25.07.2017 21:31, Gene Shuman wrote: >>>> >>>> >> > inbound -> policyspf(or some other spf check) -> OpenDKIM -> >>>> OpenDMARC >>>> >> -> >>>> >> > OpenARC Validation -> mailing list software -> OpenArc Signature -> >>>> >> > outbound. >>>> >> >>>> >> Well, OpenARC validation should be before OpenDMARC... >>>> > >>>> > Well, that depends on your implementation. If you generally evaluate >>>> local >>>> > policy conditions before checking the primary DMARC mechanisms, then >>>> yes; >>>> > otherwise, ARC only needs to be evaluated if DMARC does not achieve a >>>> PASS >>>> > from the primary mechanism or if you expect to break the message's >>>> > authentication. >>>> >>>> Granted, both ways are possible :) >>>> >>>> Juri >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >> > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --001a113ce0bac93a660555a56ce7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In that case, I dislike specifying the hop number in the p= type, given the registry nature of the ptype and property, it seems like th= ey should be specific and not an enumerated value.

Brand= on

On Mon, Jul= 31, 2017 at 4:25 PM, Gene Shuman <geneshuman@gmail.com> = wrote:
I was just talkin= g with Seth about this.=C2=A0 I think the language was poorly worded, and t= he intention is not to have a million ams.s, ams.ds in the aar, but just th= e ones from the most recent hop.=C2=A0 Is this correct?

= Also, I still dont like ARC implementations being asked to parse DKIM signa= tures to get header.s.=C2=A0 Nor do I really understand why we want that in= fo.

On Mon, Jul 31, 2017 at 4:20 PM, Bran= don Long <blong@fiction.net> wrote:
Catching up here...

Perhaps = the traditional separation of all of the mail authenticators is what should= change, ie if we combined the various handlers into one, then it becomes m= uch more obvious how the information flow would occur.

=
For our impl, it's just various calls within the single process, h= ence why it's easy to issue a single authres header as well.
=
Looking at the 5.1.1 section, I do think we should specify t= hat the source.ip is either in the arc section or the spf section, and not = leave that to random choice.

I also do not like th= e arc related data as specified.=C2=A0 If the arc chain is intact, then the= information is trivially extracted from the chain, if it's not intact,= then who cares.
Even if we want to include this data, I think th= e fact that we have a chain of data could be used, and therefore we would o= nly include the i-1 hop data in the single aar.

Ar= c-Authentication-Results: i=3D3; mx.google.com; arc=3Dpass ams.d=3Dgoogle.com ams.s=3Darc as.d=3Dgoogle.com as.s=3Darc

The spec currently says i can go up to 1024 but unlikely over 50, are we= going to generate:
Arc-Authentication-Results: i=3D50; mx.google.com;
= =C2=A0 =C2=A0 arc=3Dpass ams49.d=3Dgoogle.com ams49.s=3Darc-20160816 as49.d=3Dgoogle.com ams49.s=3Darc-20160816
=C2=A0 =C2=A0 ams48.d=3Dgoogle.com ams48.s=3Darc-20160816 as48.d=3Dgoogle.com ams48.s=3Darc-20160816
=C2= =A0 =C2=A0 ams47.d=3Dgoogle= .com ams47.s=3Darc-20160816 as47.d=3Dgoogle.com ams47.s=3Darc-20160816
=C2=A0 =C2=A0= ams46.d=3Dgoogle.com a= ms46.s=3Darc-20160816 as46.d=3Dgoogle.com ams46.s=3Darc-20160816
=C2=A0 =C2=A0 ams45.d= =3Dgoogle.com ams45.s= =3Darc-20160816 as45.d=3Dgo= ogle.com ams45.s=3Darc-20160816
=C2=A0 =C2=A0 ams44.d=3Dgoogle.com ams44.s=3Darc-201= 60816 as44.d=3Dgoogle.com ams44.s=3Darc-20160816
=C2=A0 =C2=A0 ams43.d=3Dgoogle.com ams43.s=3Darc-20160816 as43= .d=3Dgoogle.com ams43.s= =3Darc-20160816
=C2=A0 =C2=A0 ams42.d=3Dgoogle.com ams42.s=3Darc-20160816 as42.d=3Dgoogle.com ams42.s=3Darc-201= 60816
=C2=A0 =C2=A0 ams41.d=3Dgoogle.com ams41.s=3Darc-20160816 as41.d=3Dgoogle.com ams41.s=3Darc-20160816
=C2=A0 =C2=A0 ams40.d=3Dgoogle.com ams40.s=3Darc-20160816 as40.d=3Dgoogle.com ams40.s=3Darc-20160816
=C2= =A0 =C2=A0 ams39.d=3Dgoogle= .com ams39.s=3Darc-20160816 as39.d=3Dgoogle.com ams39.s=3Darc-20160816
=C2=A0 =C2=A0= ams38.d=3Dgoogle.com a= ms38.s=3Darc-20160816 as38.d=3Dgoogle.com ams38.s=3Darc-20160816
=C2=A0 =C2=A0 ams37.d= =3Dgoogle.com ams37.s= =3Darc-20160816 as37.d=3Dgo= ogle.com ams37.s=3Darc-20160816
=C2=A0 =C2=A0 ams36.d=3Dgoogle.com ams36.s=3Darc-201= 60816 as36.d=3Dgoogle.com ams36.s=3Darc-20160816
=C2=A0 =C2=A0 ams35.d=3Dgoogle.com ams35.s=3Darc-20160816 as35= .d=3Dgoogle.com ams35.s= =3Darc-20160816
=C2=A0 =C2=A0 ams34.d=3Dgoogle.com ams34.s=3Darc-20160816 as34.d=3Dgoogle.com ams34.s=3Darc-201= 60816
=C2=A0 =C2=A0 ams33.d=3Dgoogle.com ams33.s=3Darc-20160816 as33.d=3Dgoogle.com ams33.s=3Darc-20160816
=C2=A0 =C2=A0 ams32.d=3Dgoogle.com ams32.s=3Darc-20160816 as32.d=3Dgoogle.com ams32.s=3Darc-20160816
=C2= =A0 =C2=A0 ams31.d=3Dgoogle= .com ams31.s=3Darc-20160816 as31.d=3Dgoogle.com ams31.s=3Darc-20160816
=C2=A0 =C2=A0= ams30.d=3Dgoogle.com a= ms30.s=3Darc-20160816 as30.d=3Dgoogle.com ams30.s=3Darc-20160816
=C2=A0 =C2=A0 ams29.d= =3Dgoogle.com ams29.s= =3Darc-20160816 as29.d=3Dgo= ogle.com ams29.s=3Darc-20160816
=C2=A0 =C2=A0 ams28.d=3Dgoogle.com ams28.s=3Darc-201= 60816 as28.d=3Dgoogle.com ams28.s=3Darc-20160816
=C2=A0 =C2=A0 ams27.d=3Dgoogle.com ams27.s=3Darc-20160816 as27= .d=3Dgoogle.com ams27.s= =3Darc-20160816
=C2=A0 =C2=A0 ams26.d=3Dgoogle.com ams26.s=3Darc-20160816 as26.d=3Dgoogle.com ams26.s=3Darc-201= 60816
=C2=A0 =C2=A0 ams25.d=3Dgoogle.com ams25.s=3Darc-20160816 as25.d=3Dgoogle.com ams25.s=3Darc-20160816
=C2=A0 =C2=A0 ams24.d=3Dgoogle.com ams24.s=3Darc-20160816 as24.d=3Dgoogle.com ams24.s=3Darc-20160816
=C2= =A0 =C2=A0 ams23.d=3Dgoogle= .com ams23.s=3Darc-20160816 as23.d=3Dgoogle.com ams23.s=3Darc-20160816
=C2=A0 =C2=A0= ams22.d=3Dgoogle.com a= ms22.s=3Darc-20160816 as22.d=3Dgoogle.com ams22.s=3Darc-20160816
=C2=A0 =C2=A0 ams21.d= =3Dgoogle.com ams21.s= =3Darc-20160816 as21.d=3Dgo= ogle.com ams21.s=3Darc-20160816
=C2=A0 =C2=A0 ams20.d=3Dgoogle.com ams20.s=3Darc-201= 60816 as20.d=3Dgoogle.com ams20.s=3Darc-20160816
=C2=A0 =C2=A0 ams19.d=3Dgoogle.com ams19.s=3Darc-20160816 as19= .d=3Dgoogle.com ams19.s= =3Darc-20160816
=C2=A0 =C2=A0 ams18.d=3Dgoogle.com ams18.s=3Darc-20160816 as18.d=3Dgoogle.com ams18.s=3Darc-201= 60816
=C2=A0 =C2=A0 ams17.d=3Dgoogle.com ams17.s=3Darc-20160816 as17.d=3Dgoogle.com ams17.s=3Darc-20160816
=C2=A0 =C2=A0 ams16.d=3Dgoogle.com ams16.s=3Darc-20160816 as16.d=3Dgoogle.com ams16.s=3Darc-20160816
=C2= =A0 =C2=A0 ams15.d=3Dgoogle= .com ams15.s=3Darc-20160816 as15.d=3Dgoogle.com ams15.s=3Darc-20160816
=C2=A0 =C2=A0= ams14.d=3Dgoogle.com a= ms14.s=3Darc-20160816 as14.d=3Dgoogle.com ams14.s=3Darc-20160816
=C2=A0 =C2=A0 ams13.d= =3Dgoogle.com ams13.s= =3Darc-20160816 as13.d=3Dgo= ogle.com ams13.s=3Darc-20160816
=C2=A0 =C2=A0 ams12.d=3Dgoogle.com ams12.s=3Darc-201= 60816 as12.d=3Dgoogle.com ams12.s=3Darc-20160816
=C2=A0 =C2=A0 ams11.d=3Dgoogle.com ams11.s=3Darc-20160816 as11= .d=3Dgoogle.com ams11.s= =3Darc-20160816
=C2=A0 =C2=A0 ams10.d=3Dgoogle.com ams10.s=3Darc-20160816 as10.d=3Dgoogle.com ams10.s=3Darc-201= 60816
=C2=A0 =C2=A0 ams9.d=3Dgoogle.com ams9.s=3Darc-20160816 as9.d=3Dgoogle.com ams9.s=3Darc-20160816
=C2=A0 =C2=A0 ams8.d=3Dgo= ogle.com ams8.s=3Darc-20160816 as8.d=3Dgoogle.com ams8.s=3Darc-20160816
=C2=A0 =C2= =A0 ams7.d=3Dgoogle.com= ams7.s=3Darc-20160816 as7.d=3Dgoogle.com ams7.s=3Darc-20160816
=C2=A0 =C2=A0 ams6.d=3D<= a href=3D"http://google.com" target=3D"_blank">google.com ams6.s=3Darc-= 20160816 as6.d=3Dgoogle.com= ams6.s=3Darc-20160816
=C2=A0 =C2=A0 ams5.d=3Dgoogle.com ams5.s=3Darc-20160816 as5.d= =3Dgoogle.com ams5.s=3D= arc-20160816
=C2=A0 =C2=A0 ams4.d=3Dgoogle.com ams4.s=3Darc-20160816 as4.d=3Dgoogle.com ams4.s=3Darc-20160816
=C2=A0 =C2=A0 ams3.d=3Dgoogle.com ams3.s=3Darc-20160816 as3.d=3Dgoogle.com ams3.s=3Darc-20160816
=C2= =A0 =C2=A0 ams2.d=3Dgoogle.= com ams2.s=3Darc-20160816 as2.d=3Dgoogle.com ams2.s=3Darc-20160816
=C2=A0 =C2=A0 am= s1.d=3Dgoogle.com ams1.= s=3Darc-20160816 as1.d=3Dgo= ogle.com ams1.s=3Darc-20160816

I'd a= lso point out that this is iterative, so the i=3D49 one is only slightly sm= aller and so on.

Brandon

On Tue, Jul 25= , 2017 at 3:48 PM, Gene Shuman <geneshuman@gmail.com> wro= te:
I do not have any be= tter ideas.=C2=A0 I just wanted to make sure I understood the situation cor= rectly atm. =C2=A0
=

On Tue, Jul 25, 2= 017 at 3:36 PM, Juri Haberland <juri@sapienti-sat.org> w= rote:
On 26.07.2017 00:29, Kurt A= ndersen (b) wrote:
> On Tue, Jul 25, 2017 at 2:44 PM, Juri Haberland <juri@sapienti-sat.org>
> wrote:
>> On 25.07.2017 21:31, Gene Shuman wrote:

>> > inbound -> policyspf(or some other spf check)= =C2=A0 -> OpenDKIM -> OpenDMARC
>> ->
>> > OpenARC Validation -> mailing list software -> OpenArc = Signature ->
>> > outbound.
>>
>> Well, OpenARC validation should be before OpenDMARC...
>
> Well, that depends on your implementation. If you generally evaluate l= ocal
> policy conditions before checking the primary DMARC mechanisms, then y= es;
> otherwise, ARC only needs to be evaluated if DMARC does not achieve a = PASS
> from the primary mechanism or if you expect to break the message's=
> authentication.

Granted, both ways are possible :)

=C2=A0 Juri

_______________________________________________
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




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


--001a113ce0bac93a660555a56ce7-- From nobody Mon Jul 31 16:38:48 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 079341277BB for ; Mon, 31 Jul 2017 16:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0czBQHfFH0nj for ; Mon, 31 Jul 2017 16:38:43 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8B0D129A96 for ; Mon, 31 Jul 2017 16:38:43 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id m88so2028746iod.2 for ; Mon, 31 Jul 2017 16:38:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6MpljF2NwtrJldMYRdy9jVzl58yRZHs/eesgRALDmtg=; b=gl51KyizXtK7aJ9zQVQ3SAJx3Qp2nww82Xr6F8gsH3m4ymvmZS8zx3/yDYxGicdXXK 680rnIL1bHVuyh/N6mELhsx0BPVNBWJSZEFK+LUPKGknHEEvPwRdr68oHLzb9oj4CGNE 8hSpCRqKoW5NPSOFZe2qhnRMgGW2wkE+3xfLhiaN2AOFYH8f/VfN8/eKPlW5q3uIMDrE tGBPETqvMCmGfBcGbRiIlKMWiGChRUqdXfK1IVJpW40vItz1fPrqoqIkZT+mB1Vy5eNz vNxfaJRiezed2kYn6qPGav9kd4r76XhujshSXBQK0P6dUqpW3VJJXC/vH1RFzgjW2jAS NN9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6MpljF2NwtrJldMYRdy9jVzl58yRZHs/eesgRALDmtg=; b=gTFVPyqnntQhv03NFbF7VY9MlgpZLW/tabVJyoHIjLxUsEtypKSe9scUyKR+wr6ku4 ZY520xDOSEFn0pLGyMFhtvsM5twriSPS0q+5wOdW+rI13PwqTv/fspra0IG0Jb2if429 afu+dVYOCzDdFZQnGs4vOnrwdjuJL9bjSWpbJUhmE7xMCOfdHnGjzP2bHZuoXmZQAak1 DDaoUP+8QbPTFeYmSvDJCxCEwqQKIIK8YN4hFyixC9S9fxGsZd2tQO4sgy/qskKlFioU vcF7xkALm6w/6ghCu7lT/bfBfV1ZTS+r4Un0VLugpu6sRfyebsDYMFDL21YTwHIp9POq RFaQ== X-Gm-Message-State: AIVw112jxuFlWEAo6IHebFqPIYJEQFo1eaWFmknxaZhAh74lKs5AlnvL UvpzixT1pd4rtMjxSDkQWa1Iwlxxnw== X-Received: by 10.107.15.16 with SMTP id x16mr16669570ioi.288.1501544323033; Mon, 31 Jul 2017 16:38:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.106.1 with HTTP; Mon, 31 Jul 2017 16:38:42 -0700 (PDT) In-Reply-To: References: <9f93d9c9-5c84-9f78-6b22-2c637efdd09f@sapienti-sat.org> From: Gene Shuman Date: Mon, 31 Jul 2017 16:38:42 -0700 Message-ID: To: Brandon Long Cc: "dmarc@ietf.org" , Juri Haberland Content-Type: multipart/alternative; boundary="001a113f19a2fd3be90555a58733" Archived-At: Subject: Re: [dmarc-ietf] questions about section 5.1.1 of the new ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 23:38:47 -0000 --001a113f19a2fd3be90555a58733 Content-Type: text/plain; charset="UTF-8" I understand exactly why we want header.s. But I think I might have incorrectly assumed that getting this from the arc signatures was good enough. On Mon, Jul 31, 2017 at 4:31 PM, Brandon Long wrote: > In that case, I dislike specifying the hop number in the ptype, given the > registry nature of the ptype and property, it seems like they should be > specific and not an enumerated value. > > Brandon > > > On Mon, Jul 31, 2017 at 4:25 PM, Gene Shuman wrote: > >> I was just talking with Seth about this. I think the language was poorly >> worded, and the intention is not to have a million ams.s, ams.ds in the >> aar, but just the ones from the most recent hop. Is this correct? >> >> Also, I still dont like ARC implementations being asked to parse DKIM >> signatures to get header.s. Nor do I really understand why we want that >> info. >> >> On Mon, Jul 31, 2017 at 4:20 PM, Brandon Long wrote: >> >>> Catching up here... >>> >>> Perhaps the traditional separation of all of the mail authenticators is >>> what should change, ie if we combined the various handlers into one, then >>> it becomes much more obvious how the information flow would occur. >>> >>> For our impl, it's just various calls within the single process, hence >>> why it's easy to issue a single authres header as well. >>> >>> Looking at the 5.1.1 section, I do think we should specify that the >>> source.ip is either in the arc section or the spf section, and not leave >>> that to random choice. >>> >>> I also do not like the arc related data as specified. If the arc chain >>> is intact, then the information is trivially extracted from the chain, if >>> it's not intact, then who cares. >>> Even if we want to include this data, I think the fact that we have a >>> chain of data could be used, and therefore we would only include the i-1 >>> hop data in the single aar. >>> >>> Arc-Authentication-Results: i=3; mx.google.com; arc=pass ams.d= >>> google.com ams.s=arc as.d=google.com as.s=arc >>> >>> The spec currently says i can go up to 1024 but unlikely over 50, are we >>> going to generate: >>> Arc-Authentication-Results: i=50; mx.google.com; >>> arc=pass ams49.d=google.com ams49.s=arc-20160816 as49.d=google.com >>> ams49.s=arc-20160816 >>> ams48.d=google.com ams48.s=arc-20160816 as48.d=google.com >>> ams48.s=arc-20160816 >>> ams47.d=google.com ams47.s=arc-20160816 as47.d=google.com >>> ams47.s=arc-20160816 >>> ams46.d=google.com ams46.s=arc-20160816 as46.d=google.com >>> ams46.s=arc-20160816 >>> ams45.d=google.com ams45.s=arc-20160816 as45.d=google.com >>> ams45.s=arc-20160816 >>> ams44.d=google.com ams44.s=arc-20160816 as44.d=google.com >>> ams44.s=arc-20160816 >>> ams43.d=google.com ams43.s=arc-20160816 as43.d=google.com >>> ams43.s=arc-20160816 >>> ams42.d=google.com ams42.s=arc-20160816 as42.d=google.com >>> ams42.s=arc-20160816 >>> ams41.d=google.com ams41.s=arc-20160816 as41.d=google.com >>> ams41.s=arc-20160816 >>> ams40.d=google.com ams40.s=arc-20160816 as40.d=google.com >>> ams40.s=arc-20160816 >>> ams39.d=google.com ams39.s=arc-20160816 as39.d=google.com >>> ams39.s=arc-20160816 >>> ams38.d=google.com ams38.s=arc-20160816 as38.d=google.com >>> ams38.s=arc-20160816 >>> ams37.d=google.com ams37.s=arc-20160816 as37.d=google.com >>> ams37.s=arc-20160816 >>> ams36.d=google.com ams36.s=arc-20160816 as36.d=google.com >>> ams36.s=arc-20160816 >>> ams35.d=google.com ams35.s=arc-20160816 as35.d=google.com >>> ams35.s=arc-20160816 >>> ams34.d=google.com ams34.s=arc-20160816 as34.d=google.com >>> ams34.s=arc-20160816 >>> ams33.d=google.com ams33.s=arc-20160816 as33.d=google.com >>> ams33.s=arc-20160816 >>> ams32.d=google.com ams32.s=arc-20160816 as32.d=google.com >>> ams32.s=arc-20160816 >>> ams31.d=google.com ams31.s=arc-20160816 as31.d=google.com >>> ams31.s=arc-20160816 >>> ams30.d=google.com ams30.s=arc-20160816 as30.d=google.com >>> ams30.s=arc-20160816 >>> ams29.d=google.com ams29.s=arc-20160816 as29.d=google.com >>> ams29.s=arc-20160816 >>> ams28.d=google.com ams28.s=arc-20160816 as28.d=google.com >>> ams28.s=arc-20160816 >>> ams27.d=google.com ams27.s=arc-20160816 as27.d=google.com >>> ams27.s=arc-20160816 >>> ams26.d=google.com ams26.s=arc-20160816 as26.d=google.com >>> ams26.s=arc-20160816 >>> ams25.d=google.com ams25.s=arc-20160816 as25.d=google.com >>> ams25.s=arc-20160816 >>> ams24.d=google.com ams24.s=arc-20160816 as24.d=google.com >>> ams24.s=arc-20160816 >>> ams23.d=google.com ams23.s=arc-20160816 as23.d=google.com >>> ams23.s=arc-20160816 >>> ams22.d=google.com ams22.s=arc-20160816 as22.d=google.com >>> ams22.s=arc-20160816 >>> ams21.d=google.com ams21.s=arc-20160816 as21.d=google.com >>> ams21.s=arc-20160816 >>> ams20.d=google.com ams20.s=arc-20160816 as20.d=google.com >>> ams20.s=arc-20160816 >>> ams19.d=google.com ams19.s=arc-20160816 as19.d=google.com >>> ams19.s=arc-20160816 >>> ams18.d=google.com ams18.s=arc-20160816 as18.d=google.com >>> ams18.s=arc-20160816 >>> ams17.d=google.com ams17.s=arc-20160816 as17.d=google.com >>> ams17.s=arc-20160816 >>> ams16.d=google.com ams16.s=arc-20160816 as16.d=google.com >>> ams16.s=arc-20160816 >>> ams15.d=google.com ams15.s=arc-20160816 as15.d=google.com >>> ams15.s=arc-20160816 >>> ams14.d=google.com ams14.s=arc-20160816 as14.d=google.com >>> ams14.s=arc-20160816 >>> ams13.d=google.com ams13.s=arc-20160816 as13.d=google.com >>> ams13.s=arc-20160816 >>> ams12.d=google.com ams12.s=arc-20160816 as12.d=google.com >>> ams12.s=arc-20160816 >>> ams11.d=google.com ams11.s=arc-20160816 as11.d=google.com >>> ams11.s=arc-20160816 >>> ams10.d=google.com ams10.s=arc-20160816 as10.d=google.com >>> ams10.s=arc-20160816 >>> ams9.d=google.com ams9.s=arc-20160816 as9.d=google.com >>> ams9.s=arc-20160816 >>> ams8.d=google.com ams8.s=arc-20160816 as8.d=google.com >>> ams8.s=arc-20160816 >>> ams7.d=google.com ams7.s=arc-20160816 as7.d=google.com >>> ams7.s=arc-20160816 >>> ams6.d=google.com ams6.s=arc-20160816 as6.d=google.com >>> ams6.s=arc-20160816 >>> ams5.d=google.com ams5.s=arc-20160816 as5.d=google.com >>> ams5.s=arc-20160816 >>> ams4.d=google.com ams4.s=arc-20160816 as4.d=google.com >>> ams4.s=arc-20160816 >>> ams3.d=google.com ams3.s=arc-20160816 as3.d=google.com >>> ams3.s=arc-20160816 >>> ams2.d=google.com ams2.s=arc-20160816 as2.d=google.com >>> ams2.s=arc-20160816 >>> ams1.d=google.com ams1.s=arc-20160816 as1.d=google.com >>> ams1.s=arc-20160816 >>> >>> I'd also point out that this is iterative, so the i=49 one is only >>> slightly smaller and so on. >>> >>> Brandon >>> >>> On Tue, Jul 25, 2017 at 3:48 PM, Gene Shuman >>> wrote: >>> >>>> I do not have any better ideas. I just wanted to make sure I >>>> understood the situation correctly atm. >>>> >>>> On Tue, Jul 25, 2017 at 3:36 PM, Juri Haberland >>>> wrote: >>>> >>>>> On 26.07.2017 00:29, Kurt Andersen (b) wrote: >>>>> > On Tue, Jul 25, 2017 at 2:44 PM, Juri Haberland < >>>>> juri@sapienti-sat.org> >>>>> > wrote: >>>>> >> On 25.07.2017 21:31, Gene Shuman wrote: >>>>> >>>>> >> > inbound -> policyspf(or some other spf check) -> OpenDKIM -> >>>>> OpenDMARC >>>>> >> -> >>>>> >> > OpenARC Validation -> mailing list software -> OpenArc Signature >>>>> -> >>>>> >> > outbound. >>>>> >> >>>>> >> Well, OpenARC validation should be before OpenDMARC... >>>>> > >>>>> > Well, that depends on your implementation. If you generally evaluate >>>>> local >>>>> > policy conditions before checking the primary DMARC mechanisms, then >>>>> yes; >>>>> > otherwise, ARC only needs to be evaluated if DMARC does not achieve >>>>> a PASS >>>>> > from the primary mechanism or if you expect to break the message's >>>>> > authentication. >>>>> >>>>> Granted, both ways are possible :) >>>>> >>>>> Juri >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>>> >>> >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> >> > --001a113f19a2fd3be90555a58733 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I understand exactly why we want header.s.=C2=A0 But I thi= nk I might have incorrectly assumed that getting this from the arc signatur= es was good enough.

On Mon, Jul 31, 2017 at 4:31 PM, Brandon Long <= ;blong@fiction.net> wrote:
In = that case, I dislike specifying the hop number in the ptype, given the regi= stry nature of the ptype and property, it seems like they should be specifi= c and not an enumerated value.

Brandon


On Mon, Jul 31, 2017 at 4:25 PM, Gen= e Shuman <geneshuman@gmail.com> wrote:
I was just talking with Seth about this.= =C2=A0 I think the language was poorly worded, and the intention is not to = have a million ams.s, ams.ds in the aar, but just the ones from the most re= cent hop.=C2=A0 Is this correct?

Also, I still dont like= ARC implementations being asked to parse DKIM signatures to get header.s.= =C2=A0 Nor do I really understand why we want that info.

On Mon, Jul 31,= 2017 at 4:20 PM, Brandon Long <blong@fiction.net> wrote:
Catching up here...
Perhaps the traditional separation of all of the mail authenti= cators is what should change, ie if we combined the various handlers into o= ne, then it becomes much more obvious how the information flow would occur.=

For our impl, it's just various calls within = the single process, hence why it's easy to issue a single authres heade= r as well.

Looking at the 5.1.1 section, I do thin= k we should specify that the source.ip is either in the arc section or the = spf section, and not leave that to random choice.

= I also do not like the arc related data as specified.=C2=A0 If the arc chai= n is intact, then the information is trivially extracted from the chain, if= it's not intact, then who cares.
Even if we want to include = this data, I think the fact that we have a chain of data could be used, and= therefore we would only include the i-1 hop data in the single aar.
<= div>
Arc-Authentication-Results: i=3D3; mx.google.com; arc=3Dpass ams.d=3Dgoogle.com ams.s=3Darc as.d=3D= google.com as.s=3Darc

The spec currently says i can go up to 1024 but unl= ikely over 50, are we going to generate:
Arc-Authentication-Resul= ts: i=3D50; mx.google.co= m;
=C2=A0 =C2=A0 arc=3Dpass ams49.d=3Dgoogle.com ams49.s=3Darc-20160816 as49.d=3Dgoogle.com ams49.s=3Darc-2= 0160816
=C2=A0 =C2=A0 ams48.d=3Dgoogle.com ams48.s=3Darc-20160816 as48.d=3Dgoogle.com ams48.s=3Darc-20160= 816
=C2=A0 =C2=A0 ams47.d=3Dgoogle.com ams47.s=3Darc-20160816 as47.d=3Dgoogle.com ams47.s=3Darc-20160816
=
=C2=A0 =C2=A0 ams46.d=3Dgoogle.com ams46.s=3Darc-20160816 as46.d=3Dgoogle.com ams46.s=3Darc-20160816
=C2= =A0 =C2=A0 ams45.d=3Dgoogle= .com ams45.s=3Darc-20160816 as45.d=3Dgoogle.com ams45.s=3Darc-20160816
=C2=A0 =C2=A0= ams44.d=3Dgoogle.com a= ms44.s=3Darc-20160816 as44.d=3Dgoogle.com ams44.s=3Darc-20160816
=C2=A0 =C2=A0 ams43.d= =3Dgoogle.com ams43.s= =3Darc-20160816 as43.d=3Dgo= ogle.com ams43.s=3Darc-20160816
=C2=A0 =C2=A0 ams42.d=3Dgoogle.com ams42.s=3Darc-201= 60816 as42.d=3Dgoogle.com ams42.s=3Darc-20160816
=C2=A0 =C2=A0 ams41.d=3Dgoogle.com ams41.s=3Darc-20160816 as41= .d=3Dgoogle.com ams41.s= =3Darc-20160816
=C2=A0 =C2=A0 ams40.d=3Dgoogle.com ams40.s=3Darc-20160816 as40.d=3Dgoogle.com ams40.s=3Darc-201= 60816
=C2=A0 =C2=A0 ams39.d=3Dgoogle.com ams39.s=3Darc-20160816 as39.d=3Dgoogle.com ams39.s=3Darc-20160816
=C2=A0 =C2=A0 ams38.d=3Dgoogle.com ams38.s=3Darc-20160816 as38.d=3Dgoogle.com ams38.s=3Darc-20160816
=C2= =A0 =C2=A0 ams37.d=3Dgoogle= .com ams37.s=3Darc-20160816 as37.d=3Dgoogle.com ams37.s=3Darc-20160816
=C2=A0 =C2=A0= ams36.d=3Dgoogle.com a= ms36.s=3Darc-20160816 as36.d=3Dgoogle.com ams36.s=3Darc-20160816
=C2=A0 =C2=A0 ams35.d= =3Dgoogle.com ams35.s= =3Darc-20160816 as35.d=3Dgo= ogle.com ams35.s=3Darc-20160816
=C2=A0 =C2=A0 ams34.d=3Dgoogle.com ams34.s=3Darc-201= 60816 as34.d=3Dgoogle.com ams34.s=3Darc-20160816
=C2=A0 =C2=A0 ams33.d=3Dgoogle.com ams33.s=3Darc-20160816 as33= .d=3Dgoogle.com ams33.s= =3Darc-20160816
=C2=A0 =C2=A0 ams32.d=3Dgoogle.com ams32.s=3Darc-20160816 as32.d=3Dgoogle.com ams32.s=3Darc-201= 60816
=C2=A0 =C2=A0 ams31.d=3Dgoogle.com ams31.s=3Darc-20160816 as31.d=3Dgoogle.com ams31.s=3Darc-20160816
=C2=A0 =C2=A0 ams30.d=3Dgoogle.com ams30.s=3Darc-20160816 as30.d=3Dgoogle.com ams30.s=3Darc-20160816
=C2= =A0 =C2=A0 ams29.d=3Dgoogle= .com ams29.s=3Darc-20160816 as29.d=3Dgoogle.com ams29.s=3Darc-20160816
=C2=A0 =C2=A0= ams28.d=3Dgoogle.com a= ms28.s=3Darc-20160816 as28.d=3Dgoogle.com ams28.s=3Darc-20160816
=C2=A0 =C2=A0 ams27.d= =3Dgoogle.com ams27.s= =3Darc-20160816 as27.d=3Dgo= ogle.com ams27.s=3Darc-20160816
=C2=A0 =C2=A0 ams26.d=3Dgoogle.com ams26.s=3Darc-201= 60816 as26.d=3Dgoogle.com ams26.s=3Darc-20160816
=C2=A0 =C2=A0 ams25.d=3Dgoogle.com ams25.s=3Darc-20160816 as25= .d=3Dgoogle.com ams25.s= =3Darc-20160816
=C2=A0 =C2=A0 ams24.d=3Dgoogle.com ams24.s=3Darc-20160816 as24.d=3Dgoogle.com ams24.s=3Darc-201= 60816
=C2=A0 =C2=A0 ams23.d=3Dgoogle.com ams23.s=3Darc-20160816 as23.d=3Dgoogle.com ams23.s=3Darc-20160816
=C2=A0 =C2=A0 ams22.d=3Dgoogle.com ams22.s=3Darc-20160816 as22.d=3Dgoogle.com ams22.s=3Darc-20160816
=C2= =A0 =C2=A0 ams21.d=3Dgoogle= .com ams21.s=3Darc-20160816 as21.d=3Dgoogle.com ams21.s=3Darc-20160816
=C2=A0 =C2=A0= ams20.d=3Dgoogle.com a= ms20.s=3Darc-20160816 as20.d=3Dgoogle.com ams20.s=3Darc-20160816
=C2=A0 =C2=A0 ams19.d= =3Dgoogle.com ams19.s= =3Darc-20160816 as19.d=3Dgo= ogle.com ams19.s=3Darc-20160816
=C2=A0 =C2=A0 ams18.d=3Dgoogle.com ams18.s=3Darc-201= 60816 as18.d=3Dgoogle.com ams18.s=3Darc-20160816
=C2=A0 =C2=A0 ams17.d=3Dgoogle.com ams17.s=3Darc-20160816 as17= .d=3Dgoogle.com ams17.s= =3Darc-20160816
=C2=A0 =C2=A0 ams16.d=3Dgoogle.com ams16.s=3Darc-20160816 as16.d=3Dgoogle.com ams16.s=3Darc-201= 60816
=C2=A0 =C2=A0 ams15.d=3Dgoogle.com ams15.s=3Darc-20160816 as15.d=3Dgoogle.com ams15.s=3Darc-20160816
=C2=A0 =C2=A0 ams14.d=3Dgoogle.com ams14.s=3Darc-20160816 as14.d=3Dgoogle.com ams14.s=3Darc-20160816
=C2= =A0 =C2=A0 ams13.d=3Dgoogle= .com ams13.s=3Darc-20160816 as13.d=3Dgoogle.com ams13.s=3Darc-20160816
=C2=A0 =C2=A0= ams12.d=3Dgoogle.com a= ms12.s=3Darc-20160816 as12.d=3Dgoogle.com ams12.s=3Darc-20160816
=C2=A0 =C2=A0 ams11.d= =3Dgoogle.com ams11.s= =3Darc-20160816 as11.d=3Dgo= ogle.com ams11.s=3Darc-20160816
=C2=A0 =C2=A0 ams10.d=3Dgoogle.com ams10.s=3Darc-201= 60816 as10.d=3Dgoogle.com ams10.s=3Darc-20160816
=C2=A0 =C2=A0 ams9.d=3Dgoogle.com ams9.s=3Darc-20160816 as9.d= =3Dgoogle.com ams9.s=3D= arc-20160816
=C2=A0 =C2=A0 ams8.d=3Dgoogle.com ams8.s=3Darc-20160816 as8.d=3Dgoogle.com ams8.s=3Darc-20160816
=C2=A0 =C2=A0 ams7.d=3Dgoogle.com ams7.s=3Darc-20160816 as7.d=3Dgoogle.com ams7.s=3Darc-20160816
=C2= =A0 =C2=A0 ams6.d=3Dgoogle.= com ams6.s=3Darc-20160816 as6.d=3Dgoogle.com ams6.s=3Darc-20160816
=C2=A0 =C2=A0 am= s5.d=3Dgoogle.com ams5.= s=3Darc-20160816 as5.d=3Dgo= ogle.com ams5.s=3Darc-20160816
=C2=A0 =C2=A0 ams4.d=3Dgoogle.com ams4.s=3Darc-201608= 16 as4.d=3Dgoogle.com a= ms4.s=3Darc-20160816
=C2=A0 =C2=A0 ams3.d=3Dgoogle.com ams3.s=3Darc-20160816 as3.d=3Dgoogle.com ams3.s=3Darc-20= 160816
=C2=A0 =C2=A0 ams2.d=3Dgoogle.com ams2.s=3Darc-20160816 as2.d=3Dgoogle.com ams2.s=3Darc-20160816
=C2=A0 =C2=A0 ams1.d=3Dg= oogle.com ams1.s=3Darc-20160816 as1.d=3Dgoogle.com ams1.s=3Darc-20160816

<= /div>
I'd also point out that this is iterative, so the i=3D49 one = is only slightly smaller and so on.

Brandon

On T= ue, Jul 25, 2017 at 3:48 PM, Gene Shuman <geneshuman@gmail.com><= /span> wrote:
I do not h= ave any better ideas.=C2=A0 I just wanted to make sure I understood the sit= uation correctly atm. =C2=A0

On Tue, Jul 25, 2017 at 3:36 PM, Juri = Haberland <juri@sapienti-sat.org> wrote:
On 26.07.2017 00:29, Kurt Andersen (b) wrote: > On Tue, Jul 25, 2017 at 2:44 PM, Juri Haberland <juri@sapienti-sat.org>
> wrote:
>> On 25.07.2017 21:31, Gene Shuman wrote:

>> > inbound -> policyspf(or some other spf check)= =C2=A0 -> OpenDKIM -> OpenDMARC
>> ->
>> > OpenARC Validation -> mailing list software -> OpenArc = Signature ->
>> > outbound.
>>
>> Well, OpenARC validation should be before OpenDMARC...
>
> Well, that depends on your implementation. If you generally evaluate l= ocal
> policy conditions before checking the primary DMARC mechanisms, then y= es;
> otherwise, ARC only needs to be evaluated if DMARC does not achieve a = PASS
> from the primary mechanism or if you expect to break the message's=
> authentication.

Granted, both ways are possible :)

=C2=A0 Juri

_______________________________________________
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




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



--001a113f19a2fd3be90555a58733-- From nobody Mon Jul 31 16:41:50 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31B5312EB9B for ; Mon, 31 Jul 2017 16:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 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, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fiction.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwWqz8AVx9JM for ; Mon, 31 Jul 2017 16:41:46 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80E5C12EB2B for ; Mon, 31 Jul 2017 16:41:46 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id x3so910228oia.1 for ; Mon, 31 Jul 2017 16:41:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fiction.net; s=google; h=mime-version:from:date:message-id:subject:to; bh=fKB2tpsrvgtx2vnQeexOgmJEmXY6t0HoxuFaFPnmG/g=; b=S353HGEAYbJehz2Txh9HP16wxtkRfpyo3vvCHI2hUxHszQ5+nhG5p4H8rPlt3OLNVR VtjiOcfm/saI2VA5CVjU2NdFy3qRIOrNlvcNANMvGLnxnd09ULV096n09sj3THblUyH5 3+A40Y8k3z2ISWzOq0wClpQbtUaRnbn0+gxLdOEn3RnCQPjjNoIXRBx8EEG6RIognU/b tsmY8JDAOTHKeBS30pJ2CpoMFqt/TgrC8nqU2aMZVvH/0sorwhgmaWbZzRstvd7tx4/n Y38VboUGuOxe/raNuMPBzlM65I86GMhbiG+22U6esQGLERL9eaX+NH8tyioVgIcsAGkc HXcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=fKB2tpsrvgtx2vnQeexOgmJEmXY6t0HoxuFaFPnmG/g=; b=GTUJ4l/yxuSsGqynkFcf8efkvpY0iDqqVk/TaSqskO+i+UkI6vYNIurm5pUHNU4sWU 4rpGQDMb3Uk0l01b5a6q99UTMkgFVYa4kVgYLLnzPdhfhT8k54Y7yDAtZfQgGeKWJAP0 jJMxUhoqTlvAV8XMaKMLmfMlWfIVeNPKCJIFJ6i3euvshzsaa1lerEwa6I+jleUZDtoa XcPQ1UgZjnFUvzwx/4Slwnmb9VEPHUPaOfpA5XJMkNyVy2jy4OcJOjrAjSW4jY1NAhJc vqyLfQyMlonJP8rUIuY1MySMKovrA6gLMGqaiG76z6Nnsu7EXvVkK5ZDLlMG+e8GNt3G c8Ww== X-Gm-Message-State: AIVw1115SE1uQuKIdy0xEB3ugLRE3qgTP60/PkMaxIMyMT82co4inIpr suNozephLLN5t+KnC10= X-Received: by 10.202.177.137 with SMTP id a131mr15691492oif.172.1501544505717; Mon, 31 Jul 2017 16:41:45 -0700 (PDT) Received: from mail-oi0-f43.google.com (mail-oi0-f43.google.com. [209.85.218.43]) by smtp.gmail.com with ESMTPSA id b188sm29241020oia.17.2017.07.31.16.41.45 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 31 Jul 2017 16:41:45 -0700 (PDT) Received: by mail-oi0-f43.google.com with SMTP id g131so689067oic.3 for ; Mon, 31 Jul 2017 16:41:45 -0700 (PDT) X-Received: by 10.202.179.137 with SMTP id c131mr15394678oif.298.1501544504684; Mon, 31 Jul 2017 16:41:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.154.51 with HTTP; Mon, 31 Jul 2017 16:41:44 -0700 (PDT) From: Brandon Long Date: Mon, 31 Jul 2017 16:41:44 -0700 X-Gmail-Original-Message-ID: Message-ID: To: "dmarc@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [dmarc-ietf] dns failures in the draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 23:41:48 -0000 > 9.4. Handling DNS Problems While Validating ARC > DNS failures to resolve or return data which is needed for ARC > validation SHOULD result in a 421 tempfail during the SMTP > conversation with the sending system. Temporary or intermittent DNS > problems will generally not be sufficiently transitory to allow a > mediator to obtain a different result during the ordinary transit > duration so it is better to have the source system queue the > problematic message(s) than to generate (potential) backscatter. > > Operators of systems which mediate mail should be aware that broken > DNS records (or malfunctioning name servers) will result in > undeliverable mail to any downstream ARC-verifying ADMDs. > > DNS-based failures to verify a chain are treated no differently than > any other ARC violation. They result in a "cv=fail" verdict. I don't know if SHOULD is the right choice here. For a large percentage of mail, ARC is unnecessary, even when forwarded through an intermediary. The mail will continue to DMARC pass, or the mail will not be for a DMARC p=reject domain. I think that issuing a temp fail instead of a perm fail on a DMARC reject if the arc chain may have allowed a local policy override is useful, but to temp fail all arc dns failures may be more harmful than helpful. I think I used the dns failure case as a place where cv=fail instead of just not signing was actually more harmful, but that seemed more complicated than others were willing to go. Of course, passing the dns failure from a separate arc milter to a dmarc milter to make that determination is complicated, though in authres terms, we could use an arc=tempfail result to pass that info on. Brandon From nobody Mon Jul 31 16:46:13 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39241131473 for ; Mon, 31 Jul 2017 16:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YofKy_2QCtC6 for ; Mon, 31 Jul 2017 16:46:08 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 547D81243F6 for ; Mon, 31 Jul 2017 16:46:08 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id l82so432609ywc.2 for ; Mon, 31 Jul 2017 16:46:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=n73GTjlKA22mktraAEcqyFSiIR6aNIaOyn6JNTiuj/o=; b=aIb1+bPtna0kjAoBQdQqx4GYL0BYOg+jm3ODpTTOyRIAOeRRdKrqyNDRbmm80c0XZ4 aiq8eoqFORWd3QYi2CpYpVoYwoXmwAS+BbgxrQwNKM7RTyAssJHIA9rjiAS/3YOKI65U rsNqSl4yLnZPwxV2lFe6psDHTWrpb5S/+SP5IBd4E32QAA3d5GuJR+hz8ELv7ZTiOZzQ n30DgoRLz4Aw+Yt68UqL4sindaohO4cX8klU4fht64Xg1iqFQZWyFC16m5hRNbgNqCuk FtJgxUuVoXXwWb9Q5COI329WOptCr4vjwOLDTbNlRDZavfdkY047Hev+sieKBjeUOjxU /L7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=n73GTjlKA22mktraAEcqyFSiIR6aNIaOyn6JNTiuj/o=; b=P8cwIl+q2fjq+iUNELK4wKOgsWoLU4JOFjrIIrkji5v+mGNFO64Ie4Y+Qm8/C16zzx trHbiKmeDOFZXM2WIkeyXNVtVh8C5/jV2YxJtKCbxVI2+NHv/Z935Ni2BKBTK7O+FZ1z 3W+eTREGVdqQxFVumxPu8sKRFonwhQook6XioAdZ9pO353wHmsK8WhynrjiQ61J41iF0 BZ9EHCqHIfupAaEDT4z5Kdbg/x727G7Ip6Zfr+os2gH5pC7dqTamIVllVNqaclh+tRIA ru5HF962h16LJfRQ2OvOyzuul8es8viHC2+lSSEoIkD0kZMb9ifzSiyuKk40OaGD10TT AaOw== X-Gm-Message-State: AIVw112jJz8a+smUdbyxvmfob4p0vh9M4MSu1uwGnXhC5G0xEYR2LKEy JMqDqAUcdAN/tBWFhM3drLyO89VylT68 X-Received: by 10.129.197.73 with SMTP id o9mr4386178ywj.183.1501544767609; Mon, 31 Jul 2017 16:46:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.45.25 with HTTP; Mon, 31 Jul 2017 16:46:07 -0700 (PDT) In-Reply-To: References: <9f93d9c9-5c84-9f78-6b22-2c637efdd09f@sapienti-sat.org> From: Gene Shuman Date: Mon, 31 Jul 2017 16:46:07 -0700 Message-ID: To: Gene Shuman Cc: Brandon Long , "dmarc@ietf.org" , Juri Haberland Content-Type: multipart/alternative; boundary="94eb2c1a4f387cf57d0555a5a274" Archived-At: Subject: Re: [dmarc-ietf] questions about section 5.1.1 of the new ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 23:46:12 -0000 --94eb2c1a4f387cf57d0555a5a274 Content-Type: text/plain; charset="UTF-8" But I understand now, simple misunderstanding. So is this assumption correct? An AAR should look like this: Arc-Authentication-Results: i=14; mx.google.com; arc=pass ams.d=google.com ams.s=arc-20160816 as.d=google.com ams.s=arc-20160816 Maybe with some additional dkim/spf/dmarc info. This seems reasonable enough to me On Mon, Jul 31, 2017 at 4:38 PM, Gene Shuman wrote: > I understand exactly why we want header.s. But I think I might have > incorrectly assumed that getting this from the arc signatures was good > enough. > > On Mon, Jul 31, 2017 at 4:31 PM, Brandon Long wrote: > >> In that case, I dislike specifying the hop number in the ptype, given the >> registry nature of the ptype and property, it seems like they should be >> specific and not an enumerated value. >> >> Brandon >> >> >> On Mon, Jul 31, 2017 at 4:25 PM, Gene Shuman >> wrote: >> >>> I was just talking with Seth about this. I think the language was >>> poorly worded, and the intention is not to have a million ams.s, ams.ds in >>> the aar, but just the ones from the most recent hop. Is this correct? >>> >>> Also, I still dont like ARC implementations being asked to parse DKIM >>> signatures to get header.s. Nor do I really understand why we want that >>> info. >>> >>> On Mon, Jul 31, 2017 at 4:20 PM, Brandon Long wrote: >>> >>>> Catching up here... >>>> >>>> Perhaps the traditional separation of all of the mail authenticators is >>>> what should change, ie if we combined the various handlers into one, then >>>> it becomes much more obvious how the information flow would occur. >>>> >>>> For our impl, it's just various calls within the single process, hence >>>> why it's easy to issue a single authres header as well. >>>> >>>> Looking at the 5.1.1 section, I do think we should specify that the >>>> source.ip is either in the arc section or the spf section, and not leave >>>> that to random choice. >>>> >>>> I also do not like the arc related data as specified. If the arc chain >>>> is intact, then the information is trivially extracted from the chain, if >>>> it's not intact, then who cares. >>>> Even if we want to include this data, I think the fact that we have a >>>> chain of data could be used, and therefore we would only include the i-1 >>>> hop data in the single aar. >>>> >>>> Arc-Authentication-Results: i=3; mx.google.com; arc=pass ams.d= >>>> google.com ams.s=arc as.d=google.com as.s=arc >>>> >>>> The spec currently says i can go up to 1024 but unlikely over 50, are >>>> we going to generate: >>>> Arc-Authentication-Results: i=50; mx.google.com; >>>> arc=pass ams49.d=google.com ams49.s=arc-20160816 as49.d=google.com >>>> ams49.s=arc-20160816 >>>> ams48.d=google.com ams48.s=arc-20160816 as48.d=google.com >>>> ams48.s=arc-20160816 >>>> ams47.d=google.com ams47.s=arc-20160816 as47.d=google.com >>>> ams47.s=arc-20160816 >>>> ams46.d=google.com ams46.s=arc-20160816 as46.d=google.com >>>> ams46.s=arc-20160816 >>>> ams45.d=google.com ams45.s=arc-20160816 as45.d=google.com >>>> ams45.s=arc-20160816 >>>> ams44.d=google.com ams44.s=arc-20160816 as44.d=google.com >>>> ams44.s=arc-20160816 >>>> ams43.d=google.com ams43.s=arc-20160816 as43.d=google.com >>>> ams43.s=arc-20160816 >>>> ams42.d=google.com ams42.s=arc-20160816 as42.d=google.com >>>> ams42.s=arc-20160816 >>>> ams41.d=google.com ams41.s=arc-20160816 as41.d=google.com >>>> ams41.s=arc-20160816 >>>> ams40.d=google.com ams40.s=arc-20160816 as40.d=google.com >>>> ams40.s=arc-20160816 >>>> ams39.d=google.com ams39.s=arc-20160816 as39.d=google.com >>>> ams39.s=arc-20160816 >>>> ams38.d=google.com ams38.s=arc-20160816 as38.d=google.com >>>> ams38.s=arc-20160816 >>>> ams37.d=google.com ams37.s=arc-20160816 as37.d=google.com >>>> ams37.s=arc-20160816 >>>> ams36.d=google.com ams36.s=arc-20160816 as36.d=google.com >>>> ams36.s=arc-20160816 >>>> ams35.d=google.com ams35.s=arc-20160816 as35.d=google.com >>>> ams35.s=arc-20160816 >>>> ams34.d=google.com ams34.s=arc-20160816 as34.d=google.com >>>> ams34.s=arc-20160816 >>>> ams33.d=google.com ams33.s=arc-20160816 as33.d=google.com >>>> ams33.s=arc-20160816 >>>> ams32.d=google.com ams32.s=arc-20160816 as32.d=google.com >>>> ams32.s=arc-20160816 >>>> ams31.d=google.com ams31.s=arc-20160816 as31.d=google.com >>>> ams31.s=arc-20160816 >>>> ams30.d=google.com ams30.s=arc-20160816 as30.d=google.com >>>> ams30.s=arc-20160816 >>>> ams29.d=google.com ams29.s=arc-20160816 as29.d=google.com >>>> ams29.s=arc-20160816 >>>> ams28.d=google.com ams28.s=arc-20160816 as28.d=google.com >>>> ams28.s=arc-20160816 >>>> ams27.d=google.com ams27.s=arc-20160816 as27.d=google.com >>>> ams27.s=arc-20160816 >>>> ams26.d=google.com ams26.s=arc-20160816 as26.d=google.com >>>> ams26.s=arc-20160816 >>>> ams25.d=google.com ams25.s=arc-20160816 as25.d=google.com >>>> ams25.s=arc-20160816 >>>> ams24.d=google.com ams24.s=arc-20160816 as24.d=google.com >>>> ams24.s=arc-20160816 >>>> ams23.d=google.com ams23.s=arc-20160816 as23.d=google.com >>>> ams23.s=arc-20160816 >>>> ams22.d=google.com ams22.s=arc-20160816 as22.d=google.com >>>> ams22.s=arc-20160816 >>>> ams21.d=google.com ams21.s=arc-20160816 as21.d=google.com >>>> ams21.s=arc-20160816 >>>> ams20.d=google.com ams20.s=arc-20160816 as20.d=google.com >>>> ams20.s=arc-20160816 >>>> ams19.d=google.com ams19.s=arc-20160816 as19.d=google.com >>>> ams19.s=arc-20160816 >>>> ams18.d=google.com ams18.s=arc-20160816 as18.d=google.com >>>> ams18.s=arc-20160816 >>>> ams17.d=google.com ams17.s=arc-20160816 as17.d=google.com >>>> ams17.s=arc-20160816 >>>> ams16.d=google.com ams16.s=arc-20160816 as16.d=google.com >>>> ams16.s=arc-20160816 >>>> ams15.d=google.com ams15.s=arc-20160816 as15.d=google.com >>>> ams15.s=arc-20160816 >>>> ams14.d=google.com ams14.s=arc-20160816 as14.d=google.com >>>> ams14.s=arc-20160816 >>>> ams13.d=google.com ams13.s=arc-20160816 as13.d=google.com >>>> ams13.s=arc-20160816 >>>> ams12.d=google.com ams12.s=arc-20160816 as12.d=google.com >>>> ams12.s=arc-20160816 >>>> ams11.d=google.com ams11.s=arc-20160816 as11.d=google.com >>>> ams11.s=arc-20160816 >>>> ams10.d=google.com ams10.s=arc-20160816 as10.d=google.com >>>> ams10.s=arc-20160816 >>>> ams9.d=google.com ams9.s=arc-20160816 as9.d=google.com >>>> ams9.s=arc-20160816 >>>> ams8.d=google.com ams8.s=arc-20160816 as8.d=google.com >>>> ams8.s=arc-20160816 >>>> ams7.d=google.com ams7.s=arc-20160816 as7.d=google.com >>>> ams7.s=arc-20160816 >>>> ams6.d=google.com ams6.s=arc-20160816 as6.d=google.com >>>> ams6.s=arc-20160816 >>>> ams5.d=google.com ams5.s=arc-20160816 as5.d=google.com >>>> ams5.s=arc-20160816 >>>> ams4.d=google.com ams4.s=arc-20160816 as4.d=google.com >>>> ams4.s=arc-20160816 >>>> ams3.d=google.com ams3.s=arc-20160816 as3.d=google.com >>>> ams3.s=arc-20160816 >>>> ams2.d=google.com ams2.s=arc-20160816 as2.d=google.com >>>> ams2.s=arc-20160816 >>>> ams1.d=google.com ams1.s=arc-20160816 as1.d=google.com >>>> ams1.s=arc-20160816 >>>> >>>> I'd also point out that this is iterative, so the i=49 one is only >>>> slightly smaller and so on. >>>> >>>> Brandon >>>> >>>> On Tue, Jul 25, 2017 at 3:48 PM, Gene Shuman >>>> wrote: >>>> >>>>> I do not have any better ideas. I just wanted to make sure I >>>>> understood the situation correctly atm. >>>>> >>>>> On Tue, Jul 25, 2017 at 3:36 PM, Juri Haberland >>>> > wrote: >>>>> >>>>>> On 26.07.2017 00:29, Kurt Andersen (b) wrote: >>>>>> > On Tue, Jul 25, 2017 at 2:44 PM, Juri Haberland < >>>>>> juri@sapienti-sat.org> >>>>>> > wrote: >>>>>> >> On 25.07.2017 21:31, Gene Shuman wrote: >>>>>> >>>>>> >> > inbound -> policyspf(or some other spf check) -> OpenDKIM -> >>>>>> OpenDMARC >>>>>> >> -> >>>>>> >> > OpenARC Validation -> mailing list software -> OpenArc Signature >>>>>> -> >>>>>> >> > outbound. >>>>>> >> >>>>>> >> Well, OpenARC validation should be before OpenDMARC... >>>>>> > >>>>>> > Well, that depends on your implementation. If you generally >>>>>> evaluate local >>>>>> > policy conditions before checking the primary DMARC mechanisms, >>>>>> then yes; >>>>>> > otherwise, ARC only needs to be evaluated if DMARC does not achieve >>>>>> a PASS >>>>>> > from the primary mechanism or if you expect to break the message's >>>>>> > authentication. >>>>>> >>>>>> Granted, both ways are possible :) >>>>>> >>>>>> Juri >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> 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 > > --94eb2c1a4f387cf57d0555a5a274 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
But I understand now, simple misunderstanding.

So is this assumption correct?=C2=A0 An AAR should look like this:<= /div>

Arc-Authentication= -Results: i=3D14;=C2=A0= mx.google.com;
=C2=A0 =C2=A0 arc= =3Dpass ams.d=3Dgoogle.com= =C2=A0ams.s=3Darc-20160816 as.d=3Dgoogle.com=C2=A0ams.s=3Darc-20160816

Maybe with some ad= ditional dkim/spf/dmarc info.=C2=A0 This seems reasonable enough to me
=C2=A0


On Mon, Jul 31, 2017= at 4:38 PM, Gene Shuman <geneshuman@gmail.com> wrote:
I understand exactly why w= e want header.s.=C2=A0 But I think I might have incorrectly assumed that ge= tting this from the arc signatures was good enough.

On Mon, Jul 31, 2017 at 4:31 PM, Brandon Long <blong@fiction.net&= gt; wrote:
In tha= t case, I dislike specifying the hop number in the ptype, given the registr= y nature of the ptype and property, it seems like they should be specific a= nd not an enumerated value.

Brandon
=


=
On Mon, Jul 31, 2017 at 4:25 PM, Gene Shuman <geneshuman@gmail.com> wrote:
I was just talking with Seth about this.=C2=A0 I think= the language was poorly worded, and the intention is not to have a million= ams.s, ams.ds in the aar, but just the ones from the most recent hop.=C2= =A0 Is this correct?

Also, I still dont like ARC impleme= ntations being asked to parse DKIM signatures to get header.s.=C2=A0 Nor do= I really understand why we want that info.

On Mon, Jul 31, 2017 at 4:20 PM, Brandon Long <blong@fict= ion.net> wrote:
Catching up here...

Perhaps the traditional separa= tion of all of the mail authenticators is what should change, ie if we comb= ined the various handlers into one, then it becomes much more obvious how t= he information flow would occur.

For our impl, it&= #39;s just various calls within the single process, hence why it's easy= to issue a single authres header as well.

Looking= at the 5.1.1 section, I do think we should specify that the source.ip is e= ither in the arc section or the spf section, and not leave that to random c= hoice.

I also do not like the arc related data as = specified.=C2=A0 If the arc chain is intact, then the information is trivia= lly extracted from the chain, if it's not intact, then who cares.
=
Even if we want to include this data, I think the fact that we have a = chain of data could be used, and therefore we would only include the i-1 ho= p data in the single aar.

Arc-Authentication-Resul= ts: i=3D3; mx.google.com= ; arc=3Dpass ams.d=3Dgo= ogle.com ams.s=3Darc as.d=3Dgoogle.com as.s=3Darc

The spec currently = says i can go up to 1024 but unlikely over 50, are we going to generate:
Arc-Authentication-Results: i=3D50; mx.google.com;
=C2=A0 =C2=A0 arc=3Dpass a= ms49.d=3Dgoogle.com ams= 49.s=3Darc-20160816 as49.d=3Dgoogle.com ams49.s=3Darc-20160816
=C2=A0 =C2=A0 ams48.= d=3Dgoogle.com ams48.s= =3Darc-20160816 as48.d=3Dgo= ogle.com ams48.s=3Darc-20160816
=C2=A0 =C2=A0 ams47.d=3Dgoogle.com ams47.s=3Darc-201= 60816 as47.d=3Dgoogle.com ams47.s=3Darc-20160816
=C2=A0 =C2=A0 ams46.d=3Dgoogle.com ams46.s=3Darc-20160816 as46= .d=3Dgoogle.com ams46.s= =3Darc-20160816
=C2=A0 =C2=A0 ams45.d=3Dgoogle.com ams45.s=3Darc-20160816 as45.d=3Dgoogle.com ams45.s=3Darc-201= 60816
=C2=A0 =C2=A0 ams44.d=3Dgoogle.com ams44.s=3Darc-20160816 as44.d=3Dgoogle.com ams44.s=3Darc-20160816
=C2=A0 =C2=A0 ams43.d=3Dgoogle.com ams43.s=3Darc-20160816 as43.d=3Dgoogle.com ams43.s=3Darc-20160816
=C2= =A0 =C2=A0 ams42.d=3Dgoogle= .com ams42.s=3Darc-20160816 as42.d=3Dgoogle.com ams42.s=3Darc-20160816
=C2=A0 =C2=A0= ams41.d=3Dgoogle.com a= ms41.s=3Darc-20160816 as41.d=3Dgoogle.com ams41.s=3Darc-20160816
=C2=A0 =C2=A0 ams40.d= =3Dgoogle.com ams40.s= =3Darc-20160816 as40.d=3Dgo= ogle.com ams40.s=3Darc-20160816
=C2=A0 =C2=A0 ams39.d=3Dgoogle.com ams39.s=3Darc-201= 60816 as39.d=3Dgoogle.com ams39.s=3Darc-20160816
=C2=A0 =C2=A0 ams38.d=3Dgoogle.com ams38.s=3Darc-20160816 as38= .d=3Dgoogle.com ams38.s= =3Darc-20160816
=C2=A0 =C2=A0 ams37.d=3Dgoogle.com ams37.s=3Darc-20160816 as37.d=3Dgoogle.com ams37.s=3Darc-201= 60816
=C2=A0 =C2=A0 ams36.d=3Dgoogle.com ams36.s=3Darc-20160816 as36.d=3Dgoogle.com ams36.s=3Darc-20160816
=C2=A0 =C2=A0 ams35.d=3Dgoogle.com ams35.s=3Darc-20160816 as35.d=3Dgoogle.com ams35.s=3Darc-20160816
=C2= =A0 =C2=A0 ams34.d=3Dgoogle= .com ams34.s=3Darc-20160816 as34.d=3Dgoogle.com ams34.s=3Darc-20160816
=C2=A0 =C2=A0= ams33.d=3Dgoogle.com a= ms33.s=3Darc-20160816 as33.d=3Dgoogle.com ams33.s=3Darc-20160816
=C2=A0 =C2=A0 ams32.d= =3Dgoogle.com ams32.s= =3Darc-20160816 as32.d=3Dgo= ogle.com ams32.s=3Darc-20160816
=C2=A0 =C2=A0 ams31.d=3Dgoogle.com ams31.s=3Darc-201= 60816 as31.d=3Dgoogle.com ams31.s=3Darc-20160816
=C2=A0 =C2=A0 ams30.d=3Dgoogle.com ams30.s=3Darc-20160816 as30= .d=3Dgoogle.com ams30.s= =3Darc-20160816
=C2=A0 =C2=A0 ams29.d=3Dgoogle.com ams29.s=3Darc-20160816 as29.d=3Dgoogle.com ams29.s=3Darc-201= 60816
=C2=A0 =C2=A0 ams28.d=3Dgoogle.com ams28.s=3Darc-20160816 as28.d=3Dgoogle.com ams28.s=3Darc-20160816
=C2=A0 =C2=A0 ams27.d=3Dgoogle.com ams27.s=3Darc-20160816 as27.d=3Dgoogle.com ams27.s=3Darc-20160816
=C2= =A0 =C2=A0 ams26.d=3Dgoogle= .com ams26.s=3Darc-20160816 as26.d=3Dgoogle.com ams26.s=3Darc-20160816
=C2=A0 =C2=A0= ams25.d=3Dgoogle.com a= ms25.s=3Darc-20160816 as25.d=3Dgoogle.com ams25.s=3Darc-20160816
=C2=A0 =C2=A0 ams24.d= =3Dgoogle.com ams24.s= =3Darc-20160816 as24.d=3Dgo= ogle.com ams24.s=3Darc-20160816
=C2=A0 =C2=A0 ams23.d=3Dgoogle.com ams23.s=3Darc-201= 60816 as23.d=3Dgoogle.com ams23.s=3Darc-20160816
=C2=A0 =C2=A0 ams22.d=3Dgoogle.com ams22.s=3Darc-20160816 as22= .d=3Dgoogle.com ams22.s= =3Darc-20160816
=C2=A0 =C2=A0 ams21.d=3Dgoogle.com ams21.s=3Darc-20160816 as21.d=3Dgoogle.com ams21.s=3Darc-201= 60816
=C2=A0 =C2=A0 ams20.d=3Dgoogle.com ams20.s=3Darc-20160816 as20.d=3Dgoogle.com ams20.s=3Darc-20160816
=C2=A0 =C2=A0 ams19.d=3Dgoogle.com ams19.s=3Darc-20160816 as19.d=3Dgoogle.com ams19.s=3Darc-20160816
=C2= =A0 =C2=A0 ams18.d=3Dgoogle= .com ams18.s=3Darc-20160816 as18.d=3Dgoogle.com ams18.s=3Darc-20160816
=C2=A0 =C2=A0= ams17.d=3Dgoogle.com a= ms17.s=3Darc-20160816 as17.d=3Dgoogle.com ams17.s=3Darc-20160816
=C2=A0 =C2=A0 ams16.d= =3Dgoogle.com ams16.s= =3Darc-20160816 as16.d=3Dgo= ogle.com ams16.s=3Darc-20160816
=C2=A0 =C2=A0 ams15.d=3Dgoogle.com ams15.s=3Darc-201= 60816 as15.d=3Dgoogle.com ams15.s=3Darc-20160816
=C2=A0 =C2=A0 ams14.d=3Dgoogle.com ams14.s=3Darc-20160816 as14= .d=3Dgoogle.com ams14.s= =3Darc-20160816
=C2=A0 =C2=A0 ams13.d=3Dgoogle.com ams13.s=3Darc-20160816 as13.d=3Dgoogle.com ams13.s=3Darc-201= 60816
=C2=A0 =C2=A0 ams12.d=3Dgoogle.com ams12.s=3Darc-20160816 as12.d=3Dgoogle.com ams12.s=3Darc-20160816
=C2=A0 =C2=A0 ams11.d=3Dgoogle.com ams11.s=3Darc-20160816 as11.d=3Dgoogle.com ams11.s=3Darc-20160816
=C2= =A0 =C2=A0 ams10.d=3Dgoogle= .com ams10.s=3Darc-20160816 as10.d=3Dgoogle.com ams10.s=3Darc-20160816
=C2=A0 =C2=A0= ams9.d=3Dgoogle.com am= s9.s=3Darc-20160816 as9.d=3Dgoogle.com ams9.s=3Darc-20160816
=C2=A0 =C2=A0 ams8.d=3Dgoogle.com ams8.s=3Darc-201= 60816 as8.d=3Dgoogle.com ams8.s=3Darc-20160816
=C2=A0 =C2=A0 ams7.d=3Dgoogle.com ams7.s=3Darc-20160816 as7.d=3D= google.com ams7.s=3Darc= -20160816
=C2=A0 =C2=A0 ams6.d=3Dgoogle.com ams6.s=3Darc-20160816 as6.d=3Dgoogle.com ams6.s=3Darc-20160816
=C2=A0 =C2=A0 ams5.d=3Dgoogle.com ams5.s=3Darc-20160816 as5.d=3Dgoogle.com ams5.s=3Darc-20160816
=C2=A0 = =C2=A0 ams4.d=3Dgoogle.com<= /a> ams4.s=3Darc-20160816 as4.d=3Dgoogle.com ams4.s=3Darc-20160816
=C2=A0 =C2=A0 ams3.d= =3Dgoogle.com ams3.s=3D= arc-20160816 as3.d=3Dgoogle= .com ams3.s=3Darc-20160816
=C2=A0 =C2=A0 ams2.d=3Dgoogle.com ams2.s=3Darc-20160816 a= s2.d=3Dgoogle.com ams2.= s=3Darc-20160816
=C2=A0 =C2=A0 ams1.d=3Dgoogle.com ams1.s=3Darc-20160816 as1.d=3Dgoogle.com ams1.s=3Darc-201608= 16

I'd also point out that this is itera= tive, so the i=3D49 one is only slightly smaller and so on.

Brandon
=

On Tue, Jul 25, 2017 at 3:48 PM, Gene Shuman &= lt;geneshuman@gma= il.com> wrote:
I do not have any better ideas.=C2=A0 I just wanted to make sure I und= erstood the situation correctly atm. =C2=A0

On Tue, Jul 25, 2017 at 3:36 PM, Juri Haberland <= juri@sapienti-sat.org> wrote:
On 26.07.2017 00:29, Kurt Andersen (b) wrote:
> On Tue, Jul 25, 2017 at 2:44 PM, Juri Haberland <juri@sapienti-sat.org>
> wrote:
>> On 25.07.2017 21:31, Gene Shuman wrote:

>> > inbound -> policyspf(or some other spf check)= =C2=A0 -> OpenDKIM -> OpenDMARC
>> ->
>> > OpenARC Validation -> mailing list software -> OpenArc = Signature ->
>> > outbound.
>>
>> Well, OpenARC validation should be before OpenDMARC...
>
> Well, that depends on your implementation. If you generally evaluate l= ocal
> policy conditions before checking the primary DMARC mechanisms, then y= es;
> otherwise, ARC only needs to be evaluated if DMARC does not achieve a = PASS
> from the primary mechanism or if you expect to break the message's=
> authentication.

Granted, both ways are possible :)

=C2=A0 Juri

_______________________________________________
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




_______________________________________________
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


--94eb2c1a4f387cf57d0555a5a274-- From nobody Mon Jul 31 16:53:22 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49BFC129A96 for ; Mon, 31 Jul 2017 16:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jlZ8JRxvFXHj for ; Mon, 31 Jul 2017 16:53:16 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A045113167B for ; Mon, 31 Jul 2017 16:53:16 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id g13so2052902ioj.5 for ; Mon, 31 Jul 2017 16:53:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YKE/jJEmXrLNskOyGsjgcx5HXDFgQqpwACAIR7yh0HA=; b=oeeDQJ2Hk3sN2C67C33iEXPneZwOaCNOh3/GKJ7N+wo3WMq7ajZtEEoVcL6mAkrheJ GsraFWzHfTxPwEFMxAwQAFET8IKXMzGZXnAoR1k11QM88I3uMJoon08T+xbpyJ90fqAW IQqB5qP4M9iN4zRyVCbSdeI4awWcIzvyCHgggAKsiPFFmaUXZrhwzp6cj+1TS3+LKFOi r22iUGuZwNR4gLf2rjlcE3TkJho4xLIbV5XKcLKCOIdkyvszHDpI9UV6F4fLALGSKOcc yCDb9bkUpnw8T2rAe/cwFtzgpeLRAA1DvewhMPIcg2VnDgFfbH2Rdr9w/IkyA937MBhg nYgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YKE/jJEmXrLNskOyGsjgcx5HXDFgQqpwACAIR7yh0HA=; b=XyU8S3ZHOXSlZvhQhJMWdTXqTQsBcHEF9P9+3HQ1UTpvu4JyH3tP+9VbSElIvSZrct Sd4AhsraKVRP9YVRv5T27+CY/Wm5SR0YjmJUdlBaaAHqoa8XwjArF3l1TX3du5HMF91f DFap0iXE6YLeYLkMT7gRQovMVSW1K5SyIeaVJLtyJdr+n76IOFbofup93efNtlw44dJL 9iClWGNG1LsTD81VnP2h4S3r3I0wg4e59Q0+vV8ijqNArereQGVG6+ZpNtBflh4XsqHF mw7Im+7ecT6YooXcKsq/Km1R36vzfJzvc8YFVXIeyic5plGZR4fFgbecR1ClcBMZwyM5 J+hg== X-Gm-Message-State: AIVw110OMZSeIryUTOXOgwVOsVepIkTB1tLp19w2nJwVfHMM3b5NUvvO Ja3OiLycAXKhlZaFUpRIljODN6y6qA== X-Received: by 10.107.192.135 with SMTP id q129mr20219312iof.63.1501545195934; Mon, 31 Jul 2017 16:53:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.106.1 with HTTP; Mon, 31 Jul 2017 16:53:15 -0700 (PDT) In-Reply-To: References: <9f93d9c9-5c84-9f78-6b22-2c637efdd09f@sapienti-sat.org> From: Gene Shuman Date: Mon, 31 Jul 2017 16:53:15 -0700 Message-ID: To: Gene Shuman Cc: Brandon Long , "dmarc@ietf.org" , Juri Haberland Content-Type: multipart/alternative; boundary="001a114f1d2e0499ef0555a5bc33" Archived-At: Subject: Re: [dmarc-ietf] questions about section 5.1.1 of the new ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 23:53:20 -0000 --001a114f1d2e0499ef0555a5bc33 Content-Type: text/plain; charset="UTF-8" Sorry, sent from the wrong email addr. To repeat: But I understand now, simple misunderstanding. So is this assumption correct? An AAR should look like this: Arc-Authentication-Results: i=14; mx.google.com; arc=pass ams.d=google.com ams.s=arc-20160816 as.d=google.com ams.s=arc- 20160816 Maybe with some additional dkim/spf/dmarc info. This seems reasonable enough to me On Mon, Jul 31, 2017 at 4:46 PM, Gene Shuman wrote: > But I understand now, simple misunderstanding. > > So is this assumption correct? An AAR should look like this: > > Arc-Authentication-Results: i=14; mx.google.com; > arc=pass ams.d=google.com ams.s=arc-20160816 as.d=google.com > ams.s=arc-20160816 > > Maybe with some additional dkim/spf/dmarc info. This seems reasonable > enough to me > > > > On Mon, Jul 31, 2017 at 4:38 PM, Gene Shuman wrote: > >> I understand exactly why we want header.s. But I think I might have >> incorrectly assumed that getting this from the arc signatures was good >> enough. >> >> On Mon, Jul 31, 2017 at 4:31 PM, Brandon Long wrote: >> >>> In that case, I dislike specifying the hop number in the ptype, given >>> the registry nature of the ptype and property, it seems like they should be >>> specific and not an enumerated value. >>> >>> Brandon >>> >>> >>> On Mon, Jul 31, 2017 at 4:25 PM, Gene Shuman >>> wrote: >>> >>>> I was just talking with Seth about this. I think the language was >>>> poorly worded, and the intention is not to have a million ams.s, ams.ds in >>>> the aar, but just the ones from the most recent hop. Is this correct? >>>> >>>> Also, I still dont like ARC implementations being asked to parse DKIM >>>> signatures to get header.s. Nor do I really understand why we want that >>>> info. >>>> >>>> On Mon, Jul 31, 2017 at 4:20 PM, Brandon Long >>>> wrote: >>>> >>>>> Catching up here... >>>>> >>>>> Perhaps the traditional separation of all of the mail authenticators >>>>> is what should change, ie if we combined the various handlers into one, >>>>> then it becomes much more obvious how the information flow would occur. >>>>> >>>>> For our impl, it's just various calls within the single process, hence >>>>> why it's easy to issue a single authres header as well. >>>>> >>>>> Looking at the 5.1.1 section, I do think we should specify that the >>>>> source.ip is either in the arc section or the spf section, and not leave >>>>> that to random choice. >>>>> >>>>> I also do not like the arc related data as specified. If the arc >>>>> chain is intact, then the information is trivially extracted from the >>>>> chain, if it's not intact, then who cares. >>>>> Even if we want to include this data, I think the fact that we have a >>>>> chain of data could be used, and therefore we would only include the i-1 >>>>> hop data in the single aar. >>>>> >>>>> Arc-Authentication-Results: i=3; mx.google.com; arc=pass ams.d= >>>>> google.com ams.s=arc as.d=google.com as.s=arc >>>>> >>>>> The spec currently says i can go up to 1024 but unlikely over 50, are >>>>> we going to generate: >>>>> Arc-Authentication-Results: i=50; mx.google.com; >>>>> arc=pass ams49.d=google.com ams49.s=arc-20160816 as49.d=google.com >>>>> ams49.s=arc-20160816 >>>>> ams48.d=google.com ams48.s=arc-20160816 as48.d=google.com >>>>> ams48.s=arc-20160816 >>>>> ams47.d=google.com ams47.s=arc-20160816 as47.d=google.com >>>>> ams47.s=arc-20160816 >>>>> ams46.d=google.com ams46.s=arc-20160816 as46.d=google.com >>>>> ams46.s=arc-20160816 >>>>> ams45.d=google.com ams45.s=arc-20160816 as45.d=google.com >>>>> ams45.s=arc-20160816 >>>>> ams44.d=google.com ams44.s=arc-20160816 as44.d=google.com >>>>> ams44.s=arc-20160816 >>>>> ams43.d=google.com ams43.s=arc-20160816 as43.d=google.com >>>>> ams43.s=arc-20160816 >>>>> ams42.d=google.com ams42.s=arc-20160816 as42.d=google.com >>>>> ams42.s=arc-20160816 >>>>> ams41.d=google.com ams41.s=arc-20160816 as41.d=google.com >>>>> ams41.s=arc-20160816 >>>>> ams40.d=google.com ams40.s=arc-20160816 as40.d=google.com >>>>> ams40.s=arc-20160816 >>>>> ams39.d=google.com ams39.s=arc-20160816 as39.d=google.com >>>>> ams39.s=arc-20160816 >>>>> ams38.d=google.com ams38.s=arc-20160816 as38.d=google.com >>>>> ams38.s=arc-20160816 >>>>> ams37.d=google.com ams37.s=arc-20160816 as37.d=google.com >>>>> ams37.s=arc-20160816 >>>>> ams36.d=google.com ams36.s=arc-20160816 as36.d=google.com >>>>> ams36.s=arc-20160816 >>>>> ams35.d=google.com ams35.s=arc-20160816 as35.d=google.com >>>>> ams35.s=arc-20160816 >>>>> ams34.d=google.com ams34.s=arc-20160816 as34.d=google.com >>>>> ams34.s=arc-20160816 >>>>> ams33.d=google.com ams33.s=arc-20160816 as33.d=google.com >>>>> ams33.s=arc-20160816 >>>>> ams32.d=google.com ams32.s=arc-20160816 as32.d=google.com >>>>> ams32.s=arc-20160816 >>>>> ams31.d=google.com ams31.s=arc-20160816 as31.d=google.com >>>>> ams31.s=arc-20160816 >>>>> ams30.d=google.com ams30.s=arc-20160816 as30.d=google.com >>>>> ams30.s=arc-20160816 >>>>> ams29.d=google.com ams29.s=arc-20160816 as29.d=google.com >>>>> ams29.s=arc-20160816 >>>>> ams28.d=google.com ams28.s=arc-20160816 as28.d=google.com >>>>> ams28.s=arc-20160816 >>>>> ams27.d=google.com ams27.s=arc-20160816 as27.d=google.com >>>>> ams27.s=arc-20160816 >>>>> ams26.d=google.com ams26.s=arc-20160816 as26.d=google.com >>>>> ams26.s=arc-20160816 >>>>> ams25.d=google.com ams25.s=arc-20160816 as25.d=google.com >>>>> ams25.s=arc-20160816 >>>>> ams24.d=google.com ams24.s=arc-20160816 as24.d=google.com >>>>> ams24.s=arc-20160816 >>>>> ams23.d=google.com ams23.s=arc-20160816 as23.d=google.com >>>>> ams23.s=arc-20160816 >>>>> ams22.d=google.com ams22.s=arc-20160816 as22.d=google.com >>>>> ams22.s=arc-20160816 >>>>> ams21.d=google.com ams21.s=arc-20160816 as21.d=google.com >>>>> ams21.s=arc-20160816 >>>>> ams20.d=google.com ams20.s=arc-20160816 as20.d=google.com >>>>> ams20.s=arc-20160816 >>>>> ams19.d=google.com ams19.s=arc-20160816 as19.d=google.com >>>>> ams19.s=arc-20160816 >>>>> ams18.d=google.com ams18.s=arc-20160816 as18.d=google.com >>>>> ams18.s=arc-20160816 >>>>> ams17.d=google.com ams17.s=arc-20160816 as17.d=google.com >>>>> ams17.s=arc-20160816 >>>>> ams16.d=google.com ams16.s=arc-20160816 as16.d=google.com >>>>> ams16.s=arc-20160816 >>>>> ams15.d=google.com ams15.s=arc-20160816 as15.d=google.com >>>>> ams15.s=arc-20160816 >>>>> ams14.d=google.com ams14.s=arc-20160816 as14.d=google.com >>>>> ams14.s=arc-20160816 >>>>> ams13.d=google.com ams13.s=arc-20160816 as13.d=google.com >>>>> ams13.s=arc-20160816 >>>>> ams12.d=google.com ams12.s=arc-20160816 as12.d=google.com >>>>> ams12.s=arc-20160816 >>>>> ams11.d=google.com ams11.s=arc-20160816 as11.d=google.com >>>>> ams11.s=arc-20160816 >>>>> ams10.d=google.com ams10.s=arc-20160816 as10.d=google.com >>>>> ams10.s=arc-20160816 >>>>> ams9.d=google.com ams9.s=arc-20160816 as9.d=google.com >>>>> ams9.s=arc-20160816 >>>>> ams8.d=google.com ams8.s=arc-20160816 as8.d=google.com >>>>> ams8.s=arc-20160816 >>>>> ams7.d=google.com ams7.s=arc-20160816 as7.d=google.com >>>>> ams7.s=arc-20160816 >>>>> ams6.d=google.com ams6.s=arc-20160816 as6.d=google.com >>>>> ams6.s=arc-20160816 >>>>> ams5.d=google.com ams5.s=arc-20160816 as5.d=google.com >>>>> ams5.s=arc-20160816 >>>>> ams4.d=google.com ams4.s=arc-20160816 as4.d=google.com >>>>> ams4.s=arc-20160816 >>>>> ams3.d=google.com ams3.s=arc-20160816 as3.d=google.com >>>>> ams3.s=arc-20160816 >>>>> ams2.d=google.com ams2.s=arc-20160816 as2.d=google.com >>>>> ams2.s=arc-20160816 >>>>> ams1.d=google.com ams1.s=arc-20160816 as1.d=google.com >>>>> ams1.s=arc-20160816 >>>>> >>>>> I'd also point out that this is iterative, so the i=49 one is only >>>>> slightly smaller and so on. >>>>> >>>>> Brandon >>>>> >>>>> On Tue, Jul 25, 2017 at 3:48 PM, Gene Shuman >>>>> wrote: >>>>> >>>>>> I do not have any better ideas. I just wanted to make sure I >>>>>> understood the situation correctly atm. >>>>>> >>>>>> On Tue, Jul 25, 2017 at 3:36 PM, Juri Haberland < >>>>>> juri@sapienti-sat.org> wrote: >>>>>> >>>>>>> On 26.07.2017 00:29, Kurt Andersen (b) wrote: >>>>>>> > On Tue, Jul 25, 2017 at 2:44 PM, Juri Haberland < >>>>>>> juri@sapienti-sat.org> >>>>>>> > wrote: >>>>>>> >> On 25.07.2017 21:31, Gene Shuman wrote: >>>>>>> >>>>>>> >> > inbound -> policyspf(or some other spf check) -> OpenDKIM -> >>>>>>> OpenDMARC >>>>>>> >> -> >>>>>>> >> > OpenARC Validation -> mailing list software -> OpenArc >>>>>>> Signature -> >>>>>>> >> > outbound. >>>>>>> >> >>>>>>> >> Well, OpenARC validation should be before OpenDMARC... >>>>>>> > >>>>>>> > Well, that depends on your implementation. If you generally >>>>>>> evaluate local >>>>>>> > policy conditions before checking the primary DMARC mechanisms, >>>>>>> then yes; >>>>>>> > otherwise, ARC only needs to be evaluated if DMARC does not >>>>>>> achieve a PASS >>>>>>> > from the primary mechanism or if you expect to break the message's >>>>>>> > authentication. >>>>>>> >>>>>>> Granted, both ways are possible :) >>>>>>> >>>>>>> Juri >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>> >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> > --001a114f1d2e0499ef0555a5bc33 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry, sent from the wrong email addr.=C2=A0 To repeat:

But I unde= rstand now, simple misunderstanding.
=
So is this assumption correct?=C2= =A0 An AAR should look like this:

=
Arc-A= uthentication-Results: i=3D14;=C2=A0mx.google.com;
=C2=A0= =C2=A0 arc=3Dpass ams.d=3Dgoogle.com=C2=A0ams.s=3Darc-20160816 as.d=3Dgoogle.com=C2=A0ams.s=3Darc-20160816

Maybe with some additional dkim/spf/dmarc info.=C2=A0 This seems reasona= ble enough to me

On Mon, Jul 31, 2017 at 4:46 PM, Gene Shuman <gene@= valimail.com> wrote:
But I understand now, simple misunderstanding.

So is this assumption correct?=C2=A0 An AAR should look like this:
<= div>
Arc-Authentication-Resul= ts: i=3D14;=C2=A0mx.goo= gle.com;
=C2=A0 =C2=A0 arc=3Dpass = ams.d=3Dgoogle.com=C2= =A0ams.s=3Darc-20160816 as.d=3Dgoogle.com=C2=A0ams.s=3Darc-20160816

Maybe with = some additional dkim/spf/dmarc info.=C2=A0 This seems reasonable enough to = me
=C2=A0


=
On Mon, Jul 31, 2017 at 4:38 PM, Gene Shuman <geneshuman@gmail.com> wrote:
I understand exactly why we want header.s.=C2=A0 But I= think I might have incorrectly assumed that getting this from the arc sign= atures was good enough.

On Mon, Jul 31, 2017 at 4:31 PM, Brandon Long <blong@f= iction.net> wrote:
In that case, I dislike specifying the hop number in the ptype, gi= ven the registry nature of the ptype and property, it seems like they shoul= d be specific and not an enumerated value.

Brandon

<= br>
On Mon, Jul 31, 2017 at 4:25 PM, Gene Shuman = <geneshuman@gmail.com> wrote:
I was just talking with Seth about this.=C2=A0 I th= ink the language was poorly worded, and the intention is not to have a mill= ion ams.s, ams.ds in the aar, but just the ones from the most recent hop.= =C2=A0 Is this correct?

Also, I still dont like ARC impl= ementations being asked to parse DKIM signatures to get header.s.=C2=A0 Nor= do I really understand why we want that info.

On Mon, Jul 31= , 2017 at 4:20 PM, Brandon Long <blong@fiction.net> wrote:
Catching up here...
<= br>
Perhaps the traditional separation of all of the mail authent= icators is what should change, ie if we combined the various handlers into = one, then it becomes much more obvious how the information flow would occur= .

For our impl, it's just various calls within= the single process, hence why it's easy to issue a single authres head= er as well.

Looking at the 5.1.1 section, I do thi= nk we should specify that the source.ip is either in the arc section or the= spf section, and not leave that to random choice.

I also do not like the arc related data as specified.=C2=A0 If the arc cha= in is intact, then the information is trivially extracted from the chain, i= f it's not intact, then who cares.
Even if we want to include= this data, I think the fact that we have a chain of data could be used, an= d therefore we would only include the i-1 hop data in the single aar.
=

Arc-Authentication-Results: i=3D3; mx.google.com; arc=3Dpass ams.d=3Dgoogle.com ams.s=3Darc as.d= =3Dgoogle.com as.s=3Dar= c

The spec currently says i can go up to 1024 but = unlikely over 50, are we going to generate:
Arc-Authentication-Re= sults: i=3D50; mx.google= .com;
=C2=A0 =C2=A0 arc=3Dpass ams49.d=3Dgoogle.com ams49.s=3Darc-20160816 as49.d=3D= google.com ams49.s=3Dar= c-20160816
=C2=A0 =C2=A0 ams48.d=3Dgoogle.com ams48.s=3Darc-20160816 as48.d=3Dgoogle.com ams48.s=3Darc-201= 60816
=C2=A0 =C2=A0 ams47.d=3Dgoogle.com ams47.s=3Darc-20160816 as47.d=3Dgoogle.com ams47.s=3Darc-20160816
=C2=A0 =C2=A0 ams46.d=3Dgoogle.com ams46.s=3Darc-20160816 as46.d=3Dgoogle.com ams46.s=3Darc-20160816
=C2= =A0 =C2=A0 ams45.d=3Dgoogle= .com ams45.s=3Darc-20160816 as45.d=3Dgoogle.com ams45.s=3Darc-20160816
=C2=A0 =C2=A0= ams44.d=3Dgoogle.com a= ms44.s=3Darc-20160816 as44.d=3Dgoogle.com ams44.s=3Darc-20160816
=C2=A0 =C2=A0 ams43.d= =3Dgoogle.com ams43.s= =3Darc-20160816 as43.d=3Dgo= ogle.com ams43.s=3Darc-20160816
=C2=A0 =C2=A0 ams42.d=3Dgoogle.com ams42.s=3Darc-201= 60816 as42.d=3Dgoogle.com ams42.s=3Darc-20160816
=C2=A0 =C2=A0 ams41.d=3Dgoogle.com ams41.s=3Darc-20160816 as41= .d=3Dgoogle.com ams41.s= =3Darc-20160816
=C2=A0 =C2=A0 ams40.d=3Dgoogle.com ams40.s=3Darc-20160816 as40.d=3Dgoogle.com ams40.s=3Darc-201= 60816
=C2=A0 =C2=A0 ams39.d=3Dgoogle.com ams39.s=3Darc-20160816 as39.d=3Dgoogle.com ams39.s=3Darc-20160816
=C2=A0 =C2=A0 ams38.d=3Dgoogle.com ams38.s=3Darc-20160816 as38.d=3Dgoogle.com ams38.s=3Darc-20160816
=C2= =A0 =C2=A0 ams37.d=3Dgoogle= .com ams37.s=3Darc-20160816 as37.d=3Dgoogle.com ams37.s=3Darc-20160816
=C2=A0 =C2=A0= ams36.d=3Dgoogle.com a= ms36.s=3Darc-20160816 as36.d=3Dgoogle.com ams36.s=3Darc-20160816
=C2=A0 =C2=A0 ams35.d= =3Dgoogle.com ams35.s= =3Darc-20160816 as35.d=3Dgo= ogle.com ams35.s=3Darc-20160816
=C2=A0 =C2=A0 ams34.d=3Dgoogle.com ams34.s=3Darc-201= 60816 as34.d=3Dgoogle.com ams34.s=3Darc-20160816
=C2=A0 =C2=A0 ams33.d=3Dgoogle.com ams33.s=3Darc-20160816 as33= .d=3Dgoogle.com ams33.s= =3Darc-20160816
=C2=A0 =C2=A0 ams32.d=3Dgoogle.com ams32.s=3Darc-20160816 as32.d=3Dgoogle.com ams32.s=3Darc-201= 60816
=C2=A0 =C2=A0 ams31.d=3Dgoogle.com ams31.s=3Darc-20160816 as31.d=3Dgoogle.com ams31.s=3Darc-20160816
=C2=A0 =C2=A0 ams30.d=3Dgoogle.com ams30.s=3Darc-20160816 as30.d=3Dgoogle.com ams30.s=3Darc-20160816
=C2= =A0 =C2=A0 ams29.d=3Dgoogle= .com ams29.s=3Darc-20160816 as29.d=3Dgoogle.com ams29.s=3Darc-20160816
=C2=A0 =C2=A0= ams28.d=3Dgoogle.com a= ms28.s=3Darc-20160816 as28.d=3Dgoogle.com ams28.s=3Darc-20160816
=C2=A0 =C2=A0 ams27.d= =3Dgoogle.com ams27.s= =3Darc-20160816 as27.d=3Dgo= ogle.com ams27.s=3Darc-20160816
=C2=A0 =C2=A0 ams26.d=3Dgoogle.com ams26.s=3Darc-201= 60816 as26.d=3Dgoogle.com ams26.s=3Darc-20160816
=C2=A0 =C2=A0 ams25.d=3Dgoogle.com ams25.s=3Darc-20160816 as25= .d=3Dgoogle.com ams25.s= =3Darc-20160816
=C2=A0 =C2=A0 ams24.d=3Dgoogle.com ams24.s=3Darc-20160816 as24.d=3Dgoogle.com ams24.s=3Darc-201= 60816
=C2=A0 =C2=A0 ams23.d=3Dgoogle.com ams23.s=3Darc-20160816 as23.d=3Dgoogle.com ams23.s=3Darc-20160816
=C2=A0 =C2=A0 ams22.d=3Dgoogle.com ams22.s=3Darc-20160816 as22.d=3Dgoogle.com ams22.s=3Darc-20160816
=C2= =A0 =C2=A0 ams21.d=3Dgoogle= .com ams21.s=3Darc-20160816 as21.d=3Dgoogle.com ams21.s=3Darc-20160816
=C2=A0 =C2=A0= ams20.d=3Dgoogle.com a= ms20.s=3Darc-20160816 as20.d=3Dgoogle.com ams20.s=3Darc-20160816
=C2=A0 =C2=A0 ams19.d= =3Dgoogle.com ams19.s= =3Darc-20160816 as19.d=3Dgo= ogle.com ams19.s=3Darc-20160816
=C2=A0 =C2=A0 ams18.d=3Dgoogle.com ams18.s=3Darc-201= 60816 as18.d=3Dgoogle.com ams18.s=3Darc-20160816
=C2=A0 =C2=A0 ams17.d=3Dgoogle.com ams17.s=3Darc-20160816 as17= .d=3Dgoogle.com ams17.s= =3Darc-20160816
=C2=A0 =C2=A0 ams16.d=3Dgoogle.com ams16.s=3Darc-20160816 as16.d=3Dgoogle.com ams16.s=3Darc-201= 60816
=C2=A0 =C2=A0 ams15.d=3Dgoogle.com ams15.s=3Darc-20160816 as15.d=3Dgoogle.com ams15.s=3Darc-20160816
=C2=A0 =C2=A0 ams14.d=3Dgoogle.com ams14.s=3Darc-20160816 as14.d=3Dgoogle.com ams14.s=3Darc-20160816
=C2= =A0 =C2=A0 ams13.d=3Dgoogle= .com ams13.s=3Darc-20160816 as13.d=3Dgoogle.com ams13.s=3Darc-20160816
=C2=A0 =C2=A0= ams12.d=3Dgoogle.com a= ms12.s=3Darc-20160816 as12.d=3Dgoogle.com ams12.s=3Darc-20160816
=C2=A0 =C2=A0 ams11.d= =3Dgoogle.com ams11.s= =3Darc-20160816 as11.d=3Dgo= ogle.com ams11.s=3Darc-20160816
=C2=A0 =C2=A0 ams10.d=3Dgoogle.com ams10.s=3Darc-201= 60816 as10.d=3Dgoogle.com ams10.s=3Darc-20160816
=C2=A0 =C2=A0 ams9.d=3Dgoogle.com ams9.s=3Darc-20160816 as9.d= =3Dgoogle.com ams9.s=3D= arc-20160816
=C2=A0 =C2=A0 ams8.d=3Dgoogle.com ams8.s=3Darc-20160816 as8.d=3Dgoogle.com ams8.s=3Darc-20160816
=C2=A0 =C2=A0 ams7.d=3Dgoogle.com ams7.s=3Darc-20160816 as7.d=3Dgoogle.com ams7.s=3Darc-20160816
=C2= =A0 =C2=A0 ams6.d=3Dgoogle.= com ams6.s=3Darc-20160816 as6.d=3Dgoogle.com ams6.s=3Darc-20160816
=C2=A0 =C2=A0 am= s5.d=3Dgoogle.com ams5.= s=3Darc-20160816 as5.d=3Dgo= ogle.com ams5.s=3Darc-20160816
=C2=A0 =C2=A0 ams4.d=3Dgoogle.com ams4.s=3Darc-201608= 16 as4.d=3Dgoogle.com a= ms4.s=3Darc-20160816
=C2=A0 =C2=A0 ams3.d=3Dgoogle.com ams3.s=3Darc-20160816 as3.d=3Dgoogle.com ams3.s=3Darc-20= 160816
=C2=A0 =C2=A0 ams2.d=3Dgoogle.com ams2.s=3Darc-20160816 as2.d=3Dgoogle.com ams2.s=3Darc-20160816
=C2=A0 =C2=A0 ams1.d=3Dg= oogle.com ams1.s=3Darc-20160816 as1.d=3Dgoogle.com ams1.s=3Darc-20160816

<= /div>
I'd also point out that this is iterative, so the i=3D49 one = is only slightly smaller and so on.

Brandon

On Tue, Jul 25, 2017 at 3= :48 PM, Gene Shuman <geneshuman@gmail.com> wrote:
I do not have any better ideas.= =C2=A0 I just wanted to make sure I understood the situation correctly atm.= =C2=A0

=
On Tue, Jul 25, 2017 at 3:36 PM, Juri Haberland = <juri@sapienti-sat.org> wrote:
On 26.07.2017 00:29, Kurt Andersen (b) wrote:
> On Tue, Jul 25, 2017 at 2:44 PM, Juri Haberland <juri@sapienti-sat.org>
> wrote:
>> On 25.07.2017 21:31, Gene Shuman wrote:

>> > inbound -> policyspf(or some other spf check)= =C2=A0 -> OpenDKIM -> OpenDMARC
>> ->
>> > OpenARC Validation -> mailing list software -> OpenArc = Signature ->
>> > outbound.
>>
>> Well, OpenARC validation should be before OpenDMARC...
>
> Well, that depends on your implementation. If you generally evaluate l= ocal
> policy conditions before checking the primary DMARC mechanisms, then y= es;
> otherwise, ARC only needs to be evaluated if DMARC does not achieve a = PASS
> from the primary mechanism or if you expect to break the message's=
> authentication.

Granted, both ways are possible :)
=C2=A0 Juri

_______________________________________________
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




_______________________________________________
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



--001a114f1d2e0499ef0555a5bc33-- From nobody Mon Jul 31 16:58:07 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E52A129A96 for ; Mon, 31 Jul 2017 16:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fiction.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMFlDp03RH4n for ; Mon, 31 Jul 2017 16:58:03 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22D86129B25 for ; Mon, 31 Jul 2017 16:58:03 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id x3so1145878oia.1 for ; Mon, 31 Jul 2017 16:58:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fiction.net; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EP75j8G9RwYdmgsJaUL4apBuvIqD1eipzm7ScxPLYv4=; b=d+GziQZoAqXqbidhwUOajfxrBwJtykaoQ8KOaFVVPOr3vmDXIzSGZlWUFPYuoIlJ3K 06ef+vxUBw85R+mgOO0g5jzLS45FZdPoMidn+FvbphYxi39wjKWTsJT7EkkQknygR3WK QRz6llOpFW0n5ntT1glDAui9XITiqkSQvsOPi+pn/dHXsodimn01kDdxm3Syvojo9s1d wpMhgtokZlM5esp8xdveKFjEOgmYohTka6pOvBkUOEokArnrx5ABRYs3pxKSNmqIrHQL N8cfOpoFkIgBFZnGQx9GCpvbXbihw8Ar5gsK8n4wlvtZIc8xr5G8/07AGDkcBXcRPCQa 8ywg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EP75j8G9RwYdmgsJaUL4apBuvIqD1eipzm7ScxPLYv4=; b=SoMdrvz2mzh8jTW6i2qu7bnqcRgogUViw0mv4rYDV/pT1xO0WqC3LzTFKie3jG83sI mWR3YftP9TYRq/QEy594LmgQ9JZjGRF246AU2GX8VyO9/9qBC6THJS41oGF0PmtXM0k7 1uXAbKWKiHW/LUGoUlvIEO+rz32ZPz6HgMFs1WwaHewKoaITk3yPJxRi+bJ2h/ewT8pQ KKLIRxoszzyba1H/FtZ3RQRIq4HLaqye4GFn+PyZqe2kJnaUGLvAeSBBcsyQEq0FJ/d8 M1BIufhorH7q+sAksIEKddas2tHhME8f6wANsCmCESk59qtrcJhVYgFJ2R+Wr19nVmns MPlA== X-Gm-Message-State: AIVw1138zQWDAJWaYvDqhfa3okwGzY8ZIkRW4+5GquMYu5Q2eDr7Tr86 cek4n0v6UJOhE/ozHHU= X-Received: by 10.202.207.75 with SMTP id f72mr9724218oig.232.1501545482183; Mon, 31 Jul 2017 16:58:02 -0700 (PDT) Received: from mail-oi0-f51.google.com (mail-oi0-f51.google.com. [209.85.218.51]) by smtp.gmail.com with ESMTPSA id q206sm6699454oic.11.2017.07.31.16.58.01 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 31 Jul 2017 16:58:01 -0700 (PDT) Received: by mail-oi0-f51.google.com with SMTP id g131so924470oic.3 for ; Mon, 31 Jul 2017 16:58:01 -0700 (PDT) X-Received: by 10.202.189.195 with SMTP id n186mr11693795oif.251.1501545480825; Mon, 31 Jul 2017 16:58:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.154.51 with HTTP; Mon, 31 Jul 2017 16:58:00 -0700 (PDT) In-Reply-To: References: <9f93d9c9-5c84-9f78-6b22-2c637efdd09f@sapienti-sat.org> From: Brandon Long Date: Mon, 31 Jul 2017 16:58:00 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Gene Shuman Cc: Gene Shuman , "dmarc@ietf.org" , Juri Haberland Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [dmarc-ietf] questions about section 5.1.1 of the new ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 23:58:06 -0000 On Mon, Jul 31, 2017 at 4:53 PM, Gene Shuman wrote: > Sorry, sent from the wrong email addr. To repeat: > > > But I understand now, simple misunderstanding. > > So is this assumption correct? An AAR should look like this: > > Arc-Authentication-Results: i=14; mx.google.com; > arc=pass ams.d=google.com ams.s=arc-20160816 as.d=google.com > ams.s=arc-20160816 I wonder if more in keeping with the ptypes, that it would be: Arc-Authentication-Results: i=14; mx.google.com; arc=pass header.ams-d=google.com header.ams-s=arc-20160816 header.as-d=google.com header.as-s=arc-20160816 There are folks on this list who better understand authres who may have a stronger opinion. Brandon > > Maybe with some additional dkim/spf/dmarc info. This seems reasonable > enough to me > > On Mon, Jul 31, 2017 at 4:46 PM, Gene Shuman wrote: >> >> But I understand now, simple misunderstanding. >> >> So is this assumption correct? An AAR should look like this: >> >> Arc-Authentication-Results: i=14; mx.google.com; >> arc=pass ams.d=google.com ams.s=arc-20160816 as.d=google.com >> ams.s=arc-20160816 >> >> Maybe with some additional dkim/spf/dmarc info. This seems reasonable >> enough to me >> >> >> >> On Mon, Jul 31, 2017 at 4:38 PM, Gene Shuman wrote: >>> >>> I understand exactly why we want header.s. But I think I might have >>> incorrectly assumed that getting this from the arc signatures was good >>> enough. >>> >>> On Mon, Jul 31, 2017 at 4:31 PM, Brandon Long wrote: >>>> >>>> In that case, I dislike specifying the hop number in the ptype, given >>>> the registry nature of the ptype and property, it seems like they should be >>>> specific and not an enumerated value. >>>> >>>> Brandon >>>> >>>> >>>> On Mon, Jul 31, 2017 at 4:25 PM, Gene Shuman >>>> wrote: >>>>> >>>>> I was just talking with Seth about this. I think the language was >>>>> poorly worded, and the intention is not to have a million ams.s, ams.ds in >>>>> the aar, but just the ones from the most recent hop. Is this correct? >>>>> >>>>> Also, I still dont like ARC implementations being asked to parse DKIM >>>>> signatures to get header.s. Nor do I really understand why we want that >>>>> info. >>>>> >>>>> On Mon, Jul 31, 2017 at 4:20 PM, Brandon Long >>>>> wrote: >>>>>> >>>>>> Catching up here... >>>>>> >>>>>> Perhaps the traditional separation of all of the mail authenticators >>>>>> is what should change, ie if we combined the various handlers into one, then >>>>>> it becomes much more obvious how the information flow would occur. >>>>>> >>>>>> For our impl, it's just various calls within the single process, hence >>>>>> why it's easy to issue a single authres header as well. >>>>>> >>>>>> Looking at the 5.1.1 section, I do think we should specify that the >>>>>> source.ip is either in the arc section or the spf section, and not leave >>>>>> that to random choice. >>>>>> >>>>>> I also do not like the arc related data as specified. If the arc >>>>>> chain is intact, then the information is trivially extracted from the chain, >>>>>> if it's not intact, then who cares. >>>>>> Even if we want to include this data, I think the fact that we have a >>>>>> chain of data could be used, and therefore we would only include the i-1 hop >>>>>> data in the single aar. >>>>>> >>>>>> Arc-Authentication-Results: i=3; mx.google.com; arc=pass >>>>>> ams.d=google.com ams.s=arc as.d=google.com as.s=arc >>>>>> >>>>>> The spec currently says i can go up to 1024 but unlikely over 50, are >>>>>> we going to generate: >>>>>> Arc-Authentication-Results: i=50; mx.google.com; >>>>>> arc=pass ams49.d=google.com ams49.s=arc-20160816 as49.d=google.com >>>>>> ams49.s=arc-20160816 >>>>>> ams48.d=google.com ams48.s=arc-20160816 as48.d=google.com >>>>>> ams48.s=arc-20160816 >>>>>> ams47.d=google.com ams47.s=arc-20160816 as47.d=google.com >>>>>> ams47.s=arc-20160816 >>>>>> ams46.d=google.com ams46.s=arc-20160816 as46.d=google.com >>>>>> ams46.s=arc-20160816 >>>>>> ams45.d=google.com ams45.s=arc-20160816 as45.d=google.com >>>>>> ams45.s=arc-20160816 >>>>>> ams44.d=google.com ams44.s=arc-20160816 as44.d=google.com >>>>>> ams44.s=arc-20160816 >>>>>> ams43.d=google.com ams43.s=arc-20160816 as43.d=google.com >>>>>> ams43.s=arc-20160816 >>>>>> ams42.d=google.com ams42.s=arc-20160816 as42.d=google.com >>>>>> ams42.s=arc-20160816 >>>>>> ams41.d=google.com ams41.s=arc-20160816 as41.d=google.com >>>>>> ams41.s=arc-20160816 >>>>>> ams40.d=google.com ams40.s=arc-20160816 as40.d=google.com >>>>>> ams40.s=arc-20160816 >>>>>> ams39.d=google.com ams39.s=arc-20160816 as39.d=google.com >>>>>> ams39.s=arc-20160816 >>>>>> ams38.d=google.com ams38.s=arc-20160816 as38.d=google.com >>>>>> ams38.s=arc-20160816 >>>>>> ams37.d=google.com ams37.s=arc-20160816 as37.d=google.com >>>>>> ams37.s=arc-20160816 >>>>>> ams36.d=google.com ams36.s=arc-20160816 as36.d=google.com >>>>>> ams36.s=arc-20160816 >>>>>> ams35.d=google.com ams35.s=arc-20160816 as35.d=google.com >>>>>> ams35.s=arc-20160816 >>>>>> ams34.d=google.com ams34.s=arc-20160816 as34.d=google.com >>>>>> ams34.s=arc-20160816 >>>>>> ams33.d=google.com ams33.s=arc-20160816 as33.d=google.com >>>>>> ams33.s=arc-20160816 >>>>>> ams32.d=google.com ams32.s=arc-20160816 as32.d=google.com >>>>>> ams32.s=arc-20160816 >>>>>> ams31.d=google.com ams31.s=arc-20160816 as31.d=google.com >>>>>> ams31.s=arc-20160816 >>>>>> ams30.d=google.com ams30.s=arc-20160816 as30.d=google.com >>>>>> ams30.s=arc-20160816 >>>>>> ams29.d=google.com ams29.s=arc-20160816 as29.d=google.com >>>>>> ams29.s=arc-20160816 >>>>>> ams28.d=google.com ams28.s=arc-20160816 as28.d=google.com >>>>>> ams28.s=arc-20160816 >>>>>> ams27.d=google.com ams27.s=arc-20160816 as27.d=google.com >>>>>> ams27.s=arc-20160816 >>>>>> ams26.d=google.com ams26.s=arc-20160816 as26.d=google.com >>>>>> ams26.s=arc-20160816 >>>>>> ams25.d=google.com ams25.s=arc-20160816 as25.d=google.com >>>>>> ams25.s=arc-20160816 >>>>>> ams24.d=google.com ams24.s=arc-20160816 as24.d=google.com >>>>>> ams24.s=arc-20160816 >>>>>> ams23.d=google.com ams23.s=arc-20160816 as23.d=google.com >>>>>> ams23.s=arc-20160816 >>>>>> ams22.d=google.com ams22.s=arc-20160816 as22.d=google.com >>>>>> ams22.s=arc-20160816 >>>>>> ams21.d=google.com ams21.s=arc-20160816 as21.d=google.com >>>>>> ams21.s=arc-20160816 >>>>>> ams20.d=google.com ams20.s=arc-20160816 as20.d=google.com >>>>>> ams20.s=arc-20160816 >>>>>> ams19.d=google.com ams19.s=arc-20160816 as19.d=google.com >>>>>> ams19.s=arc-20160816 >>>>>> ams18.d=google.com ams18.s=arc-20160816 as18.d=google.com >>>>>> ams18.s=arc-20160816 >>>>>> ams17.d=google.com ams17.s=arc-20160816 as17.d=google.com >>>>>> ams17.s=arc-20160816 >>>>>> ams16.d=google.com ams16.s=arc-20160816 as16.d=google.com >>>>>> ams16.s=arc-20160816 >>>>>> ams15.d=google.com ams15.s=arc-20160816 as15.d=google.com >>>>>> ams15.s=arc-20160816 >>>>>> ams14.d=google.com ams14.s=arc-20160816 as14.d=google.com >>>>>> ams14.s=arc-20160816 >>>>>> ams13.d=google.com ams13.s=arc-20160816 as13.d=google.com >>>>>> ams13.s=arc-20160816 >>>>>> ams12.d=google.com ams12.s=arc-20160816 as12.d=google.com >>>>>> ams12.s=arc-20160816 >>>>>> ams11.d=google.com ams11.s=arc-20160816 as11.d=google.com >>>>>> ams11.s=arc-20160816 >>>>>> ams10.d=google.com ams10.s=arc-20160816 as10.d=google.com >>>>>> ams10.s=arc-20160816 >>>>>> ams9.d=google.com ams9.s=arc-20160816 as9.d=google.com >>>>>> ams9.s=arc-20160816 >>>>>> ams8.d=google.com ams8.s=arc-20160816 as8.d=google.com >>>>>> ams8.s=arc-20160816 >>>>>> ams7.d=google.com ams7.s=arc-20160816 as7.d=google.com >>>>>> ams7.s=arc-20160816 >>>>>> ams6.d=google.com ams6.s=arc-20160816 as6.d=google.com >>>>>> ams6.s=arc-20160816 >>>>>> ams5.d=google.com ams5.s=arc-20160816 as5.d=google.com >>>>>> ams5.s=arc-20160816 >>>>>> ams4.d=google.com ams4.s=arc-20160816 as4.d=google.com >>>>>> ams4.s=arc-20160816 >>>>>> ams3.d=google.com ams3.s=arc-20160816 as3.d=google.com >>>>>> ams3.s=arc-20160816 >>>>>> ams2.d=google.com ams2.s=arc-20160816 as2.d=google.com >>>>>> ams2.s=arc-20160816 >>>>>> ams1.d=google.com ams1.s=arc-20160816 as1.d=google.com >>>>>> ams1.s=arc-20160816 >>>>>> >>>>>> I'd also point out that this is iterative, so the i=49 one is only >>>>>> slightly smaller and so on. >>>>>> >>>>>> Brandon >>>>>> >>>>>> On Tue, Jul 25, 2017 at 3:48 PM, Gene Shuman >>>>>> wrote: >>>>>>> >>>>>>> I do not have any better ideas. I just wanted to make sure I >>>>>>> understood the situation correctly atm. >>>>>>> >>>>>>> On Tue, Jul 25, 2017 at 3:36 PM, Juri Haberland >>>>>>> wrote: >>>>>>>> >>>>>>>> On 26.07.2017 00:29, Kurt Andersen (b) wrote: >>>>>>>> > On Tue, Jul 25, 2017 at 2:44 PM, Juri Haberland >>>>>>>> > >>>>>>>> > wrote: >>>>>>>> >> On 25.07.2017 21:31, Gene Shuman wrote: >>>>>>>> >>>>>>>> >> > inbound -> policyspf(or some other spf check) -> OpenDKIM -> >>>>>>>> >> > OpenDMARC >>>>>>>> >> -> >>>>>>>> >> > OpenARC Validation -> mailing list software -> OpenArc >>>>>>>> >> > Signature -> >>>>>>>> >> > outbound. >>>>>>>> >> >>>>>>>> >> Well, OpenARC validation should be before OpenDMARC... >>>>>>>> > >>>>>>>> > Well, that depends on your implementation. If you generally >>>>>>>> > evaluate local >>>>>>>> > policy conditions before checking the primary DMARC mechanisms, >>>>>>>> > then yes; >>>>>>>> > otherwise, ARC only needs to be evaluated if DMARC does not >>>>>>>> > achieve a PASS >>>>>>>> > from the primary mechanism or if you expect to break the message's >>>>>>>> > authentication. >>>>>>>> >>>>>>>> Granted, both ways are possible :) >>>>>>>> >>>>>>>> Juri >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>>> >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >> > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > From nobody Mon Jul 31 21:56:57 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBA03126CB6 for ; Mon, 31 Jul 2017 21:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QJhyPcKV55t for ; Mon, 31 Jul 2017 21:56:53 -0700 (PDT) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69EEC131C4F for ; Mon, 31 Jul 2017 21:56:53 -0700 (PDT) Received: by mail-ua0-x234.google.com with SMTP id q25so2342989uah.1 for ; Mon, 31 Jul 2017 21:56:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=KMWtKcz8E5C+ULCousIxCtCTJjaTvosgtPr4UFRAkss=; b=NTMTzoeIVGbTnducJmThSQIw1pxKtZxp9h3bwdwtN3DOgPf55DC0KgagJwJvjG3jmf f4w1jI9cePb7OluPVNdIps3I3oNLdOfP9dPDCwPEr6M2B16qZrGLZVaqOcGqAaMVNHQK x7pXY6vEheJN2rfK0QvWz8rnYN5FFTiRRjdsw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=KMWtKcz8E5C+ULCousIxCtCTJjaTvosgtPr4UFRAkss=; b=uAKLh7/tzFK4Xm+6BfExTdrMmnaGlDhUMF9Vy20rRipviSLmKb+GJhvv+F17IdYvMy EVOphgCipMUABQjDxh74z7Ete5ioYr0NYed6b//Ic76X/gntjpgs4YBFGvz/nvCb1w1k 1C0MP4FSQuFnsqYAFNkOl67h3Bi9Wiquv3ubGdLz0/F0QudQn/ZG9uEWhAAIcQBuclG3 M8ZbzI8aMxSbP3DOWJq4vBfW6zvaaz8gcD5lLtKWIkiMRTo3l8kIS5LdO+L+K7/RjmWw /cxKqUYz6C1O7nfRhHd4sVh2QUbS54JpNwWdvnNKZ7D+zMp2X7c33RdJ+qhJXyHqPc5V Tyog== X-Gm-Message-State: AIVw110CuJXzpOyW7OzaK7/xppMdjUdze+h/Xh5t4JkIaMSmH+fP62Vw aLmGNXHkj4PuRrXc1qQTEKGYq3nb1xF3 X-Received: by 10.176.71.82 with SMTP id i18mr14451201uac.171.1501563412358; Mon, 31 Jul 2017 21:56:52 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.176.26.19 with HTTP; Mon, 31 Jul 2017 21:56:51 -0700 (PDT) In-Reply-To: References: From: "Kurt Andersen (b)" Date: Mon, 31 Jul 2017 21:56:51 -0700 X-Google-Sender-Auth: pF16t7BbhySpssXZnnZxF0KyEXw Message-ID: To: Brandon Long Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="f403045e6328cd41620555a9f90a" Archived-At: Subject: Re: [dmarc-ietf] dns failures in the draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 04:56:56 -0000 --f403045e6328cd41620555a9f90a Content-Type: text/plain; charset="UTF-8" On Mon, Jul 31, 2017 at 4:41 PM, Brandon Long wrote: > > 9.4. Handling DNS Problems While Validating ARC > > DNS failures to resolve or return data which is needed for ARC > > validation SHOULD result in a 421 tempfail during the SMTP > > conversation with the sending system. > > I don't know if SHOULD is the right choice here. > > For a large percentage of mail, ARC is unnecessary, even when > forwarded through an intermediary. The mail will continue to DMARC > pass, or the mail will not be for a DMARC p=reject domain. > Good point - you highlighted that my implicit thought related to the "is needed for ARC validation" does not adequately convey the consideration that "ARC validation" is only needed when DMARC itself does not pass. I will adjust the wording to be more explicit. Does that additional piece change your concern about returning a 421? I wanted to be a bit more forceful than just saying "MAY" in order to encourage DMARC (and possibly ARC if needed for local policy) evaluation during the SMTP session as operators implement ARC. --Kurt --f403045e6328cd41620555a9f90a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Jul 31, 2017 at 4:41 PM, Brandon Long <blong@fiction.net> wrote:
> 9.4.=C2=A0 Handling DNS Pro= blems While Validating ARC
>=C2=A0 =C2=A0 DNS failures to resolve or return data which is needed fo= r ARC
>=C2=A0 =C2=A0 validation SHOULD result in a 421 tempfail during the SMT= P
>=C2=A0 =C2=A0 conversation with the sending system. =C2=A0

I don't know if SHOULD is the right choice here.

For a large percentage of mail, ARC is unnecessary, even when
forwarded through an intermediary.=C2=A0 The mail will continue to DMARC pass, or the mail will not be for a DMARC p=3Dreject domain.

Good point - you highlighted that my implicit thought= related to the "is needed for ARC validation" does not adequatel= y convey the consideration that "ARC validation" is only needed w= hen DMARC itself does not pass. I will adjust the wording to be more explic= it.
=C2=A0
Does that additional piece change your conce= rn about returning a 421? I wanted to be a bit more forceful than just sayi= ng "MAY" in order to encourage DMARC (and possibly ARC if needed = for local policy) evaluation during the SMTP session as operators implement= ARC.

--Kurt

--f403045e6328cd41620555a9f90a-- From nobody Mon Jul 31 22:03:21 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56ECB131D05 for ; Mon, 31 Jul 2017 22:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRwKpcDJzLPa for ; Mon, 31 Jul 2017 22:03:17 -0700 (PDT) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3858126CB6 for ; Mon, 31 Jul 2017 22:03:17 -0700 (PDT) Received: by mail-ua0-x22c.google.com with SMTP id q25so2384108uah.1 for ; Mon, 31 Jul 2017 22:03:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Hq/4FU16LWGxBpNUwKFr50NGOvIWijvGC9B6sr6G4Yk=; b=Jl7l7SgRW103WFtF6urGfHq0Qw043RtAmIYl4fm63vmr3gAqeSQpqUfAd6QX8+yfgt 3d5L6+f54u7AzTw3acFl25lTzYl0Hdfj2FEAZekA4DlAIhdSlxpCWlyDghKwWFwxMzCZ ym6v7WDU4lfVCkXhW62kuWObVslugJ4bLjjRM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Hq/4FU16LWGxBpNUwKFr50NGOvIWijvGC9B6sr6G4Yk=; b=NvpwgBJraL4+qfi8sgp2+NpgCABCUHwZwGdDgUH7WA8vsRPAANUHP45kKCzwOPYoRe pthkowqScubw3cSR57/cRs1AERlpfIE6pLTjYtrsUUT7N4KccJajGlK6WRf9lMznHsea zLcOn7rY6Q6+HcNlWo7gNujyBx+fmeJXaoxZsV8Zq/pLkanXDGnu4koOxLhot6WMvBze zV/fpMDSABb+rsxKC3j101M9NZ+3WUDLcOJBM6nL/xOkElxvXj0qpVFQuEzQ4GHoJuOh RAaBZm7sW5mxyfyZO7TdAbbPX8FVUyeWvzqcgQvZL/NCBkHiRuzFog3+IR2D14JYTK/F WmgA== X-Gm-Message-State: AIVw113P0wHeCgbGmZUkx2vqEfAWZj6nmazhf8KWWxIC3895cieyK4kD 4rEXWloBM19ZkCdGes6MXk3OAGNlu98a X-Received: by 10.176.67.194 with SMTP id l60mr12561847ual.119.1501563796696; Mon, 31 Jul 2017 22:03:16 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.176.26.19 with HTTP; Mon, 31 Jul 2017 22:03:16 -0700 (PDT) In-Reply-To: References: <9f93d9c9-5c84-9f78-6b22-2c637efdd09f@sapienti-sat.org> From: "Kurt Andersen (b)" Date: Mon, 31 Jul 2017 22:03:16 -0700 X-Google-Sender-Auth: By56T0qMu8StyLGzpLNNvIXIUIQ Message-ID: To: Brandon Long Cc: Gene Shuman , "dmarc@ietf.org" , Gene Shuman , Juri Haberland Content-Type: multipart/alternative; boundary="001a114d74fab5c3d60555aa102f" Archived-At: Subject: Re: [dmarc-ietf] questions about section 5.1.1 of the new ARC draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 05:03:19 -0000 --001a114d74fab5c3d60555aa102f Content-Type: text/plain; charset="UTF-8" On Mon, Jul 31, 2017 at 4:58 PM, Brandon Long wrote: > On Mon, Jul 31, 2017 at 4:53 PM, Gene Shuman wrote: > > To repeat: > > > > But I understand now, simple misunderstanding. > > > > So is this assumption correct? An AAR should look like this: > > > > Arc-Authentication-Results: i=14; mx.google.com; > > arc=pass ams.d=google.com ams.s=arc-20160816 as.d=google.com > > ams.s=arc-20160816 > > I wonder if more in keeping with the ptypes, that it would be: > > Arc-Authentication-Results: i=14; mx.google.com; > arc=pass header.ams-d=google.com header.ams-s=arc-20160816 > header.as-d=google.com header.as-s=arc-20160816 > > There are folks on this list who better understand authres who may > have a stronger opinion. My interpretation of the conversations in Prague with Seth was that he was looking to have the (ridiculously) long list of all the chain components; but I'll take responsibility for misunderstanding that one :-) I think that what Brandon is proposing for the "only ARC" portion of the AAR is reasonable and will update the draft accordingly unless I hear otherwise from other folks. I'm also in the midst of incorporating responses to Alexy and Dave's inputs. --Kurt --001a114d74fab5c3d60555aa102f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Jul 31, 2017 at 4:58 PM, Brandon Long <blong@fiction.net> wrote:
On Mon, Jul 31,= 2017 at 4:53 PM, Gene Shuman <g= eneshuman@gmail.com> wrote:
> To repeat:
>
> But I understand now, simple misunderstanding.
>
> So is this assumption correct?=C2=A0 An AAR should look like this:
>
> Arc-Authentication-Results: i=3D14; mx.google.com;
>=C2=A0 =C2=A0 =C2=A0arc=3Dpass ams.d=3Dgoogle.com ams.s=3Darc-20160816 as.d= =3Dgoogl= e.com
> ams.s=3Darc-20160816

I wonder if more in keeping with the ptypes, that it would be:

Arc-Authentication-Results: i=3D14; mx.google.com;
=C2=A0 =C2=A0 =C2=A0arc=3Dpass header.ams-d=3Dgoogle.com header.ams-s=3Darc-201= 60816
header.as-d=3Dgoogle.com header.as-s=3Darc-20160816

There are folks on this list who better understand authres who may
have a stronger opinion.

My interpretation = of the conversations in Prague with Seth was that he was looking to have th= e (ridiculously) long list of all the chain components; but I'll take r= esponsibility for misunderstanding that one :-)

I = think that what Brandon is proposing for the "only ARC" portion o= f the AAR is reasonable and will update the draft accordingly unless I hear= otherwise from other folks.

I'm also in the m= idst of incorporating responses to Alexy and Dave's inputs.
<= br>
--Kurt=C2=A0

--001a114d74fab5c3d60555aa102f-- From nobody Mon Jul 31 22:59:16 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8E2131C56 for ; Mon, 31 Jul 2017 22:59:13 -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 yYDuEaDbLDzA for ; Mon, 31 Jul 2017 22:59:11 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89826131C33 for ; Mon, 31 Jul 2017 22:59:11 -0700 (PDT) Received: from android-df929938bd25e485.home.kitterman.com (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 25C0EC401BB; Tue, 1 Aug 2017 00:59:10 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1501567150; bh=3Tf2gqqti0dpSobPvRZpJAYDp6BcnatkKvtu7Ywip4I=; h=Date:In-Reply-To:References:Subject:To:From:From; b=u0PDutNro0guU9fJj3P+Ub+KNOKWRizhSXIv0HRZSKlncVih69dc5fNIByuvlEFqo LtaCJVNzFjwfNRyCCC3jzHlbbK0TX5HzAmVjnlHAGHE6XqukB11LgxiaWb9ZLN7NwI +CASsRdzrx6Fyr8ggsX94UsZiVVw3ETKphmy7Vh8= Date: Tue, 01 Aug 2017 05:59:04 +0000 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dmarc@ietf.org From: Scott Kitterman Message-ID: <3775088D-356B-48EA-82C2-117655840F83@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] dns failures in the draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 05:59:13 -0000 On August 1, 2017 12:56:51 AM EDT, "Kurt Andersen (b)" wrote: >On Mon, Jul 31, 2017 at 4:41 PM, Brandon Long >wrote: > >> > 9=2E4=2E Handling DNS Problems While Validating ARC >> > DNS failures to resolve or return data which is needed for ARC >> > validation SHOULD result in a 421 tempfail during the SMTP >> > conversation with the sending system=2E >> >> I don't know if SHOULD is the right choice here=2E >> >> For a large percentage of mail, ARC is unnecessary, even when >> forwarded through an intermediary=2E The mail will continue to DMARC >> pass, or the mail will not be for a DMARC p=3Dreject domain=2E >> > >Good point - you highlighted that my implicit thought related to the >"is >needed for ARC validation" does not adequately convey the consideration >that "ARC validation" is only needed when DMARC itself does not pass=2E I >will adjust the wording to be more explicit=2E > >Does that additional piece change your concern about returning a 421? I >wanted to be a bit more forceful than just saying "MAY" in order to >encourage DMARC (and possibly ARC if needed for local policy) >evaluation >during the SMTP session as operators implement ARC=2E If I understand correctly, the desired behavior is don't reject (5xx) a me= ssage due to an ARC related DNS failure=2E Why not put it that way? It s= eems like it would be clearer and simpler to specify it that way=2E Scott K