From nobody Wed Aug 17 02:47:16 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E62B12D523 for ; Wed, 17 Aug 2016 02:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.549 X-Spam-Level: X-Spam-Status: No, score=-5.549 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=-1.247, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08C_C4JeNP-0 for ; Wed, 17 Aug 2016 02:47:12 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92B6612D590 for ; Wed, 17 Aug 2016 02:47:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1471427227; bh=D3QgCFgxSJm3VJbmIfh6w/dgV9xBBOzXj5SfxTaVDJM=; l=2871; h=References:To:From:Date:In-Reply-To; b=faelbPGlmk8xNLQ+9q/uJLuyARvizSImO/Pw62ljgwylsHvhVo5DjZskhSidQUNx0 zkAJiErmAf7xdQ+7XyH4R8G0GKawqt8FkB1oqkw8VEk0bRVB2IkBW9swjXU06RMd0V hk9+MhzM+n0vtQOAafFYTaAnx3PevrWoJXqntBi4= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [192.168.1.100] ([5.170.200.41]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by wmail.tana.it with ESMTPSA; Wed, 17 Aug 2016 11:47:06 +0200 id 00000000005DC044.0000000057B4329A.00005FB4 References: <20160813023957.5679.qmail@ary.lan> <20160813150004.GM10626@thunk.org> <2561d946-b853-4dd2-5aba-921bd88f99ba@dcrocker.net> To: dmarc-ietf From: Alessandro Vesely Message-ID: <655339a0-54eb-4d84-f407-8aea3a822cc3@tana.it> Date: Wed, 17 Aug 2016 11:47:02 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <2561d946-b853-4dd2-5aba-921bd88f99ba@dcrocker.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] ARC (was - Re: DMARC and ietf.org) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 09:47:15 -0000 The message quoted below deserves discussion, which didn't take place on the IETF list where it was originally posted: https://mailarchive.ietf.org/arch/msg/ietf/0sFUeCumvE8ij6Y92H9CvLKSTJY Since ARC adoption, that discussion belongs to this WG list. So I reply here. On Sat 13/Aug/2016 17:22:52 +0200 Dave Crocker wrote: > On 8/13/2016 8:10 AM, John R Levine wrote: >> More to the point, ARC lets lists keep working they way they're supposed >> to. > > I participate in the informal group that created ARC. I am hoping ARC > will be helpful. > > But we need to be cautious with our expectations. First, it isn't > operational yet, so we don't even know whether it will do what we want > it to. Worse, we don't know how much that will help. > > That's not a claim that it won't work or won't be useful, but it is > playing amidst some Internet-scale, multi-stage dynamics that can get > complicated. > > By way of example: With DKIM, trust assessment is of the entity doing > the signing, typically the originating service. With ARC, that > assessment still must be made, but it must be coupled with an assessment > of the first ARC-signing entity. > > Maybe that's not a big deal. But I think that combinatorial trust > assessments are new and therefore might be challenging. That challenge can only be accepted by mailbox providers who are large enough to maintain a statistically meaningful perspective of global Internet mailing. Smallish MTAs will likely have to take recourse to dnswl.org, possibly after some more attempts at creating protocol-specific white lists. Formal criteria to establish when valid ARC fields can inhibit DMARC's policy would seem to be better suited for protocol specifications. I proposed ARC-0, [0] but there may be better methods than that. [0] Proposal to adopt ARC documents into the WG (toward phase 2 milestone), 11 May 2016: http://mailarchive.ietf.org/arch/msg/dmarc/RXpz36Rs_aXvhlt9Tkpi89LJmrI > And that's not counting the question of whether an ARC signature will > survive better than a DKIM signature... (The design is intended to have > better survival, but again, it hasn't been tested in the field.) SMTP currently warns that, in some unspecified cases, "more caution and conservatism should be applied when considering whether or not to perform fixes and how." Some implementations[1] look for DKIM signatures and refrain to fix if any is found. Rather than just adding ARC's fields to the list of header fields whose presence should prevent fixing, it might be more stable to standardize a generic method to signal that caution and conservatism should be applied --unless we think ARC is the final, ultimate message signing technique, that is. [1] For one, parameter NOADDRREWRITE, as documented in: http://www.courier-mta.org/submit.html Ale -- From nobody Thu Aug 18 16:40:50 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4FB12D0CF for ; Thu, 18 Aug 2016 16:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.947 X-Spam-Level: X-Spam-Status: No, score=-3.947 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=-1.247, 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 aTPeE96n3xtk for ; Thu, 18 Aug 2016 16:40:45 -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 3777212B016 for ; Thu, 18 Aug 2016 16:40:44 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id c15so43379451oig.0 for ; Thu, 18 Aug 2016 16:40:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/0tJxl9G0R9xubTvzfiOkJD+KoOux14G+/BGMD5Af6I=; b=CzJa1AOmw+DLLqPU2gMGtWBufrvqkHGYOqevisplzRiK3Kk19rfQcDnQMKrDLg8lHD NU0oHxDBHDjR8l7UwR+zKoW0OhR4lXutZ/9HfiqneAp8pxyN0W/itX+eS4+Y8pbhEvzK ottTkgoQMpLXjwCR1UaPcOe3Ztvwgm7BpFcjQUI/0sv7C8nzTXGVvXKpP7NAYigTKo09 uZHK1Nw8FsDEtM1gEIhoAV8uxma7QqjVMovx516BremPCOLEWivOxoQP0iLTrIQGmCFA vOt94RbImBtwe34gRrZKOO1Xu3Mr3KHkmRLJwmYMXW20gbNdO5hbrsvpf0Gw43aZ//1g 3cRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/0tJxl9G0R9xubTvzfiOkJD+KoOux14G+/BGMD5Af6I=; b=QjHcnm5NrVSDP1uY3L0xA9wpzXAErx+0rC2SkU5AfcDTvO58gveLPf0C+rTgKvMXZQ PSmswAXZ4CaxYzOWPIzS3YxZfzKzcL79wDjJ2mb4lnZPcmTExjled+/TUHOsvFXChHP5 BLciQm7QmVDeTuCnTKT/MTiIDtNNjbripP+hSCfX+XytJ5BRPaByj7BeFLmcsfHvWc23 T8edI2US7KvCE7GD0kj6m3MF84sDVZfZFHinwm+Yv+FLT9v9nDdq3Y9MwtANSvowsKvf fCnCvPDrNyz3UCA7VZnpw4Q5k/Vq5jC48JhIhW4KPdX3n5kdOvQGX5+19jCED12ZQNP6 AZRQ== X-Gm-Message-State: AEkoouu/5z/wST1AJ1Ap0BoAIc35tl7NTTbZ8Dxea3BMzyCEYr+4PZkwXviX4ytm1vUjZ2Mm0yRS594ZcU5UNP6e X-Received: by 10.202.92.197 with SMTP id q188mr3012215oib.79.1471563643740; Thu, 18 Aug 2016 16:40:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.37.140 with HTTP; Thu, 18 Aug 2016 16:40:42 -0700 (PDT) In-Reply-To: <655339a0-54eb-4d84-f407-8aea3a822cc3@tana.it> References: <20160813023957.5679.qmail@ary.lan> <20160813150004.GM10626@thunk.org> <2561d946-b853-4dd2-5aba-921bd88f99ba@dcrocker.net> <655339a0-54eb-4d84-f407-8aea3a822cc3@tana.it> From: Brandon Long Date: Thu, 18 Aug 2016 16:40:42 -0700 Message-ID: To: Alessandro Vesely Content-Type: multipart/alternative; boundary=001a113d5bbc404e6b053a611ca5 Archived-At: Cc: dmarc-ietf Subject: Re: [dmarc-ietf] ARC (was - Re: DMARC and ietf.org) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 23:40:48 -0000 --001a113d5bbc404e6b053a611ca5 Content-Type: text/plain; charset=UTF-8 On Wed, Aug 17, 2016 at 2:47 AM, Alessandro Vesely wrote: > The message quoted below deserves discussion, which didn't take place on > the IETF list where it was originally posted: > https://mailarchive.ietf.org/arch/msg/ietf/0sFUeCumvE8ij6Y92H9CvLKSTJY > > Since ARC adoption, that discussion belongs to this WG list. So I reply > here. > > On Sat 13/Aug/2016 17:22:52 +0200 Dave Crocker wrote: > > On 8/13/2016 8:10 AM, John R Levine wrote: > >> More to the point, ARC lets lists keep working they way they're supposed > >> to. > > > > I participate in the informal group that created ARC. I am hoping ARC > > will be helpful. > > > > But we need to be cautious with our expectations. First, it isn't > > operational yet, so we don't even know whether it will do what we want > > it to. Worse, we don't know how much that will help. > > > > That's not a claim that it won't work or won't be useful, but it is > > playing amidst some Internet-scale, multi-stage dynamics that can get > > complicated. > > > > By way of example: With DKIM, trust assessment is of the entity doing > > the signing, typically the originating service. With ARC, that > > assessment still must be made, but it must be coupled with an assessment > > of the first ARC-signing entity. > > > > Maybe that's not a big deal. But I think that combinatorial trust > > assessments are new and therefore might be challenging. > > That challenge can only be accepted by mailbox providers who are large > enough to maintain a statistically meaningful perspective of global > Internet mailing. Smallish MTAs will likely have to take recourse to > dnswl.org, possibly after some more attempts at creating > protocol-specific white lists. > > Formal criteria to establish when valid ARC fields can inhibit DMARC's > policy would seem to be better suited for protocol specifications. I > proposed ARC-0, [0] but there may be better methods than that. > > [0] Proposal to adopt ARC documents into the WG (toward phase 2 > milestone), 11 May 2016: > http://mailarchive.ietf.org/arch/msg/dmarc/RXpz36Rs_aXvhlt9Tkpi89LJmrI > > > And that's not counting the question of whether an ARC signature will > > survive better than a DKIM signature... (The design is intended to have > > better survival, but again, it hasn't been tested in the field.) > > SMTP currently warns that, in some unspecified cases, "more caution and > conservatism should be applied when considering whether or not to > perform fixes and how." Some implementations[1] look for DKIM > signatures and refrain to fix if any is found. Rather than just adding > ARC's fields to the list of header fields whose presence should prevent > fixing, it might be more stable to standardize a generic method to > signal that caution and conservatism should be applied --unless we think > ARC is the final, ultimate message signing technique, that is. > > [1] For one, parameter NOADDRREWRITE, as documented in: > http://www.courier-mta.org/submit.html With ARC, one's MTA could do the DKIM check, fix the message, and then ARC sign the result. Brandon --001a113d5bbc404e6b053a611ca5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Aug 17, 2016 at 2:47 AM, Alessandro Vesely &l= t;vesely@tana.it>= ; wrote:
The message quoted below = deserves discussion, which didn't take place on
the IETF list where it was originally posted:
https://mailarchive.ietf.org/<= wbr>arch/msg/ietf/0sFUeCumvE8ij6Y92H9CvLKSTJY

Since ARC adoption, that discussion belongs to this WG list.=C2=A0 So I rep= ly
here.

On Sat 13/Aug/2016 17:22:52 +0200 Dave Crocker wrote:
> On 8/13/2016 8:10 AM, John R Levine wrote:
>> More to the point, ARC lets lists keep working they way they'r= e supposed
>> to.
>
> I participate in the informal group that created ARC.=C2=A0 I am hopin= g ARC
> will be helpful.
>
> But we need to be cautious with our expectations.=C2=A0 First, it isn&= #39;t
> operational yet, so we don't even know whether it will do what we = want
> it to.=C2=A0 Worse, we don't know how much that will help.
>
> That's not a claim that it won't work or won't be useful, = but it is
> playing amidst some Internet-scale, multi-stage dynamics that can get<= br> > complicated.
>
> By way of example:=C2=A0 With DKIM, trust assessment is of the entity = doing
> the signing, typically the originating service.=C2=A0 With ARC, that > assessment still must be made, but it must be coupled with an assessme= nt
> of the first ARC-signing entity.
>
> Maybe that's not a big deal.=C2=A0 But I think that combinatorial = trust
> assessments are new and therefore might be challenging.

That challenge can only be accepted by mailbox providers who are large
enough to maintain a statistically meaningful perspective of global
Internet mailing.=C2=A0 Smallish MTAs will likely have to take recourse to<= br> dnswl.org= , possibly after some more attempts at creating
protocol-specific white lists.

Formal criteria to establish when valid ARC fields can inhibit DMARC's<= br> policy would seem to be better suited for protocol specifications.=C2=A0 I<= br> proposed ARC-0, [0] but there may be better methods than that.

[0] Proposal to adopt ARC documents into the WG (toward phase 2
milestone), 11 May 2016:
http://mailarchive.ietf.org/arch/msg/dmarc/RXpz36Rs_aXvhlt9Tkpi89LJmrI

> And that's not counting the question of whether an ARC signature w= ill
> survive better than a DKIM signature...=C2=A0 (The design is intended = to have
> better survival, but again, it hasn't been tested in the field.)
SMTP currently warns that, in some unspecified cases, "more caution an= d
conservatism should be applied when considering whether or not to
perform fixes and how."=C2=A0 Some implementations[1] look for DKIM signatures and refrain to fix if any is found.=C2=A0 Rather than just addin= g
ARC's fields to the list of header fields whose presence should prevent=
fixing, it might be more stable to standardize a generic method to
signal that caution and conservatism should be applied --unless we think ARC is the final, ultimate message signing technique, that is.

[1] For one, parameter NOADDRREWRITE, as documented in:
http://www.courier-mta.org/submit.html

With ARC, one's MTA could do the DKIM check, fix the = message, and then ARC sign the result.

Brandon=C2= =A0

--001a113d5bbc404e6b053a611ca5-- From nobody Sat Aug 20 04:02:25 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA7E12B03C for ; Sat, 20 Aug 2016 04:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.549 X-Spam-Level: X-Spam-Status: No, score=-5.549 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=-1.247, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6VEFt4UPOs0 for ; Sat, 20 Aug 2016 04:02:21 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 834E712B017 for ; Sat, 20 Aug 2016 04:02:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1471690937; bh=Lp23qseoMvwPE9tM478jnRkgEOrn3kONUbd+zRxcU4k=; l=3141; h=To:References:From:Date:In-Reply-To; b=neYSBqsgN4J0X17iBfYq97Tguqv+v9GrqmjwyTUiwkTMJTQV8pxEP5u0sGvrvRBxI VQbQ0/4/h0pJv8/mzb+SRMe2nvtCia8q9H4/+4Q74LtnjImwiR0NxSV4tJAGVFcHyQ tbyFDtkUmL+nLz1xS6HGl8Un4TNu8g0/7QbA6ckw= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [192.168.1.101] ([5.170.199.97]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by wmail.tana.it with ESMTPSA; Sat, 20 Aug 2016 13:02:16 +0200 id 00000000005DC053.0000000057B838B8.0000668B To: dmarc@ietf.org, Brandon Long References: <20160813023957.5679.qmail@ary.lan> <20160813150004.GM10626@thunk.org> <2561d946-b853-4dd2-5aba-921bd88f99ba@dcrocker.net> <655339a0-54eb-4d84-f407-8aea3a822cc3@tana.it> From: Alessandro Vesely Message-ID: <4a3c08f4-8fa5-efcc-f70a-cc9ec98d01b5@tana.it> Date: Sat, 20 Aug 2016 13:02:14 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] ARC and weak signatures (again) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Aug 2016 11:02:23 -0000 On Fri 19/Aug/2016 01:40:42 +0200 Brandon Long wrote: > On Wed, Aug 17, 2016 at 2:47 AM, Alessandro Vesely wrote: >> On Sat 13/Aug/2016 17:22:52 +0200 Dave Crocker wrote: >>> >>> [...] With DKIM, trust assessment is of the entity doing the >>> signing, typically the originating service. With ARC, that >>> assessment still must be made, but it must be coupled with an >>> assessment of the first ARC-signing entity. >>> >>> Maybe that's not a big deal. But I think that combinatorial >>> trust assessments are new and therefore might be challenging. >> >> That challenge can only be accepted by mailbox providers who are >> large enough to maintain a statistically meaningful perspective of >> global Internet mailing. Smallish MTAs will likely have to take >> recourse to dnswl.org, possibly after some more attempts at >> creating protocol-specific white lists. >> >> Formal criteria to establish when valid ARC fields can inhibit >> DMARC's policy would seem to be better suited for protocol >> specifications. I proposed ARC-0, but there may be better methods >> than that. >> [...] > > With ARC, one's MTA could do the DKIM check, fix the message, and > then ARC sign the result. How can that ARC set be used by the next hop? *Guidance for receivers* is based on /sufficient history/: Final message recipients may or may not choose to examine these results when messages fail other authentication checks. They are more likely to override, say, a failing DMARC result in the presence of an intact ARC chain where the participating ARC message handlers have been observed to not convey "bad" content in the past, and the initial ARC participant indicates the message they received had passed authentication checks. Say A -> B -> C are the MTAs: C sees a message where B is cited in the To: or Cc: header fields. The message is ARC signed by B. B says A's DKIM signature was good, but now it is broken. A's DMARC policy says that C should reject in that case. What should C do? If C is gmail, it likely has sufficient history to know how A and B behave. But what about small MTAs whose email flow is statistically not enough to use combinatorial trust assessments? If A had added a second DKIM signature, signing just the To: or Cc: field(s) which cited B, with l=0 for the body, then that signature likely survived B's fixing and hence C could infer that B is a true (not self-styled) forwarder. IOW, A's second (weak) signature provides C with a formal criterion to instruct its local policy to accept email that fails the DMARC mechanism check even if A has published a "reject" policy. So, what I called ARC-0 in my former proposal, doesn't really have much to do with ARC. The concept is weak signatures. Of course, they won't work unless carefully standardized and implemented. The question is if they will ever work at all, and if this WG is willing to consider them. If not, we need to address Dave's concern some other way, or resign ourselves to building a solution which will likely work 98.7% for some and 0.2% for others. Ale -- From nobody Mon Aug 22 17:07:31 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5518A12B012 for ; Mon, 22 Aug 2016 17:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 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.548, 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 o7d8MhRxk0U1 for ; Mon, 22 Aug 2016 17:07:26 -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 BABE212D0BA for ; Mon, 22 Aug 2016 17:07:26 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id f189so174838332oig.3 for ; Mon, 22 Aug 2016 17:07:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HOOKmuDWXwowretLhDkNgm+Y8h+4xDH0GYcRjHUs2X4=; b=IyC2dBpCD8DUmFEyF/qKnZY5NWkCh2ML/TfUaFtcZsZuf8xGIoeOjMjT6CW7NPx269 osNEdHShD2aiVeQCKoW72tu9ekMygOmAeBfr0Tcpxm8oEzjAL4Exs39+KlpaJTaQpDE4 Lbw1H9bGxiZoFPEBWZAksEz55uRv9wusSldVD2aeC+85X7xcXZfl3tMTlmnMFKSpUsnb T0q+K0z07bko2PvAmlv7ldKwnTgPgcvWIeUlkBHebPKx+NbvFlcfyCVeS8u20Rfti2yr X0Kc25QdabHoonmWpjkY7B3IujDYkhtuZqfHffmsx5FW44zgYVOevue9MqZG6AZIeIEC facQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HOOKmuDWXwowretLhDkNgm+Y8h+4xDH0GYcRjHUs2X4=; b=U6CKz2yDfcNRyFZjBEQIRlgy51/nnaAh2nKsBREJiENTCCnjyg0daXcEcso4b3v3ow f40pIjkSMizwgqaovhvXMUK2fVG9ntjtwWaBQWa80ZVIJTkXf/Wvr6LeZFHM7kVGKaXF IyEGQcYkZK3cls7BhVvmmoF/TiEf1oN5lKlJzzEg1fjCnWDtNfuFebt0TBJG+kTNvyOY PiMefwUkzCzNAwE2r2AalSKNf/p1BDbk6Lj30CH6hR8rPkgURxJvCPMJ9Seq/Tg1Q4qU 2UDGmBMCDrp1Lv4ZnBEtT3Y9nRe/EEaI/ho+vsn5mm7g+28qysURYSFFllgwJruARhMy 4jNw== X-Gm-Message-State: AEkoousIbXJZNLdX9sEaKQSV62UoQsuxNsQRneQ9Qwc9FmXLJj5yzFGSaFYB/lSnqKbS7aPRIz4N3TSPRbrjRcE+ X-Received: by 10.202.226.129 with SMTP id z123mr13564040oig.120.1471910846029; Mon, 22 Aug 2016 17:07:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.37.140 with HTTP; Mon, 22 Aug 2016 17:07:24 -0700 (PDT) In-Reply-To: <4a3c08f4-8fa5-efcc-f70a-cc9ec98d01b5@tana.it> References: <20160813023957.5679.qmail@ary.lan> <20160813150004.GM10626@thunk.org> <2561d946-b853-4dd2-5aba-921bd88f99ba@dcrocker.net> <655339a0-54eb-4d84-f407-8aea3a822cc3@tana.it> <4a3c08f4-8fa5-efcc-f70a-cc9ec98d01b5@tana.it> From: Brandon Long Date: Mon, 22 Aug 2016 17:07:24 -0700 Message-ID: To: Alessandro Vesely Content-Type: multipart/alternative; boundary=001a114090621ebbb0053ab1f3b4 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] ARC and weak signatures (again) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 00:07:30 -0000 --001a114090621ebbb0053ab1f3b4 Content-Type: text/plain; charset=UTF-8 On Sat, Aug 20, 2016 at 4:02 AM, Alessandro Vesely wrote: > On Fri 19/Aug/2016 01:40:42 +0200 Brandon Long wrote: > > On Wed, Aug 17, 2016 at 2:47 AM, Alessandro Vesely > wrote: > >> On Sat 13/Aug/2016 17:22:52 +0200 Dave Crocker wrote: > >>> > >>> [...] With DKIM, trust assessment is of the entity doing the > >>> signing, typically the originating service. With ARC, that > >>> assessment still must be made, but it must be coupled with an > >>> assessment of the first ARC-signing entity. > >>> > >>> Maybe that's not a big deal. But I think that combinatorial > >>> trust assessments are new and therefore might be challenging. > >> > >> That challenge can only be accepted by mailbox providers who are > >> large enough to maintain a statistically meaningful perspective of > >> global Internet mailing. Smallish MTAs will likely have to take > >> recourse to dnswl.org, possibly after some more attempts at > >> creating protocol-specific white lists. > >> > >> Formal criteria to establish when valid ARC fields can inhibit > >> DMARC's policy would seem to be better suited for protocol > >> specifications. I proposed ARC-0, but there may be better methods > >> than that. > >> [...] > > > > With ARC, one's MTA could do the DKIM check, fix the message, and > > then ARC sign the result. > > How can that ARC set be used by the next hop? *Guidance for receivers* > is based on /sufficient history/: > > Final message recipients may or may not > choose to examine these results when messages fail other > authentication checks. They are more likely to override, say, a > failing DMARC result in the presence of an intact ARC chain where the > participating ARC message handlers have been observed to not convey > "bad" content in the past, and the initial ARC participant indicates > the message they received had passed authentication checks. > > Say A -> B -> C are the MTAs: C sees a message where B is cited in the > To: or Cc: header fields. The message is ARC signed by B. B says A's > DKIM signature was good, but now it is broken. A's DMARC policy says > that C should reject in that case. What should C do? > > If C is gmail, it likely has sufficient history to know how A and B > behave. But what about small MTAs whose email flow is statistically not > enough to use combinatorial trust assessments? > If your MTA is too small to use combinatorial trust assessments, then you are stuck with the same two options you have today: manual whitelists or using a service to give you that information. If you're small enough, I don't think manually whitelisting the mailing list servers your users are subscribed to would be that challenging, especially if you receive the DMARC reports your server generates. If A had added a second DKIM signature, signing just the To: or Cc: > field(s) which cited B, with l=0 for the body, then that signature > likely survived B's fixing and hence C could infer that B is a true (not > self-styled) forwarder. IOW, A's second (weak) signature provides C > with a formal criterion to instruct its local policy to accept email > that fails the DMARC mechanism check even if A has published a "reject" > policy. > > So, what I called ARC-0 in my former proposal, doesn't really have much > to do with ARC. The concept is weak signatures. Of course, they won't > work unless carefully standardized and implemented. The question is if > they will ever work at all, and if this WG is willing to consider them. > If not, we need to address Dave's concern some other way, or resign > ourselves to building a solution which will likely work 98.7% for some > and 0.2% for others. > So, any message sent from A to B can then be used as a replay with any content to any party as long as the To/Cc are intact? That seems pretty useless. Brandon --001a114090621ebbb0053ab1f3b4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Aug 20, 2016 at 4:02 AM, Alessandro Vesely &l= t;vesely@tana.it>= ; wrote:
On Fri 19/Aug/2016 01:40:= 42 +0200 Brandon Long wrote:
> On Wed, Aug 17, 2016 at 2:47 AM, Alessandro Vesely <vesely@tana.it> wrote:
>> On Sat 13/Aug/2016 17:22:52 +0200 Dave Crocker wrote:
>>>
>>> [...]=C2=A0 With DKIM, trust assessment is of the entity doing= the
>>> signing, typically the originating service.=C2=A0 With ARC, th= at
>>> assessment still must be made, but it must be coupled with an<= br> >>> assessment of the first ARC-signing entity.
>>>
>>> Maybe that's not a big deal.=C2=A0 But I think that combin= atorial
>>> trust assessments are new and therefore might be challenging.<= br> >>
>> That challenge can only be accepted by mailbox providers who are >> large enough to maintain a statistically meaningful perspective of=
>> global Internet mailing.=C2=A0 Smallish MTAs will likely have to t= ake
>> recourse to dnswl.org, possibly after some more attempts at
>> creating protocol-specific white lists.
>>
>> Formal criteria to establish when valid ARC fields can inhibit
>> DMARC's policy would seem to be better suited for protocol
>> specifications.=C2=A0 I proposed ARC-0, but there may be better me= thods
>> than that.
>> [...]
>
> With ARC, one's MTA could do the DKIM check, fix the message, and<= br> > then ARC sign the result.

How can that ARC set be used by the next hop?=C2=A0 *Guidance for receivers= *
is based on /sufficient history/:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Final message recipients may or may not
=C2=A0 =C2=A0choose to examine these results when messages fail other
=C2=A0 =C2=A0authentication checks.=C2=A0 They are more likely to override,= say, a
=C2=A0 =C2=A0failing DMARC result in the presence of an intact ARC chain wh= ere the
=C2=A0 =C2=A0participating ARC message handlers have been observed to not c= onvey
=C2=A0 =C2=A0"bad" content in the past, and the initial ARC parti= cipant indicates
=C2=A0 =C2=A0the message they received had passed authentication checks.
Say A -> B -> C are the MTAs:=C2=A0 C sees a message where B is cited= in the
To: or Cc: header fields.=C2=A0 The message is ARC signed by B.=C2=A0 B say= s A's
DKIM signature was good, but now it is broken.=C2=A0 A's DMARC policy s= ays
that C should reject in that case.=C2=A0 What should C do?

If C is gmail, it likely has sufficient history to know how A and B
behave.=C2=A0 But what about small MTAs whose email flow is statistically n= ot
enough to use combinatorial trust assessments?

If your MTA is too small to use combinatorial trust assessments, th= en you are stuck
with the same two options you have today: manual= whitelists or using a service to
give you that information.

If you're small enough, I don't think manually= whitelisting the mailing list servers your users=C2=A0
are subsc= ribed to would be that challenging, especially if you receive the DMARC rep= orts your
server generates.=C2=A0

If A had added a second DKIM signature, signing just the To: or Cc:
field(s) which cited B, with l=3D0 for the body, then that signature
likely survived B's fixing and hence C could infer that B is a true (no= t
self-styled) forwarder.=C2=A0 IOW, A's second (weak) signature provides= C
with a formal criterion to instruct its local policy to accept email
that fails the DMARC mechanism check even if A has published a "reject= "
policy.

So, what I called ARC-0 in my former proposal, doesn't really have much=
to do with ARC.=C2=A0 The concept is weak signatures.=C2=A0 Of course, they= won't
work unless carefully standardized and implemented.=C2=A0 The question is i= f
they will ever work at all, and if this WG is willing to consider them.
If not, we need to address Dave's concern some other way, or resign
ourselves to building a solution which will likely work 98.7% for some
and 0.2% for others.

So, any message se= nt from A to B can then be used as a replay with any content to any party a= s long
as the To/Cc are intact?=C2=A0 That seems pretty useless.<= /div>

Brandon=C2=A0
--001a114090621ebbb0053ab1f3b4-- From nobody Tue Aug 23 11:55:48 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2458612D7A2 for ; Tue, 23 Aug 2016 11:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.85 X-Spam-Level: X-Spam-Status: No, score=-4.85 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.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id apJJd66Cpy_t for ; Tue, 23 Aug 2016 11:55:45 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5463112B040 for ; Tue, 23 Aug 2016 11:55:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1471978538; bh=eqvGeQeImZRekBjM88WVJY2pxH2TNcGJDMEo9o160AI=; l=5082; h=To:References:Cc:From:Date:In-Reply-To; b=NDm/NRTSR7UlE6zSiAtxerwfK77dRBjDMskUYpHDas3QCrf1O2CMaRXRTnfirxS+g 3NcTm6our3TLaolvuqkC7EWmTpn/hu88Sn/WFBYs/49NWlNhFRN19cMnhlttcAHgrr MrNDvcbZHGRnfBT1wdmIstw/gM6Xa58CoPGnk9pU= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.88] (pcale.tana [172.25.197.88]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Tue, 23 Aug 2016 20:55:38 +0200 id 00000000005DC033.0000000057BC9C2A.00005134 To: Brandon Long References: <20160813023957.5679.qmail@ary.lan> <20160813150004.GM10626@thunk.org> <2561d946-b853-4dd2-5aba-921bd88f99ba@dcrocker.net> <655339a0-54eb-4d84-f407-8aea3a822cc3@tana.it> <4a3c08f4-8fa5-efcc-f70a-cc9ec98d01b5@tana.it> From: Alessandro Vesely Message-ID: <9b51616c-2540-d8ec-61b0-2dcc6d6a29ea@tana.it> Date: Tue, 23 Aug 2016 20:55:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: dmarc-ietf Subject: Re: [dmarc-ietf] ARC and weak signatures (again) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 18:55:47 -0000 On Tue 23/Aug/2016 02:07:24 +0200 Brandon Long wrote: > On Sat, Aug 20, 2016 at 4:02 AM, Alessandro Vesely wrote: > >> >> Say A -> B -> C are the MTAs: C sees a message where B is cited in the >> To: or Cc: header fields. The message is ARC signed by B. B says A's >> DKIM signature was good, but now it is broken. A's DMARC policy says >> that C should reject in that case. What should C do? >> >> If C is gmail, it likely has sufficient history to know how A and B >> behave. But what about small MTAs whose email flow is statistically not >> enough to use combinatorial trust assessments? > > If your MTA is too small to use combinatorial trust assessments, then you > are stuck with the same two options you have today: manual whitelists or > using a service to give you that information. > > If you're small enough, I don't think manually whitelisting the mailing list > servers your users are subscribed to would be that challenging, especially > if you receive the DMARC reports your server generates. I can configure my filter to accept DMARC-failed messages from authenticated domains which are trusted MLMs. Even if I only see 20~30 new mail domains each day, I'm not going to manually look for names which seem to be lists. A two-step heuristic to determine trusted MLMs consists of (1) collect domain names from received List-Post: header fields matching , and authenticated (via SPF, DKIM, or DNSWL), and then (2) from the domains collected that way, select those that my users write to. _Small domains_ --by definition, for the scope of this discussion-- have no anonymous users. That heuristics keeps failing until a subscribed user actually posts to a MLM. Skipping step (2) makes it an obvious attack path, but whitelisting can mitigate it a bit. How can aggregate reports help here? Would you please expand? >> If A had added a second DKIM signature, signing just the To: or Cc: >> field(s) which cited B, with l=0 for the body, then that signature >> likely survived B's fixing and hence C could infer that B is a true (not >> self-styled) forwarder. IOW, A's second (weak) signature provides C >> with a formal criterion to instruct its local policy to accept email >> that fails the DMARC mechanism check even if A has published a "reject" >> policy. >> >> So, what I called ARC-0 in my former proposal, doesn't really have much >> to do with ARC. The concept is weak signatures. Of course, they won't >> work unless carefully standardized and implemented. The question is if >> they will ever work at all, and if this WG is willing to consider them. >> If not, we need to address Dave's concern some other way, or resign >> ourselves to building a solution which will likely work 98.7% for some >> and 0.2% for others. > > So, any message sent from A to B can then be used as a replay with any > content to any party as long as the To/Cc are intact? That seems pretty > useless. Yes, B can send whatever they like using your name@A. That's how weak signatures work. Of course, valuable domains such as banks and other phish targets should never use them. Our task here is to better indirect flows, not counter phishing. Anyway, regular domains may want to weak-sign only the copy of a message addressed to a trusted MLM. Bumping DKIM version was proposed as a means to have C also require a valid signature of B. Some receivers already use local policies to limit the shape of DKIM-Signatures they accept; for example, some regard signatures with l=0 as invalid. Smart C-role verifiers may want to match B to To: or Cc: before accepting weak signatures. I'd put weak signatures when I play A. That way I'd complement the above technique, trusted MLMs whitelisting, which I'd use when I play C. An additional element would be to have B save From:. In fact, A's weak h= should not include From:, because rewriting From: currently seems to be the best anti-DMARC workaround. B would save the value of From: using a new header field name, e.g., say, Original-From:, Authenticated-From:, or ARC-From: for daisy chaining (vote for one). Finally, C may consider the presence of this new field to confirm A's role, and possibly fix From:. In those cases, a message passes if C is either smart or dumb, not somewhere in between. DKIM v=2 would eliminate the "dumb" side. If I were clever, I would list all possible statuses of A, B, and C (such as complying with DKIM, DMARC and ARC, applying or recognizing weak signatures, being aware of either DKIM v=2 or the new header field, et cetera) along with the relative probabilities that they are implemented at various stages in time, and then compute the chances that C can pass/reject correctly in the two cases of B being white or black, at each stage. I reckon there are cases of A unknown to C, perhaps because either is small, where some mixes of the above techniques would save the day, thereby encouraging more small domains to publish strict DMARC policies, don't you think? Ale -- From nobody Tue Aug 23 17:19:41 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD50312D5A5 for ; Tue, 23 Aug 2016 17:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 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.548, 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 siXdzpqeqVPk for ; Tue, 23 Aug 2016 17:19:37 -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 3720212D189 for ; Tue, 23 Aug 2016 17:19:37 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id 4so1434781oih.2 for ; Tue, 23 Aug 2016 17:19:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0jJN2F9sygK+t2QeRLNVPOL5Af6xgKxoian3wHW9MIg=; b=V5MwCOaMcB1kBt2kluoRVk+2RSPp5OW0HFPicUEPQf1F4GEc4DpBi42t1ytzpjadqM sOWn7t+UBeVhFEdgOImgJfpZNnoDmO8JnjYz+rJrbT8TT9hFNuavWGjCplVY+QSwHL2O 4jkSQTSKg8BARZQx7vNjyOfTYzHcrTwXH31XTMeh38Qo+2anfiVrKdam/kNg/ZPwxZGb YlSDERWrP9YX3e/XaJvs+ipKQ6jJZ70Dl4zluoIsVM9B8aML1YVwm5v9BaoXWymTiEBB r+bz449e0dJ0jB4FeoFRc5+67hjVIvPyOhZGbTQxmkyeWUH0EHa2uvtVSYt3BCUD6/El wkzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0jJN2F9sygK+t2QeRLNVPOL5Af6xgKxoian3wHW9MIg=; b=WpDlxhkHJm8VMvAwAcAdCRKpzihZiRdhH3W0jgSUNUhHNRTgbcjRM97dnXjnr7p4i6 v09hpJWIK2yn0e92vhxES53j8nWQOG07tkeoRAGUs3FQjIwfv/fFI2j1dpS7j3s67Cyb v7eApT4iws4rYbVP10ccmzxZklb72KeB9TRkFrjv2wvnDIVqbWRDYunK9kBs4cv6m3ol rPMxMf9g+iDOBT67jEkwI4eU2ilKAfAt/AaCBlioiM7WuCQzLb23xtwn+f1PvU7QivZK m+WLWKsBJ1dP/4rDOYcaFo+JRBSVDn+oLHNYmc5AllLFqJ6S7FkEX74YVCZJN85z5ZoS QUeQ== X-Gm-Message-State: AEkoouuAbUC0EL6epbkw2J4D0USGD9yc/lpI0Jmp4XNEq+dqsaoJJh+qZpP0XAXVhblTPjIkfXq1Cje5TiSkpIre X-Received: by 10.157.20.173 with SMTP id d42mr133564ote.104.1471997976436; Tue, 23 Aug 2016 17:19:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.37.140 with HTTP; Tue, 23 Aug 2016 17:19:35 -0700 (PDT) In-Reply-To: <9b51616c-2540-d8ec-61b0-2dcc6d6a29ea@tana.it> References: <20160813023957.5679.qmail@ary.lan> <20160813150004.GM10626@thunk.org> <2561d946-b853-4dd2-5aba-921bd88f99ba@dcrocker.net> <655339a0-54eb-4d84-f407-8aea3a822cc3@tana.it> <4a3c08f4-8fa5-efcc-f70a-cc9ec98d01b5@tana.it> <9b51616c-2540-d8ec-61b0-2dcc6d6a29ea@tana.it> From: Brandon Long Date: Tue, 23 Aug 2016 17:19:35 -0700 Message-ID: To: Alessandro Vesely Content-Type: multipart/alternative; boundary=001a113e26cc7f34e5053ac63cdb Archived-At: Cc: dmarc-ietf Subject: Re: [dmarc-ietf] ARC and weak signatures (again) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 00:19:40 -0000 --001a113e26cc7f34e5053ac63cdb Content-Type: text/plain; charset=UTF-8 On Tue, Aug 23, 2016 at 11:55 AM, Alessandro Vesely wrote: > On Tue 23/Aug/2016 02:07:24 +0200 Brandon Long wrote: > >> On Sat, Aug 20, 2016 at 4:02 AM, Alessandro Vesely >> wrote: >> >> >>> Say A -> B -> C are the MTAs: C sees a message where B is cited in the >>> To: or Cc: header fields. The message is ARC signed by B. B says A's >>> DKIM signature was good, but now it is broken. A's DMARC policy says >>> that C should reject in that case. What should C do? >>> >>> If C is gmail, it likely has sufficient history to know how A and B >>> behave. But what about small MTAs whose email flow is statistically not >>> enough to use combinatorial trust assessments? >>> >> >> If your MTA is too small to use combinatorial trust assessments, then you >> are stuck with the same two options you have today: manual whitelists or >> using a service to give you that information. >> >> If you're small enough, I don't think manually whitelisting the mailing >> list >> servers your users are subscribed to would be that challenging, especially >> if you receive the DMARC reports your server generates. >> > > I can configure my filter to accept DMARC-failed messages from > authenticated domains which are trusted MLMs. Even if I only see 20~30 new > mail domains each day, I'm not going to manually look for names which seem > to be lists. > > A two-step heuristic to determine trusted MLMs consists of (1) collect > domain names from received List-Post: header fields matching , > and authenticated (via SPF, DKIM, or DNSWL), and then (2) from the domains > collected that way, select those that my users write to. _Small domains_ > --by definition, for the scope of this discussion-- have no anonymous users. > > That heuristics keeps failing until a subscribed user actually posts to a > MLM. Skipping step (2) makes it an obvious attack path, but whitelisting > can mitigate it a bit. > > How can aggregate reports help here? Would you please expand? aggregate reports you send to others would tell you about posts you were rejecting. And I guess it depends on what "small" means, if you're seeing 20-30 new domains a day that are lists and you're rejecting for DMARC, then yes, that may be beyond the ability to whitelist. If you were actually seeing 20-30 whiitelistable mailing list domains a day, I think you might get >90% of them in a couple months. Ok, that's not true, Google Apps allows domains to have mailing lists, but that's probably the bulk of them... but they'll all be ARC signed by the same provider (google.com). O365 may also have a ton, but again, probably whitelistable as a single entity. > If A had added a second DKIM signature, signing just the To: or Cc: >>> field(s) which cited B, with l=0 for the body, then that signature >>> likely survived B's fixing and hence C could infer that B is a true (not >>> self-styled) forwarder. IOW, A's second (weak) signature provides C >>> with a formal criterion to instruct its local policy to accept email >>> that fails the DMARC mechanism check even if A has published a "reject" >>> policy. >>> >>> So, what I called ARC-0 in my former proposal, doesn't really have much >>> to do with ARC. The concept is weak signatures. Of course, they won't >>> work unless carefully standardized and implemented. The question is if >>> they will ever work at all, and if this WG is willing to consider them. >>> If not, we need to address Dave's concern some other way, or resign >>> ourselves to building a solution which will likely work 98.7% for some >>> and 0.2% for others. >>> >> >> So, any message sent from A to B can then be used as a replay with any >> content to any party as long as the To/Cc are intact? That seems pretty >> useless. >> > > Yes, B can send whatever they like using your name@A. That's how weak > signatures work. Of course, valuable domains such as banks and other phish > targets should never use them. Our task here is to better indirect flows, > not counter phishing. Anyway, regular domains may want to weak-sign only > the copy of a message addressed to a trusted MLM. Bumping DKIM version was > proposed as a means to have C also require a valid signature of B. Some > receivers already use local policies to limit the shape of DKIM-Signatures > they accept; for example, some regard signatures with l=0 as invalid. > Smart C-role verifiers may want to match B to To: or Cc: before accepting > weak signatures. > > I'd put weak signatures when I play A. That way I'd complement the above > technique, trusted MLMs whitelisting, which I'd use when I play C. An > additional element would be to have B save From:. In fact, A's weak h= > should not include From:, because rewriting From: currently seems to be the > best anti-DMARC workaround. B would save the value of From: using a new > header field name, e.g., say, Original-From:, Authenticated-From:, or > ARC-From: for daisy chaining (vote for one). Finally, C may consider the > presence of this new field to confirm A's role, and possibly fix From:. In > those cases, a message passes if C is either smart or dumb, not somewhere > in between. DKIM v=2 would eliminate the "dumb" side. > But you're still whitelisting MLMs in C, or even possibly in A in this scenario. If I were clever, I would list all possible statuses of A, B, and C (such > as complying with DKIM, DMARC and ARC, applying or recognizing weak > signatures, being aware of either DKIM v=2 or the new header field, et > cetera) along with the relative probabilities that they are implemented at > various stages in time, and then compute the chances that C can pass/reject > correctly in the two cases of B being white or black, at each stage. I > reckon there are cases of A unknown to C, perhaps because either is small, > where some mixes of the above techniques would save the day, thereby > encouraging more small domains to publish strict DMARC policies, don't you > think? > I'm not sure if that's a goal. Brandon > > Ale > -- > > > > > > > --001a113e26cc7f34e5053ac63cdb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Aug 23, 2016 at 11:55 AM, Alessandro Vesely &= lt;vesely@tana.it&g= t; wrote:
On Tue = 23/Aug/2016 02:07:24 +0200 Brandon Long wrote:
On Sat, Aug 20, 2016 at 4:02 AM, Alessandro Vesely <vesely@tana.it> wrote:


Say A -> B -> C are the MTAs:=C2=A0 C sees a message where B is cited= in the
To: or Cc: header fields.=C2=A0 The message is ARC signed by B.=C2=A0 B say= s A's
DKIM signature was good, but now it is broken.=C2=A0 A's DMARC policy s= ays
that C should reject in that case.=C2=A0 What should C do?

If C is gmail, it likely has sufficient history to know how A and B
behave.=C2=A0 But what about small MTAs whose email flow is statistically n= ot
enough to use combinatorial trust assessments?

If your MTA is too small to use combinatorial trust assessments, then you are stuck with the same two options you have today: manual whitelists or using a service to give you that information.

If you're small enough, I don't think manually whitelisting the mai= ling list
servers your users are subscribed to would be that challenging, especially<= br> if you receive the DMARC reports your server generates.

I can configure my filter to accept DMARC-failed messages from authenticate= d domains which are trusted MLMs.=C2=A0 Even if I only see 20~30 new mail d= omains each day, I'm not going to manually look for names which seem to= be lists.

A two-step heuristic to determine trusted MLMs consists of (1) collect doma= in names from received List-Post: header fields matching <mailto:*@*.*&g= t;, and authenticated (via SPF, DKIM, or DNSWL), and then (2) from the doma= ins collected that way, select those that my users write to.=C2=A0 _Small d= omains_ --by definition, for the scope of this discussion-- have no anonymo= us users.

That heuristics keeps failing until a subscribed user actually posts to a M= LM. Skipping step (2) makes it an obvious attack path, but whitelisting can= mitigate it a bit.

How can aggregate reports help here?=C2=A0 Would you please expand?

aggregate reports you send to others would tell yo= u about posts you were rejecting.

And I guess it d= epends on what "small" means, if you're seeing 20-30 new doma= ins a day that are lists and you're rejecting for DMARC, then yes, that= may be beyond the ability to whitelist.

If you we= re actually seeing 20-30 whiitelistable mailing list domains a day, I think= you might get >90% of them in a couple months.

Ok, that's not true, Google Apps allows domains to have mailing lists,= but that's probably the bulk of them... but they'll all be ARC sig= ned by the same provider (google.com).=C2= =A0 O365 may also have a ton, but again, probably whitelistable as a single= entity.
=C2=A0
If A had added a second DKIM signature, signing just the To: or Cc:
field(s) which cited B, with l=3D0 for the body, then that signature
likely survived B's fixing and hence C could infer that B is a true (no= t
self-styled) forwarder.=C2=A0 IOW, A's second (weak) signature provides= C
with a formal criterion to instruct its local policy to accept email
that fails the DMARC mechanism check even if A has published a "reject= "
policy.

So, what I called ARC-0 in my former proposal, doesn't really have much=
to do with ARC.=C2=A0 The concept is weak signatures.=C2=A0 Of course, they= won't
work unless carefully standardized and implemented.=C2=A0 The question is i= f
they will ever work at all, and if this WG is willing to consider them.
If not, we need to address Dave's concern some other way, or resign
ourselves to building a solution which will likely work 98.7% for some
and 0.2% for others.

So, any message sent from A to B can then be used as a replay with any
content to any party as long as the To/Cc are intact?=C2=A0 That seems pret= ty
useless.

 Yes, B can send whatever they like using your name@A.=C2=A0 That's how = weak signatures work.=C2=A0 Of course, valuable domains such as banks and o= ther phish targets should never use them.=C2=A0 Our task here is to better = indirect flows, not counter phishing.=C2=A0 Anyway, regular domains may wan= t to weak-sign only the copy of a message addressed to a trusted MLM.=C2=A0= Bumping DKIM version was proposed as a means to have C also require a vali= d signature of B.=C2=A0 Some receivers already use local policies to limit = the shape of DKIM-Signatures they accept; for example, some regard signatur= es with l=3D0 as invalid.=C2=A0 Smart C-role verifiers may want to match B = to To: or Cc: before accepting weak signatures.

I'd put weak signatures when I play A.=C2=A0 That way I'd complemen= t the above technique, trusted MLMs whitelisting, which I'd use when I = play C.=C2=A0 An additional element would be to have B save From:.=C2=A0 In= fact, A's weak h=3D should not include From:, because rewriting From: = currently seems to be the best anti-DMARC workaround.=C2=A0 B would save th= e value of From: using a new header field name, e.g., say, Original-From:, = Authenticated-From:, or ARC-From: for daisy chaining (vote for one).=C2=A0 = Finally, C may consider the presence of this new field to confirm A's r= ole, and possibly fix From:.=C2=A0 In those cases, a message passes if C is= either smart or dumb, not somewhere in between.=C2=A0 DKIM v=3D2 would eli= minate the "dumb" side.

But y= ou're still whitelisting MLMs in C, or even possibly in A in this scena= rio.=C2=A0

If I were clever, I would list all possible statuses of A, B, and C (such a= s complying with DKIM, DMARC and ARC, applying or recognizing weak signatur= es, being aware of either DKIM v=3D2 or the new header field, et cetera) al= ong with the relative probabilities that they are implemented at various st= ages in time, and then compute the chances that C can pass/reject correctly= in the two cases of B being white or black, at each stage.=C2=A0 I reckon = there are cases of A unknown to C, perhaps because either is small, where s= ome mixes of the above techniques would save the day, thereby encouraging m= ore small domains to publish strict DMARC policies, don't you think?

I'm not sure if that's a goal.

Brandon
=C2=A0

Ale
--







--001a113e26cc7f34e5053ac63cdb-- From nobody Tue Aug 23 17:33:44 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47C8112DC1E for ; Tue, 23 Aug 2016 17:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URI_HEX=1.122] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=exchange.microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AbbFFou9tK1g for ; Tue, 23 Aug 2016 17:33:40 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0118.outbound.protection.outlook.com [104.47.37.118]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DD8012D5A4 for ; Tue, 23 Aug 2016 17:33:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=exchange.microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=U7wADmgPnoReyMVjZ6b8OO2MAnH87PH1jNUPj2VpBpE=; b=b+0CZQQaNnF7rsHzyoJIzLQLpSmybbBQxWX6WdJlmppR7QuFTUpJhymGotcMHo5ofJa0I2GzzRvLMzT9HXSrOCN0NKZi7VTc8eOukU6zElR1Z4/tGtlyfta27llMtSg0mVmGAcPWJYyPrBo0nRe4UKKIAJCj0HqZvIKaWg2M5O8= Received: from SN2PR00MB0111.namprd00.prod.outlook.com (10.167.20.134) by SN2PR00MB0110.namprd00.prod.outlook.com (10.167.20.138) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.613.0; Wed, 24 Aug 2016 00:33:38 +0000 Received: from SN2PR00MB0111.namprd00.prod.outlook.com ([10.167.20.134]) by SN2PR00MB0111.namprd00.prod.outlook.com ([10.167.20.134]) with mapi id 15.01.0612.000; Wed, 24 Aug 2016 00:33:39 +0000 From: Terry Zink To: dmarc-ietf Thread-Topic: [dmarc-ietf] ARC and weak signatures (again) Thread-Index: AQHR+tJZv7mUI1uOrUKBZJpJbwjHc6BVrwEAgAE7OgCAAFqCgIAAA8Pw Date: Wed, 24 Aug 2016 00:33:38 +0000 Message-ID: References: <20160813023957.5679.qmail@ary.lan> <20160813150004.GM10626@thunk.org> <2561d946-b853-4dd2-5aba-921bd88f99ba@dcrocker.net> <655339a0-54eb-4d84-f407-8aea3a822cc3@tana.it> <4a3c08f4-8fa5-efcc-f70a-cc9ec98d01b5@tana.it> <9b51616c-2540-d8ec-61b0-2dcc6d6a29ea@tana.it> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tzink@exchange.microsoft.com; x-originating-ip: [2001:4898:80e8:d::73d] x-ms-office365-filtering-correlation-id: 294f67a8-cd70-4af1-8237-08d3cbb64afb x-microsoft-exchange-diagnostics: 1; SN2PR00MB0110; 6:NWW6DyA41Lyr7q1CKKVpBp/JCMOR0/+nJWyuh0ji5DRHQoNWxQCc0UdCD4U6zk1nXw2Je2Shz+9AOp6xjObyedYXiN3w6uX3w7DHCLkklrift9HwWaCjpE44ofnc3Xd+4fF/k+9PkE1dKTui8hQAI6ukHhfhABoHV3rHMB7GejMEpIziid5PqXoaF+LowYNu/sUcR3ThzDK3XCKBcKomuW1JG2VI9fUr5Qc+RQU5dAwNnIa63pxgLHpd/OhUp+XK0p76O+Gej2Gv6l8ZHOwc2hGAOR1WpWoZa55dbIX+cAlMQriQDIAAQ4LWoo79P41VjVdjMOED/ePxYWuDLJQDCA==; 5:oK0rHgteT801wCNFV/BYoHLZiNrqvuy4hPw2QanQatA0Kcyx11DDT5Y3BoC15oV8mGnPP5d3CN9pkXu/AqeuTPECkM0uwmBVVGsITn0VuV212Ly+yQzFlYPQFuwxDB/2B+nYbBEzwThR9vFqda5/HQ==; 24:H0SyYUMiLv83kYencyMmSNWS3svD1lnKkjCFI2upR37h5LqHjHFmraoMvjDU8FabyXNlpYKx1Tsz+xwRqPwfzplpV/KLkKDsk3HInaezbcU=; 7:qwrh1t0sD9xuehApmoExzX2sJcK+LPzDh5GBh38TEPvv5j9dw6d6M5Q6R/O8zLIGhyrwyE6vevwKWqIPw+ZxoJP8j0TOAeW06qLnqzDTt3cXjNGZY/l/nw3holY/6iMHCeffuBr/zAN/wLp7DWrBbrzhM32UF2k6evm7koFzsFZ48KDAUlKQJ5T0FF4GRch1zmBVJhYsm1L7Eak/iAwNQi3SxBx86tiUj/EiBNDojLdNEmvMTrKbmRwJ2HkaFm2d x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN2PR00MB0110; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(20558992708506)(189930954265078)(211936372134217)(219752817060721)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:SN2PR00MB0110; BCL:0; PCL:0; RULEID:; SRVR:SN2PR00MB0110; x-forefront-prvs: 0044C17179 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(24454002)(199003)(52314003)(3905003)(377454003)(189002)(101416001)(15975445007)(99286002)(93886004)(77096005)(106356001)(54356999)(76176999)(50986999)(106116001)(105586002)(97736004)(19300405004)(8676002)(5660300001)(7736002)(7696003)(8990500004)(9686002)(8936002)(10090500001)(19609705001)(6116002)(2900100001)(2950100001)(19625215002)(74316002)(7906003)(68736007)(790700001)(7846002)(10290500002)(102836003)(3280700002)(19580395003)(122556002)(561944003)(3660700001)(2906002)(19580405001)(86362001)(81166006)(81156014)(5005710100001)(586003)(450100001)(87936001)(189998001)(33656002)(92566002)(16236675004)(10400500002)(110136002)(5002640100001)(76576001)(107886002)(19617315012)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR00MB0110; H:SN2PR00MB0111.namprd00.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: exchange.microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN2PR00MB0111A3637314C77A4CB2255396EA0SN2PR00MB0111namp_" MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Aug 2016 00:33:38.9032 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR00MB0110 Archived-At: Subject: Re: [dmarc-ietf] ARC and weak signatures (again) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 00:33:43 -0000 --_000_SN2PR00MB0111A3637314C77A4CB2255396EA0SN2PR00MB0111namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBPMzY1IG1heSBhbHNvIGhhdmUgYSB0b24sIGJ1dCBhZ2FpbiwgcHJvYmFibHkgd2hpdGVsaXN0 YWJsZSBhcyBhIHNpbmdsZSBlbnRpdHkNCg0KV2XigJlyZSB0cnlpbmcgdG8gZ2V0IHRoaXMgc2ln bmVkIGJ5IGdyb3Vwcy5vZmZpY2UubmV0Lg0KDQotLSBUZXJyeQ0KDQpGcm9tOiBkbWFyYyBbbWFp bHRvOmRtYXJjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCcmFuZG9uIExvbmcNClNl bnQ6IFR1ZXNkYXksIEF1Z3VzdCAyMywgMjAxNiA1OjIwIFBNDQpUbzogQWxlc3NhbmRybyBWZXNl bHkNCkNjOiBkbWFyYy1pZXRmDQpTdWJqZWN0OiBSZTogW2RtYXJjLWlldGZdIEFSQyBhbmQgd2Vh ayBzaWduYXR1cmVzIChhZ2FpbikNCg0KDQoNCk9uIFR1ZSwgQXVnIDIzLCAyMDE2IGF0IDExOjU1 IEFNLCBBbGVzc2FuZHJvIFZlc2VseSA8dmVzZWx5QHRhbmEuaXQ8bWFpbHRvOnZlc2VseUB0YW5h Lml0Pj4gd3JvdGU6DQpPbiBUdWUgMjMvQXVnLzIwMTYgMDI6MDc6MjQgKzAyMDAgQnJhbmRvbiBM b25nIHdyb3RlOg0KT24gU2F0LCBBdWcgMjAsIDIwMTYgYXQgNDowMiBBTSwgQWxlc3NhbmRybyBW ZXNlbHkgPHZlc2VseUB0YW5hLml0PG1haWx0bzp2ZXNlbHlAdGFuYS5pdD4+IHdyb3RlOg0KDQpT YXkgQSAtPiBCIC0+IEMgYXJlIHRoZSBNVEFzOiAgQyBzZWVzIGEgbWVzc2FnZSB3aGVyZSBCIGlz IGNpdGVkIGluIHRoZQ0KVG86IG9yIENjOiBoZWFkZXIgZmllbGRzLiAgVGhlIG1lc3NhZ2UgaXMg QVJDIHNpZ25lZCBieSBCLiAgQiBzYXlzIEEncw0KREtJTSBzaWduYXR1cmUgd2FzIGdvb2QsIGJ1 dCBub3cgaXQgaXMgYnJva2VuLiAgQSdzIERNQVJDIHBvbGljeSBzYXlzDQp0aGF0IEMgc2hvdWxk IHJlamVjdCBpbiB0aGF0IGNhc2UuICBXaGF0IHNob3VsZCBDIGRvPw0KDQpJZiBDIGlzIGdtYWls LCBpdCBsaWtlbHkgaGFzIHN1ZmZpY2llbnQgaGlzdG9yeSB0byBrbm93IGhvdyBBIGFuZCBCDQpi ZWhhdmUuICBCdXQgd2hhdCBhYm91dCBzbWFsbCBNVEFzIHdob3NlIGVtYWlsIGZsb3cgaXMgc3Rh dGlzdGljYWxseSBub3QNCmVub3VnaCB0byB1c2UgY29tYmluYXRvcmlhbCB0cnVzdCBhc3Nlc3Nt ZW50cz8NCg0KSWYgeW91ciBNVEEgaXMgdG9vIHNtYWxsIHRvIHVzZSBjb21iaW5hdG9yaWFsIHRy dXN0IGFzc2Vzc21lbnRzLCB0aGVuIHlvdQ0KYXJlIHN0dWNrIHdpdGggdGhlIHNhbWUgdHdvIG9w dGlvbnMgeW91IGhhdmUgdG9kYXk6IG1hbnVhbCB3aGl0ZWxpc3RzIG9yDQp1c2luZyBhIHNlcnZp Y2UgdG8gZ2l2ZSB5b3UgdGhhdCBpbmZvcm1hdGlvbi4NCg0KSWYgeW91J3JlIHNtYWxsIGVub3Vn aCwgSSBkb24ndCB0aGluayBtYW51YWxseSB3aGl0ZWxpc3RpbmcgdGhlIG1haWxpbmcgbGlzdA0K c2VydmVycyB5b3VyIHVzZXJzIGFyZSBzdWJzY3JpYmVkIHRvIHdvdWxkIGJlIHRoYXQgY2hhbGxl bmdpbmcsIGVzcGVjaWFsbHkNCmlmIHlvdSByZWNlaXZlIHRoZSBETUFSQyByZXBvcnRzIHlvdXIg c2VydmVyIGdlbmVyYXRlcy4NCg0KSSBjYW4gY29uZmlndXJlIG15IGZpbHRlciB0byBhY2NlcHQg RE1BUkMtZmFpbGVkIG1lc3NhZ2VzIGZyb20gYXV0aGVudGljYXRlZCBkb21haW5zIHdoaWNoIGFy ZSB0cnVzdGVkIE1MTXMuICBFdmVuIGlmIEkgb25seSBzZWUgMjB+MzAgbmV3IG1haWwgZG9tYWlu cyBlYWNoIGRheSwgSSdtIG5vdCBnb2luZyB0byBtYW51YWxseSBsb29rIGZvciBuYW1lcyB3aGlj aCBzZWVtIHRvIGJlIGxpc3RzLg0KDQpBIHR3by1zdGVwIGhldXJpc3RpYyB0byBkZXRlcm1pbmUg dHJ1c3RlZCBNTE1zIGNvbnNpc3RzIG9mICgxKSBjb2xsZWN0IGRvbWFpbiBuYW1lcyBmcm9tIHJl Y2VpdmVkIExpc3QtUG9zdDogaGVhZGVyIGZpZWxkcyBtYXRjaGluZyA8bWFpbHRvOipAKi4qPiwg YW5kIGF1dGhlbnRpY2F0ZWQgKHZpYSBTUEYsIERLSU0sIG9yIEROU1dMKSwgYW5kIHRoZW4gKDIp IGZyb20gdGhlIGRvbWFpbnMgY29sbGVjdGVkIHRoYXQgd2F5LCBzZWxlY3QgdGhvc2UgdGhhdCBt eSB1c2VycyB3cml0ZSB0by4gIF9TbWFsbCBkb21haW5zXyAtLWJ5IGRlZmluaXRpb24sIGZvciB0 aGUgc2NvcGUgb2YgdGhpcyBkaXNjdXNzaW9uLS0gaGF2ZSBubyBhbm9ueW1vdXMgdXNlcnMuDQoN ClRoYXQgaGV1cmlzdGljcyBrZWVwcyBmYWlsaW5nIHVudGlsIGEgc3Vic2NyaWJlZCB1c2VyIGFj dHVhbGx5IHBvc3RzIHRvIGEgTUxNLiBTa2lwcGluZyBzdGVwICgyKSBtYWtlcyBpdCBhbiBvYnZp b3VzIGF0dGFjayBwYXRoLCBidXQgd2hpdGVsaXN0aW5nIGNhbiBtaXRpZ2F0ZSBpdCBhIGJpdC4N Cg0KSG93IGNhbiBhZ2dyZWdhdGUgcmVwb3J0cyBoZWxwIGhlcmU/ICBXb3VsZCB5b3UgcGxlYXNl IGV4cGFuZD8NCg0KYWdncmVnYXRlIHJlcG9ydHMgeW91IHNlbmQgdG8gb3RoZXJzIHdvdWxkIHRl bGwgeW91IGFib3V0IHBvc3RzIHlvdSB3ZXJlIHJlamVjdGluZy4NCg0KQW5kIEkgZ3Vlc3MgaXQg ZGVwZW5kcyBvbiB3aGF0ICJzbWFsbCIgbWVhbnMsIGlmIHlvdSdyZSBzZWVpbmcgMjAtMzAgbmV3 IGRvbWFpbnMgYSBkYXkgdGhhdCBhcmUgbGlzdHMgYW5kIHlvdSdyZSByZWplY3RpbmcgZm9yIERN QVJDLCB0aGVuIHllcywgdGhhdCBtYXkgYmUgYmV5b25kIHRoZSBhYmlsaXR5IHRvIHdoaXRlbGlz dC4NCg0KSWYgeW91IHdlcmUgYWN0dWFsbHkgc2VlaW5nIDIwLTMwIHdoaWl0ZWxpc3RhYmxlIG1h aWxpbmcgbGlzdCBkb21haW5zIGEgZGF5LCBJIHRoaW5rIHlvdSBtaWdodCBnZXQgPjkwJSBvZiB0 aGVtIGluIGEgY291cGxlIG1vbnRocy4NCg0KT2ssIHRoYXQncyBub3QgdHJ1ZSwgR29vZ2xlIEFw cHMgYWxsb3dzIGRvbWFpbnMgdG8gaGF2ZSBtYWlsaW5nIGxpc3RzLCBidXQgdGhhdCdzIHByb2Jh Ymx5IHRoZSBidWxrIG9mIHRoZW0uLi4gYnV0IHRoZXknbGwgYWxsIGJlIEFSQyBzaWduZWQgYnkg dGhlIHNhbWUgcHJvdmlkZXIgKGdvb2dsZS5jb208aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90 ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzYSUyZiUyZmdvb2dsZS5jb20mZGF0YT0wMiU3 YzAxJTdjdHppbmslNDBleGNoYW5nZS5taWNyb3NvZnQuY29tJTdjNzIzZGU4NWNhZWM2NGZmZWIy ZDcwOGQzY2JiNDU4YTElN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzElN2Mw JTdjNjM2MDc1OTQ3ODQ3MDU1Mzc3JnNkYXRhPVhuU3huOEkybzZJUTRZR0N1ZjU1VW10S1VLdGFB YlZHdUhSJTJiQ2lydk1ocyUzZD4pLiAgTzM2NSBtYXkgYWxzbyBoYXZlIGEgdG9uLCBidXQgYWdh aW4sIHByb2JhYmx5IHdoaXRlbGlzdGFibGUgYXMgYSBzaW5nbGUgZW50aXR5Lg0KDQpJZiBBIGhh ZCBhZGRlZCBhIHNlY29uZCBES0lNIHNpZ25hdHVyZSwgc2lnbmluZyBqdXN0IHRoZSBUbzogb3Ig Q2M6DQpmaWVsZChzKSB3aGljaCBjaXRlZCBCLCB3aXRoIGw9MCBmb3IgdGhlIGJvZHksIHRoZW4g dGhhdCBzaWduYXR1cmUNCmxpa2VseSBzdXJ2aXZlZCBCJ3MgZml4aW5nIGFuZCBoZW5jZSBDIGNv dWxkIGluZmVyIHRoYXQgQiBpcyBhIHRydWUgKG5vdA0Kc2VsZi1zdHlsZWQpIGZvcndhcmRlci4g IElPVywgQSdzIHNlY29uZCAod2Vhaykgc2lnbmF0dXJlIHByb3ZpZGVzIEMNCndpdGggYSBmb3Jt YWwgY3JpdGVyaW9uIHRvIGluc3RydWN0IGl0cyBsb2NhbCBwb2xpY3kgdG8gYWNjZXB0IGVtYWls DQp0aGF0IGZhaWxzIHRoZSBETUFSQyBtZWNoYW5pc20gY2hlY2sgZXZlbiBpZiBBIGhhcyBwdWJs aXNoZWQgYSAicmVqZWN0Ig0KcG9saWN5Lg0KDQpTbywgd2hhdCBJIGNhbGxlZCBBUkMtMCBpbiBt eSBmb3JtZXIgcHJvcG9zYWwsIGRvZXNuJ3QgcmVhbGx5IGhhdmUgbXVjaA0KdG8gZG8gd2l0aCBB UkMuICBUaGUgY29uY2VwdCBpcyB3ZWFrIHNpZ25hdHVyZXMuICBPZiBjb3Vyc2UsIHRoZXkgd29u J3QNCndvcmsgdW5sZXNzIGNhcmVmdWxseSBzdGFuZGFyZGl6ZWQgYW5kIGltcGxlbWVudGVkLiAg VGhlIHF1ZXN0aW9uIGlzIGlmDQp0aGV5IHdpbGwgZXZlciB3b3JrIGF0IGFsbCwgYW5kIGlmIHRo aXMgV0cgaXMgd2lsbGluZyB0byBjb25zaWRlciB0aGVtLg0KSWYgbm90LCB3ZSBuZWVkIHRvIGFk ZHJlc3MgRGF2ZSdzIGNvbmNlcm4gc29tZSBvdGhlciB3YXksIG9yIHJlc2lnbg0Kb3Vyc2VsdmVz IHRvIGJ1aWxkaW5nIGEgc29sdXRpb24gd2hpY2ggd2lsbCBsaWtlbHkgd29yayA5OC43JSBmb3Ig c29tZQ0KYW5kIDAuMiUgZm9yIG90aGVycy4NCg0KU28sIGFueSBtZXNzYWdlIHNlbnQgZnJvbSBB IHRvIEIgY2FuIHRoZW4gYmUgdXNlZCBhcyBhIHJlcGxheSB3aXRoIGFueQ0KY29udGVudCB0byBh bnkgcGFydHkgYXMgbG9uZyBhcyB0aGUgVG8vQ2MgYXJlIGludGFjdD8gIFRoYXQgc2VlbXMgcHJl dHR5DQp1c2VsZXNzLg0KDQpZZXMsIEIgY2FuIHNlbmQgd2hhdGV2ZXIgdGhleSBsaWtlIHVzaW5n IHlvdXIgbmFtZUBBLiAgVGhhdCdzIGhvdyB3ZWFrIHNpZ25hdHVyZXMgd29yay4gIE9mIGNvdXJz ZSwgdmFsdWFibGUgZG9tYWlucyBzdWNoIGFzIGJhbmtzIGFuZCBvdGhlciBwaGlzaCB0YXJnZXRz IHNob3VsZCBuZXZlciB1c2UgdGhlbS4gIE91ciB0YXNrIGhlcmUgaXMgdG8gYmV0dGVyIGluZGly ZWN0IGZsb3dzLCBub3QgY291bnRlciBwaGlzaGluZy4gIEFueXdheSwgcmVndWxhciBkb21haW5z IG1heSB3YW50IHRvIHdlYWstc2lnbiBvbmx5IHRoZSBjb3B5IG9mIGEgbWVzc2FnZSBhZGRyZXNz ZWQgdG8gYSB0cnVzdGVkIE1MTS4gIEJ1bXBpbmcgREtJTSB2ZXJzaW9uIHdhcyBwcm9wb3NlZCBh cyBhIG1lYW5zIHRvIGhhdmUgQyBhbHNvIHJlcXVpcmUgYSB2YWxpZCBzaWduYXR1cmUgb2YgQi4g IFNvbWUgcmVjZWl2ZXJzIGFscmVhZHkgdXNlIGxvY2FsIHBvbGljaWVzIHRvIGxpbWl0IHRoZSBz aGFwZSBvZiBES0lNLVNpZ25hdHVyZXMgdGhleSBhY2NlcHQ7IGZvciBleGFtcGxlLCBzb21lIHJl Z2FyZCBzaWduYXR1cmVzIHdpdGggbD0wIGFzIGludmFsaWQuICBTbWFydCBDLXJvbGUgdmVyaWZp ZXJzIG1heSB3YW50IHRvIG1hdGNoIEIgdG8gVG86IG9yIENjOiBiZWZvcmUgYWNjZXB0aW5nIHdl YWsgc2lnbmF0dXJlcy4NCg0KSSdkIHB1dCB3ZWFrIHNpZ25hdHVyZXMgd2hlbiBJIHBsYXkgQS4g IFRoYXQgd2F5IEknZCBjb21wbGVtZW50IHRoZSBhYm92ZSB0ZWNobmlxdWUsIHRydXN0ZWQgTUxN cyB3aGl0ZWxpc3RpbmcsIHdoaWNoIEknZCB1c2Ugd2hlbiBJIHBsYXkgQy4gIEFuIGFkZGl0aW9u YWwgZWxlbWVudCB3b3VsZCBiZSB0byBoYXZlIEIgc2F2ZSBGcm9tOi4gIEluIGZhY3QsIEEncyB3 ZWFrIGg9IHNob3VsZCBub3QgaW5jbHVkZSBGcm9tOiwgYmVjYXVzZSByZXdyaXRpbmcgRnJvbTog Y3VycmVudGx5IHNlZW1zIHRvIGJlIHRoZSBiZXN0IGFudGktRE1BUkMgd29ya2Fyb3VuZC4gIEIg d291bGQgc2F2ZSB0aGUgdmFsdWUgb2YgRnJvbTogdXNpbmcgYSBuZXcgaGVhZGVyIGZpZWxkIG5h bWUsIGUuZy4sIHNheSwgT3JpZ2luYWwtRnJvbTosIEF1dGhlbnRpY2F0ZWQtRnJvbTosIG9yIEFS Qy1Gcm9tOiBmb3IgZGFpc3kgY2hhaW5pbmcgKHZvdGUgZm9yIG9uZSkuICBGaW5hbGx5LCBDIG1h eSBjb25zaWRlciB0aGUgcHJlc2VuY2Ugb2YgdGhpcyBuZXcgZmllbGQgdG8gY29uZmlybSBBJ3Mg cm9sZSwgYW5kIHBvc3NpYmx5IGZpeCBGcm9tOi4gIEluIHRob3NlIGNhc2VzLCBhIG1lc3NhZ2Ug cGFzc2VzIGlmIEMgaXMgZWl0aGVyIHNtYXJ0IG9yIGR1bWIsIG5vdCBzb21ld2hlcmUgaW4gYmV0 d2Vlbi4gIERLSU0gdj0yIHdvdWxkIGVsaW1pbmF0ZSB0aGUgImR1bWIiIHNpZGUuDQoNCkJ1dCB5 b3UncmUgc3RpbGwgd2hpdGVsaXN0aW5nIE1MTXMgaW4gQywgb3IgZXZlbiBwb3NzaWJseSBpbiBB IGluIHRoaXMgc2NlbmFyaW8uDQoNCklmIEkgd2VyZSBjbGV2ZXIsIEkgd291bGQgbGlzdCBhbGwg cG9zc2libGUgc3RhdHVzZXMgb2YgQSwgQiwgYW5kIEMgKHN1Y2ggYXMgY29tcGx5aW5nIHdpdGgg REtJTSwgRE1BUkMgYW5kIEFSQywgYXBwbHlpbmcgb3IgcmVjb2duaXppbmcgd2VhayBzaWduYXR1 cmVzLCBiZWluZyBhd2FyZSBvZiBlaXRoZXIgREtJTSB2PTIgb3IgdGhlIG5ldyBoZWFkZXIgZmll bGQsIGV0IGNldGVyYSkgYWxvbmcgd2l0aCB0aGUgcmVsYXRpdmUgcHJvYmFiaWxpdGllcyB0aGF0 IHRoZXkgYXJlIGltcGxlbWVudGVkIGF0IHZhcmlvdXMgc3RhZ2VzIGluIHRpbWUsIGFuZCB0aGVu IGNvbXB1dGUgdGhlIGNoYW5jZXMgdGhhdCBDIGNhbiBwYXNzL3JlamVjdCBjb3JyZWN0bHkgaW4g dGhlIHR3byBjYXNlcyBvZiBCIGJlaW5nIHdoaXRlIG9yIGJsYWNrLCBhdCBlYWNoIHN0YWdlLiAg SSByZWNrb24gdGhlcmUgYXJlIGNhc2VzIG9mIEEgdW5rbm93biB0byBDLCBwZXJoYXBzIGJlY2F1 c2UgZWl0aGVyIGlzIHNtYWxsLCB3aGVyZSBzb21lIG1peGVzIG9mIHRoZSBhYm92ZSB0ZWNobmlx dWVzIHdvdWxkIHNhdmUgdGhlIGRheSwgdGhlcmVieSBlbmNvdXJhZ2luZyBtb3JlIHNtYWxsIGRv bWFpbnMgdG8gcHVibGlzaCBzdHJpY3QgRE1BUkMgcG9saWNpZXMsIGRvbid0IHlvdSB0aGluaz8N Cg0KSSdtIG5vdCBzdXJlIGlmIHRoYXQncyBhIGdvYWwuDQoNCkJyYW5kb24NCg0KDQpBbGUNCi0t DQoNCg0KDQoNCg0KDQo= --_000_SN2PR00MB0111A3637314C77A4CB2255396EA0SN2PR00MB0111namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFw aCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxl LXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFy Z2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwi c2VyaWYiO30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVt YWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPiZndDsgTzM2NSBtYXkgYWxz byBoYXZlIGEgdG9uLCBidXQgYWdhaW4sIHByb2JhYmx5IHdoaXRlbGlzdGFibGUgYXMgYSBzaW5n bGUgZW50aXR5PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPldl4oCZcmUgdHJ5aW5nIHRvIGdldCB0aGlzIHNpZ25lZCBieSBncm91cHMub2ZmaWNlLm5l dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+LS0gVGVycnk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+IGRtYXJjIFttYWlsdG86ZG1hcmMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBP ZiA8L2I+QnJhbmRvbiBMb25nPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEF1Z3VzdCAyMywg MjAxNiA1OjIwIFBNPGJyPg0KPGI+VG86PC9iPiBBbGVzc2FuZHJvIFZlc2VseTxicj4NCjxiPkNj OjwvYj4gZG1hcmMtaWV0Zjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2RtYXJjLWlldGZdIEFS QyBhbmQgd2VhayBzaWduYXR1cmVzIChhZ2Fpbik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P biBUdWUsIEF1ZyAyMywgMjAxNiBhdCAxMTo1NSBBTSwgQWxlc3NhbmRybyBWZXNlbHkgJmx0Ozxh IGhyZWY9Im1haWx0bzp2ZXNlbHlAdGFuYS5pdCIgdGFyZ2V0PSJfYmxhbmsiPnZlc2VseUB0YW5h Lml0PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T24gVHVlIDIzL0F1Zy8yMDE2IDAyOjA3OjI0ICYjNDM7MDIwMCBCcmFuZG9u IExvbmcgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5PbiBTYXQsIEF1ZyAyMCwgMjAxNiBh dCA0OjAyIEFNLCBBbGVzc2FuZHJvIFZlc2VseSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZlc2VseUB0 YW5hLml0IiB0YXJnZXQ9Il9ibGFuayI+dmVzZWx5QHRhbmEuaXQ8L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpTYXkg QSAtJmd0OyBCIC0mZ3Q7IEMgYXJlIHRoZSBNVEFzOiZuYnNwOyBDIHNlZXMgYSBtZXNzYWdlIHdo ZXJlIEIgaXMgY2l0ZWQgaW4gdGhlPGJyPg0KVG86IG9yIENjOiBoZWFkZXIgZmllbGRzLiZuYnNw OyBUaGUgbWVzc2FnZSBpcyBBUkMgc2lnbmVkIGJ5IEIuJm5ic3A7IEIgc2F5cyBBJ3M8YnI+DQpE S0lNIHNpZ25hdHVyZSB3YXMgZ29vZCwgYnV0IG5vdyBpdCBpcyBicm9rZW4uJm5ic3A7IEEncyBE TUFSQyBwb2xpY3kgc2F5czxicj4NCnRoYXQgQyBzaG91bGQgcmVqZWN0IGluIHRoYXQgY2FzZS4m bmJzcDsgV2hhdCBzaG91bGQgQyBkbz88YnI+DQo8YnI+DQpJZiBDIGlzIGdtYWlsLCBpdCBsaWtl bHkgaGFzIHN1ZmZpY2llbnQgaGlzdG9yeSB0byBrbm93IGhvdyBBIGFuZCBCPGJyPg0KYmVoYXZl LiZuYnNwOyBCdXQgd2hhdCBhYm91dCBzbWFsbCBNVEFzIHdob3NlIGVtYWlsIGZsb3cgaXMgc3Rh dGlzdGljYWxseSBub3Q8YnI+DQplbm91Z2ggdG8gdXNlIGNvbWJpbmF0b3JpYWwgdHJ1c3QgYXNz ZXNzbWVudHM/PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YnI+DQpJZiB5b3VyIE1UQSBpcyB0b28gc21hbGwgdG8gdXNlIGNvbWJpbmF0b3JpYWwg dHJ1c3QgYXNzZXNzbWVudHMsIHRoZW4geW91PGJyPg0KYXJlIHN0dWNrIHdpdGggdGhlIHNhbWUg dHdvIG9wdGlvbnMgeW91IGhhdmUgdG9kYXk6IG1hbnVhbCB3aGl0ZWxpc3RzIG9yPGJyPg0KdXNp bmcgYSBzZXJ2aWNlIHRvIGdpdmUgeW91IHRoYXQgaW5mb3JtYXRpb24uPGJyPg0KPGJyPg0KSWYg eW91J3JlIHNtYWxsIGVub3VnaCwgSSBkb24ndCB0aGluayBtYW51YWxseSB3aGl0ZWxpc3Rpbmcg dGhlIG1haWxpbmcgbGlzdDxicj4NCnNlcnZlcnMgeW91ciB1c2VycyBhcmUgc3Vic2NyaWJlZCB0 byB3b3VsZCBiZSB0aGF0IGNoYWxsZW5naW5nLCBlc3BlY2lhbGx5PGJyPg0KaWYgeW91IHJlY2Vp dmUgdGhlIERNQVJDIHJlcG9ydHMgeW91ciBzZXJ2ZXIgZ2VuZXJhdGVzLjxvOnA+PC9vOnA+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KSSBjYW4gY29uZmln dXJlIG15IGZpbHRlciB0byBhY2NlcHQgRE1BUkMtZmFpbGVkIG1lc3NhZ2VzIGZyb20gYXV0aGVu dGljYXRlZCBkb21haW5zIHdoaWNoIGFyZSB0cnVzdGVkIE1MTXMuJm5ic3A7IEV2ZW4gaWYgSSBv bmx5IHNlZSAyMH4zMCBuZXcgbWFpbCBkb21haW5zIGVhY2ggZGF5LCBJJ20gbm90IGdvaW5nIHRv IG1hbnVhbGx5IGxvb2sgZm9yIG5hbWVzIHdoaWNoIHNlZW0gdG8gYmUgbGlzdHMuPGJyPg0KPGJy Pg0KQSB0d28tc3RlcCBoZXVyaXN0aWMgdG8gZGV0ZXJtaW5lIHRydXN0ZWQgTUxNcyBjb25zaXN0 cyBvZiAoMSkgY29sbGVjdCBkb21haW4gbmFtZXMgZnJvbSByZWNlaXZlZCBMaXN0LVBvc3Q6IGhl YWRlciBmaWVsZHMgbWF0Y2hpbmcgJmx0OzxhIGhyZWY9Im1haWx0bzoqQCouKiI+bWFpbHRvOipA Ki4qPC9hPiZndDssIGFuZCBhdXRoZW50aWNhdGVkICh2aWEgU1BGLCBES0lNLCBvciBETlNXTCks IGFuZCB0aGVuICgyKSBmcm9tIHRoZSBkb21haW5zIGNvbGxlY3RlZA0KIHRoYXQgd2F5LCBzZWxl Y3QgdGhvc2UgdGhhdCBteSB1c2VycyB3cml0ZSB0by4mbmJzcDsgX1NtYWxsIGRvbWFpbnNfIC0t YnkgZGVmaW5pdGlvbiwgZm9yIHRoZSBzY29wZSBvZiB0aGlzIGRpc2N1c3Npb24tLSBoYXZlIG5v IGFub255bW91cyB1c2Vycy48YnI+DQo8YnI+DQpUaGF0IGhldXJpc3RpY3Mga2VlcHMgZmFpbGlu ZyB1bnRpbCBhIHN1YnNjcmliZWQgdXNlciBhY3R1YWxseSBwb3N0cyB0byBhIE1MTS4gU2tpcHBp bmcgc3RlcCAoMikgbWFrZXMgaXQgYW4gb2J2aW91cyBhdHRhY2sgcGF0aCwgYnV0IHdoaXRlbGlz dGluZyBjYW4gbWl0aWdhdGUgaXQgYSBiaXQuPGJyPg0KPGJyPg0KSG93IGNhbiBhZ2dyZWdhdGUg cmVwb3J0cyBoZWxwIGhlcmU/Jm5ic3A7IFdvdWxkIHlvdSBwbGVhc2UgZXhwYW5kPzxvOnA+PC9v OnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YWdn cmVnYXRlIHJlcG9ydHMgeW91IHNlbmQgdG8gb3RoZXJzIHdvdWxkIHRlbGwgeW91IGFib3V0IHBv c3RzIHlvdSB3ZXJlIHJlamVjdGluZy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5kIEkgZ3Vlc3MgaXQgZGVwZW5kcyBvbiB3aGF0ICZxdW90 O3NtYWxsJnF1b3Q7IG1lYW5zLCBpZiB5b3UncmUgc2VlaW5nIDIwLTMwIG5ldyBkb21haW5zIGEg ZGF5IHRoYXQgYXJlIGxpc3RzIGFuZCB5b3UncmUgcmVqZWN0aW5nIGZvciBETUFSQywgdGhlbiB5 ZXMsIHRoYXQgbWF5IGJlIGJleW9uZCB0aGUgYWJpbGl0eSB0byB3aGl0ZWxpc3QuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHlvdSB3ZXJl IGFjdHVhbGx5IHNlZWluZyAyMC0zMCB3aGlpdGVsaXN0YWJsZSBtYWlsaW5nIGxpc3QgZG9tYWlu cyBhIGRheSwgSSB0aGluayB5b3UgbWlnaHQgZ2V0ICZndDs5MCUgb2YgdGhlbSBpbiBhIGNvdXBs ZSBtb250aHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9rLCB0aGF0J3Mgbm90IHRydWUsIEdvb2dsZSBBcHBzIGFsbG93cyBkb21haW5zIHRv IGhhdmUgbWFpbGluZyBsaXN0cywgYnV0IHRoYXQncyBwcm9iYWJseSB0aGUgYnVsayBvZiB0aGVt Li4uIGJ1dCB0aGV5J2xsIGFsbCBiZSBBUkMgc2lnbmVkIGJ5IHRoZSBzYW1lIHByb3ZpZGVyICg8 YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3Vy bD1odHRwJTNhJTJmJTJmZ29vZ2xlLmNvbSZhbXA7ZGF0YT0wMiU3YzAxJTdjdHppbmslNDBleGNo YW5nZS5taWNyb3NvZnQuY29tJTdjNzIzZGU4NWNhZWM2NGZmZWIyZDcwOGQzY2JiNDU4YTElN2M3 MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzElN2MwJTdjNjM2MDc1OTQ3ODQ3MDU1 Mzc3JmFtcDtzZGF0YT1YblN4bjhJMm82SVE0WUdDdWY1NVVtdEtVS3RhQWJWR3VIUiUyYkNpcnZN aHMlM2QiPmdvb2dsZS5jb208L2E+KS4mbmJzcDsNCiBPMzY1IG1heSBhbHNvIGhhdmUgYSB0b24s IGJ1dCBhZ2FpbiwgcHJvYmFibHkgd2hpdGVsaXN0YWJsZSBhcyBhIHNpbmdsZSBlbnRpdHkuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgQSBoYWQgYWRkZWQgYSBzZWNvbmQgREtJTSBz aWduYXR1cmUsIHNpZ25pbmcganVzdCB0aGUgVG86IG9yIENjOjxicj4NCmZpZWxkKHMpIHdoaWNo IGNpdGVkIEIsIHdpdGggbD0wIGZvciB0aGUgYm9keSwgdGhlbiB0aGF0IHNpZ25hdHVyZTxicj4N Cmxpa2VseSBzdXJ2aXZlZCBCJ3MgZml4aW5nIGFuZCBoZW5jZSBDIGNvdWxkIGluZmVyIHRoYXQg QiBpcyBhIHRydWUgKG5vdDxicj4NCnNlbGYtc3R5bGVkKSBmb3J3YXJkZXIuJm5ic3A7IElPVywg QSdzIHNlY29uZCAod2Vhaykgc2lnbmF0dXJlIHByb3ZpZGVzIEM8YnI+DQp3aXRoIGEgZm9ybWFs IGNyaXRlcmlvbiB0byBpbnN0cnVjdCBpdHMgbG9jYWwgcG9saWN5IHRvIGFjY2VwdCBlbWFpbDxi cj4NCnRoYXQgZmFpbHMgdGhlIERNQVJDIG1lY2hhbmlzbSBjaGVjayBldmVuIGlmIEEgaGFzIHB1 Ymxpc2hlZCBhICZxdW90O3JlamVjdCZxdW90Ozxicj4NCnBvbGljeS48YnI+DQo8YnI+DQpTbywg d2hhdCBJIGNhbGxlZCBBUkMtMCBpbiBteSBmb3JtZXIgcHJvcG9zYWwsIGRvZXNuJ3QgcmVhbGx5 IGhhdmUgbXVjaDxicj4NCnRvIGRvIHdpdGggQVJDLiZuYnNwOyBUaGUgY29uY2VwdCBpcyB3ZWFr IHNpZ25hdHVyZXMuJm5ic3A7IE9mIGNvdXJzZSwgdGhleSB3b24ndDxicj4NCndvcmsgdW5sZXNz IGNhcmVmdWxseSBzdGFuZGFyZGl6ZWQgYW5kIGltcGxlbWVudGVkLiZuYnNwOyBUaGUgcXVlc3Rp b24gaXMgaWY8YnI+DQp0aGV5IHdpbGwgZXZlciB3b3JrIGF0IGFsbCwgYW5kIGlmIHRoaXMgV0cg aXMgd2lsbGluZyB0byBjb25zaWRlciB0aGVtLjxicj4NCklmIG5vdCwgd2UgbmVlZCB0byBhZGRy ZXNzIERhdmUncyBjb25jZXJuIHNvbWUgb3RoZXIgd2F5LCBvciByZXNpZ248YnI+DQpvdXJzZWx2 ZXMgdG8gYnVpbGRpbmcgYSBzb2x1dGlvbiB3aGljaCB3aWxsIGxpa2VseSB3b3JrIDk4LjclIGZv ciBzb21lPGJyPg0KYW5kIDAuMiUgZm9yIG90aGVycy48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NClNvLCBhbnkgbWVzc2FnZSBzZW50IGZy b20gQSB0byBCIGNhbiB0aGVuIGJlIHVzZWQgYXMgYSByZXBsYXkgd2l0aCBhbnk8YnI+DQpjb250 ZW50IHRvIGFueSBwYXJ0eSBhcyBsb25nIGFzIHRoZSBUby9DYyBhcmUgaW50YWN0PyZuYnNwOyBU aGF0IHNlZW1zIHByZXR0eTxicj4NCnVzZWxlc3MuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpZZXMsIEIgY2FuIHNlbmQgd2hhdGV2ZXIg dGhleSBsaWtlIHVzaW5nIHlvdXIgbmFtZUBBLiZuYnNwOyBUaGF0J3MgaG93IHdlYWsgc2lnbmF0 dXJlcyB3b3JrLiZuYnNwOyBPZiBjb3Vyc2UsIHZhbHVhYmxlIGRvbWFpbnMgc3VjaCBhcyBiYW5r cyBhbmQgb3RoZXIgcGhpc2ggdGFyZ2V0cyBzaG91bGQgbmV2ZXIgdXNlIHRoZW0uJm5ic3A7IE91 ciB0YXNrIGhlcmUgaXMgdG8gYmV0dGVyIGluZGlyZWN0IGZsb3dzLCBub3QgY291bnRlciBwaGlz aGluZy4mbmJzcDsgQW55d2F5LCByZWd1bGFyDQogZG9tYWlucyBtYXkgd2FudCB0byB3ZWFrLXNp Z24gb25seSB0aGUgY29weSBvZiBhIG1lc3NhZ2UgYWRkcmVzc2VkIHRvIGEgdHJ1c3RlZCBNTE0u Jm5ic3A7IEJ1bXBpbmcgREtJTSB2ZXJzaW9uIHdhcyBwcm9wb3NlZCBhcyBhIG1lYW5zIHRvIGhh dmUgQyBhbHNvIHJlcXVpcmUgYSB2YWxpZCBzaWduYXR1cmUgb2YgQi4mbmJzcDsgU29tZSByZWNl aXZlcnMgYWxyZWFkeSB1c2UgbG9jYWwgcG9saWNpZXMgdG8gbGltaXQgdGhlIHNoYXBlIG9mIERL SU0tU2lnbmF0dXJlcw0KIHRoZXkgYWNjZXB0OyBmb3IgZXhhbXBsZSwgc29tZSByZWdhcmQgc2ln bmF0dXJlcyB3aXRoIGw9MCBhcyBpbnZhbGlkLiZuYnNwOyBTbWFydCBDLXJvbGUgdmVyaWZpZXJz IG1heSB3YW50IHRvIG1hdGNoIEIgdG8gVG86IG9yIENjOiBiZWZvcmUgYWNjZXB0aW5nIHdlYWsg c2lnbmF0dXJlcy48YnI+DQo8YnI+DQpJJ2QgcHV0IHdlYWsgc2lnbmF0dXJlcyB3aGVuIEkgcGxh eSBBLiZuYnNwOyBUaGF0IHdheSBJJ2QgY29tcGxlbWVudCB0aGUgYWJvdmUgdGVjaG5pcXVlLCB0 cnVzdGVkIE1MTXMgd2hpdGVsaXN0aW5nLCB3aGljaCBJJ2QgdXNlIHdoZW4gSSBwbGF5IEMuJm5i c3A7IEFuIGFkZGl0aW9uYWwgZWxlbWVudCB3b3VsZCBiZSB0byBoYXZlIEIgc2F2ZSBGcm9tOi4m bmJzcDsgSW4gZmFjdCwgQSdzIHdlYWsgaD0gc2hvdWxkIG5vdCBpbmNsdWRlIEZyb206LCBiZWNh dXNlIHJld3JpdGluZw0KIEZyb206IGN1cnJlbnRseSBzZWVtcyB0byBiZSB0aGUgYmVzdCBhbnRp LURNQVJDIHdvcmthcm91bmQuJm5ic3A7IEIgd291bGQgc2F2ZSB0aGUgdmFsdWUgb2YgRnJvbTog dXNpbmcgYSBuZXcgaGVhZGVyIGZpZWxkIG5hbWUsIGUuZy4sIHNheSwgT3JpZ2luYWwtRnJvbTos IEF1dGhlbnRpY2F0ZWQtRnJvbTosIG9yIEFSQy1Gcm9tOiBmb3IgZGFpc3kgY2hhaW5pbmcgKHZv dGUgZm9yIG9uZSkuJm5ic3A7IEZpbmFsbHksIEMgbWF5IGNvbnNpZGVyIHRoZSBwcmVzZW5jZQ0K IG9mIHRoaXMgbmV3IGZpZWxkIHRvIGNvbmZpcm0gQSdzIHJvbGUsIGFuZCBwb3NzaWJseSBmaXgg RnJvbTouJm5ic3A7IEluIHRob3NlIGNhc2VzLCBhIG1lc3NhZ2UgcGFzc2VzIGlmIEMgaXMgZWl0 aGVyIHNtYXJ0IG9yIGR1bWIsIG5vdCBzb21ld2hlcmUgaW4gYmV0d2Vlbi4mbmJzcDsgREtJTSB2 PTIgd291bGQgZWxpbWluYXRlIHRoZSAmcXVvdDtkdW1iJnF1b3Q7IHNpZGUuPG86cD48L286cD48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CdXQgeW91 J3JlIHN0aWxsIHdoaXRlbGlzdGluZyBNTE1zIGluIEMsIG9yIGV2ZW4gcG9zc2libHkgaW4gQSBp biB0aGlzIHNjZW5hcmlvLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiBJIHdlcmUgY2xldmVyLCBJIHdvdWxkIGxpc3Qg YWxsIHBvc3NpYmxlIHN0YXR1c2VzIG9mIEEsIEIsIGFuZCBDIChzdWNoIGFzIGNvbXBseWluZyB3 aXRoIERLSU0sIERNQVJDIGFuZCBBUkMsIGFwcGx5aW5nIG9yIHJlY29nbml6aW5nIHdlYWsgc2ln bmF0dXJlcywgYmVpbmcgYXdhcmUgb2YgZWl0aGVyIERLSU0gdj0yIG9yIHRoZSBuZXcgaGVhZGVy IGZpZWxkLCBldCBjZXRlcmEpIGFsb25nIHdpdGggdGhlDQogcmVsYXRpdmUgcHJvYmFiaWxpdGll cyB0aGF0IHRoZXkgYXJlIGltcGxlbWVudGVkIGF0IHZhcmlvdXMgc3RhZ2VzIGluIHRpbWUsIGFu ZCB0aGVuIGNvbXB1dGUgdGhlIGNoYW5jZXMgdGhhdCBDIGNhbiBwYXNzL3JlamVjdCBjb3JyZWN0 bHkgaW4gdGhlIHR3byBjYXNlcyBvZiBCIGJlaW5nIHdoaXRlIG9yIGJsYWNrLCBhdCBlYWNoIHN0 YWdlLiZuYnNwOyBJIHJlY2tvbiB0aGVyZSBhcmUgY2FzZXMgb2YgQSB1bmtub3duIHRvIEMsIHBl cmhhcHMgYmVjYXVzZQ0KIGVpdGhlciBpcyBzbWFsbCwgd2hlcmUgc29tZSBtaXhlcyBvZiB0aGUg YWJvdmUgdGVjaG5pcXVlcyB3b3VsZCBzYXZlIHRoZSBkYXksIHRoZXJlYnkgZW5jb3VyYWdpbmcg bW9yZSBzbWFsbCBkb21haW5zIHRvIHB1Ymxpc2ggc3RyaWN0IERNQVJDIHBvbGljaWVzLCBkb24n dCB5b3UgdGhpbms/PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JJ20gbm90IHN1cmUgaWYgdGhhdCdzIGEgZ29hbC48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnJhbmRvbjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCkFsZTxzcGFuIHN0eWxlPSJjb2xvcjoj ODg4ODg4Ij48YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj4tLSA8L3NwYW4+PGJyPg0KPGJyPg0K PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_SN2PR00MB0111A3637314C77A4CB2255396EA0SN2PR00MB0111namp_-- From nobody Tue Aug 30 11:48:27 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E79C012D7BC for ; Tue, 30 Aug 2016 11:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.85 X-Spam-Level: X-Spam-Status: No, score=-4.85 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.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIzm_QLY91Uy for ; Tue, 30 Aug 2016 11:48:22 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A79912D7BF for ; Tue, 30 Aug 2016 11:48:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1472582899; bh=bFxTwdZ5R3ATVTZzG8AhqySz6zkuGZUICJoHd6Zoti8=; l=3440; h=To:References:Cc:From:Date:In-Reply-To; b=ovPM/yypQNYF4D6xTaM6hmoCHc3ik3KExwSp9wgimExPUY0zPVuxe5HB+4Bi1GNDY X5P9422kvEqN5th618pvKT5V8CGQnqHYBKRBlo/OL49FsBqPmYZuDtpegSiB3Av3hj P1kuITJI9Z5Qeh6iYI3buVDjMr/LCtWTOOQoHBsg= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [192.168.1.129] (93-36-0-28.ip57.fastwebnet.it [93.36.0.28]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by wmail.tana.it with ESMTPSA; Tue, 30 Aug 2016 20:48:19 +0200 id 00000000005DC053.0000000057C5D4F3.000034A0 To: Brandon Long References: <20160813023957.5679.qmail@ary.lan> <20160813150004.GM10626@thunk.org> <2561d946-b853-4dd2-5aba-921bd88f99ba@dcrocker.net> <655339a0-54eb-4d84-f407-8aea3a822cc3@tana.it> <4a3c08f4-8fa5-efcc-f70a-cc9ec98d01b5@tana.it> <9b51616c-2540-d8ec-61b0-2dcc6d6a29ea@tana.it> From: Alessandro Vesely Message-ID: Date: Tue, 30 Aug 2016 20:48:19 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: dmarc-ietf Subject: Re: [dmarc-ietf] ARC and weak signatures (again) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 18:48:26 -0000 Back to connected lands... On Wed 24/Aug/2016 02:19:35 +0200 Brandon Long wrote: > On Tue, Aug 23, 2016 at 11:55 AM, Alessandro Vesely wrote: >>> >>>> Say A -> B -> C are the MTAs: [...] >>> >>> If your MTA is too small to use combinatorial trust assessments, then you >>> are stuck with the same two options you have today: manual whitelists or >>> using a service to give you that information. >> >> A two-step heuristic to determine trusted MLMs consists of (1) collect >> domain names from received List-Post: header fields matching , >> and authenticated (via SPF, DKIM, or DNSWL), and then (2) from the domains >> collected that way, select those that my users write to. _Small domains_ >> --by definition, for the scope of this discussion-- have no anonymous users. >> >> That heuristics keeps failing until a subscribed user actually posts to a >> MLM. Skipping step (2) makes it an obvious attack path, but whitelisting >> can mitigate it a bit. > > If you were actually seeing 20-30 whitelistable mailing list domains a > day, I think you might get >90% of them in a couple months. 20-30 was the total number, it would take me even less time to do manual whitelisting. Fact is I'd feel like wasting my time while providing a fuzzy service to my few users that way. > Ok, that's not true, Google Apps allows domains to have mailing lists, but > that's probably the bulk of them... but they'll all be ARC signed by the > same provider (google.com). O365 may also have a ton, but again, probably > whitelistable as a single entity. Thanks for the insight. >>>> [...] The concept is weak signatures. [...] >>> >>> So, any message sent from A to B can then be used as a replay with any >>> content to any party as long as the To/Cc are intact? That seems pretty >>> useless. >>> >> >> Yes, B can send whatever they like using your name@A. That's how >> weak signatures work. [...] regular domains may want to weak-sign >> only the copy of a message addressed to a trusted MLM. >> >> I'd put weak signatures when I play A. That way I'd complement the above >> technique, trusted MLMs whitelisting, which I'd use when I play C. > > But you're still whitelisting MLMs in C, or even possibly in A in this > scenario. Yup, in A it works from the first time. >> If I were clever, I would list all possible statuses of A, B, and C (such >> as complying with DKIM, DMARC and ARC, applying or recognizing weak >> signatures, being aware of either DKIM v=2 or the new header field, et >> cetera) along with the relative probabilities that they are implemented at >> various stages in time, and then compute the chances that C can pass/reject >> correctly in the two cases of B being white or black, at each stage. I >> reckon there are cases of A unknown to C, perhaps because either is small, >> where some mixes of the above techniques would save the day, thereby >> encouraging more small domains to publish strict DMARC policies, don't you >> think? > > I'm not sure if that's a goal. I agree it is not a goal to have more strict DMARC policies, not in the sense of the quest for SPF -all a dozen years ago. However, I'd regard widespread adoption of non-test policies as a success indicator of DMARC. Personally, mailing list is what prevents me from such policy shift, but other local providers don't even DKIM sign... Ale From nobody Wed Aug 31 07:30:43 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70CA512D11D for ; Wed, 31 Aug 2016 07:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, 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 0dsir6y3-MAs for ; Wed, 31 Aug 2016 07:30:34 -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 D7EAD12D1A3 for ; Wed, 31 Aug 2016 07:10:54 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id i184so10243252itf.1 for ; Wed, 31 Aug 2016 07:10:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to; bh=9LNuj6sizC27B3q2T8JJeW1KRKV7XnKDSVgS5LcWrH8=; b=e48vxmqtbBeFPay7709t82G3MQnY2StHYmqhw7IlD2kKkQCJdsscUbFrQWFvY4zOJA DGJKVIyXFsCicug/GchDddR8UuGydUgZDg1zc0JbA1FFgqlQfRjY6+fEJrt+sZuBUpVQ vAdqfn9Zi8mMn9p+p9AkP+7ykqVOiUv/azNn0W4h9/b0dI5XCWV86Vmac7l9ucF6gqch K7OURFE1ARnkT6sCMcH/zK0dZyGrH8iI3bK+JK09Csi4hJjCBsIcDEJO1Yj6vitiahcF /nQnbLwJOiVr81kuM2JQGGrVTai09BmfAbMU3ohb131hsaLu+aRSOtReF/X/htDL35S1 W8Sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=9LNuj6sizC27B3q2T8JJeW1KRKV7XnKDSVgS5LcWrH8=; b=IvdvGaOrwEc7QKVlY8XkEfzw4KzWojVPjv+Un5x7LIk4fp6exV27ib2AJNhzW1LN5V cY2CyKwV3eJXJcpGCHk6OzJOBsPKNomrUr6t7H/+Lf+K0yShNK4Zx/HOAmtNYX0UmD5g 4mgfkkPJqHmOhQXeO8jlUtTRPC/NdKq5T0XALft/PBg4xZohkhLftkILAM7q/aMNhiV7 /XFJI4Zi/dA5+GZuC6NxInsRrQlzdPUUklzUkRH8Lx1XDMtgO/eHsqJyMvW+obI9UMCq 9QgHFWAZEnkExZ+jZZMkjJZTD0155nCs8kWh61nM+XldKu/zuJm38ITVttEN5F+QlGfW moPA== X-Gm-Message-State: AE9vXwPeN3yIMnDa9e9YEpw41i0NKF6ex5YWN6WTSxxsDdo1IMpKFZRthYO/SuSyqNiD3QgVPvIy4KHMXpLgNg== X-Received: by 10.107.20.151 with SMTP id 145mr5779936iou.70.1472652653830; Wed, 31 Aug 2016 07:10:53 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.182.67 with HTTP; Wed, 31 Aug 2016 07:10:53 -0700 (PDT) From: Barry Leiba Date: Wed, 31 Aug 2016 10:10:53 -0400 X-Google-Sender-Auth: r9yNggSOAhpKji61xvIw-B_9KpY Message-ID: To: "dmarc@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [dmarc-ietf] No meeting at IETF 97 (Seoul) ? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 14:30:41 -0000 The chairs think we do not need to meet in Seoul. Does the working group think otherwise? Barry, as chair