From owner-ietf-mxcomp@mail.imc.org Mon Nov 1 13:38:15 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16016 for ; Mon, 1 Nov 2004 13:38:13 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA1Hp55C014615; Mon, 1 Nov 2004 09:51:05 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA1Hp5E9014614; Mon, 1 Nov 2004 09:51:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA1Hp4Hl014534 for ; Mon, 1 Nov 2004 09:51:04 -0800 (PST) (envelope-from hkatz@exchange.microsoft.com) Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 Nov 2004 09:51:02 -0800 Received: from red-hub-03.redmond.corp.microsoft.com ([157.54.2.25]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 Nov 2004 09:50:53 -0800 Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by red-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 Nov 2004 09:50:54 -0800 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 Nov 2004 09:51:01 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C4C03B.59DD3544" Subject: draft-lyon-senderid-pra-00 Date: Mon, 1 Nov 2004 09:51:01 -0800 Message-ID: X-MS-Has-Attach: yes Thread-Topic: draft-lyon-senderid-pra-00 Thread-Index: AcTAO1m/HKperxQjSq2PWC2221NYoQ== From: "Harry Katz" To: "IETF MARID WG" Cc: "Jim Lyon" X-OriginalArrivalTime: 01 Nov 2004 17:51:01.0970 (UTC) FILETIME=[5A0E3320:01C4C03B] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C4C03B.59DD3544 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The attached Sender ID specification, draft-lyon-senderid-pra-00, is being submitted to the IETF as an experimental Internet draft along with draft-lyon-senderid-core-00 and draft-katz-submitter-00.=20 These three drafts capture discussions held during the last few weeks of the MARID working group, as well as some subsequent feedback we've received. In summary, we've made two key changes to the Sender ID Framework: 1. The Sender ID Framework now allows receiving systems to choose which identity to validate; either the RFC2821 MAIL FROM address (aka "envelope from") or the purported responsible address (PRA) derived from RFC2822 message headers.=20 2. Sender ID is now backward compatible with any published SPF records in DNS. These records can be used for both MAIL FROM and PRA checks. We believe that the information that most sending domains need to publish in DNS will be the same for both checks. However domains which need to publish different IP addresses for each test can do so using a revised version of the SPF record syntax. Note that these specifications refer to draft-lentczner-spf-00 for the definition of the SPF record format and protocol.=20 This draft won't appear on the IETF web site until after the IETF meeting in Washington, D.C. Until then, the text version is attached. A PDF version is available at http://www.microsoft.com/senderid .=20 Thanks. ------_=_NextPart_001_01C4C03B.59DD3544 Content-Type: text/plain; name="draft-lyon-senderid-pra-00.txt" Content-Description: draft-lyon-senderid-pra-00.txt Content-Disposition: attachment; filename="draft-lyon-senderid-pra-00.txt" Content-Transfer-Encoding: base64 DQoNCiAgIEludGVybmV0IERyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBKLiBMeW9uDQogICBDYXRlZ29yeTogRXhwZXJpbWVudGFsICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBNaWNyb3NvZnQgQ29ycA0KICAgRG9jdW1lbnQ6IGRyYWZ0LWx5 b24tc2VuZGVyaWQtcHJhLTAwLnR4dA0KICAgRXhwaXJlczogQXByaWwgMjAwNSAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBPY3RvYmVyIDIwMDQNCg0KDQogICAgICAgICAgICAg UHVycG9ydGVkIFJlc3BvbnNpYmxlIEFkZHJlc3MgaW4gRS1NYWlsIE1lc3NhZ2VzDQoNCg0KU3Rh dHVzIG9mIHRoaXMgTWVtbw0KDQogICBCeSBzdWJtaXR0aW5nIHRoaXMgSW50ZXJuZXQtRHJhZnQs IEkgY2VydGlmeSB0aGF0IGFueSBhcHBsaWNhYmxlDQogICBwYXRlbnQgb3Igb3RoZXIgSVBSIGNs YWltcyBvZiB3aGljaCBJIGFtIGF3YXJlIGhhdmUgYmVlbiBkaXNjbG9zZWQsDQogICBvciB3aWxs IGJlIGRpc2Nsb3NlZCwgYW5kIGFueSBvZiB3aGljaCBJIGJlY29tZSBhd2FyZSB3aWxsIGJlDQog ICBkaXNjbG9zZWQsIGluIGFjY29yZGFuY2Ugd2l0aCBSRkMgMzY2OC4NCg0KICAgSW50ZXJuZXQt RHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcN CiAgIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBncm91cHMu ICBOb3RlIHRoYXQNCiAgIG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlIHdvcmtpbmcg ZG9jdW1lbnRzIGFzIEludGVybmV0LQ0KICAgRHJhZnRzLg0KDQogICBJbnRlcm5ldC1EcmFmdHMg YXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMNCiAg IGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1 bWVudHMgYXQgYW55DQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJu ZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQ0KICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVy IHRoYW4gYSAid29yayBpbiBwcm9ncmVzcy4iDQoNCiAgIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50 ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5v cmcvMWlkLWFic3RyYWN0cy5odG1sDQoNCiAgIFRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNo YWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNzZWQgYXQNCiAgICAgICBodHRwOi8vd3d3Lmll dGYub3JnL3NoYWRvdy5odG1sDQoNCkFic3RyYWN0DQoNCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5l cyBhbiBhbGdvcml0aG0gYnkgd2hpY2gsIGdpdmVuIGFuIGUtbWFpbCBtZXNzYWdlLA0KICAgb25l IGNhbiBleHRyYWN0IHRoZSBpZGVudGl0eSBvZiB0aGUgcGFydHkgdGhhdCBhcHBlYXJzIHRvIGhh dmUgbW9zdA0KICAgcHJveGltYXRlbHkgY2F1c2VkIHRoYXQgbWVzc2FnZSB0byBiZSBkZWxpdmVy ZWQuICBUaGlzIGlkZW50aXR5IGlzDQogICBjYWxsZWQgdGhlICJQdXJwb3J0ZWQgUmVzcG9uc2li bGUgQWRkcmVzcyIgKFBSQSkuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KSi4gTHlvbiAg ICAgICAgICAgICAgICAgIEV4cGlyZXMgLSBBcHJpbCAyMDA1ICAgICAgICAgICAgICAgICBbUGFn ZSAxXQ0KDA0KICAgICAgUHVycG9ydGVkIFJlc3BvbnNpYmxlIEFkZHJlc3MgaW4gRS1NYWlsIE1l c3NhZ2VzICAgIE9jdG9iZXIgMjAwNA0KDQoNClRhYmxlIG9mIENvbnRlbnRzDQoNCiAgIDEuIElu dHJvZHVjdGlvbi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLjINCiAgIDIuIERldGVybWluaW5nIHRoZSBQdXJwb3J0ZWQgUmVzcG9uc2libGUgQWRkcmVz cy4uLi4uLi4uLi4uLi4uLi4uLjMNCiAgIDMuIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjQNCiAgIDQuIElBTkEgQ29uc2lkZXJh dGlvbnMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjUNCiAgIDUu IEFja25vd2xlZGdlbWVudHMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLjUNCiAgIDYuIFJlZmVyZW5jZXMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLjUNCiAgICAgIDYuMSBOb3JtYXRpdmUgUmVmZXJlbmNlcy4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjUNCiAgICAgIDYuMiBJbmZvcm1h dGl2ZSBSZWZlcmVuY2VzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjUNCiAg IDcuIEF1dGhvcidzIEFkZHJlc3MuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLjUNCg0KDQpDb252ZW50aW9ucyB1c2VkIGluIHRoaXMgZG9jdW1lbnQNCg0KICAg VGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJT SEFMTCBOT1QiLA0KICAgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1B WSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXMNCiAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnBy ZXRlZCBhcyBkZXNjcmliZWQgaW4gW1JGQzIxMTldLg0KDQoNCjEuIEludHJvZHVjdGlvbg0KDQog ICBNb3N0IGUtTWFpbCBmbG93cyByZWxhdGl2ZWx5IGRpcmVjdGx5IGZyb20gYSBzZW5kZXIgdG8g YSByZWNpcGllbnQsDQogICB3aXRoIGEgc21hbGwgbnVtYmVyIG9mIE1haWwgVHJhbnNmZXIgQWdl bnRzIChNVEFzKSBpbiBiZXR3ZWVuLiAgU29tZQ0KICAgbWVzc2FnZXMsIGhvd2V2ZXIsIGFyZSBy ZXNlbnQgYnkgZm9yd2FyZGluZyBhZ2VudHMsIG1haWxpbmcgbGlzdA0KICAgc2VydmVycywgYW5k IG90aGVyIHN1Y2ggc29mdHdhcmUuICBUaGVzZSBtZXNzYWdlcyBlZmZlY3RpdmVseSByZXN1bHQN CiAgIGluIHR3byBvciBtb3JlIG1haWwgdHJhbnNhY3Rpb25zOiBvbmUgZnJvbSB0aGUgc2VuZGVy IHRvIHRoZQ0KICAgZm9yd2FyZGluZyBhZ2VudCwgYW5kIGFub3RoZXIgZnJvbSB0aGUgYWdlbnQg dG8gdGhlIGRlc3RpbmF0aW9uLg0KDQogICBJbiBzb21lIGNhc2VzLCBtZXNzYWdlcyB0cmF2ZWwg dGhyb3VnaCBtb3JlIHRoYW4gb25lIG9mIHRoZXNlIGFnZW50cy4NCiAgIFRoaXMgY2FuIG9jY3Vy LCBmb3IgZXhhbXBsZSwgd2hlbiBvbmUgbWFpbGluZyBsaXN0IGlzIHN1YnNjcmliZWQgdG8NCiAg IGFub3RoZXIsIG9yIHdoZW4gdGhlIGFkZHJlc3Mgc3Vic2NyaWJlZCB0byBhIG1haWxpbmcgbGlz dCBpcyBhDQogICBmb3J3YXJkaW5nIHNlcnZpY2UuDQoNCiAgIEZ1cnRoZXIgY29tcGxpY2F0aW5n IHRoZSBzaXR1YXRpb24sIGluIHNvbWUgY2FzZXMgdGhlIHBhcnR5IHRoYXQNCiAgIGludHJvZHVj ZXMgYSBtZXNzYWdlIGlzIG5vdCB0aGUgYXV0aG9yIG9mIHRoZSBtZXNzYWdlLiAgRm9yIGV4YW1w bGUsDQogICBtYW55IG5ld3Mgd2ViIHNpdGVzIGhhdmUgYSAiTWFpbCB0aGlzIGFydGljbGUiIGZ1 bmN0aW9uIHRoYXQgdGhlDQogICBwdWJsaWMgY2FuIHVzZSB0byBlLW1haWwgYSBjb3B5IG9mIHRo ZSBhcnRpY2xlIHRvIGEgZnJpZW5kLiAgSW4gdGhpcw0KICAgY2FzZSwgdGhlIG1haWwgaXMgImZy b20iIHRoZSBwZXJzb24gd2hvIHByZXNzZWQgdGhlIGJ1dHRvbiwgYnV0IGlzDQogICBwaHlzaWNh bGx5IHNlbnQgYnkgdGhlIG9wZXJhdG9yIG9mIHRoZSB3ZWIgc2l0ZS4NCg0KICAgVGhpcyBkb2N1 bWVudCBkZWZpbmVzIGEgbmV3IGlkZW50aXR5IGFzc29jaWF0ZWQgd2l0aCBhbiBlLW1haWwNCiAg IG1lc3NhZ2UsIGNhbGxlZCB0aGUgUHVycG9ydGVkIFJlc3BvbnNpYmxlIEFkZHJlc3MgKFBSQSks IHdoaWNoIGlzDQogICBkZXRlcm1pbmVkIGJ5IGluc3BlY3RpbmcgdGhlIGhlYWRlciBvZiB0aGUg bWVzc2FnZS4gIFRoZSBQUkEgaXMNCiAgIGRlc2lnbmVkIHRvIGJlIHRoZSBlbnRpdHkgdGhhdCAo YWNjb3JkaW5nIHRvIHRoZSBoZWFkZXIpIG1vc3QNCiAgIHJlY2VudGx5IGNhdXNlZCB0aGUgbWVz c2FnZSB0byBiZSBkZWxpdmVyZWQuDQoNCiAgIE5vdGUgdGhhdCB0aGUgcmVzdWx0cyBvZiB0aGlz IGFsZ29yaXRobSBhcmUgb25seSBhcyB0cnV0aGZ1bCBhcyB0aGUNCiAgIGhlYWRlcnMgY29udGFp bmVkIGluIHRoZSBtZXNzYWdlOyBpZiBhIG1lc3NhZ2UgY29udGFpbnMgZnJhdWR1bGVudCBvcg0K DQoNCkouIEx5b24gICAgICAgICAgICAgICAgICBFeHBpcmVzIC0gQXByaWwgMjAwNSAgICAgICAg ICAgICAgICAgW1BhZ2UgMl0NCgwNCiAgICAgIFB1cnBvcnRlZCBSZXNwb25zaWJsZSBBZGRyZXNz IGluIEUtTWFpbCBNZXNzYWdlcyAgICBPY3RvYmVyIDIwMDQNCg0KDQogICBpbmNvcnJlY3QgaGVh ZGVycywgdGhpcyBhbGdvcml0aG0gd2lsbCB5aWVsZCBhbiBpbmNvcnJlY3QgcmVzdWx0Lg0KICAg Rm9yIHRoaXMgcmVhc29uLCB0aGUgcmVzdWx0IG9mIHRoZSBhbGdvcml0aG0gaXMgY2FsbGVkIHRo ZSAiUHVycG9ydGVkDQogICBSZXNwb25zaWJsZSBBZGRyZXNzIiAtLSAicHVycG9ydGVkIiBiZWNh dXNlIGl0IHRlbGxzIHlvdSB3aGF0IGENCiAgIG1lc3NhZ2UgY2xhaW1zIGFib3V0IHdoZXJlIGl0 IGNhbWUgZnJvbSwgYnV0IG5vdCBuZWNlc3NhcmlseSB3aGVyZSBpdA0KICAgYWN0dWFsbHkgY2Ft ZSBmcm9tLg0KDQogICBUaGlzIGRvY3VtZW50IGRvZXMgbm90IHByZXNjcmliZSBhbnkgcGFydGlj dWxhciB1c2VzIGZvciB0aGUNCiAgIFB1cnBvcnRlZCBSZXNwb25zaWJsZSBBZGRyZXNzLiAgSG93 ZXZlciwgW1NlbmRlcklEXSBkZXNjcmliZXMgYQ0KICAgbWV0aG9kIG9mIGRldGVybWluaW5nIHdo ZXRoZXIgYSBwYXJ0aWN1bGFyIE1UQSBpcyBhdXRob3JpemVkIHRvIHNlbmQNCiAgIG1haWwgb24g YmVoYWxmIG9mIHRoZSBkb21haW4gY29udGFpbmVkIGluIHRoZSBQUkEuDQoNCg0KMi4gRGV0ZXJt aW5pbmcgdGhlIFB1cnBvcnRlZCBSZXNwb25zaWJsZSBBZGRyZXNzDQoNCiAgIFRoZSBwdXJwb3J0 ZWQgcmVzcG9uc2libGUgYWRkcmVzcyAoUFJBKSBvZiBhIG1lc3NhZ2UgaXMgZGV0ZXJtaW5lZCBi eQ0KICAgdGhlIGZvbGxvd2luZyBhbGdvcml0aG06DQoNCiAgIDEuIFNlbGVjdCB0aGUgZmlyc3Qg bm9uLWVtcHR5IFJlc2VudC1TZW5kZXIgaGVhZGVyIGluIHRoZSBtZXNzYWdlLiBJZg0KICAgICBu byBzdWNoIGhlYWRlciBpcyBmb3VuZCwgY29udGludWUgd2l0aCBzdGVwIDIuICBJZiBpdCBpcyBw cmVjZWRlZA0KICAgICBieSBhIG5vbi1lbXB0eSBSZXNlbnQtRnJvbSBoZWFkZXIgYW5kIG9uZSBv ciBtb3JlIFJlY2VpdmVkIG9yDQogICAgIFJldHVybi1QYXRoIGhlYWRlcnMgb2NjdXIgYWZ0ZXIg c2FpZCBSZXNlbnQtRnJvbSBoZWFkZXIgYW5kIGJlZm9yZQ0KICAgICB0aGUgUmVzZW50LVNlbmRl ciBoZWFkZXIsIGNvbnRpbnVlIHdpdGggc3RlcCAyLiAgT3RoZXJ3aXNlLA0KICAgICBwcm9jZWVk IHRvIHN0ZXAgNS4NCg0KICAgMi4gU2VsZWN0IHRoZSBmaXJzdCBub24tZW1wdHkgUmVzZW50LUZy b20gaGVhZGVyIGluIHRoZSBtZXNzYWdlLiAgSWYNCiAgICAgYSBSZXNlbnQtRnJvbSBoZWFkZXIg aXMgZm91bmQsIHByb2NlZWQgdG8gc3RlcCA1LiBPdGhlcndpc2UsDQogICAgIGNvbnRpbnVlIHdp dGggc3RlcCAzLg0KDQogICAzLiBTZWxlY3QgYWxsIHRoZSBub24tZW1wdHkgU2VuZGVyIGhlYWRl cnMgaW4gdGhlIG1lc3NhZ2UuICBJZiB0aGVyZQ0KICAgICBhcmUgbm8gc3VjaCBoZWFkZXJzLCBj b250aW51ZSB3aXRoIHN0ZXAgNC4gIElmIHRoZXJlIGlzIGV4YWN0bHkNCiAgICAgb25lIHN1Y2gg aGVhZGVyLCBwcm9jZWVkIHRvIHN0ZXAgNS4gIElmIHRoZXJlIGlzIG1vcmUgdGhhbiBvbmUNCiAg ICAgc3VjaCBoZWFkZXIsIHByb2NlZWQgdG8gc3RlcCA2Lg0KDQogICA0LiBTZWxlY3QgYWxsIHRo ZSBub24tZW1wdHkgRnJvbSBoZWFkZXJzIGluIHRoZSBtZXNzYWdlLiAgSWYgdGhlcmUgaXMNCiAg ICAgZXhhY3RseSBvbmUgc3VjaCBoZWFkZXIsIGNvbnRpbnVlIHdpdGggc3RlcCA1LiAgT3RoZXJ3 aXNlLCBwcm9jZWVkDQogICAgIHRvIHN0ZXAgNi4NCg0KICAgNS4gQSBwcmV2aW91cyBzdGVwIGhh cyBzZWxlY3RlZCBhIHNpbmdsZSBoZWFkZXIgZnJvbSB0aGUgbWVzc2FnZS4gIElmDQogICAgIHRo YXQgaGVhZGVyIGlzIG1hbGZvcm1lZCAoZS5nLiBpdCBhcHBlYXJzIHRvIGNvbnRhaW4gbXVsdGlw bGUNCiAgICAgbWFpbGJveGVzLCBvciB0aGUgc2luZ2xlIG1haWxib3ggaXMgaG9wZWxlc3NseSBt YWxmb3JtZWQsIG9yIHRoZQ0KICAgICBzaW5nbGUgbWFpbGJveCBkb2VzIG5vdCBjb250YWluIGEg ZG9tYWluIG5hbWUpLCBjb250aW51ZSB3aXRoIHN0ZXANCiAgICAgNi4gIE90aGVyd2lzZSwgcmV0 dXJuIHRoYXQgc2luZ2xlIG1haWxib3ggYXMgdGhlIFB1cnBvcnRlZA0KICAgICBSZXNwb25zaWJs ZSBBZGRyZXNzLg0KDQogICA2LiBUaGUgbWVzc2FnZSBpcyBpbGwtZm9ybWVkLCBhbmQgaXQgaXMg aW1wb3NzaWJsZSB0byBkZXRlcm1pbmUgYQ0KICAgICBQdXJwb3J0ZWQgUmVzcG9uc2libGUgQWRk cmVzcy4NCg0KICAgRm9yIHRoZSBwdXJwb3NlcyBvZiB0aGlzIGFsZ29yaXRobSwgYSBoZWFkZXIg ZmllbGQgaXMgIm5vbi1lbXB0eSIgaWYNCiAgIGFuZCBvbmx5IGlmIGl0IGNvbnRhaW5zIGFueSBu b24td2hpdGVzcGFjZSBjaGFyYWN0ZXJzLiAgSGVhZGVyIGZpZWxkcw0KDQoNCkouIEx5b24gICAg ICAgICAgICAgICAgICBFeHBpcmVzIC0gQXByaWwgMjAwNSAgICAgICAgICAgICAgICAgW1BhZ2Ug M10NCgwNCiAgICAgIFB1cnBvcnRlZCBSZXNwb25zaWJsZSBBZGRyZXNzIGluIEUtTWFpbCBNZXNz YWdlcyAgICBPY3RvYmVyIDIwMDQNCg0KDQogICB0aGF0IGFyZSBvdGhlcndpc2UgcmVsZXZhbnQg YnV0IGNvbnRhaW4gb25seSB3aGl0ZXNwYWNlIGFyZSBpZ25vcmVkDQogICBhbmQgdHJlYXRlZCBh cyBpZiB0aGV5IHdlcmUgbm90IHByZXNlbnQuDQoNCiAgIE5vdGUgdGhhdCBzdGVwcyAxIGFuZCAy IGFib3ZlIGV4dHJhY3QgdGhlIFJlc2VudC1TZW5kZXIgb3IgUmVzZW50LQ0KICAgRnJvbSBoZWFk ZXIgZnJvbSB0aGUgZmlyc3QgcmVzZW50IGJsb2NrIChhcyBkZWZpbmVkIGJ5IHNlY3Rpb24gMy42 LjYNCiAgIG9mIFtSRkMyODIyXSkgaWYgYW55LiAgU3RlcHMgMyBhbmQgNCBhYm92ZSBleHRyYWN0 IHRoZSBTZW5kZXIgb3IgRnJvbQ0KICAgaGVhZGVyIGlmIHRoZXJlIGFyZSBubyByZXNlbnQgYmxv Y2tzLg0KDQogICBOb3RlIHRoYXQgd2hhdCBjb25zdGl0dXRlcyBhIGhvcGVsZXNzbHkgbWFsZm9y bWVkIGhlYWRlciBvciBhDQogICBob3BlbGVzc2x5IG1hbGZvcm1lZCBtYWlsYm94IGluIHN0ZXAg NSBhYm92ZSBpcyBhIG1hdHRlciBmb3IgbG9jYWwNCiAgIHBvbGljeS4gIFN1Y2ggbG9jYWwgcG9s aWN5IHdpbGwgbmV2ZXIgY2F1c2UgdHdvIGltcGxlbWVudGF0aW9ucyB0bw0KICAgcmV0dXJuIGRp ZmZlcmVudCBQUkFzLiAgSG93ZXZlciBpdCBtYXkgY2F1c2Ugb25lIGltcGxlbWVudGF0aW9uIHRv DQogICByZXR1cm4gYSBQUkEgd2hlcmUgYW5vdGhlciBpbXBsZW1lbnRhdGlvbiBkb2VzIG5vdC4g IFRoaXMgd2lsbCBvbmx5DQogICBvY2N1ciB3aGVuIGRlYWxpbmcgd2l0aCBhIG1lc3NhZ2UgY29u dGFpbmluZyBoZWFkZXJzIG9mIHF1ZXN0aW9uYWJsZQ0KICAgbGVnYWxpdHkuDQoNCiAgIEFsdGhv dWdoIHRoZSBhbGdvcml0aG0gc3BlY2lmaWVzIGhvdyBtZXNzYWdlcyB0aGF0IGFyZSBub3QgaW4g c3RyaWN0DQogICBjb25mb3JtYW5jZSB3aXRoIHRoZSBwcm92aXNpb25zIG9mIFJGQzI4MjIgc2hv dWxkIGJlIHRyZWF0ZWQgZm9yIHRoZQ0KICAgcHVycG9zZXMgb2YgZGV0ZXJtaW5pbmcgdGhlIFBS QSwgdGhpcyBzaG91bGQgbm90IGJlIHRha2VuIGFzDQogICByZXF1aXJpbmcgb3IgcmVjb21tZW5k aW5nIHRoYXQgYW55IHN5c3RlbXMgYWNjZXB0IHN1Y2ggbWVzc2FnZXMgd2hlbg0KICAgdGhleSBv dGhlcndpc2Ugd291bGQgbm90IGhhdmUgZG9uZSBzby4gIEhvd2V2ZXIsIGlmIGEgbGliZXJhbA0K ICAgaW1wbGVtZW50YXRpb24gYWNjZXB0cyBzdWNoIG1lc3NhZ2VzIGFuZCBkZXNpcmVzIHRvIGtu b3cgdGhlaXIgUFJBLA0KICAgaXQgTVVTVCB1c2UgdGhlIGFsZ29yaXRobSBzcGVjaWZpZWQgaGVy ZS4NCg0KICAgV2hlcmUgbWVzc2FnZXMgY29uZm9ybSB0byBSRkM4MjIgcmF0aGVyIHRoYW4gUkZD MjgyMiwgaXQgaXMgcG9zc2libGUNCiAgIGZvciB0aGUgYWxnb3JpdGhtIHRvIGdpdmUgdW5leHBl Y3RlZCByZXN1bHRzLiAgQW4gUkZDODIyIG1lc3NhZ2UNCiAgIHNob3VsZCBub3Qgbm9ybWFsbHkg Y29udGFpbiBtb3JlIHRoYW4gb25lIHNldCBvZiByZXNlbnQgaGVhZGVyczsNCiAgIGhvd2V2ZXIg dGhlIHBsYWNlbWVudCBvZiB0aG9zZSBoZWFkZXJzIGlzIG5vdCBzcGVjaWZpZWQsIG5vciBhcmUg dGhleQ0KICAgcmVxdWlyZWQgdG8gYmUgY29udGlndW91cy4gIEl0IGlzIGhlbmNlIHBvc3NpYmxl IHRoYXQgdGhlIFJlc2VudC1Gcm9tDQogICBoZWFkZXIgd2lsbCBiZSBzZWxlY3RlZCBldmVuIHRo b3VnaCBhIFJlc2VudC1TZW5kZXIgaGVhZGVyIGlzDQogICBwcmVzZW50LiAgU3VjaCBjYXNlcyBh cmUgZXhwZWN0ZWQgdG8gYmUgcmFyZSBvciBub24tZXhpc3RlbnQgaW4NCiAgIHByYWN0aWNlLg0K DQoNCjMuIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zDQoNCiAgIFRoZSBQUkEsIGFzIGRlc2NyaWJl ZCBieSB0aGlzIGRvY3VtZW50LCBpcyBleHRyYWN0ZWQgZnJvbSBtZXNzYWdlDQogICBoZWFkZXJz IHRoYXQgaGF2ZSBoaXN0b3JpY2FsbHkgbm90IGJlZW4gdmVyaWZpZWQuICBUaHVzLCBhbnlvbmUg dXNpbmcNCiAgIHRoZSBQUkEgZm9yIGFueSBwdXJwb3NlIE1VU1QgYmUgYXdhcmUgdGhhdCB0aGUg aGVhZGVycyBmcm9tIHdoaWNoIGl0DQogICBpcyBkZXJpdmVkIG1pZ2h0IGJlIGZyYXVkdWxlbnQs IG1hbGljaW91cywgbWFsZm9ybWVkIGFuZC9vcg0KICAgaW5jb3JyZWN0LiAgW1NlbmRlcklEXSBk ZXNjcmliZXMgb25lIG1lY2hhbmlzbSBmb3IgdmFsaWRhdGluZyB0aGUNCiAgIFBSQS4NCg0KICAg QSBtZXNzYWdlJ3MgUFJBIHdpbGwgb2Z0ZW4gYmUgZXh0cmFjdGVkIGZyb20gYSBoZWFkZXIgZmll bGQgdGhhdCBpcw0KICAgbm90IG5vcm1hbGx5IGRpc3BsYXllZCBieSBleGlzdGluZyBtYWlsIHVz ZXIgYWdlbnQgc29mdHdhcmUuICBJZiB0aGUNCiAgIFBSQSBpcyB1c2VkIGFzIHBhcnQgb2YgYSBt ZWNoYW5pc20gdG8gYXV0aGVudGljYXRlIHRoZSBtZXNzYWdlJ3MNCiAgIG9yaWdpbiwgdGhlIG1l c3NhZ2UgU0hPVUxEIE5PVCBiZSBkaXNwbGF5ZWQgd2l0aCBhbiBpbmRpY2F0aW9uIG9mIGl0cw0K ICAgYXV0aGVudGljaXR5IChwb3NpdGl2ZSBvciBuZWdhdGl2ZSkgd2l0aG91dCB0aGUgUFJBIGhl YWRlciBmaWVsZCBhbHNvDQogICBiZWluZyBkaXNwbGF5ZWQuDQoNCg0KSi4gTHlvbiAgICAgICAg ICAgICAgICAgIEV4cGlyZXMgLSBBcHJpbCAyMDA1ICAgICAgICAgICAgICAgICBbUGFnZSA0XQ0K DA0KICAgICAgUHVycG9ydGVkIFJlc3BvbnNpYmxlIEFkZHJlc3MgaW4gRS1NYWlsIE1lc3NhZ2Vz ICAgIE9jdG9iZXIgMjAwNA0KDQoNCg0KNC4gSUFOQSBDb25zaWRlcmF0aW9ucw0KDQogICBUaGlz IGRvY3VtZW50IGNvbnRhaW5zIG5vIGFjdGlvbnMgZm9yIElBTkEuDQoNCg0KNS4gQWNrbm93bGVk Z2VtZW50cw0KDQogICBUaGUgUFJBIGNvbmNlcHQgd2FzIGZpcnN0IHB1Ymxpc2hlZCBpbiBbQ2Fs bGVySURdLiAgSXQgYXMgYmVlbg0KICAgcmVmaW5lZCB1c2luZyB2YWx1YWJsZSBzdWdnZXN0aW9u cyBmcm9tIG1lbWJlcnMgb2YgdGhlIE1BUklEIHdvcmtpbmcNCiAgIGdyb3VwLg0KDQoNCjYuIFJl ZmVyZW5jZXMNCg0KNi4xIE5vcm1hdGl2ZSBSZWZlcmVuY2VzDQoNCiAgIFtSRkMyMTE5XSAgIFMu IEJyYWRuZXIsICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlDQogICAgICAg ICAgICAgICBSZXF1aXJlbWVudCBMZXZlbHMiLCBSRkMgMjExOS4NCg0KICAgW1JGQzI4MjJdICAg UC4gUmVzbmljayAoZWRpdG9yKSwgIkludGVybmV0IE1lc3NhZ2UgRm9ybWF0IiwgUkZDIDI4MjIu DQoNCjYuMiBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzDQoNCiAgIFtDYWxsZXJJRF0gIE1pY3Jvc29m dCBDb3Jwb3JhdGlvbiwgQ2FsbGVyIElEIGZvciBFLU1haWwgVGVjaG5pY2FsDQogICAgICAgICAg ICAgICBTcGVjaWZpY2F0aW9uLCBodHRwOi8vd3d3Lm1pY3Jvc29mdC5jb20vbXNjb3JwL3R3Yy8N CiAgICAgICAgICAgICAgIHByaXZhY3kvc3BhbV9jYWxsZXJpZC5tc3B4Lg0KDQogICBbU2VuZGVy SURdICBKLiBMeW9uIGFuZCBNLiBXb25nLCAiU2VuZGVyIElEOiAgQXV0aGVudGljYXRpbmcgRS1N YWlsIiwNCiAgICAgICAgICAgICAgIGRyYWZ0LWx5b24tc2VuZGVyaWQtY29yZS0wMC4gIFdvcmsg aW4gcHJvZ3Jlc3MuDQoNCg0KNy4gQXV0aG9yJ3MgQWRkcmVzcw0KDQogICBKaW0gTHlvbg0KICAg TWljcm9zb2Z0IENvcnBvcmF0aW9uDQogICBPbmUgTWljcm9zb2Z0IFdheQ0KICAgUmVkbW9uZCwg V0EgOTgwNTINCiAgIFVTQQ0KICAgamltbHlvbkBtaWNyb3NvZnQuY29tDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KSi4gTHlvbiAgICAgICAgICAgICAgICAgIEV4cGlyZXMgLSBBcHJpbCAyMDA1ICAg ICAgICAgICAgICAgICBbUGFnZSA1XQ0KDA0KICAgICAgUHVycG9ydGVkIFJlc3BvbnNpYmxlIEFk ZHJlc3MgaW4gRS1NYWlsIE1lc3NhZ2VzICAgIE9jdG9iZXIgMjAwNA0KDQoNCg0KSW50ZWxsZWN0 dWFsIFByb3BlcnR5IFN0YXRlbWVudA0KDQogICBUaGUgSUVURiB0YWtlcyBubyBwb3NpdGlvbiBy ZWdhcmRpbmcgdGhlIHZhbGlkaXR5IG9yIHNjb3BlIG9mIGFueQ0KICAgSW50ZWxsZWN0dWFsIFBy b3BlcnR5IFJpZ2h0cyBvciBvdGhlciByaWdodHMgdGhhdCBtaWdodCBiZSBjbGFpbWVkIHRvDQog ICBwZXJ0YWluIHRvIHRoZSBpbXBsZW1lbnRhdGlvbiBvciB1c2Ugb2YgdGhlIHRlY2hub2xvZ3kg ZGVzY3JpYmVkIGluDQogICB0aGlzIGRvY3VtZW50IG9yIHRoZSBleHRlbnQgdG8gd2hpY2ggYW55 IGxpY2Vuc2UgdW5kZXIgc3VjaCByaWdodHMNCiAgIG1pZ2h0IG9yIG1pZ2h0IG5vdCBiZSBhdmFp bGFibGU7IG5vciBkb2VzIGl0IHJlcHJlc2VudCB0aGF0IGl0IGhhcw0KICAgbWFkZSBhbnkgaW5k ZXBlbmRlbnQgZWZmb3J0IHRvIGlkZW50aWZ5IGFueSBzdWNoIHJpZ2h0cy4gIEluZm9ybWF0aW9u DQogICBvbiB0aGUgcHJvY2VkdXJlcyB3aXRoIHJlc3BlY3QgdG8gcmlnaHRzIGluIFJGQyBkb2N1 bWVudHMgY2FuIGJlDQogICBmb3VuZCBpbiBCQ1AgNzggYW5kIEJDUCA3OS4NCg0KICAgQ29waWVz IG9mIElQUiBkaXNjbG9zdXJlcyBtYWRlIHRvIHRoZSBJRVRGIFNlY3JldGFyaWF0IGFuZCBhbnkN CiAgIGFzc3VyYW5jZXMgb2YgbGljZW5zZXMgdG8gYmUgbWFkZSBhdmFpbGFibGUsIG9yIHRoZSBy ZXN1bHQgb2YgYW4NCiAgIGF0dGVtcHQgbWFkZSB0byBvYnRhaW4gYSBnZW5lcmFsIGxpY2Vuc2Ug b3IgcGVybWlzc2lvbiBmb3IgdGhlIHVzZSBvZg0KICAgc3VjaCBwcm9wcmlldGFyeSByaWdodHMg YnkgaW1wbGVtZW50ZXJzIG9yIHVzZXJzIG9mIHRoaXMNCiAgIHNwZWNpZmljYXRpb24gY2FuIGJl IG9idGFpbmVkIGZyb20gdGhlIElFVEYgb24tbGluZSBJUFIgcmVwb3NpdG9yeSBhdA0KICAgaHR0 cDovL3d3dy5pZXRmLm9yZy9pcHIuDQoNCiAgIFRoZSBJRVRGIGludml0ZXMgYW55IGludGVyZXN0 ZWQgcGFydHkgdG8gYnJpbmcgdG8gaXRzIGF0dGVudGlvbiBhbnkNCiAgIGNvcHlyaWdodHMsIHBh dGVudHMgb3IgcGF0ZW50IGFwcGxpY2F0aW9ucywgb3Igb3RoZXIgcHJvcHJpZXRhcnkNCiAgIHJp Z2h0cyB0aGF0IG1heSBjb3ZlciB0ZWNobm9sb2d5IHRoYXQgbWF5IGJlIHJlcXVpcmVkIHRvIGlt cGxlbWVudA0KICAgdGhpcyBzdGFuZGFyZC4gIFBsZWFzZSBhZGRyZXNzIHRoZSBpbmZvcm1hdGlv biB0byB0aGUgSUVURiBhdCBpZXRmLQ0KICAgaXByQGlldGYub3JnLg0KDQoNCkRpc2NsYWltZXIg b2YgVmFsaWRpdHkNCg0KICAgVGhpcyBkb2N1bWVudCBhbmQgdGhlIGluZm9ybWF0aW9uIGNvbnRh aW5lZCBoZXJlaW4gYXJlIHByb3ZpZGVkIG9uIGFuDQogICAiQVMgSVMiIGJhc2lzIGFuZCBUSEUg Q09OVFJJQlVUT1IsIFRIRSBPUkdBTklaQVRJT04gSEUvU0hFIFJFUFJFU0VOVFMNCiAgIE9SIElT IFNQT05TT1JFRCBCWSAoSUYgQU5ZKSwgVEhFIElOVEVSTkVUIFNPQ0lFVFkgQU5EIFRIRSBJTlRF Uk5FVA0KICAgRU5HSU5FRVJJTkcgVEFTSyBGT1JDRSBESVNDTEFJTSBBTEwgV0FSUkFOVElFUywg RVhQUkVTUyBPUiBJTVBMSUVELA0KICAgSU5DTFVESU5HIEJVVCBOT1QgTElNSVRFRCBUTyBBTlkg V0FSUkFOVFkgVEhBVCBUSEUgVVNFIE9GIFRIRQ0KICAgSU5GT1JNQVRJT04gSEVSRUlOIFdJTEwg Tk9UIElORlJJTkdFIEFOWSBSSUdIVFMgT1IgQU5ZIElNUExJRUQNCiAgIFdBUlJBTlRJRVMgT0Yg TUVSQ0hBTlRBQklMSVRZIE9SIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLg0KDQoN CkNvcHlyaWdodCBTdGF0ZW1lbnQNCg0KICAgQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQgU29j aWV0eSAoMjAwNCkuICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QNCiAgIHRvIHRoZSByaWdodHMs IGxpY2Vuc2VzIGFuZCByZXN0cmljdGlvbnMgY29udGFpbmVkIGluIEJDUCA3OCwgYW5kDQogICBl eGNlcHQgYXMgc2V0IGZvcnRoIHRoZXJlaW4sIHRoZSBhdXRob3JzIHJldGFpbiBhbGwgdGhlaXIg cmlnaHRzLg0KDQoNCkFja25vd2xlZGdtZW50DQoNCiAgIEZ1bmRpbmcgZm9yIHRoZSBSRkMgRWRp dG9yIGZ1bmN0aW9uIGlzIGN1cnJlbnRseSBwcm92aWRlZCBieSB0aGUNCiAgIEludGVybmV0IFNv Y2lldHkuDQoNCg0KDQpKLiBMeW9uICAgICAgICAgICAgICAgICAgRXhwaXJlcyAtIEFwcmlsIDIw MDUgICAgICAgICAgICAgICAgIFtQYWdlIDZdDQo= ------_=_NextPart_001_01C4C03B.59DD3544-- From owner-ietf-mxcomp@mail.imc.org Mon Nov 1 13:38:17 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16035 for ; Mon, 1 Nov 2004 13:38:17 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA1I1Wj8018398; Mon, 1 Nov 2004 10:01:32 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA1I1WpF018397; Mon, 1 Nov 2004 10:01:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA1I1VGj018360 for ; Mon, 1 Nov 2004 10:01:31 -0800 (PST) (envelope-from dotis@mail-abuse.org) Received: from DDev.Mail-Abuse.ORG (DDev.Mail-Abuse.ORG [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id 13964414C5; Mon, 1 Nov 2004 10:01:31 -0800 (PST) Subject: Re: Sender-ID != SPF From: Douglas Otis To: jcouzens@6o4.ca Cc: MXCOMP LIST In-Reply-To: <1099225786.7297.108.camel@code3> References: <1099068249.11011.44.camel@antitrust.6o4.ca> <1099089998.6706.1453.camel@ddev.mail-abuse.org> <1099225786.7297.108.camel@code3> Content-Type: text/plain Message-Id: <1099332090.6706.1587.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 01 Nov 2004 10:01:31 -0800 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sun, 2004-10-31 at 04:29, James Couzens wrote: > On Fri, 2004-10-29 at 15:46 -0700, Douglas Otis wrote: > > On Fri, 2004-10-29 at 09:44, James Couzens wrote: > > > > > SenderID != SPF. Please don't associate the two. > > > > I agree. How does one establish a mix of divergent approaches? A chain > > of trust is broken when each node checks a different mailbox-domain. It > > is also seems inappropriate to misapply a record intended for a > > different mailbox-domain. Handing multiple accountable identities is > > daunting, especially when a change in convention between administrative > > domains makes spoofing easy. Correlating the mailbox-domain checked and > > then displayed becomes another matter. > > > > Regardless of the mailbox-domain checked, leaving authorization normally > > open-ended overcomes present problematic header conventions. Only > > institutions dealing with a phishing problem would have an incentive to > > tackle closing the authorization list. Changing from an address-list to > > a name-list overcomes exploits invited by an open-ended authorization > > list as well, as this would imply a separate entity is utilized for > > reputation. > > . o O Mmmmmm... I wonder just how it was possible that something like > the KISS principle was completely cast aside instead opting to do the > exact opposite. KISS Principles? 1) Email authentication must aid security and reputation assessment. 2) Only the administrator of each MTA is accountable for its security. 3) Only a validated HELO-domain directly identifies the administrator. 4) Lack of security is the principle enabler of spam. 5) Reputation remains a principle tool to abate spam. 6) Any mailbox-domain within a message is hearsay without a signature. 7) Reputation should be based upon the administrator's response to notification of a security breach. 8) Reputations based upon a mailbox-domain with a prescribed mail-channel invites litigation. 9) A prescribed closed-ended mail-channel breaks SMTP. 10) An open-ended prescribed mail-channel, when combined with mailbox-domain reputation, invites spoofing. 11) An open-ended prescribed mail-channel, when reputation is based upon the administrator, does not invite spoofing nor breaks SMTP. 12) Prescribing a mail-channel using a root-name-list of HELO domains is achieved within a single lookup without the need for script. 13) Prescribing a mail-channel using a comprehensive address-list may require many scripts and perhaps hundreds of lookups to resolve. 14) Any script, especially extensible scripts, pose risk. 15) Script within email imposes greater risk than that in a browser. 16) Script within email & DNS imposes greater risk than script in email. -Doug From owner-ietf-mxcomp@mail.imc.org Mon Nov 1 13:38:28 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16068 for ; Mon, 1 Nov 2004 13:38:27 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA1HpNhs014825; Mon, 1 Nov 2004 09:51:23 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA1HpNmS014824; Mon, 1 Nov 2004 09:51:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA1HpN1f014753 for ; Mon, 1 Nov 2004 09:51:23 -0800 (PST) (envelope-from hkatz@exchange.microsoft.com) Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 Nov 2004 09:51:21 -0800 Received: from red-hub-02.redmond.corp.microsoft.com ([157.54.7.100]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 Nov 2004 09:51:20 -0800 Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by red-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 Nov 2004 09:51:21 -0800 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 Nov 2004 09:51:17 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C4C03B.645EA374" Subject: draft-katz-submitter-00 Date: Mon, 1 Nov 2004 09:51:19 -0800 Message-ID: X-MS-Has-Attach: yes Thread-Topic: draft-katz-submitter-00 Thread-Index: AcTAO2RFDWa3yaznSVazqsBnR8y9SQ== From: "Harry Katz" To: "IETF MARID WG" Cc: "Eric Allman" X-OriginalArrivalTime: 01 Nov 2004 17:51:17.0149 (UTC) FILETIME=[631A54D0:01C4C03B] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C4C03B.645EA374 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The attached Sender ID specification, draft-katz-submitter-00, is being submitted to the IETF as an experimental Internet draft along with draft-lyon-senderid-pra-00 and draft-lyon-senderid-core-00.=20 These three drafts capture discussions held during the last few weeks of the MARID working group, as well as some subsequent feedback we've received. In summary, we've made two key changes to the Sender ID Framework: 1. The Sender ID Framework now allows receiving systems to choose which identity to validate; either the RFC2821 MAIL FROM address (aka "envelope from") or the purported responsible address (PRA) derived from RFC2822 message headers.=20 2. Sender ID is now backward compatible with any published SPF records in DNS. These records can be used for both MAIL FROM and PRA checks. We believe that the information that most sending domains need to publish in DNS will be the same for both checks. However domains which need to publish different IP addresses for each test can do so using a revised version of the SPF record syntax. Note that these specifications refer to draft-lentczner-spf-00 for the definition of the SPF record format and protocol.=20 This draft won't appear on the IETF web site until after the IETF meeting in Washington, D.C. Until then, here's the text version. A PDF version is available at http://www.microsoft.com/senderid .=20 Thanks. ------_=_NextPart_001_01C4C03B.645EA374 Content-Type: text/plain; name="draft-katz-submitter-00.txt" Content-Description: draft-katz-submitter-00.txt Content-Disposition: attachment; filename="draft-katz-submitter-00.txt" Content-Transfer-Encoding: base64 DQoNCg0KDQogICBJbnRlcm5ldCBEcmFmdCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIEUuIEFsbG1hbg0KICAgQ2F0ZWdvcnk6IEV4cGVyaW1lbnRhbCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFNlbmRtYWlsLCBJbmMNCiAgIERvY3VtZW50OiBkcmFm dC1rYXR6LXN1Ym1pdHRlci0wMC50eHQgICAgICAgICAgICAgICAgICAgICAgICBILiBLYXR6DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBN aWNyb3NvZnQgQ29ycA0KICAgRXhwaXJlczogIEFwcmlsIDIwMDUgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBPY3RvYmVyIDIwMDQNCg0KDQogICAgICAgICAgICAgICAgICAgICAg ICBTTVRQIFNlcnZpY2UgRXh0ZW5zaW9uIGZvcg0KICAgICAgICAgSW5kaWNhdGluZyB0aGUgUmVz cG9uc2libGUgU3VibWl0dGVyIG9mIGFuIEUtbWFpbCBNZXNzYWdlDQoNCg0KU3RhdHVzIG9mIHRo aXMgTWVtbw0KDQogICBCeSBzdWJtaXR0aW5nIHRoaXMgSW50ZXJuZXQtRHJhZnQsIEkgY2VydGlm eSB0aGF0IGFueSBhcHBsaWNhYmxlDQogICBwYXRlbnQgb3Igb3RoZXIgSVBSIGNsYWltcyBvZiB3 aGljaCBJIGFtIGF3YXJlIGhhdmUgYmVlbiBkaXNjbG9zZWQsDQogICBvciB3aWxsIGJlIGRpc2Ns b3NlZCwgYW5kIGFueSBvZiB3aGljaCBJIGJlY29tZSBhd2FyZSB3aWxsIGJlDQogICBkaXNjbG9z ZWQsIGluIGFjY29yZGFuY2Ugd2l0aCBSRkMgMzY2OC4gW1NURF0NCg0KICAgSW50ZXJuZXQtRHJh ZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiBUYXNrIEZvcmNlIChJRVRGKSwgaXRzDQogICBh cmVhcywgYW5kIGl0cyB3b3JraW5nIGdyb3Vwcy4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5 IGFsc28NCiAgIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRz Lg0KDQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBt YXhpbXVtIG9mIHNpeCBtb250aHMNCiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9y IG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55DQogICB0aW1lLiAgSXQgaXMgaW5h cHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQ0KICAgbWF0ZXJp YWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIg0KDQog ICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQN CiAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0DQogICBU aGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMgY2FuIGJlIGFjY2Vz c2VkIGF0DQogICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuDQoNCg0KQ29w eXJpZ2h0IE5vdGljZQ0KDQogICBDb3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgy MDA0KS4gQWxsIFJpZ2h0cyBSZXNlcnZlZC4NCg0KDQpBYnN0cmFjdA0KDQogICBUaGlzIG1lbW8g ZGVmaW5lcyBhbiBleHRlbnNpb24gdG8gdGhlIFNpbXBsZSBNYWlsIFRyYW5zZmVyIFByb3RvY29s DQogICAoU01UUCkgc2VydmljZSwgd2hpY2ggYWxsb3dzIGFuIFNNVFAgY2xpZW50IHRvIHNwZWNp ZnkgdGhlDQogICByZXNwb25zaWJsZSBzdWJtaXR0ZXIgb2YgYW4gZS1tYWlsIG1lc3NhZ2UuICBU aGUgcmVzcG9uc2libGUNCiAgIHN1Ym1pdHRlciBpcyB0aGUgZS1tYWlsIGFkZHJlc3Mgb2YgdGhl IGVudGl0eSBtb3N0IHJlY2VudGx5DQogICByZXNwb25zaWJsZSBmb3IgaW50cm9kdWNpbmcgYSBt ZXNzYWdlIGludG8gdGhlIHRyYW5zcG9ydCBzdHJlYW0uDQogICBUaGlzIGV4dGVuc2lvbiBoZWxw cyByZWNlaXZpbmcgZS1tYWlsIHNlcnZlcnMgZWZmaWNpZW50bHkgZGV0ZXJtaW5lDQogICB3aGV0 aGVyIHRoZSBTTVRQIGNsaWVudCBpcyBhdXRob3JpemVkIHRvIHRyYW5zbWl0IG1haWwgb24gYmVo YWxmIG9mDQogICB0aGUgcmVzcG9uc2libGUgc3VibWl0dGVyJ3MgZG9tYWluLg0KDQoNCg0KQWxs bWFuLCBLYXR6ICAgICAgICAgICAgIEV4cGlyZXMgLSBBcHJpbCAyMDA1ICAgICAgICAgICAgICAg ICBbUGFnZSAxXQ0KDA0KICAgICAgICAgICAgICAgICBTTVRQIFJlc3BvbnNpYmxlIFN1Ym1pdHRl ciBFeHRlbnNpb24gICAgIE9jdG9iZXIgMjAwNA0KDQoNCg0KQ29udmVudGlvbnMgVXNlZCBpbiBU aGlzIERvY3VtZW50DQoNCiAgIEluIGV4YW1wbGVzLCAiQzoiIGFuZCAiUzoiIGluZGljYXRlIGxp bmVzIHNlbnQgYnkgdGhlIGNsaWVudCBhbmQNCiAgIHNlcnZlciByZXNwZWN0aXZlbHkuDQoNCiAg IFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAi U0hBTEwgTk9UIiwNCiAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJN QVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzDQogICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJw cmV0ZWQgYXMgZGVzY3JpYmVkIGluIFJGQy0yMTE5IFtLRVlXT1JEU10uDQoNCg0KVGFibGUgb2Yg Q29udGVudHMNCg0KICAgMS4gSW50cm9kdWN0aW9uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMg0KICAgMi4gVGhlIFNVQk1JVFRFUiBTZXJ2aWNlIEV4 dGVuc2lvbi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNA0KICAgMy4gVGhlIFNVQk1J VFRFUiBLZXl3b3JkIG9mIHRoZSBFSExPIENvbW1hbmQuLi4uLi4uLi4uLi4uLi4uLi4uLi4uNA0K ICAgNC4gVGhlIFNVQk1JVFRFUiBQYXJhbWV0ZXIgb2YgdGhlIE1BSUwgQ29tbWFuZC4uLi4uLi4u Li4uLi4uLi4uLi4uNA0KICAgICAgNC4xIFNldHRpbmcgdGhlIFNVQk1JVFRFUiBQYXJhbWV0ZXIg VmFsdWUuLi4uLi4uLi4uLi4uLi4uLi4uLi4uNQ0KICAgICAgNC4yIFByb2Nlc3NpbmcgdGhlIFNV Qk1JVFRFUiBQYXJhbWV0ZXIuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNQ0KICAgICAgNC4zIFRy YW5zbWl0dGluZyB0byBhIE5vbi1TVUJNSVRURVIgQXdhcmUgU01UUCBTZXJ2ZXIuLi4uLi4uLi4u Ng0KICAgNS4gRXhhbXBsZXMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uNg0KICAgICAgNS4xIE1haWwgU3VibWlzc2lvbi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNg0KICAgICAgNS4yIE1haWwgRm9yd2FyZGlu Zy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNw0KICAgICAgNS4z IE1vYmlsZSBVc2VyLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uOA0KICAgICAgNS40IEd1ZXN0IEUtbWFpbCBTZXJ2aWNlLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uOQ0KICAgICAgNS41IFNVQk1JVFRFUiBVc2VkIG9uIGEgTm9uLURl bGl2ZXJ5IFJlcG9ydC4uLi4uLi4uLi4uLi4uLi4uLi4xMA0KICAgNi4gU2VjdXJpdHkgQ29uc2lk ZXJhdGlvbnMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMA0KICAgNy4g SUFOQSBDb25zaWRlcmF0aW9ucy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4xMQ0KICAgOC4gUmVmZXJlbmNlcy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4xMQ0KICAgICAgOC4xIE5vcm1hdGl2ZSBSZWZlcmVuY2VzLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMQ0KICAgICAgOC4yIEluZm9ybWF0 aXZlIFJlZmVyZW5jZXMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMg0KICAg OS4gQWNrbm93bGVkZ21lbnRzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4xMg0KICAgMTAuIEF1dGhvcnMnIEFkZHJlc3Nlcy4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMg0KICAgMTEuIENoYW5nZSBIaXN0b3J5Li4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMw0KICAgMTIuIEZ1bGwgQ29w eXJpZ2h0IFN0YXRlbWVudC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xNQ0K DQoNCjEuIEludHJvZHVjdGlvbg0KDQogICBUaGUgcHJhY3RpY2Ugb2YgZmFsc2lmeWluZyB0aGUg aWRlbnRpdHkgb2YgdGhlIHNlbmRlciBvZiBhbiBlLW1haWwNCiAgIG1lc3NhZ2UsIGNvbW1vbmx5 IGNhbGxlZCAic3Bvb2ZpbmciLCBpcyBhIHByZXZhbGVudCB0YWN0aWMgdXNlZCBieQ0KICAgc2Vu ZGVycyBvZiB1bnNvbGljaXRlZCBjb21tZXJjaWFsIGUtbWFpbCBvciAic3BhbSIuICBUaGlzIGZv cm0gb2YNCiAgIGFidXNlIGhhcyBoaWdobGlnaHRlZCB0aGUgbmVlZCB0byBpbXByb3ZlIGlkZW50 aWZpY2F0aW9uIG9mIHRoZQ0KICAgInJlc3BvbnNpYmxlIHN1Ym1pdHRlciIgb2YgYW4gZS1tYWls IG1lc3NhZ2UuDQoNCiAgIEluIHRoaXMgc3BlY2lmaWNhdGlvbiwgdGhlIHJlc3BvbnNpYmxlIHN1 Ym1pdHRlciBpcyB0aGUgZW50aXR5IG1vc3QNCiAgIHJlY2VudGx5IHJlc3BvbnNpYmxlIGZvciBp bmplY3RpbmcgYSBtZXNzYWdlIGludG8gdGhlIGUtbWFpbA0KICAgdHJhbnNwb3J0IHN0cmVhbS4g IFRoZSBlLW1haWwgYWRkcmVzcyBvZiB0aGUgcmVzcG9uc2libGUgc3VibWl0dGVyDQogICB3aWxs IGJlIHJlZmVycmVkIHRvIGFzIHRoZSAicHVycG9ydGVkIHJlc3BvbnNpYmxlIGFkZHJlc3MiIChQ UkEpIG9mDQoNCg0KQWxsbWFuLCBLYXR6ICAgICAgICAgICAgIEV4cGlyZXMgLSBNYXJjaCAyMDA1 ICAgICAgICAgICAgICAgICBbUGFnZSAyXQ0KDA0KICAgICAgICAgICAgICAgICBTTVRQIFJlc3Bv bnNpYmxlIFN1Ym1pdHRlciBFeHRlbnNpb24gICAgIE9jdG9iZXIgMjAwNA0KDQoNCiAgIHRoZSBt ZXNzYWdlLiAgVGhlICJwdXJwb3J0ZWQgcmVzcG9uc2libGUgZG9tYWluIiAoUFJEKSBpcyB0aGUg ZG9tYWluDQogICBwb3J0aW9uIG9mIHRoYXQgYWRkcmVzcy4NCg0KICAgVGhpcyBzcGVjaWZpY2F0 aW9uIGNvZGlmaWVzIHJ1bGVzIGZvciBlbmNvZGluZyB0aGUgcHVycG9ydGVkDQogICByZXNwb25z aWJsZSBhZGRyZXNzIGludG8gdGhlIFNNVFAgdHJhbnNwb3J0IHByb3RvY29sLiAgVGhpcyB3aWxs DQogICBwZXJtaXQgcmVjZWl2aW5nIFNNVFAgc2VydmVycyB0byBlZmZpY2llbnRseSB2YWxpZGF0 ZSB3aGV0aGVyIG9yIG5vdA0KICAgdGhlIFNNVFAgY2xpZW50IGlzIGF1dGhvcml6ZWQgdG8gdHJh bnNtaXQgbWFpbCBvbiBiZWhhbGYgb2YgdGhlDQogICByZXNwb25zaWJsZSBzdWJtaXR0ZXIncyBk b21haW4uDQoNCiAgIEJyb2FkbHkgc3BlYWtpbmcsIHRoZXJlIGFyZSB0d28gcG9zc2libGUgYXBw cm9hY2hlcyBmb3IgZGV0ZXJtaW5pbmcNCiAgIHRoZSBwdXJwb3J0ZWQgcmVzcG9uc2libGUgYWRk cmVzczsgZWl0aGVyIGZyb20gUkZDIDI4MjEgW1NNVFBdDQogICBwcm90b2NvbCBkYXRhIG9yIGZy b20gUkZDIDI4MjIgW01TRy1GT1JNQVRdIG1lc3NhZ2UgaGVhZGVycy4gIEVhY2gNCiAgIGFwcHJv YWNoIGhhcyBjZXJ0YWluIGFkdmFudGFnZXMgYW5kIGRpc2FkdmFudGFnZXMuDQoNCiAgIERlcml2 aW5nIHRoZSBwdXJwb3J0ZWQgcmVzcG9uc2libGUgZG9tYWluIGZyb20gUkZDIDI4MjEgZGF0YSBo YXMgdGhlDQogICBhZHZhbnRhZ2UgdGhhdCB2YWxpZGF0aW9uIGNhbiBiZSBwZXJmb3JtZWQgYmVm b3JlIHRoZSBTTVRQIGNsaWVudCBoYXMNCiAgIHRyYW5zbWl0dGVkIHRoZSBtZXNzYWdlIGJvZHku ICBJZiBzcG9vZmluZyBpcyBkZXRlY3RlZCwgdGhlbiB0aGUgU01UUA0KICAgc2VydmVyIGhhcyB0 aGUgb3Bwb3J0dW5pdHksIGRlcGVuZGluZyB1cG9uIGxvY2FsIHBvbGljeSwgdG8gcmVqZWN0DQog ICB0aGUgbWVzc2FnZSBiZWZvcmUgaXQgaXMgZXZlciB0cmFuc21pdHRlZC4gIFRoZSBkaXNhZHZh bnRhZ2Ugb2YgdGhpcw0KICAgYXBwcm9hY2ggaXMgdGhlIHJpc2sgb2YgZmFsc2UgcG9zaXRpdmVz LCB0aGF0IGlzLCBpbmNvcnJlY3RseQ0KICAgY29uY2x1ZGluZyB0aGF0IHRoZSBzZW5kZXIncyBl LW1haWwgYWRkcmVzcyBoYXMgYmVlbiBzcG9vZmVkLiAgVGhlcmUNCiAgIGFyZSB0b2RheSBsZWdp dGltYXRlIHJlYXNvbnMgd2h5IHRoZSBJbnRlcm5ldCBkb21haW4gbmFtZXMgdXNlZCBpbg0KICAg UkZDIDI4MjEgY29tbWFuZHMgbWF5IGJlIGRpZmZlcmVudCBmcm9tIHRoYXQgb2YgdGhlIHNlbmRl ciBvZiBhbiBlLQ0KICAgbWFpbCBtZXNzYWdlLg0KDQogICBEZXJpdmluZyB0aGUgcHVycG9ydGVk IHJlc3BvbnNpYmxlIGRvbWFpbiBmcm9tIFJGQyAyODIyIGhlYWRlcnMgaGFzDQogICB0aGUgYWR2 YW50YWdlIHRoYXQgdmFsaWRhdGlvbiBjYW4gdXN1YWxseSBiZSBiYXNlZCBvbiBhbiBpZGVudGl0 eQ0KICAgdGhhdCBpcyBkaXNwbGF5ZWQgdG8gcmVjaXBpZW50cyBieSBleGlzdGluZyBNVUFzIGFz IHRoZSBzZW5kZXIncw0KICAgaWRlbnRpdHkuICBUaGlzIGFpZHMgaW4gZGV0ZWN0aW9uIG9mIGEg cGFydGljdWxhcmx5IG5veGlvdXMgZm9ybSBvZg0KICAgc3Bvb2Zpbmcga25vd24gYXMgInBoaXNo aW5nIiBpbiB3aGljaCBhIG1hbGljaW91cyBzZW5kZXIgYXR0ZW1wdHMgdG8NCiAgIGZvb2wgYSBy ZWNpcGllbnQgaW50byBiZWxpZXZpbmcgdGhhdCBhIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIGFu DQogICBlbnRpdHkgd2VsbCBrbm93biB0byB0aGUgcmVjaXBpZW50LiAgVGhpcyBhcHByb2FjaCBj YXJyaWVzIGEgbG93ZXINCiAgIHJpc2sgb2YgZmFsc2UgcG9zaXRpdmVzIHNpbmNlIHRoZXJlIGFy ZSBmZXdlciBsZWdpdGltYXRlIHJlYXNvbnMgZm9yDQogICBSRkMgMjgyMiBoZWFkZXJzIHRvIGRp ZmZlciBmcm9tIHRoZSB0cnVlIHNlbmRlciBvZiB0aGUgbWVzc2FnZS4gIFRoZQ0KICAgZGlzYWR2 YW50YWdlIG9mIHRoaXMgYXBwcm9hY2ggaXMgdGhhdCBpdCBkb2VzIHJlcXVpcmUgcGFyc2luZyBh bmQNCiAgIGFuYWx5c2lzIG9mIG1lc3NhZ2UgaGVhZGVycy4gIEluIHByYWN0aWNlLCBtdWNoIGlm IG5vdCBhbGwgdGhlDQogICBtZXNzYWdlIGJvZHkgaXMgYWxzbyB0cmFuc21pdHRlZCBzaW5jZSB0 aGUgU01UUCBwcm90b2NvbCBkZXNjcmliZWQgaW4NCiAgIFJGQyAyODIxIHByb3ZpZGVzIG5vIG1l Y2hhbmlzbSB0byBpbnRlcnJ1cHQgbWVzc2FnZSB0cmFuc21pc3Npb24NCiAgIGFmdGVyIHRoZSBE QVRBIGNvbW1hbmQgaGFzIGJlZW4gaXNzdWVkLg0KDQogICBJdCBpcyBkZXNpcmFibGUgdG8gdW5p ZnkgdGhlc2UgdHdvIGFwcHJvYWNoZXMgaW4gYSB3YXkgdGhhdCBjb21iaW5lcw0KICAgdGhlIGJl bmVmaXRzIG9mIGJvdGggd2hpbGUgbWluaW1pemluZyB0aGVpciByZXNwZWN0aXZlIGRpc2FkdmFu dGFnZXMuDQoNCiAgIFRoaXMgc3BlY2lmaWNhdGlvbiBkZXNjcmliZXMganVzdCBzdWNoIGEgdW5p ZmllZCBhcHByb2FjaC4gIEl0IHVzZXMNCiAgIHRoZSBtZWNoYW5pc20gZGVzY3JpYmVkIGluIFtT TVRQXSB0byBkZXNjcmliZSBhbiBleHRlbnNpb24gdG8gdGhlDQogICBTTVRQIHByb3RvY29sLiAg VXNpbmcgdGhpcyBleHRlbnNpb24sIGFuIFNNVFAgY2xpZW50IGNhbiBzcGVjaWZ5IHRoZQ0KICAg ZS1tYWlsIGFkZHJlc3Mgb2YgdGhlIGVudGl0eSBtb3N0IHJlY2VudGx5IHJlc3BvbnNpYmxlIGZv ciBzdWJtaXR0aW5nDQogICB0aGUgbWVzc2FnZSB0byB0aGUgU01UUCBjbGllbnQgaW4gYSBuZXcg U1VCTUlUVEVSIHBhcmFtZXRlciBvZiB0aGUNCiAgIFNNVFAgTUFJTCBjb21tYW5kLiAgU01UUCBz ZXJ2ZXJzIGNhbiB1c2UgdGhpcyBpbmZvcm1hdGlvbiB0byB2YWxpZGF0ZQ0KDQoNCkFsbG1hbiwg S2F0eiAgICAgICAgICAgICBFeHBpcmVzIC0gQXByaWwgMjAwNSAgICAgICAgICAgICAgICAgW1Bh Z2UgM10NCgwNCiAgICAgICAgICAgICAgICAgU01UUCBSZXNwb25zaWJsZSBTdWJtaXR0ZXIgRXh0 ZW5zaW9uICAgICBPY3RvYmVyIDIwMDQNCg0KDQogICB0aGF0IHRoZSBTTVRQIGNsaWVudCBpcyBh dXRob3JpemVkIHRvIHRyYW5zbWl0IGUtbWFpbCBvbiBiZWhhbGYgb2YNCiAgIHRoZSBJbnRlcm5l dCBkb21haW4gY29udGFpbmVkIGluIHRoZSBTVUJNSVRURVIgcGFyYW1ldGVyLg0KDQoNCjIuIFRo ZSBTVUJNSVRURVIgU2VydmljZSBFeHRlbnNpb24NCg0KICAgVGhlIGZvbGxvd2luZyBTTVRQIHNl cnZpY2UgZXh0ZW5zaW9uIGlzIGhlcmVieSBkZWZpbmVkOg0KDQogICAoMSkgIFRoZSBuYW1lIG9m IHRoaXMgU01UUCBzZXJ2aWNlIGV4dGVuc2lvbiBpcyAiUmVzcG9uc2libGUNCiAgICAgICAgU3Vi bWl0dGVyIjsNCg0KICAgKDIpICBUaGUgRUhMTyBrZXl3b3JkIHZhbHVlIGFzc29jaWF0ZWQgd2l0 aCB0aGlzIGV4dGVuc2lvbiBpcw0KICAgICAgICAiU1VCTUlUVEVSIjsNCg0KICAgKDMpICBUaGUg U1VCTUlUVEVSIGtleXdvcmQgaGFzIG5vIHBhcmFtZXRlcnM7DQoNCiAgICg0KSAgTm8gYWRkaXRp b25hbCBTTVRQIHZlcmJzIGFyZSBkZWZpbmVkIGJ5IHRoaXMgZXh0ZW5zaW9uOw0KDQogICAoNSkg IEFuIG9wdGlvbmFsIHBhcmFtZXRlciBpcyBhZGRlZCB0byB0aGUgTUFJTCBjb21tYW5kIHVzaW5n IHRoZQ0KICAgICAgICBlc210cC1rZXl3b3JkICJTVUJNSVRURVIiLCBhbmQgaXMgdXNlZCB0byBz cGVjaWZ5IHRoZSBlLW1haWwNCiAgICAgICAgYWRkcmVzcyBvZiB0aGUgZW50aXR5IHJlc3BvbnNp YmxlIGZvciBzdWJtaXR0aW5nIHRoZSBtZXNzYWdlIGZvcg0KICAgICAgICBkZWxpdmVyeTsNCg0K ICAgKDYpICBUaGlzIGV4dGVuc2lvbiBpcyBhcHByb3ByaWF0ZSBmb3IgdGhlIHN1Ym1pc3Npb24g cHJvdG9jb2wNCiAgICAgICAgW1NVQk1JVF0uDQoNCg0KMy4gVGhlIFNVQk1JVFRFUiBLZXl3b3Jk IG9mIHRoZSBFSExPIENvbW1hbmQNCg0KICAgQW4gU01UUCBzZXJ2ZXIgaW5jbHVkZXMgdGhlIFNV Qk1JVFRFUiBrZXl3b3JkIGluIGl0cyBFSExPIHJlc3BvbnNlIHRvDQogICB0ZWxsIHRoZSBTTVRQ IGNsaWVudCB0aGF0IHRoZSBTVUJNSVRURVIgc2VydmljZSBleHRlbnNpb24gaXMNCiAgIHN1cHBv cnRlZC4NCg0KICAgVGhlIFNVQk1JVFRFUiBrZXl3b3JkIGhhcyBubyBwYXJhbWV0ZXJzLg0KDQoN CjQuIFRoZSBTVUJNSVRURVIgUGFyYW1ldGVyIG9mIHRoZSBNQUlMIENvbW1hbmQNCg0KICAgVGhl IHN5bnRheCBvZiB0aGUgU1VCTUlUVEVSIHBhcmFtZXRlciBpczoNCg0KICAgICAgIlNVQk1JVFRF Uj0iIE1haWxib3gNCg0KICAgd2hlcmUgTWFpbGJveCBpcyB0aGUgQUJORiBbQUJORl0gcHJvZHVj dGlvbiBkZWZpbmVkIGluIFNlY3Rpb24gNC4xLjINCiAgIG9mIFtTTVRQXS4gIENoYXJhY3RlcnMg c3VjaCBhcyBTUCwgIisiIGFuZCAiPSIgd2hpY2ggbWF5IG9jY3VyIGluDQogICBNYWlsYm94IGJ1 dCBhcmUgbm90IHBlcm1pdHRlZCBpbiBFU01UUCBwYXJhbWV0ZXIgdmFsdWVzIE1VU1QgYmUNCiAg IGVuY29kZWQgYXMgInh0ZXh0IiBhcyBkZXNjcmliZWQgaW4gc2VjdGlvbiA0IG9mIFtEU05dLg0K DQoNCg0KDQoNCkFsbG1hbiwgS2F0eiAgICAgICAgICAgICBFeHBpcmVzIC0gQXByaWwgMjAwNSAg ICAgICAgICAgICAgICAgW1BhZ2UgNF0NCgwNCiAgICAgICAgICAgICAgICAgU01UUCBSZXNwb25z aWJsZSBTdWJtaXR0ZXIgRXh0ZW5zaW9uICAgICBPY3RvYmVyIDIwMDQNCg0KDQo0LjEgU2V0dGlu ZyB0aGUgU1VCTUlUVEVSIFBhcmFtZXRlciBWYWx1ZQ0KDQogICBUaGUgcHVycG9zZSBvZiB0aGUg U1VCTUlUVEVSIHBhcmFtZXRlciBpcyB0byBhbGxvdyB0aGUgU01UUCBjbGllbnQgdG8NCiAgIGlu ZGljYXRlIHRvIHRoZSBzZXJ2ZXIgdGhlIHB1cnBvcnRlZCByZXNwb25zaWJsZSBhZGRyZXNzIG9m IHRoZQ0KICAgbWVzc2FnZSBkaXJlY3RseSBpbiB0aGUgUkZDIDI4MjEgcHJvdG9jb2wuDQoNCiAg IFRoZXJlZm9yZSwgU01UUCBjbGllbnRzIHRoYXQgc3VwcG9ydCB0aGUgUmVzcG9uc2libGUgU3Vi bWl0dGVyDQogICBleHRlbnNpb24gTVVTVCBpbmNsdWRlIHRoZSBTVUJNSVRURVIgcGFyYW1ldGVy IG9uIGFsbCBtZXNzYWdlcy4gIFRoaXMNCiAgIGluY2x1ZGVzIG1lc3NhZ2VzIGNvbnRhaW5pbmcg YSBudWxsIHJldmVyc2UtcGF0aCBpbiB0aGUgTUFJTCBjb21tYW5kLg0KDQogICBTTVRQIGNsaWVu dHMgTVVTVCBzZXQgdGhlIFNVQk1JVFRFUiBwYXJhbWV0ZXIgdmFsdWUgdG8gdGhlIHB1cnBvcnRl ZA0KICAgcmVzcG9uc2libGUgYWRkcmVzcyBvZiB0aGUgbWVzc2FnZSBhcyBkZWZpbmVkIGluIFtQ UkFdLiAgVGhpcyBhbHNvDQogICBhcHBsaWVzIHRvIG1lc3NhZ2VzIGNvbnRhaW5pbmcgYSBudWxs IHJldmVyc2UtcGF0aC4NCg0KICAgSW4gc29tZSBjaXJjdW1zdGFuY2VzLCBkZXNjcmliZWQgaW4g c2VjdGlvbiA3IG9mIFtTRU5ERVItSURdLCBTTVRQDQogICBjbGllbnRzIG1heSBuZWVkIHRvIGFk ZCBSRkMgMjgyMiBoZWFkZXJzIHRvIHRoZSBtZXNzYWdlIGluIG9yZGVyIHRvDQogICBlbnN1cmUg dGhhdCB0aGUgY29ycmVjdCBTVUJNSVRURVIgcGFyYW1ldGVyIHZhbHVlIGNhbiBiZSBzZXQuDQoN CjQuMiBQcm9jZXNzaW5nIHRoZSBTVUJNSVRURVIgUGFyYW1ldGVyDQoNCiAgIFJlY2VpdmVycyBv ZiBlLW1haWwgbWVzc2FnZXMgc2VudCB3aXRoIHRoZSBTVUJNSVRURVIgcGFyYW1ldGVyIFNIT1VM RA0KICAgc2VsZWN0IHRoZSBkb21haW4gcGFydCBvZiB0aGUgU1VCTUlUVEVSIGFkZHJlc3MgdmFs dWUgYXMgdGhlDQogICBwdXJwb3J0ZWQgcmVzcG9uc2libGUgZG9tYWluIG9mIHRoZSBtZXNzYWdl LCBhbmQgU0hPVUxEIHBlcmZvcm0gc3VjaA0KICAgdGVzdHMsIGluY2x1ZGluZyB0aG9zZSBkZWZp bmVkIGluIFtTRU5ERVItSURdLCBhcyBhcmUgZGVlbWVkDQogICBuZWNlc3NhcnkgdG8gZGV0ZXJt aW5lIHdoZXRoZXIgdGhlIGNvbm5lY3RpbmcgU01UUCBjbGllbnQgaXMNCiAgIGF1dGhvcml6ZWQg dG8gdHJhbnNtaXQgZS1tYWlsIG1lc3NhZ2VzIG9uIGJlaGFsZiBvZiB0aGF0IGRvbWFpbi4NCg0K ICAgSWYgdGhlc2UgdGVzdHMgaW5kaWNhdGUgdGhhdCB0aGUgY29ubmVjdGluZyBTTVRQIGNsaWVu dCBpcyBub3QNCiAgIGF1dGhvcml6ZWQgdG8gdHJhbnNtaXQgZS1tYWlsIG1lc3NhZ2VzIG9uIGJl aGFsZiBvZiB0aGUgU1VCTUlUVEVSDQogICBkb21haW4sIHRoZSByZWNlaXZpbmcgU01UUCBzZXJ2 ZXIgU0hPVUxEIHJlamVjdCB0aGUgbWVzc2FnZSBhbmQgd2hlbg0KICAgcmVqZWN0aW5nIE1VU1Qg dXNlICI1NTAgNS43LjEgU3VibWl0dGVyIG5vdCBhbGxvd2VkLiINCg0KICAgSWYgdGhlIHJlY2Vp dmluZyBTTVRQIHNlcnZlciBhbGxvd3MgdGhlIGNvbm5lY3RpbmcgU01UUCBjbGllbnQgdG8NCiAg IHRyYW5zbWl0IG1lc3NhZ2UgZGF0YSwgdGhlbiB0aGUgc2VydmVyIFNIT1VMRCBkZXRlcm1pbmUg dGhlIHB1cnBvcnRlZA0KICAgcmVzcG9uc2libGUgYWRkcmVzcyBvZiB0aGUgbWVzc2FnZSBieSBl eGFtaW5pbmcgdGhlIFJGQyAyODIyIG1lc3NhZ2UNCiAgIGhlYWRlcnMgYXMgZGVzY3JpYmVkIGlu IFtQUkFdLiAgSWYgdGhpcyBwdXJwb3J0ZWQgcmVzcG9uc2libGUgYWRkcmVzcw0KICAgZG9lcyBu b3QgbWF0Y2ggdGhlIGFkZHJlc3MgYXBwZWFyaW5nIGluIHRoZSBTVUJNSVRURVIgcGFyYW1ldGVy LCB0aGUNCiAgIHJlY2VpdmluZyBTTVRQIHNlcnZlciBNVVNUIHJlamVjdCB0aGUgbWVzc2FnZSBh bmQgd2hlbiByZWplY3RpbmcgTVVTVA0KICAgdXNlICI1NTAgNS43LjEgU3VibWl0dGVyIGRvZXMg bm90IG1hdGNoIGhlYWRlci4iDQoNCiAgIElmIG5vIHB1cnBvcnRlZCByZXNwb25zaWJsZSBhZGRy ZXNzIGlzIGZvdW5kIGFjY29yZGluZyB0byB0aGUNCiAgIHByb2NlZHVyZSBkZWZpbmVkIGluIFtQ UkFdLCB0aGUgU01UUCBzZXJ2ZXIgU0hPVUxEIHJlamVjdCB0aGUgbWVzc2FnZQ0KICAgYW5kIHdo ZW4gcmVqZWN0aW5nIE1VU1QgdXNlICI1NTQgNS43LjcgQ2Fubm90IHZlcmlmeSBzdWJtaXR0ZXIN CiAgIGFkZHJlc3MuIg0KDQogICBWZXJpZnlpbmcgTVRBcyBhcmUgc3Ryb25nbHkgdXJnZWQgdG8g dmFsaWRhdGUgdGhlIFNVQk1JVFRFUiBwYXJhbWV0ZXINCiAgIGFnYWluc3QgdGhlIFJGQyAyODIy IGhlYWRlcnM7IG90aGVyd2lzZSwgYW4gYXR0YWNrZXIgY2FuIHRyaXZpYWxseQ0KICAgZGVmZWF0 IHRoZSBhbGdvcml0aG0uDQoNCg0KDQpBbGxtYW4sIEthdHogICAgICAgICAgICAgRXhwaXJlcyAt IEFwcmlsIDIwMDUgICAgICAgICAgICAgICAgIFtQYWdlIDVdDQoMDQogICAgICAgICAgICAgICAg IFNNVFAgUmVzcG9uc2libGUgU3VibWl0dGVyIEV4dGVuc2lvbiAgICAgT2N0b2JlciAyMDA0DQoN Cg0KICAgTm90ZSB0aGF0IHRoZSBwcmVzZW5jZSBvZiB0aGUgU1VCTUlUVEVSIHBhcmFtZXRlciBv biB0aGUgTUFJTCBjb21tYW5kDQogICBNVVNUIE5PVCBjaGFuZ2UgdGhlIGVmZmVjdGl2ZSByZXZl cnNlLXBhdGggb2YgYSBtZXNzYWdlLiAgQW55DQogICBkZWxpdmVyeSBzdGF0dXMgbm90aWZpY2F0 aW9ucyBtdXN0IGJlIHNlbnQgdG8gdGhlIHJldmVyc2UtcGF0aCwgaWYNCiAgIG9uZSBleGlzdHMs IGFzIHBlciBzZWN0aW9uIDMuNyBvZiBbU01UUF0gcmVnYXJkbGVzcyBvZiB0aGUgcHJlc2VuY2UN CiAgIG9mIGEgU1VCTUlUVEVSIHBhcmFtZXRlci4gIElmIHRoZSByZXZlcnNlLXBhdGggaXMgbnVs bCwgZGVsaXZlcnkNCiAgIHN0YXR1cyBub3RpZmljYXRpb25zIE1VU1QgTk9UIGJlIHNlbnQgdG8g dGhlIFNVQk1JVFRFUiBhZGRyZXNzLg0KDQogICBMaWtld2lzZSwgdGhlIFNVQk1JVFRFUiBwYXJh bWV0ZXIgTVVTVCBOT1QgY2hhbmdlIHRoZSBlZmZlY3RpdmUgcmVwbHkNCiAgIGFkZHJlc3Mgb2Yg YSBtZXNzYWdlLiAgUmVwbGllcyBNVVNUIGJlIHNlbnQgdG8gdGhlIEZyb20gYWRkcmVzcyBvcg0K ICAgdGhlIFJlcGx5LVRvIGFkZHJlc3MsIGlmIHByZXNlbnQsIGFzIGRlc2NyaWJlZCBpbiBzZWN0 aW9uIDMuNi4yIG9mDQogICBbTVNHLUZPUk1BVF0gcmVnYXJkbGVzcyBvZiB0aGUgcHJlc2VuY2Ug b2YgYSBTVUJNSVRURVIgcGFyYW1ldGVyLg0KDQo0LjMgVHJhbnNtaXR0aW5nIHRvIGEgTm9uLVNV Qk1JVFRFUiBBd2FyZSBTTVRQIFNlcnZlcg0KDQogICBOb3R3aXRoc3RhbmRpbmcgdGhlIHByb3Zp c2lvbnMgb2Ygc2VjdGlvbiA0LjEgYWJvdmUsIHdoZW4gYW4gTVRBDQogICB0cmFuc21pdHMgYSBt ZXNzYWdlIHRvIGFub3RoZXIgTVRBIHRoYXQgZG9lcyBub3Qgc3VwcG9ydCB0aGUNCiAgIFNVQk1J VFRFUiBleHRlbnNpb24sIHRoZSBmb3J3YXJkaW5nIE1UQSBNVVNUIHRyYW5zbWl0IHRoZSBtZXNz YWdlDQogICB3aXRob3V0IHRoZSBTVUJNSVRURVIgcGFyYW1ldGVyLiAgVGhpcyBzaG91bGQgaW52 b2x2ZSBubyBpbmZvcm1hdGlvbg0KICAgbG9zcywgc2luY2UgdGhlIFNVQk1JVFRFUiBwYXJhbWV0 ZXIgaXMgcmVxdWlyZWQgdG8gY29udGFpbg0KICAgaW5mb3JtYXRpb24gZGVyaXZlZCBmcm9tIHRo ZSBtZXNzYWdlIGhlYWRlcnMuDQoNCg0KNS4gRXhhbXBsZXMNCg0KICAgVGhpcyBzZWN0aW9uIHBy b3ZpZGVzIGV4YW1wbGVzIG9mIGhvdyB0aGUgU1VCTUlUVEVSIHBhcmFtZXRlciB3b3VsZA0KICAg YmUgdXNlZC4gIFRoZSBmb2xsb3dpbmcgZHJhbWF0aXMgcGVyc29uYWUgYXBwZWFyIGluIHRoZSBl eGFtcGxlczoNCg0KICAgYWxpY2VAZXhhbXBsZS5jb206IHRoZSBvcmlnaW5hbCBzZW5kZXIgb2Yg ZWFjaCBlLW1haWwgbWVzc2FnZS4NCg0KICAgYm9iQGNvbXBhbnkuY29tLmV4YW1wbGU6IHRoZSBm aW5hbCByZWNpcGllbnQgb2YgZWFjaCBlLW1haWwuDQoNCiAgIGJvYkBhbG1hbWF0ZXIuZWR1LmV4 YW1wbGU6IGFuIGVtYWlsIGFkZHJlc3MgdXNlZCBieSBCb2Igd2hpY2ggaGUgaGFzDQogICBjb25m aWd1cmVkIHRvIGZvcndhcmQgbWFpbCB0byBoaXMgb2ZmaWNlIGFjY291bnQgYXQNCiAgIGJvYkBj b21wYW55LmNvbS5leGFtcGxlLg0KDQogICBhbGljZUBtb2JpbGUubmV0LmV4YW1wbGU6IGFuIGUt bWFpbCBhY2NvdW50IHByb3ZpZGVkIHRvIEFsaWNlIGJ5IGhlcg0KICAgbW9iaWxlIGUtbWFpbCBu ZXR3b3JrIGNhcnJpZXIuDQoNCjUuMSBNYWlsIFN1Ym1pc3Npb24NCg0KICAgVW5kZXIgbm9ybWFs IGNpcmN1bXN0YW5jZXMsIEFsaWNlIHdvdWxkIGNvbmZpZ3VyZSBoZXIgTVVBIHRvIHN1Ym1pdA0K ICAgaGVyIG1lc3NhZ2UgdG8gdGhlIG1haWwgc3lzdGVtIHVzaW5nIHRoZSBTVUJNSVQgcHJvdG9j b2wgW1NVQk1JVF0uDQogICBUaGUgTVVBIHdvdWxkIHRyYW5zbWl0IHRoZSBtZXNzYWdlIHdpdGhv dXQgdGhlIFNVQk1JVFRFUiBwYXJhbWV0ZXIuDQogICBUaGUgU1VCTUlUIHNlcnZlciB3b3VsZCB2 YWxpZGF0ZSB0aGF0IHRoZSBNVUEgaXMgYWxsb3dlZCB0byBzdWJtaXQgYQ0KICAgbWVzc2FnZSB0 aHJvdWdoIHNvbWUgZXh0ZXJuYWwgc2NoZW1lLCBwZXJoYXBzIFNNVFAgQXV0aGVudGljYXRpb24N CiAgIFtTTVRQQVVUSF0uICBVbmRlciBtb3N0IGNpcmN1bXN0YW5jZXMgdGhpcyB3b3VsZCBsb29r IGxpa2UgYSBub3JtYWwsDQogICBhdXRoZW50aWNhdGVkIFNNVFAgdHJhbnNhY3Rpb24uICBUaGUg U1VCTUlUIHNlcnZlciB3b3VsZCBleHRyYWN0IGhlcg0KICAgbmFtZSBmcm9tIHRoZSBSRkMgMjgy MiBoZWFkZXJzIGZvciB1c2UgaW4gdGhlIFNVQk1JVFRFUiBwYXJhbWV0ZXJzIG9mDQogICBzdWJz ZXF1ZW50IHRyYW5zbWlzc2lvbnMgb2YgdGhlIG1lc3NhZ2UuDQoNCg0KQWxsbWFuLCBLYXR6ICAg ICAgICAgICAgIEV4cGlyZXMgLSBBcHJpbCAyMDA1ICAgICAgICAgICAgICAgICBbUGFnZSA2XQ0K DA0KICAgICAgICAgICAgICAgICBTTVRQIFJlc3BvbnNpYmxlIFN1Ym1pdHRlciBFeHRlbnNpb24g ICAgIE9jdG9iZXIgMjAwNA0KDQoNCjUuMiBNYWlsIEZvcndhcmRpbmcNCg0KICAgV2hlbiBBbGlj ZSBzZW5kcyBhIG1lc3NhZ2UgdG8gQm9iIGF0IGhpcyBhbG1hbWF0ZXIuZWR1LmV4YW1wbGUNCiAg IGFjY291bnQsIHRoZSBTTVRQIHNlc3Npb24gZnJvbSBoZXIgU1VCTUlUIHNlcnZlciBtaWdodCBs b29rIHNvbWV0aGluZw0KICAgbGlrZSB0aGlzOg0KDQoNCiAgICAgIFM6IDIyMCBhbG1hbWF0ZXIu ZWR1LmV4YW1wbGUgRVNNVFAgc2VydmVyIHJlYWR5DQogICAgICBDOiBFSExPIGV4YW1wbGUuY29t DQogICAgICBTOiAyNTAtYWxtYW1hdGVyLmVkdS5leGFtcGxlDQogICAgICBTOiAyNTAtRFNODQog ICAgICBTOiAyNTAtQVVUSA0KICAgICAgUzogMjUwLVNVQk1JVFRFUg0KICAgICAgUzogMjUwIFNJ WkUNCiAgICAgIEM6IE1BSUwgRlJPTTo8YWxpY2VAZXhhbXBsZS5jb20+IFNVQk1JVFRFUj1hbGlj ZUBleGFtcGxlLmNvbQ0KICAgICAgUzogMjUwIDxhbGljZUBleGFtcGxlLmNvbT4gc2VuZGVyIG9r DQogICAgICBDOiBSQ1BUIFRPOjxib2JAYWxtYW1hdGVyLmVkdS5leGFtcGxlPg0KICAgICAgUzog MjUwIDxib2JAYWxtYW1hdGVyLmVkdS5leGFtcGxlPiByZWNpcGllbnQgb2sNCiAgICAgIEM6IERB VEENCiAgICAgIFM6IDM1NCBva2F5LCBzZW5kIG1lc3NhZ2UNCiAgICAgIEM6IChtZXNzYWdlIGJv ZHkgZ29lcyBoZXJlKQ0KICAgICAgQzogLg0KICAgICAgUzogMjUwIG1lc3NhZ2UgYWNjZXB0ZWQN CiAgICAgIEM6IFFVSVQNCiAgICAgIFM6IDIyMSBnb29kYnllDQoNCiAgIFRoZSBhbG1hbWF0ZXIu ZWR1LmV4YW1wbGUgTVRBIG11c3Qgbm93IGZvcndhcmQgdGhpcyBtZXNzYWdlIHRvDQogICBib2JA Y29tcGFueS5jb20uZXhhbXBsZS4gIEFsdGhvdWdoIHRoZSBvcmlnaW5hbCBzZW5kZXIgb2YgdGhl IG1lc3NhZ2UNCiAgIGlzIGFsaWNlQGV4YW1wbGUuY29tLCBBbGljZSBpcyBub3QgcmVzcG9uc2li bGUgZm9yIHRoaXMgbW9zdCByZWNlbnQNCiAgIHJldHJhbnNtaXNzaW9uIG9mIHRoZSBtZXNzYWdl LiAgVGhhdCByb2xlIGlzIGZpbGxlZCBieQ0KICAgYm9iQGFsbWFtYXRlci5lZHUuZXhhbXBsZSB3 aG8gZXN0YWJsaXNoZWQgdGhlIGZvcndhcmRpbmcgb2YgbWFpbCB0bw0KICAgYm9iQGNvbXBhbnku Y29tLmV4YW1wbGUuICBUaGVyZWZvcmUsIHRoZSBhbG1hbWF0ZXIuZWR1LmV4YW1wbGUgTVRBDQog ICBkZXRlcm1pbmVzIGEgbmV3IHB1cnBvcnRlZCByZXNwb25zaWJsZSBhZGRyZXNzIGZvciB0aGUg bWVzc2FnZSwNCiAgIG5hbWVseSBib2JAYWxtYW1hdGVyLmVkdS5leGFtcGxlLCBhbmQgc2V0cyB0 aGUgU1VCTUlUVEVSIHBhcmFtZXRlcg0KICAgYWNjb3JkaW5nbHkuICBUaGUgZm9yd2FyZGluZyBN VEEgYWxzbyBpbnNlcnRzIGEgUmVzZW50LUZyb20gaGVhZGVyIGluDQogICB0aGUgbWVzc2FnZSBi b2R5IHRvIGVuc3VyZSB0aGUgcHVycG9ydGVkIHJlc3BvbnNpYmxlIGFkZHJlc3MgZGVyaXZlZA0K ICAgZnJvbSB0aGUgUkZDIDI4MjIgaGVhZGVycyBtYXRjaGVzIHRoZSBTVUJNSVRURVIgYWRkcmVz cy4NCg0KICAgICAgUzogMjIwIGNvbXBhbnkuY29tLmV4YW1wbGUgRVNNVFAgc2VydmVyIHJlYWR5 DQogICAgICBDOiBFSExPIGFsbWFtYXRlci5lZHUuZXhhbXBsZQ0KICAgICAgUzogMjUwLWNvbXBh bnkuY29tLmV4YW1wbGUNCiAgICAgIFM6IDI1MC1EU04NCiAgICAgIFM6IDI1MC1BVVRIDQogICAg ICBTOiAyNTAtU1VCTUlUVEVSDQogICAgICBTOiAyNTAgU0laRQ0KICAgICAgQzogTUFJTCBGUk9N OjxhbGljZUBleGFtcGxlLmNvbT4NCiAgICAgICAgICAgICAgU1VCTUlUVEVSPWJvYkBhbG1hbWF0 ZXIuZWR1LmV4YW1wbGUNCiAgICAgIFM6IDI1MCA8YWxpY2VAZXhhbXBsZS5jb20+IHNlbmRlciBv aw0KICAgICAgQzogUkNQVCBUTzo8Ym9iQGNvbXBhbnkuY29tLmV4YW1wbGU+DQogICAgICBTOiAy NTAgPGJvYkBjb21wYW55LmNvbS5leGFtcGxlPiByZWNpcGllbnQgb2sNCg0KQWxsbWFuLCBLYXR6 ICAgICAgICAgICAgIEV4cGlyZXMgLSBBcHJpbCAyMDA1ICAgICAgICAgICAgICAgICBbUGFnZSA3 XQ0KDA0KICAgICAgICAgICAgICAgICBTTVRQIFJlc3BvbnNpYmxlIFN1Ym1pdHRlciBFeHRlbnNp b24gICAgIE9jdG9iZXIgMjAwNA0KDQoNCiAgICAgIEM6IERBVEENCiAgICAgIFM6IDM1NCBva2F5 LCBzZW5kIG1lc3NhZ2UNCiAgICAgIEM6IFJlc2VudC1Gcm9tOiBib2JAYWxtYW1hdGVyLmVkdS5l eGFtcGxlDQogICAgICBDOiBSZWNlaXZlZCBCeTogLi4uDQogICAgICBDOiAobWVzc2FnZSBib2R5 IGdvZXMgaGVyZSkNCiAgICAgIEM6IC4NCiAgICAgIFM6IDI1MCBtZXNzYWdlIGFjY2VwdGVkDQog ICAgICBDOiBRVUlUDQogICAgICBTOiAyMjEgZ29vZGJ5ZQ0KDQo1LjMgTW9iaWxlIFVzZXINCg0K ICAgQWxpY2UgaXMgYXQgdGhlIGFpcnBvcnQgYW5kIHVzZXMgaGVyIG1vYmlsZSBlLW1haWwgZGV2 aWNlIHRvIHNlbmQgYQ0KICAgbWVzc2FnZSB0byBCb2IuICBUaGUgbWVzc2FnZSB0cmF2ZWxzIHRo cm91Z2ggdGhlIGNhcnJpZXIgbmV0d29yaw0KICAgcHJvdmlkZWQgYnkgbW9iaWxlLm5ldC5leGFt cGxlLCBidXQgQWxpY2UgdXNlcyBoZXIgZXhhbXBsZS5jb20NCiAgIGFkZHJlc3Mgb24gdGhlIEZy b20gbGluZSBvZiBhbGwgaGVyIG1lc3NhZ2VzIHNvIHRoYXQgcmVwbGllcyBnbyB0bw0KICAgaGVy IG9mZmljZSBtYWlsYm94Lg0KDQogICBIZXJlIGlzIGFuIGV4YW1wbGUgb2YgdGhlIFNNVFAgc2Vz c2lvbiBiZXR3ZWVuIHRoZSBNVEFzIGF0DQogICBtb2JpbGUubmV0LmV4YW1wbGUgYW5kIGFsbWFt YXRlci5lZHUuZXhhbXBsZS4NCg0KICAgICAgUzogMjIwIGFsbWFtYXRlci5lZHUuZXhhbXBsZSBF U01UUCBzZXJ2ZXIgcmVhZHkNCiAgICAgIEM6IEVITE8gbW9iaWxlLm5ldC5leGFtcGxlDQogICAg ICBTOiAyNTAtYWxtYW1hdGVyLmVkdS5leGFtcGxlDQogICAgICBTOiAyNTAtRFNODQogICAgICBT OiAyNTAtQVVUSA0KICAgICAgUzogMjUwLVNVQk1JVFRFUg0KICAgICAgUzogMjUwIFNJWkUNCiAg ICAgIEM6IE1BSUwgRlJPTTo8YWxpY2VAZXhhbXBsZS5jb20+DQogICAgICAgICAgICAgIFNVQk1J VFRFUj1hbGljZUBtb2JpbGUubmV0LmV4YW1wbGUNCiAgICAgIFM6IDI1MCA8YWxpY2VAZXhhbXBs ZS5jb20+IHNlbmRlciBvaw0KICAgICAgQzogUkNQVCBUTzo8Ym9iQGFsbWFtYXRlci5lZHUuZXhh bXBsZT4NCiAgICAgIFM6IDI1MCA8Ym9iQGFsbWFtYXRlci5lZHUuZXhhbXBsZT4gcmVjaXBpZW50 IG9rDQogICAgICBDOiBEQVRBDQogICAgICBTOiAzNTQgb2theSwgc2VuZCBtZXNzYWdlDQogICAg ICBDOiBTZW5kZXI6IGFsaWNlQG1vYmlsZS5uZXQuZXhhbXBsZQ0KICAgICAgQzogUmVjZWl2ZWQg Qnk6IC4uLg0KICAgICAgQzogKG1lc3NhZ2UgYm9keSBnb2VzIGhlcmUpDQogICAgICBDOiAuDQog ICAgICBTOiAyNTAgbWVzc2FnZSBhY2NlcHRlZA0KICAgICAgQzogUVVJVA0KICAgICAgUzogMjIx IGdvb2RieWUNCg0KICAgTm90ZSB0aGF0IG1vYmlsZS5uZXQuZXhhbXBsZSB1c2VzIHRoZSBTVUJN SVRURVIgcGFyYW1ldGVyIHRvDQogICBkZXNpZ25hdGUgYWxpY2VAbW9iaWxlLm5ldC5leGFtcGxl IGFzIHRoZSByZXNwb25zaWJsZSBzdWJtaXR0ZXIgZm9yDQogICB0aGlzIG1lc3NhZ2UuICBGdXJ0 aGVyIHRoaXMgTVRBIGFsc28gaW5zZXJ0cyBhIFNlbmRlciBoZWFkZXIgdG8NCiAgIGVuc3VyZSB0 aGUgcHVycG9ydGVkIHJlc3BvbnNpYmxlIGFkZHJlc3MgZGVyaXZlZCBmcm9tIHRoZSBSRkMgMjgy Mg0KICAgaGVhZGVycyBtYXRjaGVzIHRoZSBTVUJNSVRURVIgYWRkcmVzcy4NCg0KDQoNCkFsbG1h biwgS2F0eiAgICAgICAgICAgICBFeHBpcmVzIC0gQXByaWwgMjAwNSAgICAgICAgICAgICAgICAg W1BhZ2UgOF0NCgwNCiAgICAgICAgICAgICAgICAgU01UUCBSZXNwb25zaWJsZSBTdWJtaXR0ZXIg RXh0ZW5zaW9uICAgICBPY3RvYmVyIDIwMDQNCg0KDQogICBMaWtld2lzZSwgY29udmVudGlvbmFs IElTUHMgbWF5IGFsc28gY2hvb3NlIHRvIHVzZSB0aGUgU1VCTUlUVEVSDQogICBwYXJhbWV0ZXIg dG8gZGVzaWduYXRlIGFzIHRoZSByZXNwb25zaWJsZSBzdWJtaXR0ZXIgdGhlIHVzZXIncw0KICAg YWRkcmVzcyBvbiB0aGUgSVNQJ3MgbmV0d29yayBpZiB0aGF0IGFkZHJlc3MgaXMgZGlmZmVyZW50 IGZyb20gdGhlDQogICBNQUlMIEZST00gYWRkcmVzcy4gIFRoaXMgbWF5IGJlIGVzcGVjaWFsbHkg dXNlZnVsIGZvciBJU1BzIHRoYXQgaG9zdA0KICAgbXVsdGlwbGUgZG9tYWlucyBvciBvdGhlcndp c2Ugc2hhcmUgTVRBcyBhbW9uZyBtdWx0aXBsZSBkb21haW5zLg0KDQogICBXaGVuIHRoZSBtZXNz YWdlIGlzIHN1YnNlcXVlbnRseSBmb3J3YXJkZWQgYnkgdGhlDQogICBhbG1hbWF0ZXIuZWR1LmV4 YW1wbGUgTVRBLCB0aGF0IE1UQSB3aWxsIHJlcGxhY2UgdGhlIFNVQk1JVFRFUg0KICAgcGFyYW1l dGVyIHdpdGggYm9iQGFsbWFtYXRlci5lZHUuZXhhbXBsZSBhcyBpbiBzZWN0aW9uIDUuMiBhbmQg YWRkDQogICBpdHMgb3duIFJlc2VudC1Gcm9tIGhlYWRlci4NCg0KNS40IEd1ZXN0IEUtbWFpbCBT ZXJ2aWNlDQoNCiAgIFdoaWxlIG9uIGEgYnVzaW5lc3MgdHJpcCwgQWxpY2UgdXNlcyB0aGUgYnJv YWRiYW5kIGFjY2VzcyBmYWNpbGl0aWVzDQogICBwcm92aWRlZCBieSB0aGUgRXhlbXBsYXIgSG90 ZWwgdG8gY29ubmVjdCB0byB0aGUgSW50ZXJuZXQgYW5kIHNlbmQgZS0NCiAgIG1haWwuICBUaGUg aG90ZWwgcm91dGVzIGFsbCBvdXRib3VuZCBlLW1haWwgdGhyb3VnaCBpdHMgb3duIFNNVFANCiAg IHNlcnZlciwgZW1haWwuaG90ZWwuY29tLmV4YW1wbGUuDQoNCiAgIFRoZSBTTVRQIHNlc3Npb24g Zm9yIEFsaWNlJ3MgbWVzc2FnZSB0byBCb2IgZnJvbSB0aGUgRXhlbXBsYXIgSG90ZWwNCiAgIHdv dWxkIGxvb2sgbGlrZSB0aGlzOg0KDQogICAgICBTOiAyMjAgYWxtYW1hdGVyLmVkdS5leGFtcGxl IEVTTVRQIHNlcnZlciByZWFkeQ0KICAgICAgQzogRUhMTyBlbWFpbC5ob3RlbC5jb20uZXhhbXBs ZQ0KICAgICAgUzogMjUwLWFsbWFtYXRlci5lZHUuZXhhbXBsZQ0KICAgICAgUzogMjUwLURTTg0K ICAgICAgUzogMjUwLUFVVEgNCiAgICAgIFM6IDI1MC1TVUJNSVRURVINCiAgICAgIFM6IDI1MCBT SVpFDQogICAgICBDOiBNQUlMIEZST006PGFsaWNlQGV4YW1wbGUuY29tPg0KICAgICAgICAgICAg ICBTVUJNSVRURVI9Z3Vlc3Quc2VydmljZXNAZW1haWwuaG90ZWwuY29tLmV4YW1wbGUNCiAgICAg IFM6IDI1MCA8YWxpY2VAZXhhbXBsZS5jb20+IHNlbmRlciBvaw0KICAgICAgQzogUkNQVCBUTzo8 Ym9iQGFsbWFtYXRlci5lZHUuZXhhbXBsZT4NCiAgICAgIFM6IDI1MCA8Ym9iQGFsbWFtYXRlci5l ZHUuZXhhbXBsZT4gcmVjaXBpZW50IG9rDQogICAgICBDOiBEQVRBDQogICAgICBTOiAzNTQgb2th eSwgc2VuZCBtZXNzYWdlDQogICAgICBDOiBSZXNlbnQtRnJvbTogZ3Vlc3Quc2VydmljZXNAZW1h aWwuaG90ZWwuY29tLmV4YW1wbGUNCiAgICAgIEM6IFJlY2VpdmVkIEJ5OiAuLi4NCiAgICAgIEM6 IChtZXNzYWdlIGJvZHkgZ29lcyBoZXJlKQ0KICAgICAgQzogLg0KICAgICAgUzogMjUwIG1lc3Nh Z2UgYWNjZXB0ZWQNCiAgICAgIEM6IFFVSVQNCiAgICAgIFM6IDIyMSBnb29kYnllDQoNCiAgIE5v dGUgdGhhdCBlbWFpbC5ob3RlbC5jb20uZXhhbXBsZSB1c2VzIHRoZSBTVUJNSVRURVIgcGFyYW1l dGVyIHRvDQogICBkZXNpZ25hdGUgYSBnZW5lcmljIGFjY291bnQgZ3Vlc3Quc2VydmljZXNAZW1h aWwuaG90ZWwuY29tLmV4YW1wbGUgYXMNCiAgIHRoZSByZXNwb25zaWJsZSBzdWJtaXR0ZXIgYWRk cmVzcyBmb3IgdGhpcyBtZXNzYWdlLiAgQSBnZW5lcmljDQogICBhY2NvdW50IGlzIHVzZWQgc2lu Y2UgQWxpY2UgaGVyc2VsZiBkb2VzIG5vdCBoYXZlIGFuIGFjY291bnQgYXQgdGhhdA0KICAgZG9t YWluLiAgRnVydGhlciB0aGlzIGNsaWVudCBhbHNvIGluc2VydHMgYSBSZXNlbnQtRnJvbSBoZWFk ZXIgdG8NCiAgIGVuc3VyZSB0aGUgcHVycG9ydGVkIHJlc3BvbnNpYmxlIGFkZHJlc3MgZGVyaXZl ZCBmcm9tIHRoZSBSRkMgMjgyMg0KICAgaGVhZGVycyB3aXRoIHRoZSBTVUJNSVRURVIgYWRkcmVz cy4NCg0KQWxsbWFuLCBLYXR6ICAgICAgICAgICAgIEV4cGlyZXMgLSBBcHJpbCAyMDA1ICAgICAg ICAgICAgICAgICBbUGFnZSA5XQ0KDA0KICAgICAgICAgICAgICAgICBTTVRQIFJlc3BvbnNpYmxl IFN1Ym1pdHRlciBFeHRlbnNpb24gICAgIE9jdG9iZXIgMjAwNA0KDQoNCg0KICAgQXMgYmVmb3Jl LCB3aGVuIHRoZSBtZXNzYWdlIGlzIHN1YnNlcXVlbnRseSBmb3J3YXJkZWQgYnkgdGhlDQogICBh bG1hbWF0ZXIuZWR1LmV4YW1wbGUgTVRBLCB0aGF0IE1UQSB3aWxsIHJlcGxhY2UgdGhlIFNVQk1J VFRFUg0KICAgcGFyYW1ldGVyIHdpdGggYm9iQGFsbWFtYXRlci5lZHUuZXhhbXBsZSBhcyBpbiBz ZWN0aW9uIDUuMiBhbmQgYWRkDQogICBpdHMgb3duIFJlc2VudC1Gcm9tIGhlYWRlci4NCg0KNS41 IFNVQk1JVFRFUiBVc2VkIG9uIGEgTm9uLURlbGl2ZXJ5IFJlcG9ydA0KDQogICBBbGljZSBzZW5k cyBhbiBpbmNvcnJlY3RseSBhZGRyZXNzZWQgZS1tYWlsIG1lc3NhZ2UgYW5kIHJlY2VpdmVzIGEN CiAgIG5vbi1kZWxpdmVyeSByZXBvcnQgZnJvbSBhIFNVQk1JVFRFUi1jb21wbGlhbnQgc2VydmVy Lg0KDQogICAgICBTOiAyMjAgZXhhbXBsZS5jb20gRVNNVFAgc2VydmVyIHJlYWR5DQogICAgICBD OiBFSExPIGFsbWFtYXRlci5lZHUuZXhhbXBsZQ0KICAgICAgUzogMjUwLWV4YW1wbGUuY29tDQog ICAgICBTOiAyNTAtRFNODQogICAgICBTOiAyNTAtQVVUSA0KICAgICAgUzogMjUwLVNVQk1JVFRF Ug0KICAgICAgUzogMjUwIFNJWkUNCiAgICAgIEM6IE1BSUwgRlJPTTo8PiBTVUJNSVRURVI9bWFp bGVyLWRhZW1vbkBhbG1hbWF0ZXIuZWR1LmV4YW1wbGUNCiAgICAgIFM6IDI1MCBPSw0KICAgICAg QzogUkNQVCBUTzo8YWxpY2VAZXhhbXBsZS5jb20+DQogICAgICBTOiAyNTAgT0sNCiAgICAgIEM6 IERBVEENCiAgICAgIFM6IDM1NCBPSywgc2VuZCBtZXNzYWdlDQogICAgICBDOiAobWVzc2FnZSBi b2R5IGdvZXMgaGVyZSkNCiAgICAgIEM6IC4NCiAgICAgIFM6IDI1MCBtZXNzYWdlIGFjY2VwdGVk DQogICAgICBDOiBRVUlUDQogICAgICBTOiAyMjEgZ29vZGJ5ZQ0KDQoNCjYuIFNlY3VyaXR5IENv bnNpZGVyYXRpb25zDQoNCiAgIFRoaXMgZXh0ZW5zaW9uIHByb3ZpZGVzIGFuIG9wdGltaXphdGlv biB0byBhbGxvdyBhbiBTTVRQIGNsaWVudCB0bw0KICAgaWRlbnRpZnkgdGhlIHJlc3BvbnNpYmxl IHN1Ym1pdHRlciBvZiBhbiBlLW1haWwgbWVzc2FnZSBpbiB0aGUgU01UUA0KICAgcHJvdG9jb2ws IGFuZCB0byBlbmFibGUgU01UUCBzZXJ2ZXJzIHRvIHBlcmZvcm0gZWZmaWNpZW50IHZhbGlkYXRp b24NCiAgIG9mIHRoYXQgaWRlbnRpdHkgYmVmb3JlIHRoZSBtZXNzYWdlIGNvbnRlbnRzIGFyZSB0 cmFuc21pdHRlZC4NCg0KICAgSXQgaXMsIGhvd2V2ZXIsIHF1aXRlIHBvc3NpYmxlIGZvciBhbiBh dHRhY2tlciB0byBmb3JnZSB0aGUgdmFsdWUgb2YNCiAgIHRoZSBTVUJNSVRURVIgcGFyYW1ldGVy LiAgRnVydGhlcm1vcmUsIGl0IGlzIHBvc3NpYmxlIGZvciBhbiBhdHRhY2tlcg0KICAgdG8gdHJh bnNtaXQgYW4gZS1tYWlsIG1lc3NhZ2Ugd2hvc2UgU1VCTUlUVEVSIHBhcmFtZXRlciBkb2VzIG5v dA0KICAgbWF0Y2ggdGhlIHB1cnBvcnRlZCByZXNwb25zaWJsZSBhZGRyZXNzIG9mIHRoZSBtZXNz YWdlIGFzIGRlcml2ZWQNCiAgIGZyb20gdGhlIFJGQyAyODIyIGhlYWRlcnMuICBUaGVyZWZvcmUg dGhlIHByZXNlbmNlIG9mIHRoZSBTVUJNSVRURVINCiAgIHBhcmFtZXRlciBwcm92aWRlcywgYnkg aXRzZWxmLCBubyBhc3N1cmFuY2Ugb2YgdGhlIGF1dGhlbnRpY2l0eSBvZg0KICAgdGhlIG1lc3Nh Z2Ugb3IgdGhlIHJlc3BvbnNpYmxlIHN1Ym1pdHRlci4gIFJhdGhlciwgdGhlIFNVQk1JVFRFUg0K ICAgcGFyYW1ldGVyIGlzIGludGVuZGVkIHRvIHByb3ZpZGUgYWRkaXRpb25hbCBpbmZvcm1hdGlv biB0byByZWNlaXZpbmcNCiAgIGUtbWFpbCBzeXN0ZW1zIHRvIGVuYWJsZSB0aGVuIHRvIGVmZmlj aWVudGx5IGRldGVybWluZSB0aGUgdmFsaWRpdHkNCiAgIG9mIHRoZSByZXNwb25zaWJsZSBzdWJt aXR0ZXIsIGFuZCBzcGVjaWZpY2FsbHksIHdoZXRoZXIgdGhlIFNNVFANCiAgIGNsaWVudCBpcyBh dXRob3JpemVkIHRvIHRyYW5zbWl0IGUtbWFpbCBvbiBiZWhhbGYgb2YgdGhlIHB1cnBvcnRlZA0K DQoNCkFsbG1hbiwgS2F0eiAgICAgICAgICAgICBFeHBpcmVzIC0gQXByaWwgMjAwNSAgICAgICAg ICAgICAgICBbUGFnZSAxMF0NCgwNCiAgICAgICAgICAgICAgICAgU01UUCBSZXNwb25zaWJsZSBT dWJtaXR0ZXIgRXh0ZW5zaW9uICAgICBPY3RvYmVyIDIwMDQNCg0KDQogICByZXNwb25zaWJsZSBz dWJtaXR0ZXIncyBkb21haW4uICBTZWN0aW9uIDQuMiBkZXNjcmliZXMgaG93IHJlY2VpdmluZw0K ICAgZS1tYWlsIHN5c3RlbXMgc2hvdWxkIHByb2Nlc3MgdGhlIFNVQk1JVFRFUiBwYXJhbWV0ZXIu DQoNCg0KNy4gSUFOQSBDb25zaWRlcmF0aW9ucw0KDQogICBJQU5BIGlzIGhlcmVieSByZXF1ZXN0 ZWQgdG8gcmVnaXN0ZXIgdGhlIFNVQk1JVFRFUiBTTVRQIHNlcnZpY2UNCiAgIGV4dGVuc2lvbi4N Cg0KDQo4LiBSZWZlcmVuY2VzDQoNCjguMSBOb3JtYXRpdmUgUmVmZXJlbmNlcw0KDQogICAgW0FC TkZdICAgICAgICAgQ3JvY2tlciwgRC4gYW5kIFAuIE92ZXJlbGwsICJBdWdtZW50ZWQgQk5GIGZv ciBTeW50YXgNCiAgICAgICAgICAgICAgICAgICBTcGVjaWZpY2F0aW9uczogQUJORiIsIFJGQyAy MjM0LCBOb3ZlbWJlciAxOTk3Lg0KDQogICAgW0RTTl0gICAgICAgICAgTW9vcmUsIEsuLCAiU2lt cGxlIE1haWwgVHJhbnNmZXIgUHJvdG9jb2wgKFNNVFApDQogICAgICAgICAgICAgICAgICAgU2Vy dmljZSBFeHRlbnNpb24gZm9yIERlbGl2ZXJ5IFN0YXR1cyBOb3RpZmljYXRpb25zDQogICAgICAg ICAgICAgICAgICAgKERTTnMpIiwgUkZDIDM0NjEsIEphbnVhcnkgMjAwMy4NCg0KICAgIFtLRVlX T1JEU10gICAgIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRp Y2F0ZQ0KICAgICAgICAgICAgICAgICAgIFJlcXVpcmVtZW50IExldmVscyIsIEJDUCAxNCwgUkZD IDIxMTksIE1hcmNoIDE5OTcuDQoNCiAgICBbTVNHLUZPUk1BVF0gICBSZXNuaWNrLCBQLiwgRWQu LCAiSW50ZXJuZXQgTWVzc2FnZSBGb3JtYXQiLCBSRkMNCiAgICAgICAgICAgICAgICAgICAyODIy LCBBcHJpbCAyMDAxLg0KDQogICAgW1BSQV0gICAgICAgICAgTHlvbiwgSi4sICJQdXJwb3J0ZWQg UmVzcG9uc2libGUgQWRkcmVzcyBpbiBFLW1haWwNCiAgICAgICAgICAgICAgICAgICBNZXNzYWdl cyIsIGRyYWZ0LWx5b24tc2VuZGVyaWQtcHJhLTAwLCBPY3RvYmVyIDIwMDQuDQogICAgICAgICAg ICAgICAgICAgV29yayBpbiBwcm9ncmVzcy4NCg0KICAgIFtTRU5ERVItSURdICAgIEx5b24sIEou IGFuZCBNZW5nIFdlbmcgV29uZywgIlNlbmRlciBJRDoNCiAgICAgICAgICAgICAgICAgICBBdXRo ZW50aWNhdGluZyBFLW1haWwiLCBkcmFmdC1seW9uLXNlbmRlcmlkLWNvcmUtMDAsDQogICAgICAg ICAgICAgICAgICAgT2N0b2JlciAyMDA0LiAgV29yayBpbiBwcm9ncmVzcy4NCg0KICAgIFtTVUJN SVRdICAgICAgIEdlbGxlbnMsIFIuIGFuZCBKLiBLbGVuc2luLCAiTWVzc2FnZSBTdWJtaXNzaW9u IiwgUkZDDQogICAgICAgICAgICAgICAgICAgMjQ3NiwgRGVjZW1iZXIgMTk5OC4NCg0KICAgIFtT VERdICAgICAgICAgIEJyYWRuZXIsIFMuLCAiSW50ZWxsZWN0dWFsIFByb3BlcnR5IFJpZ2h0cyBp biBJRVRGDQogICAgICAgICAgICAgICAgICAgVGVjaG5vbG9neSIsIEJDUCA3OSwgUkZDIDM2Njgs IEZlYnJ1YXJ5IDIwMDQuDQoNCiAgICBbU01UUF0gICAgICAgICBLbGVuc2luLCBKLiwgIlNpbXBs ZSBNYWlsIFRyYW5zZmVyIFByb3RvY29sIiwgUkZDDQogICAgICAgICAgICAgICAgICAgMjgyMSwg QXByaWwgMjAwMS4NCg0KICAgIFtTTVRQQVVUSF0gICAgIE1leWVycywgSi4sICJTTVRQIFNlcnZp Y2UgRXh0ZW5zaW9uIGZvcg0KICAgICAgICAgICAgICAgICAgIEF1dGhlbnRpY2F0aW9uIiwgUkZD IDI1NTQsIE1hcmNoIDE5OTkuDQoNCg0KDQoNCg0KQWxsbWFuLCBLYXR6ICAgICAgICAgICAgIEV4 cGlyZXMgLSBBcHJpbCAyMDA1ICAgICAgICAgICAgICAgIFtQYWdlIDExXQ0KDA0KICAgICAgICAg ICAgICAgICBTTVRQIFJlc3BvbnNpYmxlIFN1Ym1pdHRlciBFeHRlbnNpb24gICAgIE9jdG9iZXIg MjAwNA0KDQoNCjguMiBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzDQoNCiAgIE5vbmUuDQoNCg0KOS4g QWNrbm93bGVkZ21lbnRzDQoNCiAgIFRoZSBpZGVhIG9mIGFuIEVTTVRQIGV4dGVuc2lvbiB0byBj b252ZXkgdGhlIGlkZW50aXR5IG9mIHRoZQ0KICAgcmVzcG9uc2libGUgc2VuZGVyIG9mIGFuIGUt bWFpbCBtZXNzYWdlIGhhcyBtYW55IHByb2dlbml0b3JzLiAgTmljaw0KICAgU2hlbG5lc3Mgc3Vn Z2VzdGVkIHRoZSBpZGVhIGluIGEgcHJpdmF0ZSBjb252ZXJzYXRpb24gd2l0aCBvbmUgb2YgdGhl DQogICBhdXRob3JzLiAgUGV0ZSBSZXNuaWNrIHN1Z2dlc3RlZCBhIHZhcmlhbnQgb24gdGhlIE1B UklEIG1haWxpbmcgbGlzdC4NCiAgIFRoZSBpZGVhIHdhcyBhbHNvIGRpc2N1c3NlZCBvbiB0aGUg QW50aS1TcGFtIFJlc2VhcmNoIEdyb3VwIChBU1JHKQ0KICAgbWFpbGluZyBsaXN0Lg0KDQogICBU aGUgYXV0aG9ycyB3b3VsZCBhbHNvIGxpa2UgdG8gdGhhbmsgdGhlIHBhcnRpY2lwYW50cyBvZiB0 aGUgTUFSSUQNCiAgIHdvcmtpbmcgZ3JvdXAgYW5kIHRoZSBmb2xsb3dpbmcgaW5kaXZpZHVhbHMg Zm9yIHRoZWlyIGNvbW1lbnRzIGFuZA0KICAgc3VnZ2VzdGlvbnMsIHdoaWNoIGdyZWF0bHkgaW1w cm92ZWQgdGhpcyBkb2N1bWVudDoNCg0KICAgICBSb2JlcnQgQXRraW5zb24sIFNpbW9uIEF0dHdl bGwsIFJveSBCYWRhbWksIEdyZWcgQ29ubm9yLCBEYXZlDQogICAgIENyb2NrZXIsIE1hdHRoZXcg RWx2ZXksIFRvbnkgRmluY2gsIE5lZCBGcmVlZCwgTWFyayBMZW50Y3puZXIsIEppbQ0KICAgICBM eW9uLCBCcnVjZSBNY01pbGxhbiwgU2FtIE5lZWx5LCBEYXJ5bCBPZG5lcnQsIE1hcmdhcmV0IE9s c29uLCBQZXRlDQogICAgIFJlc25pY2ssIEhlY3RvciBTYW50b3MsIE5pY2sgU2hlbG5lc3MsIFJh bmQgV2Fja2VyLCBNZW5nIFdlbmcgV29uZw0KDQoNCjEwLiBBdXRob3JzJyBBZGRyZXNzZXMNCg0K ICAgRXJpYyBBbGxtYW4NCiAgIFNlbmRtYWlsLCBJbmMuDQogICA2NDI1IENocmlzdGllIEF2ZSwg U3VpdGUgNDAwDQogICBFbWVyeXZpbGxlLCBDQSA5NDYwOA0KICAgVVNBDQoNCiAgIEUtbWFpbDog ZXJpY0BzZW5kbWFpbC5jb20NCg0KICAgSGFycnkgS2F0eg0KICAgTWljcm9zb2Z0IENvcnAuDQog ICAxIE1pY3Jvc29mdCBXYXkNCiAgIFJlZG1vbmQsIFdBIDk4MDUyDQogICBVU0ENCg0KICAgRS1t YWlsOiBoa2F0ekBtaWNyb3NvZnQuY29tDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkFsbG1hbiwgS2F0 eiAgICAgICAgICAgICBFeHBpcmVzIC0gQXByaWwgMjAwNSAgICAgICAgICAgICAgICBbUGFnZSAx Ml0NCgwNCiAgICAgICAgICAgICAgICAgU01UUCBSZXNwb25zaWJsZSBTdWJtaXR0ZXIgRXh0ZW5z aW9uICAgICBPY3RvYmVyIDIwMDQNCg0KDQoxMS4gQ2hhbmdlIEhpc3RvcnkNCg0KICAgVGhlIGZv bGxvd2luZyBjaGFuZ2VzIHdlcmUgbWFkZSBpbiBkcmFmdC1rYXR6LXN1Ym1pdHRlci0wMDoNCg0K ICAgLSBpbiA0LjIsIGFkZGVkIGEgcGFyYWdyYXBoIG5vdGluZyB0aGF0IHRoZSBTVUJNSVRURVIg cGFyYW1ldGVyIGlzDQogICAgIG5vdCB0byBiZSB1c2VkIGFzIGEgcmVwbHkgYWRkcmVzcy4NCiAg IC0gaW4gNS4zLCBhZGRlZCB3b3JkaW5nIHRvIG5vdGUgdGhhdCB0aGlzIGV4YW1wbGUgYWxzbyBh cHBsaWVzIHRvDQogICAgIElTUHMgaG9zdGluZyBtdWx0aXBsZSBkb21haW5zLg0KICAgLSBhZGRl ZCBtb3JlIGRldGFpbCB0byBBY2tub3dsZWRnZW1lbnRzIHNlY3Rpb24uDQogICAtIG1pbm9yIHdv cmRpbmcgY2hhbmdlcyBhbmQgY29ycmVjdGlvbnMgdGhyb3VnaG91dC4NCg0KICAgVGhlIGZvbGxv d2luZyBjaGFuZ2VzIHdlcmUgbWFkZSBpbiBkcmFmdC1pZXRmLW1hcmlkLXN1Ym1pdHRlci0wMzoN Cg0KICAgLSBpbiAxLCBhbWVuZGVkIHdvcmRpbmcgYWJvdXQgdGhlIGFkdmFudGFnZXMgb2YgYmFz aW5nIHZhbGlkYXRpb24gb24NCiAgICAgUkZDIDI4MjIgaGVhZGVycy4NCiAgIC0gaW4gNC4xLCBh bWVuZGVkIHdvcmRpbmcgdG8gdXNlICJudWxsIHJldmVyc2UtcGF0aCIgdG8gY29uZm9ybSB3aXRo DQogICAgIFJGQyAyODIxIHRlcm1pbm9sb2d5Lg0KICAgLSBpbiA0LjEsIG1hZGUgU1VCTUlUVEVS IGEgTVVTVCBvbiBhbGwgbWVzc2FnZXMgZm9yIGNvbmZvcm1hbmNlLg0KICAgLSBpbiA0LjIsIGNo YW5nZWQgU0hPVUxEIHJlamVjdCB0byBNVVNUIHJlamVjdCB3aGVuIFNVQk1JVFRFUiB2YWx1ZQ0K ICAgICBkb2VzIG5vdCBtYXRjaCBQUkEgdmFsdWUgZGVyaXZlZCBmcm9tIGhlYWRlcnMuDQogICAt IGluIDQuMiwgYWRkZWQgYSBwYXJhZ3JhcGggbm90aW5nIHRoYXQgdGhlIFNVQk1JVFRFUiBwYXJh bWV0ZXIgaXMNCiAgICAgbm90IHRvIGJlIHVzZWQgYXMgYSByZXZlcnNlLXBhdGggYWRkcmVzcy4N CiAgIC0gYWRkZWQgNS41LCBleGFtcGxlIG9mIFNVQk1JVFRFUiB1c2FnZSB3aGVuIHJldmVyc2Ug cGF0aCBpcyBudWxsLg0KICAgLSBjaGFuZ2VkIHNldmVyYWwgcmVmZXJlbmNlcyBmcm9tIFtTRU5E RVItSURdIHRvIFtQUkFdIHRvIHJlZmxlY3QNCiAgICAgY3JlYXRpb24gb2Ygc2VwYXJhdGUgW1BS QV0gZG9jdW1lbnQuDQogICAtIG1pbm9yIHdvcmRpbmcgY2hhbmdlcyBhbmQgY29ycmVjdGlvbnMg dGhyb3VnaG91dC4NCg0KICAgVGhlIGZvbGxvd2luZyBjaGFuZ2VzIHdlcmUgbWFkZSBpbiBkcmFm dC1pZXRmLW1hcmlkLXN1Ym1pdHRlci0wMjoNCg0KICAgLSBvbiB0aXRsZSBwYWdlLCB1cGRhdGVk IHRoZSBpbnRlbGxlY3R1YWwgcHJvcGVydHkgZGVjbGFyYXRpb24gdG8gYmUNCiAgICAgY29uc2lz dGVudCB3aXRoIFJGQyAzNjY4Lg0KICAgLSBpbiAxLCByZXdvcmtlZCB0ZXh0IHJlbW92aW5nIHJl ZmVyZW5jZXMgdG8gdmFyaW91cyBhbnRpLXNwb29maW5nDQogICAgIHByb3Bvc2FscyBhbmQgY2xh cmlmeWluZyB0aGUgZGVmaW5pdGlvbiBvZiBzZXZlcmFsIHRlcm1zIHVzZWQNCiAgICAgaGVyZWlu Lg0KICAgLSBpbiA0LCByZW1vdmVkIHJlZHVuZGFudCB0ZXh0IGZyb20gdGhlIGZpcnN0IHBhcmFn cmFwaA0KICAgLSBpbiA0LjEsIHN0cmVuZ3RoZW5lZCB0aGUgY29uZm9ybWFuY2UgcmVxdWlyZW1l bnRzIGFuZCBhZGRlZCB0aGUNCiAgICAgcmVjb21tZW5kYXRpb24gZm9yIGluY2x1c2lvbiBvZiB0 aGUgU1VCTUlUVEVSIHBhcmFtZXRlciBldmVuIHdoZW4NCiAgICAgdGhlIE1BSUwgRlJPTSBhZGRy ZXNzIGlzIGlkZW50aWNhbCB0byB0aGUgcHVycG9ydGVkIHJlc3BvbnNpYmxlDQogICAgIGFkZHJl c3MuDQogICAtIGluIDQuMSwgcmVtb3ZlZCB3b3JkaW5nIGFib3V0IG1ha2luZyB0aGUgU1VCTUlU VEVSIHBhcmFtZXRlcg0KICAgICBtYW5kYXRvcnkgYXQgc29tZSBmdXR1cmUgdGltZS4NCiAgIC0g aW4gNC4xLCBtb3ZlZCB0aGUgcHJvY2VkdXJhbCBkZXNjcmlwdGlvbnMgZm9yIGluaXRpYWwgbWVz c2FnZQ0KICAgICBzdWJtaXNzaW9uIGFuZCBzdWJzZXF1ZW50IG1lc3NhZ2UgcmV0cmFuc21pc3Np b24gdG8gdGhlIG5vbi0NCiAgICAgbm9ybWF0aXZlIEV4YW1wbGVzIHNlY3Rpb24uDQogICAtIGlu IDQuMiwgcmVtb3ZlZCB0aGUgd29yZGluZyBhYm91dCBwcm9jZWR1cmVzIHRvIGJlIHVzZWQgYXQg c29tZQ0KICAgICBmdXR1cmUgdGltZSB3aGVuIHRoZSBTVUJNSVRURVIgcGFyYW1ldGVyIGJlY29t ZXMgbWFuZGF0b3J5DQogICAtIGluIDQuMiwgc2lnbmlmaWNhbnQgcmV3b3JkaW5nIHRvIHNpbXBs aWZ5IGFuZCBjbGFyaWZ5IHRoZQ0KICAgICB2ZXJpZmljYXRpb24gcHJvY2VzcyBhbmQgZXJyb3Ig bWVzc2FnZXMuDQogICAtIGluIDQuMywgY2xhcmlmaWVkIHRoZSB3b3JkaW5nIHRvIGluY2x1ZGUg YWxsIGNhc2VzIG9mIG1lc3NhZ2UNCiAgICAgdHJhbnNtaXNzaW9uIHRvIGEgbm9uLVNVQk1JVFRF UiBhd2FyZSBzZXJ2ZXIuDQoNCkFsbG1hbiwgS2F0eiAgICAgICAgICAgICBFeHBpcmVzIC0gQXBy aWwgMjAwNSAgICAgICAgICAgICAgICBbUGFnZSAxM10NCgwNCiAgICAgICAgICAgICAgICAgU01U UCBSZXNwb25zaWJsZSBTdWJtaXR0ZXIgRXh0ZW5zaW9uICAgICBPY3RvYmVyIDIwMDQNCg0KDQog ICAtIGluIDUsIGNoYW5nZWQgZXhhbXBsZSBhZGRyZXNzZXMgdG8gYmUgY29tcGxpYW50IHdpdGgg UkZDIDI2MDYNCiAgIC0gaW4gNiwgcmV3b3JkaW5nIGFuZCBmb2N1cyBvbiBzZWN1cml0eSBjb25z aWRlcmF0aW9ucyBzcGVjaWZpYyB0bw0KICAgICB0aGlzIHByb3Bvc2FsDQogICAtIGFkZGVkIDcs IElBTkEgQ29uc2lkZXJhdGlvbnMNCiAgIC0gaW4gOCwgcmVtb3ZlZCB1bnJlZmVyZW5jZWQgaW5m b3JtYXRpdmUgcmVmZXJlbmNlcw0KICAgLSBtaW5vciB3b3JkaW5nIGNoYW5nZXMgdGhyb3VnaG91 dC4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkFsbG1hbiwgS2F0eiAgICAgICAg ICAgICBFeHBpcmVzIC0gQXByaWwgMjAwNSAgICAgICAgICAgICAgICBbUGFnZSAxNF0NCgwNCiAg ICAgICAgICAgICAgICAgU01UUCBSZXNwb25zaWJsZSBTdWJtaXR0ZXIgRXh0ZW5zaW9uICAgICBP Y3RvYmVyIDIwMDQNCg0KDQoxMi4gRnVsbCBDb3B5cmlnaHQgU3RhdGVtZW50DQoNCiAgIENvcHly aWdodCAoQykgVGhlIEludGVybmV0IFNvY2lldHkgKDIwMDQpLiAgVGhpcyBkb2N1bWVudCBpcyBz dWJqZWN0DQogICB0byB0aGUgcmlnaHRzLCBsaWNlbnNlcyBhbmQgcmVzdHJpY3Rpb25zIGNvbnRh aW5lZCBpbiBCQ1AgNzggYW5kDQogICBleGNlcHQgYXMgc2V0IGZvcnRoIHRoZXJlaW4sIHRoZSBh dXRob3JzIHJldGFpbiBhbGwgdGhlaXIgcmlnaHRzLg0KDQogICBUaGlzIGRvY3VtZW50IGFuZCB0 aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBhcmUgcHJvdmlkZWQgb24gYW4NCiAgICJB UyBJUyIgYmFzaXMgYW5kIFRIRSBDT05UUklCVVRPUiwgVEhFIE9SR0FOSVpBVElPTiBIRS9TSEUg UkVQUkVTRU5UUw0KICAgT1IgSVMgU1BPTlNPUkVEIEJZIChJRiBBTlkpLCBUSEUgSU5URVJORVQg U09DSUVUWSBBTkQgVEhFIElOVEVSTkVUDQogICBFTkdJTkVFUklORyBUQVNLIEZPUkNFIERJU0NM QUlNIEFMTCBXQVJSQU5USUVTLCBFWFBSRVNTIE9SIElNUExJRUQsDQogICBJTkNMVURJTkcgQlVU IE5PVCBMSU1JVEVEIFRPIEFOWSBXQVJSQU5UWSBUSEFUIFRIRSBVU0UgT0YgVEhFDQogICBJTkZP Uk1BVElPTiBIRVJFSU4gV0lMTCBOT1QgSU5GUklOR0UgQU5ZIFJJR0hUUyBPUiBBTlkgSU1QTElF RA0KICAgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgT1IgRklUTkVTUyBGT1IgQSBQQVJU SUNVTEFSIFBVUlBPU0UuDQoNCiAgIEludGVsbGVjdHVhbCBQcm9wZXJ0eQ0KDQogICBUaGUgSUVU RiB0YWtlcyBubyBwb3NpdGlvbiByZWdhcmRpbmcgdGhlIHZhbGlkaXR5IG9yIHNjb3BlIG9mIGFu eQ0KICAgSW50ZWxsZWN0dWFsIFByb3BlcnR5IFJpZ2h0cyBvciBvdGhlciByaWdodHMgdGhhdCBt aWdodCBiZSBjbGFpbWVkDQogICB0byBwZXJ0YWluIHRvIHRoZSBpbXBsZW1lbnRhdGlvbiBvciB1 c2Ugb2YgdGhlIHRlY2hub2xvZ3kgZGVzY3JpYmVkDQogICBpbiB0aGlzIGRvY3VtZW50IG9yIHRo ZSBleHRlbnQgdG8gd2hpY2ggYW55IGxpY2Vuc2UgdW5kZXIgc3VjaCByaWdodHMNCiAgIG1pZ2h0 IG9yIG1pZ2h0IG5vdCBiZSBhdmFpbGFibGU7IG5vciBkb2VzIGl0IHJlcHJlc2VudCB0aGF0IGl0 IGhhcw0KICAgbWFkZSBhbnkgaW5kZXBlbmRlbnQgZWZmb3J0IHRvIGlkZW50aWZ5IGFueSBzdWNo IHJpZ2h0cy4gSW5mb3JtYXRpb24NCiAgIG9uIHRoZSBwcm9jZWR1cmVzIHdpdGggcmVzcGVjdCB0 byByaWdodHMgaW4gUkZDIGRvY3VtZW50cyBjYW4gYmUNCiAgIGZvdW5kIGluIEJDUCA3OCBhbmQg QkNQIDc5Lg0KDQogICBDb3BpZXMgb2YgSVBSIGRpc2Nsb3N1cmVzIG1hZGUgdG8gdGhlIElFVEYg U2VjcmV0YXJpYXQgYW5kIGFueQ0KICAgYXNzdXJhbmNlcyBvZiBsaWNlbnNlcyB0byBiZSBtYWRl IGF2YWlsYWJsZSwgb3IgdGhlIHJlc3VsdCBvZiBhbg0KICAgYXR0ZW1wdCBtYWRlIHRvIG9idGFp biBhIGdlbmVyYWwgbGljZW5zZSBvciBwZXJtaXNzaW9uIGZvciB0aGUgdXNlIG9mDQogICBzdWNo IHByb3ByaWV0YXJ5IHJpZ2h0cyBieSBpbXBsZW1lbnRlcnMgb3IgdXNlcnMgb2YgdGhpcw0KICAg c3BlY2lmaWNhdGlvbiBjYW4gYmUgb2J0YWluZWQgZnJvbSB0aGUgSUVURiBvbi1saW5lIElQUiBy ZXBvc2l0b3J5IGF0DQogICBodHRwOi8vd3d3LmlldGYub3JnL2lwci4NCg0KICAgVGhlIElFVEYg aW52aXRlcyBhbnkgaW50ZXJlc3RlZCBwYXJ0eSB0byBicmluZyB0byBpdHMgYXR0ZW50aW9uIGFu eQ0KICAgY29weXJpZ2h0cywgcGF0ZW50cyBvciBwYXRlbnQgYXBwbGljYXRpb25zLCBvciBvdGhl ciBwcm9wcmlldGFyeQ0KICAgcmlnaHRzIHRoYXQgbWF5IGNvdmVyIHRlY2hub2xvZ3kgdGhhdCBt YXkgYmUgcmVxdWlyZWQgdG8gaW1wbGVtZW50DQogICB0aGlzIHN0YW5kYXJkLiAgUGxlYXNlIGFk ZHJlc3MgdGhlIGluZm9ybWF0aW9uIHRvIHRoZSBJRVRGIGF0IGlldGYtDQogICBpcHJAaWV0Zi5v cmcuDQoNCg0KQWNrbm93bGVkZ2VtZW50DQoNCiAgIEZ1bmRpbmcgZm9yIHRoZSBSRkMgRWRpdG9y IGZ1bmN0aW9uIGlzIGN1cnJlbnRseSBwcm92aWRlZCBieSB0aGUNCiAgIEludGVybmV0IFNvY2ll dHkuDQoNCg0KDQoNCg0KDQoNCg0KQWxsbWFuLCBLYXR6ICAgICAgICAgICAgIEV4cGlyZXMgLSBB cHJpbCAyMDA1ICAgICAgICAgICAgICAgIFtQYWdlIDE1XQ== ------_=_NextPart_001_01C4C03B.645EA374-- From owner-ietf-mxcomp@mail.imc.org Mon Nov 1 14:39:48 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21545 for ; Mon, 1 Nov 2004 14:39:47 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA1HooiT014442; Mon, 1 Nov 2004 09:50:50 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA1HooF8014441; Mon, 1 Nov 2004 09:50:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA1Hoo2K014372 for ; Mon, 1 Nov 2004 09:50:50 -0800 (PST) (envelope-from hkatz@exchange.microsoft.com) Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 Nov 2004 09:50:57 -0800 Received: from red-hub-01.redmond.corp.microsoft.com ([157.54.7.71]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 Nov 2004 09:50:47 -0800 Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by red-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 Nov 2004 09:50:48 -0800 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 Nov 2004 09:50:44 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C4C03B.50EC54C4" Subject: draft-lyon-senderid-core-00 Date: Mon, 1 Nov 2004 09:50:46 -0800 Message-ID: X-MS-Has-Attach: yes Thread-Topic: draft-lyon-senderid-core-00 Thread-Index: AcTAO1DGu5vW0hg7QEyGr7rOKx2qPQ== From: "Harry Katz" To: "IETF MARID WG" Cc: "Jim Lyon" , "Meng Weng Wong" X-OriginalArrivalTime: 01 Nov 2004 17:50:44.0601 (UTC) FILETIME=[4FB3E690:01C4C03B] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C4C03B.50EC54C4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The attached Sender ID specification, draft-lyon-senderid-core-00, is being submitted to the IETF as an experimental Internet draft along with draft-lyon-senderid-pra-00 and draft-katz-submitter-00.=20 These three drafts capture discussions held during the last few weeks of the MARID working group, as well as some subsequent feedback we've received. In summary, we've made two key changes to the Sender ID Framework: 1. The Sender ID Framework now allows receiving systems to choose which identity to validate; either the RFC2821 MAIL FROM address (aka "envelope from") or the purported responsible address (PRA) derived from RFC2822 message headers.=20 2. Sender ID is now backward compatible with any published SPF records in DNS. These records can be used for both MAIL FROM and PRA checks. We believe that the information that most sending domains need to publish in DNS will be the same for both checks. However domains which need to publish different IP addresses for each test can do so using a revised version of the SPF record syntax. =20 Note that these specifications refer to draft-lentczner-spf-00 for the definition of the SPF record format and protocol.=20 This draft won't appear on the IETF web site until after the IETF meeting in Washington, D.C. Until then, here's the text version. A PDF version is available at http://www.microsoft.com/senderid.=20 Thanks. ------_=_NextPart_001_01C4C03B.50EC54C4 Content-Type: text/plain; name="draft-lyon-senderid-core-00.txt" Content-Description: draft-lyon-senderid-core-00.txt Content-Disposition: attachment; filename="draft-lyon-senderid-core-00.txt" Content-Transfer-Encoding: base64 DQoNCg0KDQogICBJbnRlcm5ldCBEcmFmdCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgSi4gTHlvbg0KICAgQ2F0ZWdvcnk6IEV4cGVyaW1lbnRhbCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgTWljcm9zb2Z0IENvcnANCiAgIERvY3VtZW50OiBkcmFm dC1seW9uLXNlbmRlcmlkLWNvcmUtMDAudHh0ICAgICAgICAgICAgICAgICAgICBNLiBXb25nDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHBvYm94LmNvbQ0KICAgRXhwaXJlczogQXByaWwgMjAwNSAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBPY3RvYmVyIDIwMDQNCg0KDQogICAgICAgICAgICAgICAgICAgICBT ZW5kZXIgSUQ6IEF1dGhlbnRpY2F0aW5nIEUtTWFpbA0KDQoNClN0YXR1cyBvZiB0aGlzIE1lbW8N Cg0KICAgQnkgc3VibWl0dGluZyB0aGlzIEludGVybmV0LURyYWZ0LCBJIGNlcnRpZnkgdGhhdCBh bnkgYXBwbGljYWJsZQ0KICAgcGF0ZW50IG9yIG90aGVyIElQUiBjbGFpbXMgb2Ygd2hpY2ggSSBh bSBhd2FyZSBoYXZlIGJlZW4gZGlzY2xvc2VkLA0KICAgb3Igd2lsbCBiZSBkaXNjbG9zZWQsIGFu ZCBhbnkgb2Ygd2hpY2ggSSBiZWNvbWUgYXdhcmUgd2lsbCBiZQ0KICAgZGlzY2xvc2VkLCBpbiBh Y2NvcmRhbmNlIHdpdGggUkZDIDM2NjguDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2lu ZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nDQogICBUYXNrIEZvcmNlIChJ RVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiAgTm90ZSB0aGF0DQogICBv dGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRl cm5ldC0NCiAgIERyYWZ0cy4NCg0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVu dHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzDQogICBhbmQgbWF5IGJlIHVwZGF0 ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQ0KICAg dGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZl cmVuY2UNCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGEgIndvcmsgaW4g cHJvZ3Jlc3MuIg0KDQogICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4g YmUgYWNjZXNzZWQgYXQNCiAgICAgICBodHRwOi8vd3d3LmlldGYub3JnLzFpZC1hYnN0cmFjdHMu aHRtbA0KDQogICBUaGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMg Y2FuIGJlIGFjY2Vzc2VkIGF0DQogICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRt bA0KDQpBYnN0cmFjdA0KDQogICBJbnRlcm5ldCBtYWlsIHN1ZmZlcnMgZnJvbSB0aGUgZmFjdCB0 aGF0IG11Y2ggdW53YW50ZWQgbWFpbCBpcyBzZW50DQogICB1c2luZyBzcG9vZmVkIGFkZHJlc3Nl cyAtLSAic3Bvb2ZlZCIgaW4gdGhpcyBjYXNlIG1lYW5zIHRoZSBhZGRyZXNzDQogICBpcyB1c2Vk IHdpdGhvdXQgdGhlIHBlcm1pc3Npb24gb2YgdGhlIGRvbWFpbiBvd25lci4gIFRoaXMgZG9jdW1l bnQNCiAgIGRlc2NyaWJlcyBhIGZhbWlseSBvZiB0ZXN0cyBieSB3aGljaCBTTVRQIHNlcnZlcnMg Y2FuIGRldGVybWluZQ0KICAgd2hldGhlciBhbiBlLW1haWwgYWRkcmVzcyBpbiBhIHJlY2VpdmVk IG1lc3NhZ2Ugd2FzIHVzZWQgd2l0aCB0aGUNCiAgIHBlcm1pc3Npb24gb2YgdGhlIG93bmVyIG9m IHRoZSBkb21haW4gY29udGFpbmVkIGluIHRoYXQgZS1tYWlsDQogICBhZGRyZXNzLg0KDQoNCg0K DQoNCg0KDQoNCg0KTHlvbiwgV29uZyAgICAgICAgICAgICAgIEV4cGlyZXMgLSBBcHJpbCAyMDA1 ICAgICAgICAgICAgICAgICBbUGFnZSAxXQ0KDA0KICAgICAgICAgICAgICAgICAgIFNlbmRlciBJ RDogQXV0aGVudGljYXRpbmcgRS1NYWlsICAgICAgIE9jdG9iZXIgMjAwNA0KDQoNClRhYmxlIG9m IENvbnRlbnRzDQoNCiAgIDEuIEludHJvZHVjdGlvbi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjMNCiAgIDIuIFByb2JsZW0gU3RhdGVtZW50Li4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjMNCiAgIDMuIFNQRiBSZWNv cmRzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjQN CiAgICAgIDMuMSBQb3NpdGlvbmFsIE1vZGlmaWVycy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLjQNCiAgICAgIDMuMiBNdWx0aXBsZSBSZWNvcmRzLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjUNCiAgICAgIDMuMyBWZXJzaW9uIGFuZCBTY29w ZS4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjYNCiAgICAgIDMuNCBC YWNrd2FyZCBDb21wYXRpYmlsaXR5Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u LjcNCiAgIDQuIERlY2lzaW9uIE1vZGVsLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLjgNCiAgIDUuIEFjdGlvbnMgQmFzZWQgb24gdGhlIERlY2lzaW9uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjkNCiAgICAgIDUuMSBOZXV0cmFsLCBOb25l LCBTb2Z0RmFpbCBvciBQZXJtRXJyb3IuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjkNCiAgICAgIDUu MiBQYXNzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLjkNCiAgICAgIDUuMyBGYWlsLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLjkNCiAgICAgIDUuNCBUZW1wRXJyb3IuLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjkNCiAgIDYuIFNlY3VyaXR5IENvbnNp ZGVyYXRpb25zLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTANCiAgICAg IDYuMSBETlMgQXR0YWNrcy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uMTANCiAgICAgIDYuMiBUQ1AgQXR0YWNrcy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uMTANCiAgICAgIDYuMyBGb3JnZWQgU2VuZGVyIEF0dGFja3Mu Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTANCiAgICAgIDYuNCBBZGRyZXNz IFNwYWNlIEhpamFja2luZy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTENCiAg ICAgIDYuNSBNYWxpY2lvdXMgRE5TIGF0dGFja3Mgb24gdGhpcmQtcGFydGllcy4uLi4uLi4uLi4u Li4uLi4uLi4uMTENCiAgIDcuIEltcGxlbWVudGF0aW9uIEd1aWRhbmNlLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTINCiAgICAgIDcuMSBTaW1wbGUgRS1tYWlsZXJzLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTINCiAgICAgIDcuMiBFLU1h aWwgRm9yd2FyZGVycy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTIN CiAgICAgIDcuMyBNYWlsaW5nIExpc3QgU2VydmVycy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uMTMNCiAgICAgIDcuNCBUaGlyZC1QYXJ0eSBNYWlsZXJzLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTMNCiAgICAgIDcuNSBNVUEgSW1wbGVtZW50ZXJz Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTQNCiAgIDguIElBTkEg Q29uc2lkZXJhdGlvbnMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u MTQNCiAgIDkuIEFja25vd2xlZGdlbWVudHMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uMTUNCiAgIDEwLiBSZWZlcmVuY2VzLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTUNCiAgICAgIDEwLjEgTm9ybWF0aXZlIFJl ZmVyZW5jZXMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTUNCiAgICAgIDEw LjIgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uMTUNCiAgIDExLiBBdXRob3JzJyBBZGRyZXNzZXMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uMTYNCg0KQ29udmVudGlvbnMgdXNlZCBpbiB0aGlzIGRvY3VtZW50 DQoNCiAgIFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hB TEwiLCAiU0hBTEwgTk9UIiwNCiAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRF RCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzDQogICBkb2N1bWVudCBhcmUgdG8gYmUg aW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIFtSRkMyMTE5XS4NCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCkx5b24sIFdvbmcgICAgICAgICAgICAgICBFeHBpcmVzIC0gQXByaWwgMjAwNSAgICAg ICAgICAgICAgICAgW1BhZ2UgMl0NCgwNCiAgICAgICAgICAgICAgICAgICBTZW5kZXIgSUQ6IEF1 dGhlbnRpY2F0aW5nIEUtTWFpbCAgICAgICBPY3RvYmVyIDIwMDQNCg0KDQoxLiBJbnRyb2R1Y3Rp b24NCg0KICAgVG9kYXksIGEgaHVnZSBtYWpvcml0eSBvZiB1bndhbnRlZCBlbWFpbCBjb250YWlu cyBoZWFkZXJzIHRoYXQgbGllDQogICBhYm91dCB0aGUgb3JpZ2luIG9mIHRoZSBtYWlsLiAgVGhp cyBpcyB0cnVlIG9mIG1vc3Qgc3BhbSBhbmQNCiAgIHN1YnN0YW50aWFsbHkgYWxsIG9mIHRoZSB2 aXJ1cyBlbWFpbCB0aGF0IGlzIHNlbnQuDQoNCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEg bWVjaGFuaXNtIHN1Y2ggdGhhdCByZWNlaXZpbmcgTVRBcywgTURBcw0KICAgYW5kL29yIE1VQXMg Y2FuIHJlY29nbml6ZSBtYWlsIGluIHRoZSBhYm92ZSBjYXRlZ29yeSBhbmQgdGFrZQ0KICAgYXBw cm9wcmlhdGUgYWN0aW9uLiAgRm9yIGV4YW1wbGUsIGFuIE1UQSBtaWdodCByZWZ1c2UgdG8gYWNj ZXB0IGENCiAgIG1lc3NhZ2UsIGFuIE1EQSBtaWdodCBkaXNjYXJkIGEgbWVzc2FnZSByYXRoZXIg dGhhbiBwbGFjaW5nIGl0IGludG8gYQ0KICAgbWFpbGJveCwgYW5kIGFuIE1VQSBtaWdodCByZW5k ZXIgdGhhdCBtZXNzYWdlIGluIHNvbWUgZGlzdGluY3RpdmUNCiAgIGZhc2hpb24uDQoNCiAgIElu IG9yZGVyIHRvIGF2b2lkIGZ1cnRoZXIgZnJhZ21lbnRhdGlvbiBvZiB0aGUgSW50ZXJuZXQgZW1h aWwgc3lzdGVtLA0KICAgaXQgaXMgZGVzaXJhYmxlIHRoYXQgdGhlIEludGVybmV0IGNvbW11bml0 eSBhcyBhIHdob2xlIGNvbWUgdG8gYQ0KICAgY29uc2Vuc3VzIGFzIHRvIHdoYXQgbWFpbCBzZW5k ZXJzIHNob3VsZCBkbyB0byBtYWtlIHRoZWlyIG1haWwgYXBwZWFyDQogICBub24tc3Bvb2ZlZCwg YW5kIGhvdyBtYWlsIHJlY2VpdmVycyBzaG91bGQgZGV0ZXJtaW5lIHdoZXRoZXIgbWFpbCBpcw0K ICAgc3Bvb2ZlZC4gIE9uIHRoZSBvdGhlciBoYW5kLCBpdCBpcyBub3QgbmVjZXNzYXJ5IHRvIHJl YWNoIGEgY29uc2Vuc3VzDQogICByZWdhcmRpbmcgdGhlIGFjdGlvbnMgdGhhdCB2YXJpb3VzIHBh cnRpZXMgdGFrZSBvbmNlIGEgbWVzc2FnZSBoYXMNCiAgIGJlZW4gZGV0ZXJtaW5lZCB0byBiZSBz cG9vZmVkLiAgVGhpcyBjYW4gYmUgZG9uZSB1bmlsYXRlcmFsbHkgLS0gb25lDQogICBhZ2VudCBt aWdodCBkZWNpZGUgdG8gZGlzY2FyZCBhIHNwb29mZWQgbWVzc2FnZSB3aGlsZSBhbm90aGVyIGRl Y2lkZXMNCiAgIHRvIGFkZCBhIGRpc2NsYWltZXIuDQoNCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5l cyBhIHBhaXIgb2YgY2xvc2VseS1yZWxhdGVkIHRlc3RzLiAgT25lIHZhbGlkYXRlcw0KICAgYSBt ZXNzYWdlJ3MgUHVycG9ydGVkIFJlc3BvbnNpYmxlIEFkZHJlc3MgKFBSQSkgYXMgZGVmaW5lZCBp biBbUFJBXS4NCiAgIFRoZSBvdGhlciB2YWxpZGF0ZXMgYSBtZXNzYWdlJ3MgUmV2ZXJzZS1QYXRo IChhbHNvIGtub3duIGFzIE1BSUwtRlJPTQ0KICAgYWRkcmVzcykgYXMgZGVmaW5lZCBpbiBbU1BG XS4NCg0KICAgQW4gZS1tYWlsIHNlbmRlciBTSE9VTEQgcHVibGlzaCBpbmZvcm1hdGlvbiBmb3Ig Ym90aCB0ZXN0cywgYW5kDQogICBTSE9VTEQgYXJyYW5nZSB0aGF0IGFueSBtYWlsIHRoYXQgaXMg c2VudCB3aWxsIHBhc3MgYm90aCB0ZXN0cy4gIEFuDQogICBlLW1haWwgcmVjZWl2ZXIgU0hPVUxE IHBlcmZvcm0gYXQgbGVhc3Qgb25lIG9mIHRoZXNlIHRlc3RzLg0KDQoNCjIuIFByb2JsZW0gU3Rh dGVtZW50DQoNCiAgIEJyaWVmbHkgc3RhdGVkLCB0aGUgbWVjaGFuaXNtcyBvZiB0aGlzIGRvY3Vt ZW50IGFsbG93IG9uZSB0byBhbnN3ZXINCiAgIHRoZSBmb2xsb3dpbmcgcXVlc3Rpb246DQoNCiAg ICAgIFdoZW4gYSBtZXNzYWdlIGlzIHRyYW5zZmVycmVkIHZpYSBTTVRQIGJldHdlZW4gdHdvIHVu cmVsYXRlZA0KICAgICAgcGFydGllcywgZG9lcyB0aGUgU01UUCBjbGllbnQgaG9zdCBoYXZlIHBl cm1pc3Npb24gdG8gc2VuZCBtYWlsDQogICAgICBvbiBiZWhhbGYgb2YgYSBtYWlsYm94IHJlZmVy ZW5jZWQgYnkgdGhlIG1lc3NhZ2U/DQoNCiAgIEFzIHNlZW4gZnJvbSB0aGUgcXVlc3Rpb24sIHRo aXMgbWVjaGFuaXNtIGFwcGxpZXMgdG8gdW5yZWxhdGVkDQogICBwYXJ0aWVzOiAgaXQgaXMgdXNl ZnVsIGF0IHRoZSBwb2ludCB3aGVyZSBhIG1lc3NhZ2UgcGFzc2VzIGFjcm9zcyB0aGUNCiAgIElu dGVybmV0IGZyb20gb25lIG9yZ2FuaXphdGlvbiB0byBhbm90aGVyLiAgSXQgaXMgYmV5b25kIHRo ZSBzY29wZSBvZg0KICAgdGhpcyBkb2N1bWVudCB0byBkZXNjcmliZSBhdXRoZW50aWNhdGlvbiBt ZWNoYW5pc21zIHRoYXQgY2FuIGJlDQogICBkZXBsb3llZCB3aXRoaW4gYW4gb3JnYW5pemF0aW9u Lg0KDQoNCg0KDQpMeW9uLCBXb25nICAgICAgICAgICAgICAgRXhwaXJlcyAtIEFwcmlsIDIwMDUg ICAgICAgICAgICAgICAgIFtQYWdlIDNdDQoMDQogICAgICAgICAgICAgICAgICAgU2VuZGVyIElE OiBBdXRoZW50aWNhdGluZyBFLU1haWwgICAgICAgT2N0b2JlciAyMDA0DQoNCg0KICAgVGhlIFBS QSB2ZXJzaW9uIG9mIHRoZSB0ZXN0IHNlZWtzIHRvIGF1dGhlbnRpY2F0ZSB0aGUgbWFpbGJveA0K ICAgYXNzb2NpYXRlZCB3aXRoIHRoZSBtb3N0IHJlY2VudCBpbnRyb2R1Y3Rpb24gb2YgYSBtZXNz YWdlIGludG8gdGhlDQogICBtYWlsIGRlbGl2ZXJ5IHN5c3RlbS4gIEluIHNpbXBsZSBjYXNlcywg dGhpcyBpcyB3aG8gdGhlIG1haWwgaXMgZnJvbS4NCiAgIEhvd2V2ZXIsIGluIHRoZSBjYXNlIG9m IGEgdGhpcmQtcGFydHkgbWFpbGVyLCBhIGZvcndhcmRlciBvciBhDQogICBtYWlsaW5nIGxpc3Qg c2VydmVyLCB0aGUgYWRkcmVzcyBiZWluZyBhdXRoZW50aWNhdGVkIGlzIHRoYXQgb2YgdGhlDQog ICB0aGlyZCBwYXJ0eSwgdGhlIGZvcndhcmRlciBvciB0aGUgbWFpbGluZyBsaXN0Lg0KDQogICBP biB0aGUgb3RoZXIgaGFuZCwgdGhlIE1BSUwtRlJPTSB2ZXJzaW9uIG9mIHRoZSB0ZXN0IHNlZWtz IHRvDQogICBhdXRoZW50aWNhdGUgdGhlIG1haWxib3ggdGhhdCB3b3VsZCByZWNlaXZlIERlbGl2 ZXJ5IFN0YXR1cw0KICAgTm90aWZpY2F0aW9ucyAoRFNOcywgb3IgYm91bmNlcykgZm9yIHRoZSBt ZXNzYWdlLiBJbiBzaW1wbGUgY2FzZXMsDQogICB0aGlzIHRvbyBpcyB3aG8gdGhlIG1haWwgaXMg ZnJvbS4gIEhvd2V2ZXIsIHRoaXJkLXBhcnR5IG1haWxlcnMsDQogICBmb3J3YXJkZXJzIGFuZCBt YWlsaW5nIGxpc3Qgc2VydmVycyBNVVNUIHNwZWNpZnkgYW4gYWRkcmVzcyB1bmRlcg0KICAgdGhl aXIgY29udHJvbCwgYW5kIFNIT1VMRCBhcnJhbmdlIHRoYXQgRFNOcyByZWNlaXZlZCBhdCB0aGlz IGFkZHJlc3MNCiAgIGFyZSBmb3J3YXJkZWQgdG8gdGhlIG9yaWdpbmFsIGJvdW5jZSBhZGRyZXNz Lg0KDQogICBJbiBib3RoIGNhc2VzLCB0aGUgZG9tYWluIGFzc29jaWF0ZWQgd2l0aCBhbiBlLW1h aWwgYWRkcmVzcyBpcyB3aGF0DQogICBpcyBhdXRoZW50aWNhdGVkOyBubyBhdHRlbXB0IGlzIG1h ZGUgdG8gYXV0aGVudGljYXRlIHRoZSBsb2NhbC1wYXJ0Lg0KICAgQSBkb21haW4gb3duZXIgZ2V0 cyB0byBkZXRlcm1pbmUgd2hpY2ggU01UUCBjbGllbnRzIHNwZWFrIG9uIGJlaGFsZg0KICAgb2Yg YWRkcmVzc2VzIHdpdGhpbiB0aGUgZG9tYWluOyBhIHJlc3BvbnNpYmxlIGRvbWFpbiBvd25lciBz aG91bGQgbm90DQogICBhdXRob3JpemUgU01UUCBjbGllbnRzIHRoYXQgd2lsbCBsaWUgYWJvdXQg bG9jYWwgcGFydHMuDQoNCiAgIEluIHRoZSBsb25nIHJ1biwgb25jZSB0aGUgZG9tYWluIG9mIHRo ZSBzZW5kZXIgaXMgYXV0aGVudGljYXRlZCwgaXQNCiAgIHdpbGwgYmUgcG9zc2libGUgdG8gdXNl IHRoYXQgZG9tYWluIGFzIHBhcnQgb2YgYSBtZWNoYW5pc20gdG8NCiAgIGRldGVybWluZSB0aGUg bGlrZWxpaG9vZCB0aGF0IGEgZ2l2ZW4gbWVzc2FnZSBpcyBzcGFtLCB1c2luZywgZm9yDQogICBl eGFtcGxlLCByZXB1dGF0aW9uIGFuZCBhY2NyZWRpdGF0aW9uIHNlcnZpY2VzLiAoVGhlc2Ugc2Vy dmljZXMgYXJlDQogICBub3QgdGhlIHN1YmplY3Qgb2YgdGhlIHByZXNlbnQgbWVjaGFuaXNtLCBi dXQgaXQgc2hvdWxkIGVuYWJsZSB0aGVtLikNCg0KDQozLiBTUEYgUmVjb3Jkcw0KDQogICBEb21h aW5zIGRlY2xhcmUgd2hpY2ggaG9zdHMgYXJlIGFuZCBhcmUgbm90IGF1dGhvcml6ZWQgdG8gdHJh bnNtaXQNCiAgIGVtYWlsIG1lc3NhZ2VzIG9uIHRoZWlyIGJlaGFsZiBieSBwdWJsaXNoaW5nIFNQ RiByZWNvcmRzIGFzIGRlZmluZWQNCiAgIGluIFtTUEZdLiAgU2VuZGVyIElEIGVtcGxveXMgU1BG IHJlY29yZHMsIGFzIGRlc2NyaWJlZCBiZWxvdywgaW4NCiAgIG9yZGVyIHRvIGRldGVybWluZSBp ZiBhIHNwZWNpZmljIGVtYWlsIG1lc3NhZ2UgaGFzIGJlZW4gcmVjZWl2ZWQgZnJvbQ0KICAgYW4g YXV0aG9yaXplZCBob3N0Lg0KDQogICBTZW5kZXIgSUQgbW9kaWZpZXMgdGhlIGRlZmluaXRpb24g b2YgU1BGIHJlY29yZHMgYXMgZGVzY3JpYmVkIGluIHRoZQ0KICAgZm9sbG93aW5nIHN1Yi1zZWN0 aW9ucy4NCg0KMy4xIFBvc2l0aW9uYWwgTW9kaWZpZXJzDQoNCiAgIFRoaXMgc2VjdGlvbiByZXBs YWNlcyBzZWN0aW9uIDQuNi4zIG9mIFtTUEZdIGFuZCBhZGRzIHRoZSBjb25jZXB0IG9mDQogICBw b3NpdGlvbmFsIG1vZGlmaWVycy4NCg0KICAgTW9kaWZpZXJzIGFyZSBrZXkvdmFsdWUgcGFpcnMg dGhhdCBhZmZlY3QgdGhlIGV2YWx1YXRpb24gb2YgdGhlDQogICBjaGVja19ob3N0KCkgZnVuY3Rp b24uDQoNCiAgIE1vZGlmaWVycyBhcmUgZWl0aGVyIGdsb2JhbCBvciBwb3NpdGlvbmFsOg0KDQoN Cg0KTHlvbiwgV29uZyAgICAgICAgICAgICAgIEV4cGlyZXMgLSBBcHJpbCAyMDA1ICAgICAgICAg ICAgICAgICBbUGFnZSA0XQ0KDA0KICAgICAgICAgICAgICAgICAgIFNlbmRlciBJRDogQXV0aGVu dGljYXRpbmcgRS1NYWlsICAgICAgIE9jdG9iZXIgMjAwNA0KDQoNCiAgICAgR2xvYmFsIG1vZGlm aWVycyBNQVkgYXBwZWFyIGFueXdoZXJlIGluIHRoZSByZWNvcmQsIGJ1dCBTSE9VTEQNCiAgICAg YXBwZWFyIGF0IHRoZSBlbmQsIGFmdGVyIGFsbCBtZWNoYW5pc21zIGFuZCBwb3NpdGlvbmFsIG1v ZGlmaWVycy4NCg0KICAgICBQb3NpdGlvbmFsIG1vZGlmaWVycyBhcHBseSBvbmx5IHRvIHRoZSBt ZWNoYW5pc20gdGhleSBmb2xsb3cuICBJdA0KICAgICBpcyBhIHN5bnRheCBlcnJvciBmb3IgYSBw b3NpdGlvbmFsIG1vZGlmaWVyIHRvIGFwcGVhciBiZWZvcmUgdGhlDQogICAgIGZpcnN0IG1lY2hh bmlzbS4NCg0KICAgTW9kaWZpZXJzIG9mIGVpdGhlciB0eXBlIGFyZSBhbHNvIGVpdGhlciBzaW5n dWxhciBvciBtdWx0aXBsZToNCg0KICAgICBTaW5ndWxhciBtb2RpZmllcnMgbWF5IGFwcGVhciBv bmx5IG9uY2UgaW4gdGhlIHJlY29yZCBpZiB0aGV5IGFyZQ0KICAgICBnbG9iYWwsIG9yIG9uY2Ug YWZ0ZXIgZWFjaCBtZWNoYW5pc20gaWYgdGhleSBhcmUgcG9zaXRpb25hbC4NCg0KICAgICBNdWx0 aXBsZSBtb2RpZmllcnMgbWF5IGFwcGVhciBtdWx0aXBsZSB0aW1lcyBpbiB0aGUgcmVjb3JkIGlm IHRoZXkNCiAgICAgb3IgbXVsdGlwbGUgdGltZXMgYWZ0ZXIgZWFjaCBtZWNoYW5pc20gaWYgdGhl eSBhcmUNCiAgICAgcG9zaXRpb25hbC4NCg0KICAgQSBtb2RpZmllciBpcyBub3QgYWxsb3dlZCB0 byBiZSBkZWZpbmVkIGFzIGJvdGggZ2xvYmFsIGFuZA0KICAgcG9zaXRpb25hbC4NCg0KICAgVGhl IG1vZGlmaWVycyAicmVkaXJlY3QiIGFuZCAiZXhwIiBkZXNjcmliZWQgaW4gc2VjdGlvbiA1IG9m IFtTUEZdDQogICBhcmUgZ2xvYmFsIGFuZCBzaW5ndWxhci4NCg0KICAgT3JkZXJpbmcgb2YgbW9k aWZpZXJzIGRvZXMgbm90IG1hdHRlciwgZXhjZXB0Og0KICAgMSkgICAgIHBvc2l0aW9uYWwgbW9k aWZpZXJzIG11c3QgYXBwZWFyIGFmdGVyIHRoZSBtZWNoYW5pc20gdGhleQ0KICAgICAgICAgIGFm ZmVjdCBhbmQgYmVmb3JlIGFueSBzdWJzZXF1ZW50IG1lY2hhbmlzbXMuDQogICBhbmQgMikgd2hl biBhIG11bHRpcGxlIG1vZGlmaWVyIGFwcGVhcnMgbW9yZSB0aGFuIG9uZSB0aW1lLCB0aGUNCiAg ICAgICAgICBvcmRlcmluZyBvZiB0aGUgYXBwZWFyYW5jZXMgbWF5IGJlIHNpZ25pZmljYW50IHRv IHRoZQ0KICAgICAgICAgIG1vZGlmaWVyLg0KICAgT3RoZXIgdGhhbiB0aGVzZSBjb25zdHJhaW50 cywgaW1wbGVtZW50YXRpb25zIE1VU1QgdHJlYXQgZGlmZmVyZW50DQogICBvcmRlcnMgb2YgbW9k aWZpZXJzIHRoZSBzYW1lLiAgQW4gaW50ZW5kZWQgc2lkZSBlZmZlY3Qgb2YgdGhlc2UgcnVsZXMN CiAgIGlzIG1vZGlmaWVycyBjYW5ub3QgYmUgZGVmaW5lZCB0aGF0IG1vZGlmeSBvdGhlciBtb2Rp ZmllcnMuDQoNCiAgIFRoZXNlIHJ1bGVzIGFsbG93IGFuIGltcGxlbWVudGF0aW9uIHRvIGNvcnJl Y3RseSBwcmUtcGFyc2UgYSByZWNvcmQuDQogICBGdXJ0aGVybW9yZSwgdGhleSBhcmUgY3JhZnRl ZCB0byBhbGxvdyB0aGUgcGFyc2luZyBhbGdvcml0aG0gdG8gYmUNCiAgIHN0YWJsZSwgZXZlbiB3 aGVuIG5ldyBtb2RpZmllcnMgYXJlIGludHJvZHVjZWQuDQoNCiAgIE1vZGlmaWVycyB3aGljaCBh cmUgdW5yZWNvZ25pemVkIE1VU1QgYmUgaWdub3JlZC4gIFRoaXMgYWxsb3dzIG9sZGVyDQogICBp bXBsZW1lbnRhdGlvbnMgdG8gaGFuZGxlIHJlY29yZHMgd2l0aCBtb2RpZmllcnMgdGhhdCB3ZXJl IGRlZmluZWQNCiAgIGFmdGVyIHRoZXkgd2VyZSB3cml0dGVuLg0KDQozLjIgTXVsdGlwbGUgUmVj b3Jkcw0KDQogICBOb3R3aXRoc3RhbmRpbmcgc2VjdGlvbiAzLjEuMiBvZiBbU1BGXSwgYSBkb21h aW4gTUFZIHB1Ymxpc2ggdHdvIFNQRg0KICAgcmVjb3Jkcywgb25lIG9mIHdoaWNoIHVzZXMgdGhl ICJ2PXNwZjEiIHZlcnNpb24gaWRlbnRpZmllciBkZWZpbmVkIGluDQogICBbU1BGXSBhbmQgdGhl IG90aGVyIG9mIHdoaWNoIHVzZXMgdGhlICJzcGYyIiB2ZXJzaW9uIGlkZW50aWZpZXINCiAgIGRl ZmluZWQgYmVsb3cuICBBIGRvbWFpbiBNVVNUIE5PVCBwdWJsaXNoIG1vcmUgdGhhbiBvbmUgcmVj b3JkIG9mDQogICBlYWNoIHZlcnNpb24uDQoNCg0KDQoNCkx5b24sIFdvbmcgICAgICAgICAgICAg ICBFeHBpcmVzIC0gQXByaWwgMjAwNSAgICAgICAgICAgICAgICAgW1BhZ2UgNV0NCgwNCiAgICAg ICAgICAgICAgICAgICBTZW5kZXIgSUQ6IEF1dGhlbnRpY2F0aW5nIEUtTWFpbCAgICAgICBPY3Rv YmVyIDIwMDQNCg0KDQozLjMgVmVyc2lvbiBhbmQgU2NvcGUNCg0KICAgVW5kZXIgU2VuZGVyIElE LCByZWNlaXZpbmcgZG9tYWlucyBtYXkgcGVyZm9ybSBhIGNoZWNrIG9mIGVpdGhlciB0aGUNCiAg IFBSQSBpZGVudGl0eSBvciB0aGUgTUFJTC1GUk9NIGlkZW50aXR5LiAgU2VuZGluZyBkb21haW5z IHRoZXJlZm9yZQ0KICAgcmVxdWlyZSBhIG1ldGhvZCBmb3IgZGVjbGFyaW5nIHdoZXRoZXIgdGhl aXIgcHVibGlzaGVkIGxpc3Qgb2YNCiAgIGF1dGhvcml6ZWQgb3V0Ym91bmQgZW1haWwgc2VydmVy cyBjYW4gYmUgdXNlZCBmb3IgdGhlIFBSQSBjaGVjaywgdGhlDQogICBNQUlMLUZST00gY2hlY2sg b3IgYm90aC4NCg0KICAgVGhpcyBzZWN0aW9uIHJlcGxhY2VzIHNlY3Rpb24gNC41IG9mIFtTUEZd IGFuZCBhZGRzIHRoZSBjb25jZXB0IG9mDQogICBTUEYgcmVjb3JkIHNjb3Blcy4NCg0KICAgU1BG IHJlY29yZHMgYmVnaW4gd2l0aCBhIHZlcnNpb24gaWRlbnRpZmllciBhbmQgbWF5IGFsc28gaW5j bHVkZSBhDQogICBzY29wZToNCg0KICAgICAgcmVjb3JkICAgICAgPSB2ZXJzaW9uIHRlcm1zICpT UA0KICAgICAgdmVyc2lvbiAgICAgPSAidj1zcGYxIiB8ICggInNwZjIuIiB2ZXItbWlub3Igc2Nv cGUpDQogICAgICB2ZXItbWlub3IgICA9IDEqRElHSVQNCiAgICAgIHNjb3BlICAgICAgID0gIi8i IHNjb3BlLWlkICooICIsIiBzY29wZS1pZCApDQogICAgICBzY29wZS1pZCAgICA9ICJtZnJvbSIg LyAicHJhIiAvIG5hbWUNCg0KICAgU3RhcnRpbmcgd2l0aCB0aGUgc2V0IG9mIHJlY29yZHMgdGhh dCB3ZXJlIHJldHVybmVkIGJ5IHRoZSBsb29rdXAsDQogICByZWNvcmQgc2VsZWN0aW9uIHByb2Nl ZWRzIGluIHRocmVlIHN0ZXBzOg0KDQogICAxLiBJZiBhbnkgcmVjb3JkcyBvZiB0eXBlIFNQRiBh cmUgaW4gdGhlIHNldCwgdGhlbiBhbGwgcmVjb3JkcyBvZg0KICAgICAgdHlwZSBUWFQgYXJlIGRp c2NhcmRlZC4NCiAgIDIuIFJlY29yZHMgdGhhdCBkbyBub3QgYmVnaW4gd2l0aCBwcm9wZXIgdmVy c2lvbiBhbmQgc2NvcGUgc2VjdGlvbnMNCiAgICAgIGFyZSBkaXNjYXJkZWQuICBUaGUgdmVyc2lv biBzZWN0aW9uIGZvciAic3BmMiIgcmVjb3JkcyBjb250YWlucyBhDQogICAgICB2ZXItbWlub3Ig ZmllbGQgdGhhdCBpcyBmb3IgYmFja3dhcmQgY29tcGF0aWJsZSBmdXR1cmUNCiAgICAgIGV4dGVu c2lvbnMuICBUaGlzIGZpZWxkIG11c3QgYmUgd2VsbC1mb3JtZWQgZm9yIGEgcmVjb3JkIHRvIGJl DQogICAgICByZXRhaW5lZCwgYnV0IGlzIG90aGVyd2lzZSBpZ25vcmVkLg0KICAgMy4gUmVjb3Jk cyB0aGF0IHVzZSB0aGUgInNwZjIiIHZlcnNpb24gaWRlbnRpZmllciBhbmQgZG8gbm90IGhhdmUg YQ0KICAgICAgc2NvcGUtaWQgdGhhdCBtYXRjaGVzIDxzY29wZT4gYXJlIGRpc2NhcmRlZC4gIE5v dGUgdGhhdCB0aGlzIGlzIGENCiAgICAgIGNvbXBsZXRlIHN0cmluZyBtYXRjaCBvbiB0aGUgc2Nv cGUtaWQgdG9rZW5zOiBJZiA8c2NvcGU+IGlzICJwcmEiLA0KICAgICAgdGhlbiB0aGUgcmVjb3Jk IHN0YXJ0aW5nICJzcGYyLjAvbWZyb20scHJhdHRsZSxmdWJhciIgd291bGQgYmUNCiAgICAgIGRp c2NhcmRlZCwgYnV0IGEgcmVjb3JkIHN0YXJ0aW5nICJzcGYyLjAvbWZyb20scHJhLGZ1YmFyIiB3 b3VsZCBiZQ0KICAgICAgcmV0YWluZWQuDQogICA0LiBJZiB0aGUgbG9va3VwIHJldHVybmVkIHR3 byByZWNvcmRzLCBvbmUgY29udGFpbmluZyB0aGUgInY9c3BmMSINCiAgICAgIHZlcnNpb24gaWRl bnRpZmllciBhbmQgdGhlIG90aGVyIGNvbnRhaW5pbmcgdGhlICJzcGYyIg0KICAgICAgdmVyc2lv biBpZGVudGlmaWVyLCB0aGUgInNwZjIiIHZlcnNpb24gdGFrZXMgcHJlY2VkZW5jZSBmb3IgdGhl DQogICAgICBkZXNpcmVkIHNjb3BlLWlkLiAgSWYgdGhlICJzcGYyIiByZWNvcmQgZG9lcyBub3Qg Y29udGFpbiB0aGUNCiAgICAgIGRlc2lyZWQgc2NvcGUtaWQsIHRoZW4gdGhlICJ2PXNwZjEiIHJl Y29yZCBpcyBzZWxlY3RlZC4NCiAgIDUuIElmIGFuICJzcGYyIiByZWNvcmQgZG9lcyBub3QgY29u dGFpbiB0aGUgZGVzaXJlZCBzY29wZS1pZCBhbmQNCiAgICAgIHRoZXJlIGlzIG5vICJ2PXNwZjEi IHJlY29yZCBmb3IgdGhlIGRvbWFpbiwgdGhlbiBubyByZWNvcmQgaXMNCiAgICAgIHNlbGVjdGVk Lg0KDQogICBBZnRlciB0aGUgYWJvdmUgc3RlcHMsIHRoZXJlIHNob3VsZCBiZSBvbmUgcmVjb3Jk IHJlbWFpbmluZyBhbmQNCiAgIGV2YWx1YXRpb24gY2FuIHByb2NlZWQuICBJZiB0aGVyZSBhcmUg bm8gcmVjb3JkcyByZW1haW5pbmcsDQogICBjaGVja19ob3N0KCkgZXhpdHMgaW1tZWRpYXRlbHkg d2l0aCB0aGUgcmVzdWx0ICJOb25lIi4gIElmIHRoZXJlIGFyZQ0KDQoNCg0KTHlvbiwgV29uZyAg ICAgICAgICAgICAgIEV4cGlyZXMgLSBBcHJpbCAyMDA1ICAgICAgICAgICAgICAgICBbUGFnZSA2 XQ0KDA0KICAgICAgICAgICAgICAgICAgIFNlbmRlciBJRDogQXV0aGVudGljYXRpbmcgRS1NYWls ICAgICAgIE9jdG9iZXIgMjAwNA0KDQoNCiAgIHR3byBvciBtb3JlIHJlY29yZHMgcmVtYWluaW5n LCB0aGVuIGNoZWNrX2hvc3QoKSBleGl0cyBpbW1lZGlhdGVseQ0KICAgd2l0aCB0aGUgZXJyb3Ig IlBlcm1FcnJvciIuDQoNCiAgIFRoaXMgZG9jdW1lbnQgb25seSBkZWZpbmVzIHRoZSBleGlzdGVu Y2Ugb2YgdHdvIHNjb3BlczogIm1mcm9tIiBhbmQNCiAgICJwcmEiLiAgVGhlIGRldGFpbHMgb2Yg dGhlc2UgdHdvIHNjb3BlcyBhcmUgZGVmaW5lZCBpbiBvdGhlcg0KICAgZG9jdW1lbnRzOiAibWZy b20iIGlzIGRlZmluZWQgaW4gW1NQRl0sICJwcmEiIGlzIGRlZmluZWQgaW4gW1BSQV0uDQoNCiAg IE90aGVyIHNjb3BlcyBtYXkgYmUgZGVmaW5lZCBieSBmdXR1cmUgZG9jdW1lbnRzIG9ubHkuICBU aGVyZSBpcyBubw0KICAgcmVnaXN0cnkgZm9yIHNjb3Blcy4gIEEgc2NvcGUgZGVmaW5pdGlvbiBt dXN0IGRlZmluZSB3aGF0IGl0DQogICBpZGVudGlmaWVzIGFzIHRoZSBzZW5kaW5nIG1haWxib3gg Zm9yIGEgbWVzc2FnZSwgaG93IHRvIGV4dHJhY3QgdGhhdA0KICAgaW5mb3JtYXRpb24gZnJvbSBh IG1lc3NhZ2UsIGhvdyB0byBkZXRlcm1pbmUgdGhlIGluaXRpYWwgYXJndW1lbnRzDQogICBmb3Ig dGhlIGNoZWNrX2hvc3QoKSBmdW5jdGlvbiwgYW5kIHdoYXQgdGhlIGNvbXBsaWFudCByZXNwb25z ZXMgdG8NCiAgIHRoZSByZXN1bHQgYXJlLiAgVGhpcyBlbnN1cmVzIHRoYXQgZG9tYWlucyB3aXRo IHB1Ymxpc2hlZCByZWNvcmRzIGFuZA0KICAgbWFpbCByZWNlaXZlciBhZ3JlZSBvbiB0aGUgc2Vt YW50aWNzIG9mIHRoZSBzY29wZS4NCg0KICAgQSBjb21wbGlhbnQgZG9tYWluIFNIT1VMRCBwdWJs aXNoIGF1dGhvcml6YXRpb25zIGZvciBldmVyeSBkZWZpbmVkDQogICBzY29wZS4NCg0KMy4zLjEg TWlub3IgVmVyc2lvbg0KDQogICBBbGwgcHVibGlzaGVkIHJlY29yZHMgdGhhdCB1c2UgdGhlICJz cGYyIiB2ZXJzaW9uIGlkZW50aWZpZXIgTVVTVA0KICAgc3RhcnQgd2l0aCAic3BmMi4wIi4gIFRo aXMgZG9jdW1lbnQgb25seSBzcGVjaWZpZXMgcmVjb3JkcyB3aXRoIGENCiAgIG1pbm9yIHZlcnNp b24gb2YgIjAiLg0KDQogICBGdXR1cmUgdmVyc2lvbnMgb2YgdGhpcyBkb2N1bWVudCBtYXkgZGVm aW5lIG90aGVyIG1pbm9yIHZlcnNpb25zIHRvDQogICBiZSB1c2VkLg0KDQozLjQgQmFja3dhcmQg Q29tcGF0aWJpbGl0eQ0KDQogICBBcyBkZXNjcmliZWQgaW4gW1NQRl0sIGRvbWFpbiBhZG1pbmlz dHJhdG9ycyBhcmUgcmVxdWlyZWQgdG8gcHVibGlzaA0KICAgaW5mb3JtYXRpb24gaW4gRE5TIHJl Z2FyZGluZyB0aGVpciBhdXRob3JpemVkIG91dGJvdW5kIGUtbWFpbA0KICAgc2VydmVycy4gIFtT UEZdIGRlc2NyaWJlcyBhIGZvcm1hdCBmb3IgdGhpcyBpbmZvcm1hdGlvbiBpZGVudGlmaWVkIGJ5 DQogICB0aGUgdmVyc2lvbiBwcmVmaXggInY9c3BmMSIuICBNYW55IGRvbWFpbnMgaGF2ZSBwdWJs aXNoZWQgaW5mb3JtYXRpb24NCiAgIGluIEROUyB1c2luZyB0aGlzIGZvcm1hdC4gIEluIG9yZGVy IHRvIHByb3ZpZGUgYmFja3dhcmQgY29tcGF0aWJpbGl0eQ0KICAgZm9yIHRoZXNlIGRvbWFpbnMs IFNlbmRlciBJRCBpbXBsZW1lbnRhdGlvbnMgU0hPVUxEIGludGVycHJldCB0aGUNCiAgIHZlcnNp b24gcHJlZml4ICJ2PXNwZjEiIGFzIGVxdWl2YWxlbnQgdG8gInNwZjIuMC9tZnJvbSxwcmEiLCBw cm92aWRlZA0KICAgbm8gcmVjb3JkIHN0YXJ0aW5nIHdpdGggInNwZjIuMCIgZXhpc3RzLg0KDQog ICBbU1BGXSBkZXNjcmliZXMgYSBNQUlMLUZST00gY2hlY2sgb25seS4gIEFkbWluaXN0cmF0b3Jz IHdobyBoYXZlDQogICBhbHJlYWR5IHB1Ymxpc2hlZCAidj1zcGYxIiByZWNvcmRzIFNIT1VMRCBy ZXZpZXcgdGhlc2UgcmVjb3JkcyB0bw0KICAgZGV0ZXJtaW5lIHdoZXRoZXIgdGhleSBhcmUgYWxz byB2YWxpZCBmb3IgdXNlIHdpdGggUFJBIGNoZWNrcy4gIElmDQogICB0aGUgaW5mb3JtYXRpb24g aW4gYSAidj1zcGYxIiByZWNvcmQgaXMgbm90IGNvcnJlY3QgZm9yIGEgUFJBIGNoZWNrLA0KICAg YWRtaW5pc3RyYXRvcnMgU0hPVUxEIHB1Ymxpc2ggZWl0aGVyIGFuICJzcGYyLjAvcHJhIiByZWNv cmQgd2l0aA0KICAgY29ycmVjdCBpbmZvcm1hdGlvbiwgb3IgYW4gInNwZjIuMC9wcmEgP2FsbCIg cmVjb3JkIGluZGljYXRpbmcgdGhhdA0KICAgdGhlIHJlc3VsdCBvZiBhIFBSQSBjaGVrIGlzIGV4 cGxpY2l0bHkgaW5jb25jbHVzaXZlLg0KDQoNCg0KDQoNCg0KTHlvbiwgV29uZyAgICAgICAgICAg ICAgIEV4cGlyZXMgLSBBcHJpbCAyMDA1ICAgICAgICAgICAgICAgICBbUGFnZSA3XQ0KDA0KICAg ICAgICAgICAgICAgICAgIFNlbmRlciBJRDogQXV0aGVudGljYXRpbmcgRS1NYWlsICAgICAgIE9j dG9iZXIgMjAwNA0KDQoNCiAgIDQuIERlY2lzaW9uIE1vZGVsDQoNCiAgIFNlbmRlciBJRCBlbmFi bGVzIHJlY2VpdmluZyBlbWFpbCBzeXN0ZW1zIHRvIGFuc3dlciB0aGUgcXVlc3Rpb246DQoNCiAg IEdpdmVuIGFuIGVtYWlsIG1lc3NhZ2UsIGFuZCBnaXZlbiBhbiBJUCBhZGRyZXNzIGZyb20gd2hp Y2ggaXQgaGFzDQogICBiZWVuIChvciB3aWxsIGJlKSByZWNlaXZlZCwgaXMgdGhlIFNNVFAgY2xp ZW50IGF0IHRoYXQgSVAgYWRkcmVzcw0KICAgYXV0aG9yaXplZCB0byBzZW5kIHRoYXQgZW1haWwg bWVzc2FnZT8NCg0KICAgVGhpcyBxdWVzdGlvbiB3aWxsIHVzdWFsbHkgYmUgYXNrZWQgYnkgYW4g U01UUCBzZXJ2ZXIgYXMgcGFydCBvZg0KICAgZGVjaWRpbmcgd2hldGhlciB0byBhY2NlcHQgYW4g aW5jb21pbmcgbWFpbCBtZXNzYWdlLiAgSG93ZXZlciwgdGhpcw0KICAgcXVlc3Rpb24gY291bGQg YWxzbyBiZSBhc2tlZCBsYXRlciBieSBhIGRpZmZlcmVudCBwYXJ0eS4gIEFuIE1VQSwgZm9yDQog ICBleGFtcGxlLCBjb3VsZCB1c2UgdGhlIHJlc3VsdCBvZiB0aGlzIHF1ZXN0aW9uIHRvIGRldGVy bWluZSBob3cgdG8NCiAgIGZpbGUgb3IgcHJlc2VudCBhIG1lc3NhZ2UuDQoNCiAgIFRoZXJlIGFy ZSB0aHJlZSBzdGVwcyB0byBhbnN3ZXJpbmcgdGhpcyBxdWVzdGlvbjoNCg0KICAgKDEpICBGcm9t IGFuIGUtbWFpbCBtZXNzYWdlLCBleHRyYWN0IHRoZSBhZGRyZXNzIHRvIHZlcmlmeS4gIFRoZSBQ UkENCiAgICAgICB2YXJpYW50IG9mIHRoaXMgdGVzdCBkb2VzIHNvIGFzIHNwZWNpZmllZCBpbiBb UFJBXSwgb3B0aW9uYWxseQ0KICAgICAgIHVzaW5nIHRoZSBvcHRpbWl6YXRpb24gc3BlY2lmaWVk IGluIFtTdWJtaXR0ZXJdLiAgVGhlIE1BSUwgRlJPTQ0KICAgICAgIHZhcmlhbnQgb2YgdGhpcyB0 ZXN0IGRvZXMgc28gYXMgc3BlY2lmaWVkIGluIFtTUEZdLg0KDQogICAoMikgIEV4dHJhY3QgdGhl IGRvbWFpbiBwYXJ0IG9mIHRoZSBhZGRyZXNzIGRldGVybWluZWQgaW4gc3RlcCAoMSkuDQoNCiAg ICgzKSAgQ2FsbCB0aGUgY2hlY2tfaG9zdCgpIGZ1bmN0aW9uIGRlZmluZWQgaW4gW1NQRl0sIG1v ZGlmaWVkIGJ5IHRoZQ0KICAgICAgIGFkZGl0aW9uIG9mIGEgc2NvcGUgcGFyYW1ldGVyLiAgVGh1 cywgZm9yIFNlbmRlciBJRCB0aGUNCiAgICAgICBjaGVja19ob3N0KCkgZnVuY3Rpb24gaXMgY2Fs bGVkIHBhc3NpbmcgdGhlIGZvbGxvd2luZw0KICAgICAgIHBhcmFtZXRlcnM6DQogICAgICAgICBh LiBBIHNjb3BlIG9mICJwcmEiIChmb3IgdGhlIFBSQSB2YXJpYW50IG9mIHRoZSB0ZXN0KSwgb3IN CiAgICAgICAgICAgICJtZnJvbSIgKGZvciB0aGUgTUFJTCBGUk9NIHZhcmlhbnQgb2YgdGhlIHRl c3QpLg0KICAgICAgICAgYi4gVGhlIElQIGFkZHJlc3MgKGVpdGhlciBJUHY0IG9yIElQdjYpIGZy b20gd2hpY2ggdGhlIG1lc3NhZ2UNCiAgICAgICAgICAgIGlzIGJlaW5nIG9yIGhhcyBiZWVuIHJl Y2VpdmVkLg0KICAgICAgICAgYy4gVGhlIGRvbWFpbiBmcm9tIHN0ZXAgKDIpIGFib3ZlLg0KICAg ICAgICAgZC4gVGhlIGFkZHJlc3MgZnJvbSBzdGVwICgxKSBhYm92ZS4NCg0KICAgSWYgdGhlIFNl bmRlciBJRCBjaGVjayBpcyBiZWluZyBwZXJmb3JtZWQgYnkgYW4gTVRBIGFzIHBhcnQgb2YNCiAg IHJlY2VpdmluZyBhbiBlLW1haWwgbWVzc2FnZSwgYW5kIGl0IGNhbm5vdCBkZXRlcm1pbmUgYW4g YWRkcmVzcyBpbg0KICAgc3RlcCAoMSkgYWJvdmUgKGJlY2F1c2UgdGhlIG1lc3NhZ2Ugb3IgYWRk cmVzcyBpcyBtYWxmb3JtZWQpLCB0aGVuDQogICB0aGUgbWVzc2FnZSBTSE9VTEQgYmUgcmVqZWN0 ZWQgd2l0aCBlcnJvciAiNTUwIDUuNy4xIE1pc3NpbmcNCiAgIFB1cnBvcnRlZCBSZXNwb25zaWJs ZSBBZGRyZXNzIiBvciBlcnJvciAiNTUwIDUuNy4xIE1pc3NpbmcgUmV2ZXJzZS0NCiAgIFBhdGgg YWRkcmVzcyIuDQoNCiAgIFRoZSByZXN1bHQgb2YgdGhlIGNoZWNrX2hvc3QoKSBmdW5jdGlvbiBp cyBvbmUgb2YgdGhlIHZhbHVlcw0KICAgIk5ldXRyYWwiLCAiUGFzcyIsICJGYWlsIiwgIlNvZnRG YWlsIiwgIk5vbmUiLCAiVGVtcEVycm9yIiBvcg0KICAgIlBlcm1FcnJvciIuICBTZWN0aW9uIDUg ZGVzY3JpYmVzIGhvdyB0aGVzZSByZXN1bHRzIGFyZSB1c2VkIGJ5IE1UQXMNCiAgIHJlY2Vpdmlu ZyBtZXNzYWdlcy4gIFRoaXMgc3BlY2lmaWNhdGlvbiBpbXBvc2VzIG5vIHJlcXVpcmVtZW50cyBv bg0KICAgcGFydGllcyBwZXJmb3JtaW5nIHRoaXMgdGVzdCBpbiBvdGhlciBlbnZpcm9ubWVudHMu DQoNCg0KDQoNCg0KTHlvbiwgV29uZyAgICAgICAgICAgICAgIEV4cGlyZXMgLSBBcHJpbCAyMDA1 ICAgICAgICAgICAgICAgICBbUGFnZSA4XQ0KDA0KICAgICAgICAgICAgICAgICAgIFNlbmRlciBJ RDogQXV0aGVudGljYXRpbmcgRS1NYWlsICAgICAgIE9jdG9iZXIgMjAwNA0KDQoNCjUuIEFjdGlv bnMgQmFzZWQgb24gdGhlIERlY2lzaW9uDQoNCiAgIFdoZW4gdGhlIFNlbmRlciBJRCB0ZXN0IGlz IHVzZWQgYnkgYW4gU01UUCBzZXJ2ZXIgYXMgcGFydCBvZg0KICAgcmVjZWl2aW5nIGEgbWVzc2Fn ZSwgdGhlIHNlcnZlciBzaG91bGQgdGFrZSB0aGUgYWN0aW9ucyBkZXNjcmliZWQgYnkNCiAgIHRo aXMgc2VjdGlvbi4NCg0KICAgVGhlIGNoZWNrX2hvc3QoKSBmdW5jdGlvbiByZXR1cm5zIG9uZSBv ZiB0aGUgZm9sbG93aW5nIHJlc3VsdHMuIFNlZQ0KICAgW1NQRl0gZm9yIHRoZSBtZWFuaW5nIG9m IHRoZXNlIHJlc3VsdHMuDQoNCjUuMSBOZXV0cmFsLCBOb25lLCBTb2Z0RmFpbCBvciBQZXJtRXJy b3INCg0KICAgQW4gU01UUCBzZXJ2ZXIgcmVjZWl2aW5nIG9uZSBvZiB0aGVzZSByZXN1bHRzIFNI T1VMRCBOT1QgcmVqZWN0IHRoZQ0KICAgbWVzc2FnZSBmb3IgdGhpcyByZWFzb24gYWxvbmUsIGJ1 dCBNQVkgc3ViamVjdCB0aGUgbWVzc2FnZSB0bw0KICAgaGVpZ2h0ZW5lZCBzY3J1dGlueSBieSBv dGhlciBtZWFzdXJlcywgYW5kIE1BWSByZWplY3QgdGhlIG1lc3NhZ2UgYXMNCiAgIGEgcmVzdWx0 IG9mIHRoaXMgaGVpZ2h0ZW5lZCBzY3J1dGlueS4NCg0KICAgU3VjaCBhZGRpdGlvbmFsIHNlY3Vy aXR5IG1lYXN1cmVzIE1BWSB0YWtlIGludG8gYWNjb3VudCB0aGF0IGENCiAgIG1lc3NhZ2UgZm9y IHdoaWNoIHRoZSByZXN1bHQgaXMgIlNvZnRGYWlsIiBpcyBsZXNzIGxpa2VseSB0byBiZQ0KICAg YXV0aGVudGljIHRoYW4gYSBtZXNzYWdlIGZvciB3aGljaCB0aGUgcmVzdWx0IGlzICJOZXV0cmFs Ii4NCg0KNS4yIFBhc3MNCg0KICAgQW4gU01UUCBzZXJ2ZXIgcmVjZWl2aW5nIHRoaXMgcmVzdWx0 IFNIT1VMRCB0cmVhdCB0aGUgbWVzc2FnZSBhcw0KICAgYXV0aGVudGljLiAgSXQgbWF5IGFjY2Vw dCBvciByZWplY3QgdGhlIG1lc3NhZ2UgZGVwZW5kaW5nIG9uIG90aGVyDQogICBwb2xpY2llcy4N Cg0KNS4zIEZhaWwNCg0KICAgV2hlbiBwZXJmb3JtaW5nIHRoZSBTZW5kZXItSUQgdGVzdCBkdXJp bmcgYW4gU01UUCB0cmFuc2FjdGlvbiwgYW4gTVRBDQogICByZWNlaXZpbmcgdGhpcyByZXN1bHQg U0hPVUxEIHJlamVjdCB0aGUgbWVzc2FnZSB3aXRoIGEgIjU1MCA1LjcuMQ0KICAgU2VuZGVyIElE ICh4eHgpIHl5eSAtIHp6eiIgU01UUCBlcnJvciwgd2hlcmUgInh4eCIgaXMgcmVwbGFjZWQgd2l0 aA0KICAgIlBSQSIgb3IgIk1BSUwgRlJPTSIsICJ5eXkiIGlzIHJlcGxhY2VkIHdpdGggdGhlIGFk ZGl0aW9uYWwgcmVhc29uDQogICByZXR1cm5lZCBieSB0aGUgY2hlY2tfaG9zdCgpIGZ1bmN0aW9u IGFuZCAienp6IiBpcyByZXBsYWNlZCB3aXRoIHRoZQ0KICAgZXhwbGFuYXRpb24gc3RyaW5nIHJl dHVybmVkIGJ5IHRoZSBjaGVja19ob3N0KCkgZnVuY3Rpb24uDQoNCiAgIFdoZW4gcGVyZm9ybWlu ZyB0aGUgU2VuZGVyLUlEIHRlc3QgYWZ0ZXIgYWNjZXB0aW5nIGFuIGUtbWFpbCBtZXNzYWdlDQog ICBmb3IgZGVsaXZlcnksIGFuIE1UQSByZWNlaXZpbmcgdGhpcyByZXN1bHQgU0hPVUxEIG5vdCBk ZWxpdmVyIHRoZQ0KICAgbWVzc2FnZS4gSW5zdGVhZCwgaXQgc2hvdWxkIGNyZWF0ZSBhIERTTiBt ZXNzYWdlLCBjb25zaXN0ZW50IHdpdGggdGhlDQogICB1c3VhbCBydWxlcyBmb3IgRFNOIG1lc3Nh Z2VzLg0KDQo1LjQgVGVtcEVycm9yDQoNCiAgIEFuIFNNVFAgc2VydmVyIHJlY2VpdmluZyB0aGlz IHJlc3VsdCBNQVkgcmVqZWN0IHRoZSBtZXNzYWdlIHdpdGggYQ0KICAgIjQ1MCA0LjQuMyBTZW5k ZXIgSUQgY2hlY2sgaXMgdGVtcG9yYXJpbHkgdW5hdmFpbGFibGUiIGVycm9yIGNvZGUuDQogICBB bHRlcm5hdGl2ZWx5LCBhbiBTTVRQIHNlcnZlciByZWNlaXZpbmcgdGhpcyByZXN1bHQgTUFZIGFj Y2VwdCBhDQogICBtZXNzYWdlIGFuZCBvcHRpb25hbGx5IHN1YmplY3QgaXQgdG8gaGVpZ2h0ZW5l ZCBzY3J1dGlueSBieSBvdGhlcg0KICAgYW50aS1zcGFtIG1lYXN1cmVzLg0KDQoNCg0KDQpMeW9u LCBXb25nICAgICAgICAgICAgICAgRXhwaXJlcyAtIEFwcmlsIDIwMDUgICAgICAgICAgICAgICAg IFtQYWdlIDldDQoMDQogICAgICAgICAgICAgICAgICAgU2VuZGVyIElEOiBBdXRoZW50aWNhdGlu ZyBFLU1haWwgICAgICAgT2N0b2JlciAyMDA0DQoNCg0KNi4gU2VjdXJpdHkgQ29uc2lkZXJhdGlv bnMNCg0KICAgVGhpcyBlbnRpcmUgZG9jdW1lbnQgZGVzY3JpYmVzIGEgbmV3IG1lY2hhbmlzbSBm b3IgbWl0aWdhdGluZyBzcG9vZmVkDQogICBlbWFpbCwgd2hpY2ggaXMgdG9kYXkgYSBwZXJ2YXNp dmUgc2VjdXJpdHkgcHJvYmxlbSBpbiB0aGUgSW50ZXJuZXQuDQoNCiAgIEFzc3VtaW5nIHRoYXQg dGhpcyBtZWNoYW5pc20gaXMgd2lkZWx5IGRlcGxveWVkLCB0aGUgZm9sbG93aW5nDQogICBzZWN0 aW9ucyBkZXNjcmliZSBjb3VudGVyLWF0dGFja3MgdGhhdCBjb3VsZCBiZSB1c2VkIHRvIGRlZmVh dCB0aGlzDQogICBtZWNoYW5pc20uDQoNCg0KNi4xIEROUyBBdHRhY2tzDQoNCiAgIFRoZSBuZXcg bWVjaGFuaXNtIGlzIGVudGlyZWx5IGRlcGVuZGVudCBvbiBETlMgbG9va3VwcywgYW5kIGlzDQog ICB0aGVyZWZvcmUgb25seSBhcyBzZWN1cmUgYXMgRE5TLiAgQW4gYXR0YWNrZXIgYmVudCBvbiBz cG9vZmluZw0KICAgbWVzc2FnZXMgY291bGQgYXR0ZW1wdCB0byBnZXQgaGlzIG1lc3NhZ2VzIGFj Y2VwdGVkIGJ5IHNlbmRpbmcgZm9yZ2VkDQogICBhbnN3ZXJzIHRvIEROUyBxdWVyaWVzLg0KDQog ICBBbiBNVEEgY291bGQgbGFyZ2VseSBkZWZlYXQgc3VjaCBhbiBhdHRhY2sgYnkgdXNpbmcgYSBw cm9wZXJseQ0KICAgcGFyYW5vaWQgRE5TIHJlc29sdmVyLiAgRE5TU0VDIG1heSB1bHRpbWF0ZWx5 IHByb3ZpZGUgYSB3YXkgdG8NCiAgIGNvbXBsZXRlbHkgbmV1dHJhbGl6ZSB0aGlzIGNsYXNzIG9m IGF0dGFja3MuDQoNCg0KNi4yIFRDUCBBdHRhY2tzDQoNCiAgIFRoaXMgbWVjaGFuaXNtIGlzIGRl c2lnbmVkIHRvIGJlIHVzZWQgaW4gY29uanVuY3Rpb24gd2l0aCBTTVRQIG92ZXINCiAgIFRDUC4g IEEgc3VmZmljaWVudGx5IHJlc291cmNlZnVsIGF0dGFja2VyIG1pZ2h0IGJlIGFibGUgdG8gc2Vu ZCBUQ1ANCiAgIHBhY2tldHMgd2l0aCBmb3JnZWQgZnJvbS1hZGRyZXNzZXMsIGFuZCB0aHVzIGV4 ZWN1dGUgYW4gZW50aXJlIFNNVFANCiAgIHNlc3Npb24gdGhhdCBhcHBlYXJzIHRvIGNvbWUgZnJv bSBzb21ld2hlcmUgb3RoZXIgdGhhbiBpdHMgdHJ1ZQ0KICAgb3JpZ2luLg0KDQogICBTdWNoIGFu IGF0dGFjayByZXF1aXJlcyBndWVzc2luZyB3aGF0IFRDUCBzZXF1ZW5jZSBudW1iZXJzIGFuIFNN VFANCiAgIHNlcnZlciB3aWxsIHVzZS4gSXQgYWxzbyByZXF1aXJlcyB0cmFuc21pdHRpbmcgY29t cGxldGVseSBpbiB0aGUNCiAgIGJsaW5kIC0gdGhlIGF0dGFjayB3aWxsIGJlIHVuYWJsZSBoZWFy IGFueSBvZiB0aGUgc2VydmVyJ3Mgc2lkZSBvZg0KICAgdGhlIGNvbnZlcnNhdGlvbi4NCg0KICAg QXR0YWNrcyBvZiB0aGlzIHNvcnQgY2FuIGJlIGFtZWxpb3JhdGVkIGlmIElQIGdhdGV3YXlzIHJl ZnVzZSB0bw0KICAgZm9yd2FyZCBwYWNrZXRzIHdoZW4gdGhlIHNvdXJjZSBhZGRyZXNzIGlzIGNs ZWFybHkgYm9ndXMuDQoNCg0KNi4zIEZvcmdlZCBTZW5kZXIgQXR0YWNrcw0KDQogICBUaGlzIG1l Y2hhbmlzbSBjaG9vc2VzIGFuIGFkZHJlc3MgdG8gdmFsaWRhdGUgZWl0aGVyIGZyb20gb25lIG9m IGENCiAgIG51bWJlciBvZiBtZXNzYWdlIGhlYWRlcnMgb3IgZnJvbSB0aGUgUkZDMjgyMSBNQUlM IGNvbW1hbmQsIGFuZCB0aGVuDQogICB1c2VzIHRoYXQgYWRkcmVzcyBmb3IgdmFsaWRhdGlvbi4g QSBtZXNzYWdlIHdpdGggYSB0cnVlIFJlc2VudC1Gcm9tDQogICBoZWFkZXIgb3IgUmV0dXJuLVBh dGgsIGJ1dCBhIGZvcmdlZCBGcm9tIGhlYWRlciB3aWxsIGJlIGFjY2VwdGVkLg0KICAgU2luY2Ug bWFueSBNVUFzIGRvIG5vdCBkaXNwbGF5IGFsbCBvZiB0aGUgaGVhZGVycyBvZiByZWNlaXZlZA0K ICAgbWVzc2FnZXMsIHRoZSBtZXNzYWdlIHdpbGwgYXBwZWFyIHRvIGJlIGZvcmdlZCB3aGVuIGRp c3BsYXllZC4NCg0KDQoNCg0KTHlvbiwgV29uZyAgICAgICAgICAgICAgIEV4cGlyZXMgLSBBcHJp bCAyMDA1ICAgICAgICAgICAgICAgIFtQYWdlIDEwXQ0KDA0KICAgICAgICAgICAgICAgICAgIFNl bmRlciBJRDogQXV0aGVudGljYXRpbmcgRS1NYWlsICAgICAgIE9jdG9iZXIgMjAwNA0KDQoNCiAg IEluIG9yZGVyIHRvIG5ldXRyYWxpemUgdGhpcyBhdHRhY2ssIE1VQXMgd2lsbCBuZWVkIHRvIHN0 YXJ0DQogICBkaXNwbGF5aW5nIGF0IGxlYXN0IHRoZSBoZWFkZXIgdGhhdCB3YXMgdmVyaWZpZWQu ICBJbiBhZGRpdGlvbiBNVEFzDQogICBjb3VsZCBzdWJqZWN0IG1lc3NhZ2VzIHRvIGhlaWdodGVu ZWQgc2NydXRpbnkgd2hlbiB0aGUgdmFsaWRhdGVkDQogICBhZGRyZXNzIGRpZmZlcnMgZnJvbSB0 aGUgRnJvbSBoZWFkZXIuDQoNCg0KNi40IEFkZHJlc3MgU3BhY2UgSGlqYWNraW5nDQoNCiAgIFRo aXMgbWVjaGFuaXNtIGFzc3VtZXMgdGhlIGludGVncml0eSBvZiBJUCBhZGRyZXNzIHNwYWNlIGZv cg0KICAgZGV0ZXJtaW5pbmcgd2hldGhlciBhIGdpdmVuIGNsaWVudCBpcyBhdXRob3JpemVkIHRv IHNlbmQgbWVzc2FnZXMNCiAgIGZyb20gYSBnaXZlbiBQUkEuICBJbiBhZGRpdGlvbiB0byB0aGUg VENQIGF0dGFjayBnaXZlbiBpbiBzZWN0aW9uDQogICA2LjIsIGEgc3VmZmljaWVudGx5IHJlc291 cmNlZnVsIGF0dGFja2VyIG1pZ2h0IGJlIGFibGUgdG8gYWx0ZXIgdGhlDQogICBJUCByb3V0aW5n IHN0cnVjdHVyZSB0byBwZXJtaXQgdHdvLXdheSBjb21tdW5pY2F0aW9uIHVzaW5nIGENCiAgIHNw ZWNpZmllZCBJUCBhZGRyZXNzLiAgSXQgd291bGQgdGhlbiBiZSBwb3NzaWJsZSB0byBleGVjdXRl IGFuIFNNVFANCiAgIHNlc3Npb24gdGhhdCBhcHBlYXJzIHRvIGNvbWUgZnJvbSBhbiBhdXRob3Jp emVkIGFkZHJlc3MsIHdpdGhvdXQgdGhlDQogICBuZWVkIHRvIGd1ZXNzIFRDUCBzZXF1ZW5jZSBu dW1iZXJzIG9yIHRyYW5zbWl0IGluIHRoZSBibGluZC4NCg0KICAgU3VjaCBhbiBhdHRhY2sgbWln aHQgb2NjdXIgaWYgdGhlIGF0dGFja2VyIG9idGFpbmVkIGFjY2VzcyB0byBhDQogICByb3V0ZXIg d2hpY2ggcGFydGljaXBhdGVzIGluIGV4dGVybmFsIEJHUCByb3V0aW5nLiAgU3VjaCBhIHJvdXRl cg0KICAgY291bGQgYWR2ZXJ0aXNlIGEgbW9yZSBzcGVjaWZpYyByb3V0ZSB0byBhIHJvZ3VlIFNN VFAgY2xpZW50LA0KICAgdGVtcG9yYXJpbHkgb3ZlcnJpZGluZyB0aGUgbGVnaXRpbWF0ZSBvd25l ciBvZiB0aGUgYWRkcmVzcy4NCg0KDQo2LjUgTWFsaWNpb3VzIEROUyBhdHRhY2tzIG9uIHRoaXJk LXBhcnRpZXMNCg0KICAgVGhlcmUgaXMgY2xhc3Mgb2YgYXR0YWNrcyBpbiB3aGljaCBhbiBhdHRh Y2tlciBBIGNhbiBlbnRpY2UgYQ0KICAgcGFydGljaXBhbnQgUCB0byBzZW5kIGEgbWFsaWNpb3Vz IG1lc3NhZ2UgdG8gYSB2aWN0aW0gVi4NCg0KICAgVGhlc2UgYXR0YWNrcyBhcmUgdW5kZXJ0YWtl biBieSBBIGNpdGluZyB0aGUgYWRkcmVzcyBvZiBWIGluIHRoZSBTTVRQDQogICBNQUlMIEZST00g cmVxdWVzdCBhbmQgdGhlbiBieSBjYXVzaW5nIFAgdG8gZ2VuZXJhdGUgKG9yIGludm9rZSB0aGUN CiAgIGdlbmVyYXRpb24gb2YpIGEgRGVsaXZlcnkgU3RhdHVzIE5vdGlmaWNhdGlvbiAnYm91bmNl JyBtZXNzYWdlDQogICAoUkZDMzQ2NCksIHdoaWNoIGlzIHNlbnQgdG8gdGhlIHZpY3RpbSBWLg0K DQogICBUaGUgYXR0YWNrZXIgcmVsaWVzIHVwb24gaXQgYmVpbmcgY29tbW9uIHByYWN0aWNlIHRv IGNvcHkgdGhlDQogICBvcmlnaW5hbCBtZXNzYWdlIGludG8gdGhlICdib3VuY2UnIHJlcG9ydCwg dGhlcmVieSBjYXVzaW5nIHRoZSBtYWxpY2UNCiAgIHRvIGJlIHNlbnQgb253YXJkcyB0byBWLg0K DQogICBUaGlzIG1vZGUgb2YgYXR0YWNrIGhhcyB0aGUgYWR2YW50YWdlcyAodG8gdGhlIGF0dGFj a2VyKSBvZg0KICAgb2JmdXNjYXRpbmcgdGhlIGxvY2F0aW9uIG9mIHRoZSBob3N0IGZyb20gd2hp Y2ggdGhlIGF0dGFjayB3YXMNCiAgIG1vdW50ZWQsIGFuZCBvZiBwb3NzaWJseSBkYW1hZ2luZyB0 aGUgcmVwdXRhdGlvbiBvZiBQIGJ5IG1ha2luZyBpdA0KICAgYXBwZWFyIHRoYXQgUCBvcmlnaW5h dGVkIG9yIHdhcyBhbiBhY3RpdmUgcGFydGljaXBhbnQgaW4gdGhlIHNlbmRpbmcNCiAgIG9mIHRo ZSBtYWxpY2lvdXMgbWVzc2FnZS4NCg0KICAgSW4gY3VycmVudCBwcmFjdGljZSwgQSBjYXVzZXMg UCB0byBjYXVzZSB0aGUgJ2JvdW5jZScgYnkgYWRkcmVzc2luZw0KICAgdGhlIG9yaWdpbmFsIG1l c3NhZ2UgdG8gYSBub24tZXhpc3RlbnQgcmVjaXBpZW50Lg0KDQogICBTZW5kZXItSUQgZW5hYmxl cyBhIG5ldyB2YXJpYW50IG9mIHRoaXMgYXR0YWNrLg0KDQoNCg0KDQpMeW9uLCBXb25nICAgICAg ICAgICAgICAgRXhwaXJlcyAtIEFwcmlsIDIwMDUgICAgICAgICAgICAgICAgW1BhZ2UgMTFdDQoM DQogICAgICAgICAgICAgICAgICAgU2VuZGVyIElEOiBBdXRoZW50aWNhdGluZyBFLU1haWwgICAg ICAgT2N0b2JlciAyMDA0DQoNCg0KICAgSW4gdGhpcyB2YXJpYW50IHRoZSBhdHRhY2tlciBBIHNl bmRzIGEgbWVzc2FnZSB3aG9zZSBQUkEgKHNlY3Rpb24gNCkNCiAgIGlzIHNlbGVjdGVkIGJ5IHRo ZSBhdHRhY2tlciB0byBiZSBzdWNoIHRoYXQsIHdoZW4gUCB1bmRlcnRha2VzIHRoZQ0KICAgU2Vu ZGVyLUlEIHRlc3QsIGEgJ0ZhaWwnIHdpbGwgcmVzdWx0IChzZWN0aW9uIDUuMykuDQoNCiAgIFRo ZSBtZXNzYWdlIHdpbGwgYmUgcmVqZWN0ZWQgKGFzIHRoZSBhdHRhY2tlciBpbnRlbmRlZCkgYW5k IGENCiAgIG1hbGljaW91cyAnYm91bmNlJyBtZXNzYWdlIG1heSBiZSBnZW5lcmF0ZWQgYW5kIHNl bnQgdG8gdGhlIHZpY3RpbSBWLg0KDQoNCjcuIEltcGxlbWVudGF0aW9uIEd1aWRhbmNlDQoNCiAg IFRoaXMgc2VjdGlvbiBkZXNjcmliZXMgdGhlIGFjdGlvbnMgdGhhdCBjZXJ0YWluIG1lbWJlcnMg b2YgdGhlDQogICBJbnRlcm5ldCBlbWFpbCBlY29zeXN0ZW0gbXVzdCB0YWtlIHRvIGJlIGNvbXBs aWFudCB3aXRoIHRoaXMNCiAgIHNwZWNpZmljYXRpb24uDQoNCg0KNy4xIFNpbXBsZSBFLW1haWxl cnMNCg0KICAgQSBkb21haW4gdGhhdCBpbmplY3RzIG9yaWdpbmFsIGVtYWlsIGludG8gdGhlIElu dGVybmV0LCB1c2luZyBpdHMgb3duDQogICBuYW1lIGluIEZyb20gaGVhZGVycywgbmVlZCBkbyBu b3RoaW5nIHRvIGJlIGNvbXBsaWFudC4gIEhvd2V2ZXIsIHN1Y2gNCiAgIGRvbWFpbnMgU0hPVUxE IHB1Ymxpc2ggcmVjb3JkcyBpbiBETlMgYXMgZGVmaW5lZCBieSBbU1BGXSBhbmQgdGhpcw0KICAg c3BlY2lmaWNhdGlvbi4NCg0KICAgSW4gdGhlIG1ham9yaXR5IG9mIGNhc2VzLCB0aGUgZG9tYWlu J3MgcHVibGlzaGVkIGluZm9ybWF0aW9uIHdpbGwgYmUNCiAgIHRoZSBzYW1lIGZvciBib3RoIHRo ZSBQUkEgYW5kIE1BSUwgRlJPTSB2YXJpYW50cyBvZiB0aGlzIHRlc3QuICBJbg0KICAgdGhpcyBj YXNlLCBkb21haW5zIFNIT1VMRCBwdWJsaXNoIHRoZWlyIGluZm9ybWF0aW9uIHVzaW5nIGFuIFNQ Rg0KICAgcmVjb3JkIHdpdGggdGhlIHByZWZpeCAidj1zcGYxIi4gIERvaW5nIHNvIHdpbGwgcmVu ZGVyIHRoZWlyDQogICBwdWJsaXNoZWQgaW5mb3JtYXRpb24gdXNhYmxlIGJ5IHRoZSBvbGRlciBT UEYgcHJvdG9jb2wsIHRvby4gIChTZWUNCiAgIFtTUEZdIGZvciBpbmZvcm1hdGlvbiBvbiB0aGUg U1BGIHByb3RvY29sLikNCg0KDQo3LjIgRS1NYWlsIEZvcndhcmRlcnMNCg0KICAgSW4gb3JkZXIg dG8gcGFzcyB0aGUgUFJBIHZhcmlhbnQgb2YgdGhlIHRlc3QsIGEgcHJvZ3JhbSB0aGF0IGZvcndh cmRzDQogICByZWNlaXZlZCBtYWlsIHRvIG90aGVyIGFkZHJlc3NlcyBNVVNUIGFkZCBhbiBhcHBy b3ByaWF0ZSBoZWFkZXIgdGhhdA0KICAgY29udGFpbnMgYW4gZW1haWwgYWRkcmVzcyB0aGF0IGl0 IGlzIGF1dGhvcml6ZWQgdG8gdXNlLiAgU3VjaA0KICAgcHJvZ3JhbXMgU0hPVUxEIHVzZSB0aGUg UmVzZW50LUZyb20gaGVhZGVyIGZvciB0aGlzIHB1cnBvc2UuDQoNCiAgIEluIG9yZGVyIHRvIHBh c3MgdGhlIE1BSUwgRlJPTSB2YXJpYW50IG9mIHRoZSB0ZXN0LCBhIHByb2dyYW0gdGhhdA0KICAg Zm9yd2FyZHMgcmVjZWl2ZWQgbWFpbCB0byBvdGhlciBhZGRyZXNzZXMgTVVTVCBhbHRlciB0aGUg TUFJTCBGUk9NDQogICBhZGRyZXNzIHRvIGFuIGFkZHJlc3MgdW5kZXIgaXRzIGNvbnRyb2wuICBT aG91bGQgdGhhdCBhZGRyZXNzDQogICBldmVudHVhbGx5IHJlY2VpdmUgYSBEU04gcmVsYXRpbmcg dG8gdGhlIG9yaWdpbmFsIG1lc3NhZ2UsIHRoYXQgRFNODQogICBTSE9VTEQgYmUgZm9yd2FyZGVk IHRvIHRoZSBvcmlnaW5hbCBNQUlMIEZST00gYWRkcmVzcy4gIEhvd2V2ZXIsIGlmDQogICB0aGlz IGFsdGVyZWQgYWRkcmVzcyByZWNlaXZlcyBhbnkgbWVzc2FnZXMgb3RoZXIgdGhhbiBEU05zIHJl bGF0ZWQgdG8NCiAgIHRoZSBvcmlnaW5hbCBtZXNzYWdlLCB0aGVzZSBtZXNzYWdlcyBNVVNUIE5P VCBiZSBmb3J3YXJkZWQgdG8gdGhlDQogICBvcmlnaW5hbCBNQUlMIEZST00gYWRkcmVzczsgdGhl eSBTSE9VTEQgYmUgcmVmdXNlZCBkdXJpbmcgYW4gU01UUA0KICAgdHJhbnNhY3Rpb24uDQoNCg0K DQoNCg0KTHlvbiwgV29uZyAgICAgICAgICAgICAgIEV4cGlyZXMgLSBBcHJpbCAyMDA1ICAgICAg ICAgICAgICAgIFtQYWdlIDEyXQ0KDA0KICAgICAgICAgICAgICAgICAgIFNlbmRlciBJRDogQXV0 aGVudGljYXRpbmcgRS1NYWlsICAgICAgIE9jdG9iZXIgMjAwNA0KDQoNCiAgIEFkZGl0aW9uYWxs eSwgZS1tYWlsIGZvcndhcmRlcnMgU0hPVUxEIHB1Ymxpc2ggU2VuZGVyIElEIHJlY29yZHMgZm9y DQogICB0aGVpciBkb21haW5zLCBhbmQgU0hPVUxEIHVzZSBNVEFzIGZvciB3aGljaCB0aGUgU2Vu ZGVyIElEIGNoZWNrDQogICB5aWVsZHMgYSAicGFzcyIgcmVzdWx0Lg0KDQogICBTb21lIG9mIHRv ZGF5J3MgZm9yd2FyZGVycyBhbHJlYWR5IGFkZCBhbiBhcHByb3ByaWF0ZSBoZWFkZXINCiAgIChh bHRob3VnaCBtYW55IG9mIHRoZW0gdXNlIFNlbmRlciByYXRoZXIgdGhhbiBSZXNlbnQtRnJvbS4p IE1vc3Qgb2YNCiAgIHRoZW0gZG8gbm90IHBlcmZvcm0gdGhlIGFkZHJlc3MtcmV3cml0aW5nIHNw ZWNpZmllZCBhYm92ZS4NCg0KICAgTm90ZSB0aGF0IGFuIGUtbWFpbCBmb3J3YXJkZXIgbWlnaHQg cmVjZWl2ZSBhIHNpbmdsZSBtZXNzYWdlIGZvciB0d28NCiAgIG9yIG1vcmUgcmVjaXBpZW50cywg ZWFjaCBvZiB3aG9tIHJlcXVlc3RzIGZvcndhcmRpbmcgdG8gYSBuZXcNCiAgIGFkZHJlc3MuICBJ biB0aGlzIGNhc2UsIHRoZSBmb3J3YXJkZXIncyBNVEEgU0hPVUxEIHRyYW5zbWl0IHRoZQ0KICAg bWVzc2FnZSB0byBlYWNoIG5ldyByZWNpcGllbnQgaW5kaXZpZHVhbGx5LCB3aXRoIGVhY2ggY29w eSBvZiB0aGUNCiAgIG1lc3NhZ2UgY29udGFpbmluZyBhIGRpZmZlcmVudCBuZXdseSBpbnNlcnRl ZCBSZXNlbnQtRnJvbSBoZWFkZXINCiAgIGZpZWxkLg0KDQoNCjcuMyBNYWlsaW5nIExpc3QgU2Vy dmVycw0KDQogICBJbiBvcmRlciB0byBwYXNzIHRoZSBQUkEgdmFyaWFudCBvZiB0aGUgdGVzdCwg YSBtYWlsaW5nIGxpc3Qgc2VydmVyDQogICBNVVNUIGFkZCBhbiBhcHByb3ByaWF0ZSBoZWFkZXIg dGhhdCBjb250YWlucyBhbiBlbWFpbCBhZGRyZXNzIHRoYXQgaXQNCiAgIGlzIGF1dGhvcml6ZWQg dG8gdXNlLiAgU3VjaCBwcm9ncmFtcyBTSE9VTEQgdXNlIHRoZSBSZXNlbnQtRnJvbQ0KICAgaGVh ZGVyIGZvciB0aGlzIHB1cnBvc2UuDQoNCiAgIEluIG9yZGVyIHRvIHBhc3MgdGhlIE1BSUwgRlJP TSB2YXJpYW50IG9mIHRoZSB0ZXN0LCBhIG1haWxpbmcgbGlzdA0KICAgc2VydmVyIE1VU1QgYWx0 ZXIgdGhlIE1BSUwgRlJPTSBhZGRyZXNzIHRvIGFuIGFkZHJlc3MgdW5kZXIgaXRzDQogICBjb250 cm9sLg0KDQogICBBZGRpdGlvbmFsbHksIG1haWxpbmcgbGlzdCBzZXJ2ZXJzIFNIT1VMRCBwdWJs aXNoIFNlbmRlciBJRCByZWNvcmRzDQogICBmb3IgdGhlaXIgZG9tYWlucywgYW5kIFNIT1VMRCB1 c2UgTVRBcyBmb3Igd2hpY2ggdGhlIFNlbmRlciBJRCBjaGVjaw0KICAgeWllbGRzIGEgInBhc3Mi IHJlc3VsdC4NCg0KICAgTW9zdCBvZiB0b2RheSdzIG1haWxpbmcgbGlzdCBzb2Z0d2FyZSBhbHJl YWR5IGFkZHMgYW4gYXBwcm9wcmlhdGUNCiAgIGhlYWRlciAoYWx0aG91Z2ggbW9zdCBvZiB0aGVt IHVzZSBTZW5kZXIgcmF0aGVyIHRoYW4gUmVzZW50LUZyb20pLA0KICAgYW5kIG1vc3Qgb2YgdGhl bSBhbHJlYWR5IGFsdGVyIHRoZSBNQUlMIEZST00gYWRkcmVzcy4NCg0KDQo3LjQgVGhpcmQtUGFy dHkgTWFpbGVycw0KDQogICBJbiBvcmRlciB0byBwYXNzIHRoZSBQUkEgdmFyaWFudCBvZiB0aGlz IHRlc3QsIGEgcHJvZ3JhbSB0aGF0IHNlbmRzDQogICBtYWlsIG9uIGJlaGFsZiBvZiBhbm90aGVy IHVzZXIgTVVTVCBhZGQgYW4gYXBwcm9wcmlhdGUgaGVhZGVyIHRoYXQNCiAgIGNvbnRhaW5zIGFu IGVtYWlsIGFkZHJlc3MgdGhhdCBpdCBpcyBhdXRob3JpemVkIHRvIHVzZS4gIFN1Y2gNCiAgIHBy b2dyYW1zIFNIT1VMRCB1c2UgdGhlIFNlbmRlciBoZWFkZXIgZm9yIHRoaXMgcHVycG9zZS4NCg0K ICAgSW4gb3JkZXIgdG8gcGFzcyB0aGUgTUFJTCBGUk9NIHZhcmlhbnQgb2YgdGhpcyB0ZXN0LCBh IHByb2dyYW0gdGhhdA0KICAgc2VuZHMgbWFpbCBvbiBiZWhhbGYgb2YgYW5vdGhlciB1c2VyIE1V U1QgdXNlIGEgTUFJTCBGUk9NIGFkZHJlc3MNCiAgIHRoYXQgaXMgdW5kZXIgaXRzIGNvbnRyb2wu ICBEZWZpbmluZyB3aGF0IHRoZSBwcm9ncmFtIGRvZXMgd2l0aCBhbnkNCiAgIG1haWwgcmVjZWl2 ZWQgYXQgdGhhdCBhZGRyZXNzIGlzIGJleW9uZCB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4N Cg0KDQoNCg0KTHlvbiwgV29uZyAgICAgICAgICAgICAgIEV4cGlyZXMgLSBBcHJpbCAyMDA1ICAg ICAgICAgICAgICAgIFtQYWdlIDEzXQ0KDA0KICAgICAgICAgICAgICAgICAgIFNlbmRlciBJRDog QXV0aGVudGljYXRpbmcgRS1NYWlsICAgICAgIE9jdG9iZXIgMjAwNA0KDQoNCiAgIEFkZGl0aW9u YWxseSwgdGhpcmQtcGFydHkgbWFpbGVycyBzZXJ2ZXJzIFNIT1VMRCBwdWJsaXNoIFNlbmRlciBJ RA0KICAgcmVjb3JkcyBmb3IgdGhlaXIgZG9tYWlucywgYW5kIFNIT1VMRCB1c2UgTVRBcyBmb3Ig d2hpY2ggdGhlIFNlbmRlcg0KICAgSUQgY2hlY2sgeWllbGRzIGEgInBhc3MiIHJlc3VsdC4NCg0K ICAgTWFueSwgYnV0IG5vdCBhbGwsIG9mIHRvZGF5J3MgdGhpcmQtcGFydHkgbWFpbGVycyBhcmUg YWxyZWFkeQ0KICAgY29tcGxpYW50IHdpdGggdGhlIFBSQSB2YXJpYW50IG9mIHRoZSB0ZXN0LiAg VGhlIGV4dGVudCB0byB3aGljaA0KICAgbWFpbGVycyBhcmUgYWxyZWFkeSBjb21wbGlhbnQgd2l0 aCB0aGUgTUFJTCBGUk9NIHZhcmlhbnQgb2YgdGhpcyB0ZXN0DQogICBpcyB1bmtub3duLg0KDQoN CjcuNSBNVUEgSW1wbGVtZW50ZXJzDQoNCiAgIFdoZW4gZGlzcGxheWluZyBhIHJlY2VpdmVkIG1l c3NhZ2UsIGFuIE1VQSBTSE9VTEQgZGlzcGxheSB0aGUNCiAgIHB1cnBvcnRlZCByZXNwb25zaWJs ZSBhZGRyZXNzIGFzIGRlZmluZWQgYnkgdGhpcyBkb2N1bWVudCB3aGVuZXZlcg0KICAgdGhhdCBh ZGRyZXNzIGRpZmZlcnMgZnJvbSB0aGUgUkZDIDI4MjIgRnJvbSBhZGRyZXNzLiAgVGhpcyBkaXNw bGF5DQogICBTSE9VTEQgYmUgaW4gYWRkaXRpb24gdG8gdGhlIFJGQyAyODIyIEZyb20gYWRkcmVz cy4NCg0KICAgV2hlbiBhIHJlY2VpdmVkIG1lc3NhZ2UgY29udGFpbnMgbXVsdGlwbGUgaGVhZGVy cyB0aGF0IG1pZ2h0IGJlIHVzZWQNCiAgIGZvciB0aGUgcHVycG9ydGVkIHJlc3BvbnNpYmxlIGFk ZHJlc3MgZGV0ZXJtaW5hdGlvbiwgYW4gTVVBIHNob3VsZA0KICAgY29uc2lkZXIgZGlzcGxheWlu ZyBhbGwgb2YgdGhlbS4gVGhhdCBpcywgaWYgYSBtZXNzYWdlIGNvbnRhaW5zDQogICBzZXZlcmFs IFJlc2VudC1Gcm9tJ3MsIGEgU2VuZGVyIGFuZCBhIEZyb20sIGFuIE1VQSBzaG91bGQgY29uc2lk ZXINCiAgIGRpc3BsYXlpbmcgYWxsIG9mIHRoZW0uDQoNCiAgIFNlbmRlciBJRCBhbHNvIGRvZXMg bm90IHZhbGlkYXRlIHRoZSBkaXNwbGF5IG5hbWUgdGhhdCBtYXkgYmUNCiAgIHRyYW5zbWl0dGVk IGFsb25nIHdpdGggYW4gZS1tYWlsIGFkZHJlc3MuICBUaGUgZGlzcGxheSBuYW1lIGlzIGFsc28N CiAgIHZ1bG5lcmFibGUgdG8gc3Bvb2ZpbmcgYW5kIG90aGVyIGZvcm1zIG9mIGF0dGFja3MuICBJ biBvcmRlciB0bw0KICAgcmVkdWNlIHRoZSBvY2N1cnJlbmNlIGFuZCBlZmZlY3RpdmVuZXNzIG9m IHN1Y2ggYXR0YWNrcywgTVVBDQogICBpbXBsZW1lbnRlcnMgc2hvdWxkIGNvbnNpZGVyIG1ldGhv ZHMgdG8gc2FmZWd1YXJkIHRoZSBkaXNwbGF5IG5hbWUuDQogICBUaGlzIGNvdWxkIGluY2x1ZGU6 DQoNCiAgICogTm90IHByZXNlbnRpbmcgdGhlIGRpc3BsYXkgbmFtZSB0byB0aGUgdXNlciBhdCBh bGwsIG9yIG5vdA0KICAgICBwcmVzZW50aW5nIHRoZSBkaXNwbGF5IG5hbWUgdW5sZXNzIHRoZSBj b3JyZXNwb25kaW5nIGVtYWlsIGFkZHJlc3MNCiAgICAgaXMgbGlzdGVkIGluIHRoZSB1c2VyJ3Mg YWRkcmVzcyBib29rLg0KDQogICAqIFRyZWF0aW5nIGFzIHN1c3BpY2lvdXMgYW55IGUtbWFpbCB3 aGVyZSB0aGUgZGlzcGxheSBuYW1lIGlzIGl0c2VsZg0KICAgICBpbiB0aGUgZm9ybSBvZiBhbiBl LW1haWwgYWRkcmVzcywgZXNwZWNpYWxseSB3aGVuIGl0IGRpZmZlcnMgZnJvbQ0KICAgICB0aGUg YWN0dWFsIGUtbWFpbCBhZGRyZXNzIGluIHRoZSBoZWFkZXIuDQoNCiAgICogTWFraW5nIGl0IGNs ZWFyIHRvIHVzZXJzIHRoYXQgdGhlIGVtYWlsIGFkZHJlc3MgaGFzIGJlZW4gY2hlY2tlZA0KICAg ICByYXRoZXIgdGhhbiB0aGUgZGlzcGxheSBuYW1lLg0KDQoNCjguIElBTkEgQ29uc2lkZXJhdGlv bnMNCg0KICAgVGhpcyBkb2N1bWVudCBjb250YWlucyBubyBhY3Rpb25zIGZvciBJQU5BLg0KDQoN Cg0KDQoNCg0KTHlvbiwgV29uZyAgICAgICAgICAgICAgIEV4cGlyZXMgLSBBcHJpbCAyMDA1ICAg ICAgICAgICAgICAgIFtQYWdlIDE0XQ0KDA0KICAgICAgICAgICAgICAgICAgIFNlbmRlciBJRDog QXV0aGVudGljYXRpbmcgRS1NYWlsICAgICAgIE9jdG9iZXIgMjAwNA0KDQoNCjkuIEFja25vd2xl ZGdlbWVudHMNCg0KICAgVGhpcyBkZXNpZ24gaXMgYmFzZWQgb24gZWFybGllciB3b3JrIHB1Ymxp c2hlZCBpbiAyMDAzIGluIFtSTVhdIGFuZA0KICAgW0RNUF0gZHJhZnRzIChieSBIYWRtdXQgRGFu aXNjaCBhbmQgR29yZG9uIEZlY3lrIHJlc3BlY3RpdmVseSkuICBUaGUNCiAgIGlkZWEgb2YgdXNp bmcgYSBETlMgcmVjb3JkIHRvIGNoZWNrIHRoZSBsZWdpdGltYWN5IG9mIGFuIGVtYWlsDQogICBh ZGRyZXNzIHRyYWNlcyBpdHMgYW5jZXN0cnkgdG8gIlJlcHVkaWF0aW5nIE1haWwgRnJvbSIgZHJh ZnQgYnkgUGF1bA0KICAgVml4aWUgW1ZpeGllXSAoYmFzZWQgb24gc3VnZ2VzdGlvbiBieSBKaW0g TWlsbGVyKSBhbmQgdG8gIkRvbWFpbi0NCiAgIEF1dGhvcml6ZWQgU01UUCBNYWlsIiBkcmFmdCBi eSBEYXZpZCBHcmVlbiBbR3JlZW5dIHdobyBmaXJzdA0KICAgaW50cm9kdWNlZCB0aGlzIGlkZWEg b24gbmFtZWRyb3BwZXJzIG1haWxpbmcgbGlzdCBpbiAyMDAyLg0KDQogICBUaGUgY3VycmVudCBk b2N1bWVudCBib3Jyb3dzIGhlYXZpbHkgZnJvbSBlYWNoIG9mIHRoZSBhYm92ZSwgYW5kDQogICBp bmNvcnBvcmF0ZXMgaWRlYXMgcHJvcG9zZWQgYnkgbWFueSBtZW1iZXJzIG9mIHRoZSBNQVJJRCB3 b3JraW5nDQogICBncm91cC4gIFRoZSBjb250cmlidXRpb25zIG9mIGVhY2ggb2YgdGhlIGFib3Zl IGFyZSBncmF0ZWZ1bGx5DQogICBhY2tub3dsZWRnZWQuDQoNCg0KMTAuIFJlZmVyZW5jZXMNCg0K MTAuMSBOb3JtYXRpdmUgUmVmZXJlbmNlcw0KDQogICBbUFJBXSAgICAgICBKLiBMeW9uLCAiUHVy cG9ydGVkIFJlc3BvbnNpYmxlIEFkZHJlc3MgaW4gRS1NYWlsDQogICAgICAgICAgICAgICBNZXNz YWdlcyIsIGRyYWZ0LWx5b24tc2VuZGVyaWQtcHJhLTAwLiAgV29yayBpbiBwcm9ncmVzcy4NCg0K ICAgW1JGQzIxMTldICAgUy4gQnJhZG5lciwgIktleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8g SW5kaWNhdGUNCiAgICAgICAgICAgICAgIFJlcXVpcmVtZW50IExldmVscyIsIFJGQyAyMTE5Lg0K DQogICBbU1BGXSAgICAgICBNLiBMZW50Y3puZXIgYW5kIE0uIFdvbmcsICJTZW5kZXIgUG9saWN5 IEZyYW1ld29yazoNCiAgICAgICAgICAgICAgIEF1dGhvcml6aW5nIFVzZSBvZiBEb21haW5zIGlu IE1BSUwgRlJPTSIsIGRyYWZ0LQ0KICAgICAgICAgICAgICAgbGVudGN6bmVyLXNwZi0wMC4gIFdv cmsgaW4gcHJvZ3Jlc3MuDQoNCiAgIFtTdWJtaXR0ZXJdIEUuIEFsbG1hbiBhbmQgSC4gS2F0eiwg IlNNVFAgU2VydmljZSBFeHRlbnNpb24gZm9yDQogICAgICAgICAgICAgICBJbmRpY2F0aW5nIHRo ZSBSZXNwb25zaWJsZSBTdWJtaXR0ZXIgb2YgYW4gRS1tYWlsDQogICAgICAgICAgICAgICBNZXNz YWdlIiwgZHJhZnQta2F0ei1zdWJtaXR0ZXItMDAuICBXb3JrIGluIHByb2dyZXNzLg0KDQoxMC4y IEluZm9ybWF0aXZlIFJlZmVyZW5jZXMNCg0KICAgW0NhbGxlcklEXSAgTWljcm9zb2Z0IENvcnBv cmF0aW9uLCBDYWxsZXIgSUQgZm9yIEUtTWFpbCBUZWNobmljYWwNCiAgICAgICAgICAgICAgIFNw ZWNpZmljYXRpb24sDQogICAgICAgICAgICAgICBodHRwOi8vd3d3Lm1pY3Jvc29mdC5jb20vbXNj b3JwL3R3Yy9wcml2YWN5L3NwYW1fY2FsbGVyaWQNCiAgICAgICAgICAgICAgIC5tc3B4Lg0KDQog ICBbR3JlZW59ICAgICBEYXZpZCBHcmVlbiwgIk1haWwtVHJhbnNtaXR0ZXIgUlIiLA0KICAgICAg ICAgICAgICAgaHR0cDovL29wcy5pZXRmLm9yZy9saXN0cy9uYW1lZHJvcHBlcnMvbmFtZWRyb3Bw ZXJzLjIwMDIvDQogICAgICAgICAgICAgICBtc2cwMDY1Ni5odG1sLCBKdW5lIDIwMDIuDQoNCiAg IFtSTVhdICAgICAgIEguIERhbmlzY2gsICJUaGUgUk1YIEROUyBSUiBhbmQgbWV0aG9kIGZvciBs aWdodHdlaWdodA0KICAgICAgICAgICAgICAgU01UUCBzZW5kZXIgYXV0aG9yaXphdGlvbiIsIGRy YWZ0LWRhbmlzY2gtZG5zLXJyLXNtdHAtMDQuDQogICAgICAgICAgICAgICBXb3JrIGluIHByb2dy ZXNzLg0KDQoNCg0KTHlvbiwgV29uZyAgICAgICAgICAgICAgIEV4cGlyZXMgLSBBcHJpbCAyMDA1 ICAgICAgICAgICAgICAgIFtQYWdlIDE1XQ0KDA0KICAgICAgICAgICAgICAgICAgIFNlbmRlciBJ RDogQXV0aGVudGljYXRpbmcgRS1NYWlsICAgICAgIE9jdG9iZXIgMjAwNA0KDQoNCiAgIFtWaXhp ZV0gICAgIFBhdWwgVml4aWUsICJSZXB1ZGlhdGluZyBNYWlsIEZyb20iLA0KICAgICAgICAgICAg ICAgaHR0cDovL29wcy5pZXRmLm9yZy9saXN0cy9uYW1lZHJvcHBlcnMvbmFtZWRyb3BwZXJzLjIw MDIvDQogICAgICAgICAgICAgICBtc2cwMDY1OC5odG1sLCBKdW5lIDIwMDIuDQoNCg0KMTEuIEF1 dGhvcnMnIEFkZHJlc3Nlcw0KDQogICBKaW0gTHlvbg0KICAgTWljcm9zb2Z0IENvcnBvcmF0aW9u DQogICBPbmUgTWljcm9zb2Z0IFdheQ0KICAgUmVkbW9uZCwgV0EgOTgwNTINCiAgIFVTQQ0KICAg amltbHlvbkBtaWNyb3NvZnQuY29tDQoNCiAgIE1lbmcgV2VuZyBXb25nDQogICBTaW5nYXBvcmUN CiAgIG1lbmd3b25nQGR1bWJvLnBvYm94LmNvbQ0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkx5b24sIFdvbmcgICAgICAgICAg ICAgICBFeHBpcmVzIC0gQXByaWwgMjAwNSAgICAgICAgICAgICAgICBbUGFnZSAxNl0NCgwNCiAg ICAgICAgICAgICAgICAgICBTZW5kZXIgSUQ6IEF1dGhlbnRpY2F0aW5nIEUtTWFpbCAgICAgICBP Y3RvYmVyIDIwMDQNCg0KDQpJbnRlbGxlY3R1YWwgUHJvcGVydHkgU3RhdGVtZW50DQoNCiAgIFRo ZSBJRVRGIHRha2VzIG5vIHBvc2l0aW9uIHJlZ2FyZGluZyB0aGUgdmFsaWRpdHkgb3Igc2NvcGUg b2YgYW55DQogICBJbnRlbGxlY3R1YWwgUHJvcGVydHkgUmlnaHRzIG9yIG90aGVyIHJpZ2h0cyB0 aGF0IG1pZ2h0IGJlIGNsYWltZWQgdG8NCiAgIHBlcnRhaW4gdG8gdGhlIGltcGxlbWVudGF0aW9u IG9yIHVzZSBvZiB0aGUgdGVjaG5vbG9neSBkZXNjcmliZWQgaW4NCiAgIHRoaXMgZG9jdW1lbnQg b3IgdGhlIGV4dGVudCB0byB3aGljaCBhbnkgbGljZW5zZSB1bmRlciBzdWNoIHJpZ2h0cw0KICAg bWlnaHQgb3IgbWlnaHQgbm90IGJlIGF2YWlsYWJsZTsgbm9yIGRvZXMgaXQgcmVwcmVzZW50IHRo YXQgaXQgaGFzDQogICBtYWRlIGFueSBpbmRlcGVuZGVudCBlZmZvcnQgdG8gaWRlbnRpZnkgYW55 IHN1Y2ggcmlnaHRzLiAgSW5mb3JtYXRpb24NCiAgIG9uIHRoZSBwcm9jZWR1cmVzIHdpdGggcmVz cGVjdCB0byByaWdodHMgaW4gUkZDIGRvY3VtZW50cyBjYW4gYmUNCiAgIGZvdW5kIGluIEJDUCA3 OCBhbmQgQkNQIDc5Lg0KDQogICBDb3BpZXMgb2YgSVBSIGRpc2Nsb3N1cmVzIG1hZGUgdG8gdGhl IElFVEYgU2VjcmV0YXJpYXQgYW5kIGFueQ0KICAgYXNzdXJhbmNlcyBvZiBsaWNlbnNlcyB0byBi ZSBtYWRlIGF2YWlsYWJsZSwgb3IgdGhlIHJlc3VsdCBvZiBhbg0KICAgYXR0ZW1wdCBtYWRlIHRv IG9idGFpbiBhIGdlbmVyYWwgbGljZW5zZSBvciBwZXJtaXNzaW9uIGZvciB0aGUgdXNlIG9mDQog ICBzdWNoIHByb3ByaWV0YXJ5IHJpZ2h0cyBieSBpbXBsZW1lbnRlcnMgb3IgdXNlcnMgb2YgdGhp cw0KICAgc3BlY2lmaWNhdGlvbiBjYW4gYmUgb2J0YWluZWQgZnJvbSB0aGUgSUVURiBvbi1saW5l IElQUiByZXBvc2l0b3J5IGF0DQogICBodHRwOi8vd3d3LmlldGYub3JnL2lwci4NCg0KICAgVGhl IElFVEYgaW52aXRlcyBhbnkgaW50ZXJlc3RlZCBwYXJ0eSB0byBicmluZyB0byBpdHMgYXR0ZW50 aW9uIGFueQ0KICAgY29weXJpZ2h0cywgcGF0ZW50cyBvciBwYXRlbnQgYXBwbGljYXRpb25zLCBv ciBvdGhlciBwcm9wcmlldGFyeQ0KICAgcmlnaHRzIHRoYXQgbWF5IGNvdmVyIHRlY2hub2xvZ3kg dGhhdCBtYXkgYmUgcmVxdWlyZWQgdG8gaW1wbGVtZW50DQogICB0aGlzIHN0YW5kYXJkLiAgUGxl YXNlIGFkZHJlc3MgdGhlIGluZm9ybWF0aW9uIHRvIHRoZSBJRVRGIGF0IGlldGYtDQogICBpcHJA aWV0Zi5vcmcuDQoNCg0KRGlzY2xhaW1lciBvZiBWYWxpZGl0eQ0KDQogICBUaGlzIGRvY3VtZW50 IGFuZCB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBhcmUgcHJvdmlkZWQgb24gYW4N CiAgICJBUyBJUyIgYmFzaXMgYW5kIFRIRSBDT05UUklCVVRPUiwgVEhFIE9SR0FOSVpBVElPTiBI RS9TSEUgUkVQUkVTRU5UUw0KICAgT1IgSVMgU1BPTlNPUkVEIEJZIChJRiBBTlkpLCBUSEUgSU5U RVJORVQgU09DSUVUWSBBTkQgVEhFIElOVEVSTkVUDQogICBFTkdJTkVFUklORyBUQVNLIEZPUkNF IERJU0NMQUlNIEFMTCBXQVJSQU5USUVTLCBFWFBSRVNTIE9SIElNUExJRUQsDQogICBJTkNMVURJ TkcgQlVUIE5PVCBMSU1JVEVEIFRPIEFOWSBXQVJSQU5UWSBUSEFUIFRIRSBVU0UgT0YgVEhFDQog ICBJTkZPUk1BVElPTiBIRVJFSU4gV0lMTCBOT1QgSU5GUklOR0UgQU5ZIFJJR0hUUyBPUiBBTlkg SU1QTElFRA0KICAgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgT1IgRklUTkVTUyBGT1Ig QSBQQVJUSUNVTEFSIFBVUlBPU0UuDQoNCg0KQ29weXJpZ2h0IFN0YXRlbWVudA0KDQogICBDb3B5 cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDA0KS4gIFRoaXMgZG9jdW1lbnQgaXMg c3ViamVjdA0KICAgdG8gdGhlIHJpZ2h0cywgbGljZW5zZXMgYW5kIHJlc3RyaWN0aW9ucyBjb250 YWluZWQgaW4gQkNQIDc4LCBhbmQNCiAgIGV4Y2VwdCBhcyBzZXQgZm9ydGggdGhlcmVpbiwgdGhl IGF1dGhvcnMgcmV0YWluIGFsbCB0aGVpciByaWdodHMuDQoNCg0KQWNrbm93bGVkZ21lbnQNCg0K ICAgRnVuZGluZyBmb3IgdGhlIFJGQyBFZGl0b3IgZnVuY3Rpb24gaXMgY3VycmVudGx5IHByb3Zp ZGVkIGJ5IHRoZQ0KICAgSW50ZXJuZXQgU29jaWV0eS4NCg0KDQoNCg0KTHlvbiwgV29uZyAgICAg ICAgICAgICAgIEV4cGlyZXMgLSBBcHJpbCAyMDA1ICAgICAgICAgICAgICAgIFtQYWdlIDE3XQ0K ------_=_NextPart_001_01C4C03B.50EC54C4-- From owner-ietf-mxcomp@mail.imc.org Tue Nov 2 17:19:52 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22902 for ; Tue, 2 Nov 2004 17:19:52 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA2LSqxX093950; Tue, 2 Nov 2004 13:28:52 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA2LSq6L093949; Tue, 2 Nov 2004 13:28:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA2LSlhm093888 for ; Tue, 2 Nov 2004 13:28:47 -0800 (PST) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id iA2LnWQ0006842; Tue, 2 Nov 2004 13:49:32 -0800 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id iA2LnWwI006839; Tue, 2 Nov 2004 13:49:32 -0800 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Tue, 2 Nov 2004 13:49:32 -0800 (PST) From: "william(at)elan.net" To: spf-discuss@v2.listbox.com cc: MXCOMP Subject: Redirected Trace header draft (was Processed-By or Transmitted-By header concept) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I would like to receive comments and open discusion on the following document which I expect to publish as Internet Draft after the IETF meeting in Washington http://www.elan.net/~william/emailsecurity/draft-leibzon-emailredirection-traceheaders-00pre02.txt The draft describes concept that we right now refer to as automated forwarding by new name email "redirection" (along same lines it refers to mail systems that do the this forwarding as "Mail Redirection Agents" aka MRA) and describes "Redirected:" header (which I previously was going to call Processed-By) for purposes of tracking when redirection takes place and providing information on what changes are done there to SMTP 2821 parameters and SMTP 2822 headers during redirection process. -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Wed Nov 3 22:22:20 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18868 for ; Wed, 3 Nov 2004 22:22:19 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA42d86G061350; Wed, 3 Nov 2004 18:39:08 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA42d86v061349; Wed, 3 Nov 2004 18:39:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA42d7P2061342 for ; Wed, 3 Nov 2004 18:39:07 -0800 (PST) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id iA4307c7027934; Wed, 3 Nov 2004 19:00:07 -0800 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id iA43072u027931; Wed, 3 Nov 2004 19:00:07 -0800 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Wed, 3 Nov 2004 19:00:07 -0800 (PST) From: "william(at)elan.net" To: spf-discuss@v2.listbox.com cc: MXCOMP Subject: MEDIA: Revised Sender ID does not impress Apache, Debian Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: http://www.theage.com.au/news/Breaking/Revised-Sender-ID-does-not-impress-Apache-Debian/2004/11/04/1099362268484.html?oneclick=true Revised Sender ID does not impress Apache, Debian By Sam Varghese November 4, 2004 - 11:43AM The Apache Software Foundation and the Debian GNU/Linux Project have given the revised Sender ID draft submitted by Microsoft a thumbs-down, with both saying that the changes effectively meant nothing. ... In a statement, a Debian spokesman said the changes which had been made did not look promising. ... A spokesman for the Apache Software Foundation said that unfortunately, these changes in the FAQ did not actually alter the terms of the licence. "It may be possible to implement portions of the specification without a licence from Microsoft, but Microsoft has indicated their intention to promote the encumbered portions of the specification (PRA) and use their considerable influence to cripple the the unencumbered alternative (MAIL FROM)," the spokesman [for the Apache Foundation] said. --- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Wed Nov 3 22:47:34 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20217 for ; Wed, 3 Nov 2004 22:47:34 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA43B5jY076577; Wed, 3 Nov 2004 19:11:05 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA43B54f076576; Wed, 3 Nov 2004 19:11:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA43B4jj076551 for ; Wed, 3 Nov 2004 19:11:04 -0800 (PST) (envelope-from matthew@elvey.com) Received: from frontend3.messagingengine.com (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id 6A283C361D7; Wed, 3 Nov 2004 22:10:37 -0500 (EST) X-Sasl-enc: 5FzkdJTb1EmUmIuvC2HnNg 1099537837 Received: from [192.168.1.141] (ns.nextbus.com [64.164.28.194]) by frontend3.messagingengine.com (Postfix) with ESMTP id A5D5028482; Wed, 3 Nov 2004 22:10:36 -0500 (EST) Message-ID: <41899DAA.8090304@elvey.com> Date: Wed, 03 Nov 2004 19:10:34 -0800 From: Matthew Elvey User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "william(at)elan.net" Cc: MXCOMP Subject: Re: Redirected Trace header draft References: In-Reply-To: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 11/2/2004 1:49 PM, william(at)elan.net sent forth electrons to convey: >I would like to receive comments and open discusion on ... >draft-leibzon-emailredirection-traceheaders-00pre02.txt > > This looks good. It adds information that may well be useful for debugging and investigating, without adding tons of redundant info. An earlier criticism of mine wasn't that it adds tons of info, but that (I thought) it added redundant info - that it duplicated info that was already there in 'Received:'. Looking at it more closely, now in draft format, I see that this isn't the case. It's not redundant. :) I'm going to give another swing at explaining why I feel there are SHOULDs that should be MUSTs in this spec. At a high level, consider SMTP as an example of a set of specs. The purpose of SMTP is to allow e-mail to flow in an interoperable way between systems. If an implementation follows all the MUSTs in the specs for SMTP, then it will be capable of accomplishing this purpose. (Or at least that is the intent of the specs.) In general: If an implementation follows all the MUSTs in the specs for the implementation, then it will be capable of accomplishing the purpose of the implementation. Or at least I think that's the way it should be. The purpose of the Redirected spec is to enable interoperable traceability of an automatically forwarded email by providing all the key information that the forwarder changes or replaces. The general case should apply: If an implementation follows all the MUSTs in the spec for the implementation, then it will be capable of accomplishing the purpose of the implementation. Using wording from RFC 2119 defining SHOULD, let me state: I can't think of a valid reason in any particular circumstance where an implementation's implementer who desires it to be compatible with this spec would need to ignore the particular items suggested by (e.g.) the first three SHOULDs in the spec. Also, the goal of the spec can't be met if these SHOULDs aren't followed, so they should be MUSTs. If an implementer doesn't want to enable "interoperable traceability of an automatically forwarded email by providing all the key information that the forwarder changes or replaces" then fine, but it must be clear that isn't compatible with this spec. Therefore, these SHOULDs must be MUSTs. Does this make sense to you? Am I mis-reading 2119? (Said another way: Some servers admins do not wish them to send or receive e-mail. Their purpose does not include accomplishment of that goal. So they don't support the RFCs defining SMTP. They violate the MUSTS of these RFCs. This isn't a problem. It *doesn't* follow that the MUSTs of these RFCs shouldn't have been SHOULDs or MAYs!) From owner-ietf-mxcomp@mail.imc.org Wed Nov 3 23:06:34 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21174 for ; Wed, 3 Nov 2004 23:06:34 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA43UdGQ086122; Wed, 3 Nov 2004 19:30:39 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA43UdN6086119; Wed, 3 Nov 2004 19:30:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA43Uc7W086069 for ; Wed, 3 Nov 2004 19:30:39 -0800 (PST) (envelope-from dean@av8.com) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id iA43Udb1028552 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 3 Nov 2004 22:30:41 -0500 Date: Wed, 3 Nov 2004 22:30:39 -0500 (EST) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: Harry Katz cc: IETF MARID WG Subject: Status of MARID WG? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Unless I missed something, the MARID working group is shutdown, so it can no longer consider drafts. It was my understanding that this list was kept active for discussion only. Did the MARID WG start up again? --Dean On Mon, 1 Nov 2004, Harry Katz wrote: > The attached Sender ID specification, draft-lyon-senderid-pra-00, is > being submitted to the IETF as an experimental Internet draft along with > draft-lyon-senderid-core-00 and draft-katz-submitter-00. > > These three drafts capture discussions held during the last few weeks of > the MARID working group, as well as some subsequent feedback we've > received. In summary, we've made two key changes to the Sender ID > Framework: -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From owner-ietf-mxcomp@mail.imc.org Thu Nov 4 00:56:11 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00565 for ; Thu, 4 Nov 2004 00:56:10 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA45Lp2S036339; Wed, 3 Nov 2004 21:21:51 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA45LpYL036338; Wed, 3 Nov 2004 21:21:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.midwestcs.com (elginwatches.org [206.222.212.234]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA45Lo3D036273 for ; Wed, 3 Nov 2004 21:21:50 -0800 (PST) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.34) id 1CPa4A-000820-0V for ietf-mxcomp@imc.org; Wed, 03 Nov 2004 23:21:51 -0600 To: "IETF MARID WG" References: From: wayne Reply-To: "IETF MARID WG" Date: Wed, 03 Nov 2004 23:21:45 -0600 In-Reply-To: (Dean Anderson's message of "Wed, 3 Nov 2004 22:30:39 -0500 (EST)") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: Status of MARID WG? Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-5.7 required=4.0 tests=AWL,BAYES_00,GREYLIST_ISWHITE autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In Dean Anderson writes: > Unless I missed something, the MARID working group is shutdown, so it can > no longer consider drafts. It was my understanding that this list was kept > active for discussion only. Did the MARID WG start up again? If the MARID WG started up again, it would be a shock to me. Note that the pointers to the I-Ds that Harry kindly posted are draft-lyon-* rather than the draft-marid-* which would indicate MARID involvement. This is simply following through on the co-chair's suggestion when this WG was shut down that the authors submit individual I-Ds. Speaking of which, does anyone know anything about the Directorate that was supposed to be set up? Last time I asked, it was suggested that nothing much would be done until IETF-61, which seems reasonable. -wayne From owner-ietf-mxcomp@mail.imc.org Thu Nov 4 04:13:25 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29490 for ; Thu, 4 Nov 2004 04:13:24 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA48ZYcD070963; Thu, 4 Nov 2004 00:35:34 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA48ZYXY070962; Thu, 4 Nov 2004 00:35:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA48ZSYp070874 for ; Thu, 4 Nov 2004 00:35:28 -0800 (PST) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id iA48uNpt006459; Thu, 4 Nov 2004 00:56:23 -0800 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id iA48uN3C006456; Thu, 4 Nov 2004 00:56:23 -0800 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Thu, 4 Nov 2004 00:56:23 -0800 (PST) From: "william(at)elan.net" To: Matthew Elvey cc: MXCOMP , Subject: Re: Redirected Trace header draft In-Reply-To: <41899DAA.8090304@elvey.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 3 Nov 2004, Matthew Elvey wrote: > > On 11/2/2004 1:49 PM, william(at)elan.net sent forth electrons to convey: > > >I would like to receive comments and open discusion on ... > >draft-leibzon-emailredirection-traceheaders-00pre02.txt I appreciate your feedback. New version based on all the feedback received today and fixes that I made is now available at: http://www.elan.net/~william/emailsecurity/draft-leibzon-emailredirection-traceheaders-00pre03.txt > I'm going to give another swing at explaining why I feel there are > SHOULDs that should be MUSTs in this spec. Using MUST makes it appear that I'm making it an immediate requirement for all systems involved in forwarding/redirection. In fact it will still be just a new optional trace header for recording what happened during redirection. > If an implementation follows all the MUSTs in the specs for the > implementation, then it will be capable of accomplishing the purpose of > the implementation. Or at least I think that's the way it should be. > > Using wording from RFC 2119 defining SHOULD, let me state: I can't > think of a valid reason in any particular circumstance where an > implementation's implementer who desires it to be compatible with this > spec would need to ignore the particular items suggested by (e.g.) the > first three SHOULDs in the spec. I'm going to try to follow your suggestion and change first three SHOULD to MUST because if somebody does follow this document, they really should be doing it right (i.e. MUST). But i'll emphasise again that document in itself and new header is not any more requirement then current Received header - its just a good idea. As such I believe in the end I'll be forced to change language back to SHOULD when the draft is discussed at ietf-822 and other lists. > The purpose of the Redirected spec is to enable interoperable > traceability of an automatically forwarded email by providing all the > key information that the forwarder changes or replaces. > The general case should apply: > > If an implementation follows all the MUSTs in the spec for the > implementation, then it will be capable of accomplishing the purpose of > the implementation. > > Using wording from RFC 2119 defining SHOULD, let me state: I can't > think of a valid reason in any particular circumstance where an > implementation's implementer who desires it to be compatible with this > spec would need to ignore the particular items suggested by (e.g.) the > first three SHOULDs in the spec. > Also, the goal of the spec can't be met if these SHOULDs aren't > followed, so they should be MUSTs. If an implementer doesn't want to > enable "interoperable traceability of an automatically forwarded email > by providing all the key information that the forwarder changes or > replaces" then fine, but it must be clear that isn't compatible with > this spec. Therefore, these SHOULDs must be MUSTs. > > Does this make sense to you? Am I mis-reading 2119? Yes it does. But Standard Track RFCs with MUST mandate required behavior and in this case it would be required behavior of the forwarding systems and current forwarders don't do it so we really can't make it a MUST although as I said already if they are tryingto follow this spec, then for them it should all be MUST. -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Thu Nov 4 12:28:52 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13794 for ; Thu, 4 Nov 2004 12:28:52 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA4GmwCX038955; Thu, 4 Nov 2004 08:48:58 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA4GmwYD038954; Thu, 4 Nov 2004 08:48:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA4Gmu73038892 for ; Thu, 4 Nov 2004 08:48:56 -0800 (PST) (envelope-from hkatz@exchange.microsoft.com) Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 Nov 2004 08:48:53 -0800 Received: from red-hub-04.redmond.corp.microsoft.com ([157.54.3.6]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 Nov 2004 08:48:44 -0800 Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by red-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 Nov 2004 08:48:07 -0800 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 Nov 2004 08:49:01 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Status of MARID WG? Date: Thu, 4 Nov 2004 08:48:51 -0800 Message-ID: Thread-Topic: Status of MARID WG? thread-index: AcTCHqrYW6YbteQ/RzeBbyIREccBjgAbxMAA From: "Harry Katz" To: "Dean Anderson" Cc: "IETF MARID WG" X-OriginalArrivalTime: 04 Nov 2004 16:49:01.0686 (UTC) FILETIME=[2FD52960:01C4C28E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iA4Gmu73038911 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit To my knowledge, MARID has not started again. I was just using the list to provide members with copies of the specifications since they will not appear on the IETF web site until after the IETF 61 meeting. > -----Original Message----- > From: Dean Anderson [mailto:dean@av8.com] > Sent: Wednesday, November 03, 2004 7:31 PM > To: Harry Katz > Cc: IETF MARID WG > Subject: Status of MARID WG? > > Unless I missed something, the MARID working group is > shutdown, so it can no longer consider drafts. It was my > understanding that this list was kept active for discussion > only. Did the MARID WG start up again? > > --Dean > > On Mon, 1 Nov 2004, Harry Katz wrote: > > > The attached Sender ID specification, > draft-lyon-senderid-pra-00, is > > being submitted to the IETF as an experimental Internet draft along > > with draft-lyon-senderid-core-00 and draft-katz-submitter-00. > > > > These three drafts capture discussions held during the last > few weeks > > of the MARID working group, as well as some subsequent > feedback we've > > received. In summary, we've made two key changes to the Sender ID > > Framework: > > -- > Av8 Internet Prepared to pay a premium for better service? > www.av8.net faster, more reliable, better service > 617 344 9000 > > > From owner-ietf-mxcomp@mail.imc.org Thu Nov 4 13:01:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16516 for ; Thu, 4 Nov 2004 13:01:06 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA4HRwoQ057531; Thu, 4 Nov 2004 09:27:58 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA4HRw4v057529; Thu, 4 Nov 2004 09:27:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sb7.songbird.com (sb7.songbird.com [208.184.79.137]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA4HRwQp057517 for ; Thu, 4 Nov 2004 09:27:58 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11/8.12.11) with SMTP id iA4HRagg015896; Thu, 4 Nov 2004 09:27:36 -0800 From: Dave Crocker To: Harry Katz , Dean Anderson CC: IETF MARID WG X-Mailer: PocoMail 3.2 (2000) - Licensed Version X-URL: brandenburg.com Reply-To: Dave Crocker Date: Thu, 4 Nov 2004 09:27:36 -0800 Message-ID: <200411492736.083061@bbprime> In-Reply-To: Subject: RE: Status of MARID WG? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 4 Nov 2004 08:48:51 -0800, Harry Katz wrote: > I was just using the list to provide members with copies for which you should be thanked, not hassled. your use of the list fits just fine with my own experience in post-wg mailing list use. (actually, it was more constructive than most uses...) d/ -- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... www.brandenburg.com From owner-ietf-mxcomp@mail.imc.org Thu Nov 4 15:00:37 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27608 for ; Thu, 4 Nov 2004 15:00:37 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA4JMhcf099779; Thu, 4 Nov 2004 11:22:43 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA4JMhmH099778; Thu, 4 Nov 2004 11:22:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA4JMfHh099772 for ; Thu, 4 Nov 2004 11:22:42 -0800 (PST) (envelope-from dean@av8.com) Received: from dakota.av8.net (dakota.av8.net [130.105.19.131]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id iA4JMTQS013645 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 4 Nov 2004 14:22:39 -0500 Date: Thu, 4 Nov 2004 14:22:28 -0500 (EST) From: Dean Anderson X-X-Sender: dean@localhost.localdomain To: Dave Crocker cc: Harry Katz , IETF MARID WG Subject: RE: Status of MARID WG? In-Reply-To: <200411492736.083061@bbprime> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I was not "hassling" anyone. The "submitted to the IETF for consideration as experimental..." in the introduction sounds very much like the WG is operating, and very much as if the WG is considering these drafts, which is not the case. Submitting drafts for interested people to look at is another issue entirely. And I certainly have no problem with that. But it is different than being "submitted to the IETF". --Dean On Thu, 4 Nov 2004, Dave Crocker wrote: > On Thu, 4 Nov 2004 08:48:51 -0800, Harry Katz wrote: > > I was just using the list to provide members with copies > > for which you should be thanked, not hassled. your use of the list > fits just fine with my own experience in post-wg mailing list use. > > (actually, it was more constructive than most uses...) > > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > +1.408.246.8253 > dcrocker a t ... > www.brandenburg.com > > > > -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From owner-ietf-mxcomp@mail.imc.org Thu Nov 4 15:15:06 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29748 for ; Thu, 4 Nov 2004 15:15:05 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA4JlnSX010965; Thu, 4 Nov 2004 11:47:49 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA4Jln6a010964; Thu, 4 Nov 2004 11:47:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA4Jlm8V010957 for ; Thu, 4 Nov 2004 11:47:48 -0800 (PST) (envelope-from dean@av8.com) Received: from dakota.av8.net (dakota.av8.net [130.105.19.131]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id iA4JlpHa014106 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 4 Nov 2004 14:47:52 -0500 Date: Thu, 4 Nov 2004 14:47:50 -0500 (EST) From: Dean Anderson X-X-Sender: dean@localhost.localdomain To: IETF MARID WG Subject: Re: Status of MARID WG? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 3 Nov 2004, wayne wrote: > > In Dean Anderson writes: > > > Unless I missed something, the MARID working group is shutdown, so it can > > no longer consider drafts. It was my understanding that this list was kept > > active for discussion only. Did the MARID WG start up again? > > If the MARID WG started up again, it would be a shock to me. > > Note that the pointers to the I-Ds that Harry kindly posted are > draft-lyon-* rather than the draft-marid-* which would indicate MARID > involvement. This is simply following through on the co-chair's > suggestion when this WG was shut down that the authors submit > individual I-Ds. Ah. I see. I missed the -lyon- part. That makes sense, now. Thanks. -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From owner-ietf-mxcomp@mail.imc.org Thu Nov 4 15:50:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03548 for ; Thu, 4 Nov 2004 15:50:19 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA4KKxMT025360; Thu, 4 Nov 2004 12:20:59 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA4KKx1u025357; Thu, 4 Nov 2004 12:20:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from lv-svr.lumenvox.com (mail.lumenvox.com [206.169.193.45]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA4KKvKa025271 for ; Thu, 4 Nov 2004 12:20:57 -0800 (PST) (envelope-from ThomasGal@LumenVox.com) Received: from PROGTHOMAS ([10.0.0.141]) by lv-svr.lumenvox.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 4 Nov 2004 12:12:21 -0800 Reply-To: From: "Thomas Gal" To: "'Harry Katz'" , "'Dean Anderson'" Cc: "'IETF MARID WG'" Subject: RE: Status of MARID WG? Date: Thu, 4 Nov 2004 12:20:56 -0800 Organization: LumenVox LLC MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <2D0CA64CDC33E14DA7AB043B8CC4D2BB0263B0C1@svr-exc.domain.com> Thread-Index: AcTCHqrYW6YbteQ/RzeBbyIREccBjgAbxMAAAAdr/hA= Message-ID: X-OriginalArrivalTime: 04 Nov 2004 20:12:21.0984 (UTC) FILETIME=[97C6E600:01C4C2AA] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I guess technically since the drafts have the writers' names rather than then working group name they are not implied to be ietf WG documents. -Tom thomasgal@lumenvox.com > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org] On Behalf Of Harry Katz > Sent: Thursday, November 04, 2004 8:49 AM > To: Dean Anderson > Cc: IETF MARID WG > Subject: RE: Status of MARID WG? > > > To my knowledge, MARID has not started again. > > I was just using the list to provide members with copies of > the specifications since they will not appear on the IETF web > site until after the IETF 61 meeting. > > > -----Original Message----- > > From: Dean Anderson [mailto:dean@av8.com] > > Sent: Wednesday, November 03, 2004 7:31 PM > > To: Harry Katz > > Cc: IETF MARID WG > > Subject: Status of MARID WG? > > > > Unless I missed something, the MARID working group is > shutdown, so it > > can no longer consider drafts. It was my understanding that > this list > > was kept active for discussion only. Did the MARID WG > start up again? > > > > --Dean > > > > On Mon, 1 Nov 2004, Harry Katz wrote: > > > > > The attached Sender ID specification, > > draft-lyon-senderid-pra-00, is > > > being submitted to the IETF as an experimental Internet > draft along > > > with draft-lyon-senderid-core-00 and draft-katz-submitter-00. > > > > > > These three drafts capture discussions held during the last > > few weeks > > > of the MARID working group, as well as some subsequent > > feedback we've > > > received. In summary, we've made two key changes to the Sender ID > > > Framework: > > > > -- > > Av8 Internet Prepared to pay a premium for better service? > > www.av8.net faster, more reliable, better service > > 617 344 9000 > > > > > > > From owner-ietf-mxcomp@mail.imc.org Thu Nov 4 18:25:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22375 for ; Thu, 4 Nov 2004 18:25:13 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA4MjH6i082474; Thu, 4 Nov 2004 14:45:17 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA4MjHTJ082471; Thu, 4 Nov 2004 14:45:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA4MjGUc082438 for ; Thu, 4 Nov 2004 14:45:16 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC04.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id iA4MjDar014791; Thu, 4 Nov 2004 14:45:13 -0800 (PST) Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 4 Nov 2004 14:45:13 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'ThomasGal@LumenVox.com'" , "'Harry Katz'" , "'Dean Anderson'" Cc: "'IETF MARID WG'" Subject: RE: Status of MARID WG? Date: Thu, 4 Nov 2004 14:45:12 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The practical difference is not that important. There are many RFCs that have reached draft standard status that have never been deployed. There are many protocols that have never progressed beyond experimental or informational that are real defacto standards. It was abundantly clear than many in the group were working from a mental model that went something like obtain IETF standards status, get deployed. This is in practice only the way forward after a protocol is reasonably mature. There is a high probability that the blogosphere will converge on whatever ATOM decides, but the IETF could not have created the blogosphere by simply ratifying an RFC. > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org] On Behalf Of Thomas Gal > Sent: Thursday, November 04, 2004 3:21 PM > To: 'Harry Katz'; 'Dean Anderson' > Cc: 'IETF MARID WG' > Subject: RE: Status of MARID WG? > > > > I guess technically since the drafts have the writers' names > rather than then working group name they are not implied to > be ietf WG documents. > > > -Tom > > thomasgal@lumenvox.com > > > -----Original Message----- > > From: owner-ietf-mxcomp@mail.imc.org > > [mailto:owner-ietf-mxcomp@mail.imc.org] On Behalf Of Harry Katz > > Sent: Thursday, November 04, 2004 8:49 AM > > To: Dean Anderson > > Cc: IETF MARID WG > > Subject: RE: Status of MARID WG? > > > > > > To my knowledge, MARID has not started again. > > > > I was just using the list to provide members with copies of > > the specifications since they will not appear on the IETF web > > site until after the IETF 61 meeting. > > > > > -----Original Message----- > > > From: Dean Anderson [mailto:dean@av8.com] > > > Sent: Wednesday, November 03, 2004 7:31 PM > > > To: Harry Katz > > > Cc: IETF MARID WG > > > Subject: Status of MARID WG? > > > > > > Unless I missed something, the MARID working group is > > shutdown, so it > > > can no longer consider drafts. It was my understanding that > > this list > > > was kept active for discussion only. Did the MARID WG > > start up again? > > > > > > --Dean > > > > > > On Mon, 1 Nov 2004, Harry Katz wrote: > > > > > > > The attached Sender ID specification, > > > draft-lyon-senderid-pra-00, is > > > > being submitted to the IETF as an experimental Internet > > draft along > > > > with draft-lyon-senderid-core-00 and draft-katz-submitter-00. > > > > > > > > These three drafts capture discussions held during the last > > > few weeks > > > > of the MARID working group, as well as some subsequent > > > feedback we've > > > > received. In summary, we've made two key changes to the > Sender ID > > > > Framework: > > > > > > -- > > > Av8 Internet Prepared to pay a premium for better service? > > > www.av8.net faster, more reliable, better service > > > 617 344 9000 > > > > > > > > > > > > From owner-ietf-mxcomp@mail.imc.org Sat Nov 6 21:16:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26563 for ; Sat, 6 Nov 2004 21:16:13 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA71ToLv007923; Sat, 6 Nov 2004 17:29:50 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA71ToHp007922; Sat, 6 Nov 2004 17:29:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA71Tl5a007822 for ; Sat, 6 Nov 2004 17:29:49 -0800 (PST) (envelope-from dean@av8.com) Received: from dakota.av8.net (dakota.av8.net [130.105.19.131]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id iA71Td86004610 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 6 Nov 2004 20:29:40 -0500 Date: Sat, 6 Nov 2004 20:29:39 -0500 (EST) From: Dean Anderson X-X-Sender: dean@localhost.localdomain To: "Hallam-Baker, Phillip" cc: "'ThomasGal@LumenVox.com'" , "'Harry Katz'" , "'IETF MARID WG'" Subject: RE: Status of MARID WG? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 4 Nov 2004, Hallam-Baker, Phillip wrote: > There are many RFCs that have reached draft standard status that have never > been deployed. I don't think this is true; in this or any other WG. Your claim runs counter to the requirements for Draft Standard status. Do you have an example RFC demonstrating this? > There are many protocols that have never progressed beyond > experimental or informational that are real defacto standards. This has certainly happened, but I think usually this is due to sloppiness by those WG chairs to take care of the business of the working group and move drafts along. Though this might be too harsh a criticism in some cases, such as where the Experimental RFC lost consensus, but use/interest was picked up later. > It was abundantly clear than many in the group were working from a mental > model that went something like obtain IETF standards status, get deployed. > This is in practice only the way forward after a protocol is reasonably > mature. It is hard to say what the mental model of many participating in the WG was. However, it is not the case that to "obtain IETF standards status, then get deployed" is "in practice only the way forward after a protocol is reasonably mature". The point of the RFC process is to define clearly a protocol; test, analyze, and fix flaws; and move forward based on consensus that something useful is being achieved. It is not a rubber stamp on "reasonably mature protocols". Not to restart the subject Eric Raymond and other discussed on the main IETF list over the last couple weeks, but the RFC process worked correctly in the MARID WG. The proposed protocols were severely flawed, and consensus could not be reached, so nothing useful could be accomplished. Some people are bitter about that result, and suggest that the IETF is therefore going to be "left in the dustbin". That isn't the first time that claim has been leveled, nor will it be the last. The SPF idea is not the last "ultimate spam solution", that will be found to have not quite considered everything, or even considered enough to be more useful than harmful. It was a good try, and the authors should be credited. However, reasonable people recognize when it's time to go back to the drawing board. I think the SPF authors and propoenents need to get to work again instead of complaining about the lack of ratification of their flawed proposals. I suggested previously that the authors take a hard, long look at information theory, and whether the spam problem can be solved technically, and in particular, to look at what sort of features of a spam filter are possible and what sort of limits information theory imposes on solutions. I've suggested also that they have to remember that the spammer has all the knowledge and privileges that they have. And I also suggest that instead of spam, they consider controlling an information flow in general. Lets call it 'Vienna Sausage', which is simply unwanted, ignoring the reasons for which it is unwanted. > There is a high probability that the blogosphere will converge on > whatever ATOM decides, but the IETF could not have created the blogosphere > by simply ratifying an RFC. The "blogosphere"? Is that like the punditariat? -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From owner-ietf-mxcomp@mail.imc.org Sat Nov 6 22:41:15 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00720 for ; Sat, 6 Nov 2004 22:41:14 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA73831o048189; Sat, 6 Nov 2004 19:08:03 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA7383xV048188; Sat, 6 Nov 2004 19:08:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.midwestcs.com (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA73827W048142 for ; Sat, 6 Nov 2004 19:08:02 -0800 (PST) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.34) id 1CQdPG-0007kI-9M for ietf-mxcomp@imc.org; Sat, 06 Nov 2004 21:08:02 -0600 To: "IETF MARID WG" References: From: wayne Reply-To: "IETF MARID WG" Date: Sat, 06 Nov 2004 21:07:53 -0600 In-Reply-To: (Dean Anderson's message of "Sat, 6 Nov 2004 20:29:39 -0500 (EST)") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: SenderID != SPF (Was: Status of MARID WG?) Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-5.7 required=4.0 tests=AWL,BAYES_00,GREYLIST_ISWHITE autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In Dean Anderson writes: > [...] The SPF idea is not > the last "ultimate spam solution", that will be found to have not quite > considered everything, or even considered enough to be more useful than > harmful. It was a good try, and the authors should be credited. However, > reasonable people recognize when it's time to go back to the drawing > board. I think the SPF authors and propoenents need to get to work again > instead of complaining about the lack of ratification of their flawed > proposals. This working group never advanced SPF as a proposal. It was involved in the creation of SenderID, which has many technical and licensing problems, but SenderID was never SPF. SPF is progressing just fine, both publication of SPF records and SPF checking are up sharply in the last month or so. (This upsurge occured before Microsoft and Meng published their new SenderID proposal, so they have nothing to do with it.) SPF has never been considered by the SPF community as being an "ultimate spam solution", and people who imply that it is generally are doing so to set up a strawman argument. -wayne From owner-ietf-mxcomp@mail.imc.org Sun Nov 7 21:04:46 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22863 for ; Sun, 7 Nov 2004 21:04:45 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA81QTa2047904; Sun, 7 Nov 2004 17:26:29 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA81QTcs047903; Sun, 7 Nov 2004 17:26:29 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA81QOQR047836 for ; Sun, 7 Nov 2004 17:26:24 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.vcorp.ad.vrsn.com (mailer5.verisign.com [65.205.251.54]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id iA81QLvB008741; Sun, 7 Nov 2004 17:26:21 -0800 (PST) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Sun, 7 Nov 2004 17:26:21 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Dean Anderson'" , "Hallam-Baker, Phillip" Cc: "'ThomasGal@LumenVox.com'" , "'Harry Katz'" , "'IETF MARID WG'" Subject: RE: Status of MARID WG? Date: Sun, 7 Nov 2004 17:26:19 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > -----Original Message----- > From: Dean Anderson [mailto:dean@av8.com] > > On Thu, 4 Nov 2004, Hallam-Baker, Phillip wrote: > > > There are many RFCs that have reached draft standard status > that have > > never been deployed. > > I don't think this is true; in this or any other WG. Your > claim runs counter to the requirements for Draft Standard > status. Do you have an example RFC demonstrating this? Various parts of DNSSEC have reached draft standard (or are about to) with no sign of deployment, IPSEC, IPv6, SMIME, PGP, various parts of PKIX the list goes on. All you need is two interoperable implementations and a userbase noticable to the IETF. The fact that 98% of the users of the internet will never use it directly or indirectly does not matter. > > There are many protocols that have never progressed beyond > > experimental or informational that are real defacto standards. > > This has certainly happened, but I think usually this is due > to sloppiness by those WG chairs to take care of the business > of the working group and move drafts along. Or the WG consensus choose a different protocol to the market. Nobody in the IETF is elected, nobody is accountable. The inevitable consequence of that situation is that nothing that the IETF does can ever rise above the level of a personal opinion. > It is hard to say what the mental model of many participating > in the WG was. However, it is not the case that to "obtain > IETF standards status, then get deployed" is "in practice > only the way forward after a protocol is reasonably mature". > The point of the RFC process is to define clearly a protocol; > test, analyze, and fix flaws; and move forward based on > consensus that something useful is being achieved. It is not > a rubber stamp on "reasonably mature protocols". The folk who were stopping at nothing to filibuster the proposal thought that stopping Sender-ID in the IETF would kill it in the real world. In fact nothing of the sort could ever happen. > Some people are bitter about that result, and suggest that > the IETF is therefore going to be "left in the dustbin". > That isn't the first time that claim has been leveled, nor > will it be the last. It may well be one of the last opportunities the IETF gets. Other forums elect their officers and run their WG is a responsible and accountable manner. > > There is a high probability that the blogosphere will converge on > > whatever ATOM decides, but the IETF could not have created the > > blogosphere by simply ratifying an RFC. > > The "blogosphere"? Is that like the punditariat? The political weblogs that largely drove the last election campaign. From owner-ietf-mxcomp@mail.imc.org Wed Nov 17 01:35:09 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17155 for ; Wed, 17 Nov 2004 01:35:08 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAH5dWTx051698; Tue, 16 Nov 2004 21:39:32 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAH5dWG8051697; Tue, 16 Nov 2004 21:39:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAH5dMkW051509 for ; Tue, 16 Nov 2004 21:39:23 -0800 (PST) (envelope-from dean@av8.com) Received: from dakota.av8.net (dakota.av8.net [130.105.19.131]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id iAH5d5Od031383 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 17 Nov 2004 00:39:06 -0500 Date: Wed, 17 Nov 2004 00:39:05 -0500 (EST) From: Dean Anderson X-X-Sender: dean@localhost.localdomain To: "Hallam-Baker, Phillip" cc: "'ThomasGal@LumenVox.com'" , "'Harry Katz'" , "'IETF MARID WG'" Subject: RE: Status of MARID WG? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sun, 7 Nov 2004, Hallam-Baker, Phillip wrote: > > > > -----Original Message----- > > From: Dean Anderson [mailto:dean@av8.com] > > > > > On Thu, 4 Nov 2004, Hallam-Baker, Phillip wrote: > > > > > There are many RFCs that have reached draft standard status that > > > have never been deployed. > > > > I don't think this is true; in this or any other WG. Your > > claim runs counter to the requirements for Draft Standard > > status. Do you have an example RFC demonstrating this? > > Various parts of DNSSEC have reached draft standard (or are about to) with > no sign of deployment, IPSEC, IPv6, SMIME, PGP, various parts of PKIX the > list goes on. I don't think it is the case that DNSSEC is about to reach "draft standard" status, nor is it the case that there aren't test deployments and "working" implementations of DNSSEC. For DNSSEC tools, a good site is http://www.dnssec.net/software.php. The oldest DNSSEC RFC is 2181 or perhaps 2535, 2536, etc. These are all in "Proposed Draft Standard" status. There is much ongoing work on DNSSEC, but I don't think anything will be finished in the near future. There are still significant problems to overcome before these drafts can move forward. > All you need is two interoperable implementations and a userbase noticable > to the IETF. The fact that 98% of the users of the internet will never use > it directly or indirectly does not matter. The "userbase noticable" isn't requirement of the RFC process. The IETF doesn't standardize based on popularity, but on consensus. > > > There are many protocols that have never progressed beyond > > > experimental or informational that are real defacto standards. > > > > This has certainly happened, but I think usually this is due > > to sloppiness by those WG chairs to take care of the business > > of the working group and move drafts along. > > Or the WG consensus choose a different protocol to the market. > > Nobody in the IETF is elected, nobody is accountable. The inevitable > consequence of that situation is that nothing that the IETF does can ever > rise above the level of a personal opinion. This is also not true. It may appear this way from time to time, but it isn't literally true. I've been on the other end when rules are broken, and no one seems to take responsibility. I can appreciate that it is frustrating, believe me. There are others who have had similar experiences with abuse. But, eventually, those who fail to take responsibility are moved out. There are ways to make organizations follow their own rules. When push comes to shove, organizations are obligated to follow their own rules. > > It is hard to say what the mental model of many participating > > in the WG was. However, it is not the case that to "obtain > > IETF standards status, then get deployed" is "in practice > > only the way forward after a protocol is reasonably mature". > > The point of the RFC process is to define clearly a protocol; > > test, analyze, and fix flaws; and move forward based on > > consensus that something useful is being achieved. It is not > > a rubber stamp on "reasonably mature protocols". > > The folk who were stopping at nothing to filibuster the proposal thought > that stopping Sender-ID in the IETF would kill it in the real world. In fact > nothing of the sort could ever happen. I have a different view. And I saw no "filibuster". Rather, I saw people trying to use the IETF to gain credibility for commercial exploitation, no matter that they actaully created more harm, and no good. I think they are chagrined at the loss of a "stamp of approval". The IETF isn't a rubber-stamp. But I have no illusions that any explanation or demonstration of the harms of either Sender-ID or SPF will in anyway disuade those spam-profiteers who described SPF and/or Sender-ID to the press as "ending spam". (eg, the Linux World article, statements by Microsoft, etc). But at the end, I recall people saying it was unnecessary to have any effect on spam, much less "end spam". So, my opinion is that when people see an opportunity to extract money, they'll go ahead no matter what. There is no interest in stopping spam. Indeed, the Microsoft presentation given at the Anti-spam conference at MIT demonstrated that. The MSN people noted that their biggest complaints came from other divisions of Microsoft whose spam they blocked (and that was unblocked). And while they weren't sharing their techniques (better to exploit them that way), what little they did reveal made me think they were using bayesian technique, though I think they specifically denied using spam-bayes. I thought it odd for them to come to a technical conference, give a presentation, and not actually share any technical information. They even poked fun of Barry Shein for saying he didn't trust any blackbox from Microsoft. The proceeding was video-taped, and I think it can be downloaded off the web somewhere. Its telling that most of the spam-profiteers think that spam-bayes is pure evil. Its only evil to spam-profiteers because its free, and it prevents them from making money on spam. These same people saying spam-bayes is pure evil (eg Vixie) have made statements to the effect that anything that helps reduce spam is good. Except spam-bayes. They say that's bad. Not just a little bad. But terribly, horribly, drastically bad. I've done some work applying information theory to spam, and have discovered that there is no ultimate solution to spam. This is probably worth writing up, unlike many of my observations of obvious flaws where the noted flaws were so obvious as to be an embarrasment to the proposer, rather than a credit to my insight. But the information theory work is fairly obscure. In theory, the abuser can adapt to whatever you deploy, and circumvent it. Read that again, with emphasis on THEORY, ADAPT, WHATEVER, CIRCUMVENT. The best you can do is detect and adapt to whatever they do. So you can keep doing whackamole. If fact, you can't do better than whackamole. But maybe you can do whackamole better. Of course, the abuser can do the mole part better, too. So you can't ever win. It's unclear if uping the stakes is a good bet. But we can think about doing that. So, if you want to speed up the "detect and adapt" process, you need statistical methods. Enter Bayes Rule, which specifies how to calculate conditional probability. So, from a purely mathematical point of view, what you'd do is something along the lines of spam-bayes. Spam-bayes may in fact be too simple, and still too hard to train. But its going in the best direction. In the end, it won't succeed either. But it will require the most from the abuser to be the most adaptable and least predictable they can be. Of course, not everyone agrees. And there could be better ways to react faster. I have no proof that Bayesian filters are the //absolute best way to play whackamole//, as opposed to just being in the right direction as compared with other approaches, and as compared with constraints implied by information theory. Indeed, I've thought that analyzing the meaning of the message in relation to the recipient's interest in the content of the message, like a human secretary, may be a good approach. This is probably hard. Previous AI approaches failed. Automated text summarization research seems to be useful. There may be other statistical methods, or other non-statistical "detect and adapt" methods. But the reaction to spam-bayes from the spam-profiteers is most telling. They really, really, really hate the idea of spam-bayes. How is that? So I wonder if maybe they hate spam-bayes because they can't make money on it, and if its the best solution, then they won't make money on spam at all. Too bad for them. I wonder, if they give up, if the abusers will stop sending spam the same way that open relay abusers pretty much stopped abusing open relays after the open relay blacklists shutdown. One thing CAN-SPAM has demonstrated is that spammers aren't commercial. I also speculated that was the case a long time ago, but it wasn't obvious even to me that I was so completely right. I knew some few people were conducting abuse for the sake of abuse. But I had no idea how much. So, given that, it _could_ be possible that abusers might get tired of the game and just choose to stop of their own accord. But I also thought that virus writing was a fad that would lose its appeal, and it hasn't let up some 15 years after I thought that. So I'm not always right. And Virus writing seems to be related to spamming, so probably we can't expect either to just stop someday. > > Some people are bitter about that result, and suggest that > > the IETF is therefore going to be "left in the dustbin". > > That isn't the first time that claim has been leveled, nor > > will it be the last. > > It may well be one of the last opportunities the IETF gets. Other forums > elect their officers and run their WG is a responsible and accountable > manner. Some other standards bodies do run a tighter ship. I used to work for one of those forums. Certainly, the IETF could be run better. There is room for criticism and improvement. But there is a nomination process for the IETF chairman, and members of the IAB. The IETF is also an activity of ICANN, which also has officers, elections, and bylaws. This all could be improved, without doubt. But the basics are there. I doubt very much that it will be the "last opportunity". That is just an implied ultimatum: "Do this or else be ignored". I saw similar ultimatums from the radical anti-spam community on subjects such as open relays. Nearly all of the open relay blacklists closed because ISPs were blocking their scans. In fact, I have seen a systematic scan in a long time. Nor has there been any open relay abuse in a long time. Funny, that. > > > There is a high probability that the blogosphere will converge on > > > whatever ATOM decides, but the IETF could not have created the > > > blogosphere by simply ratifying an RFC. > > > > The "blogosphere"? Is that like the punditariat? > > The political weblogs that largely drove the last election campaign. Yes. It was a joke, of sorts. The "punditariat" is the collection of pundits who write editorials and opinion pieces. Before there were weblogs, there were pundits. The pundits are sometimes referred to by those in the political campaigns as the punditariat. A pun on the word secretariat, which is a congress. -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From owner-ietf-mxcomp@mail.imc.org Wed Nov 17 15:13:43 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07652 for ; Wed, 17 Nov 2004 15:13:43 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHJTDJB005527; Wed, 17 Nov 2004 11:29:13 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAHJTDAk005524; Wed, 17 Nov 2004 11:29:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHJTBgj005414 for ; Wed, 17 Nov 2004 11:29:11 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.vcorp.ad.vrsn.com (mailer5.verisign.com [65.205.251.54]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id iAHJT5ad018995; Wed, 17 Nov 2004 11:29:06 -0800 (PST) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Wed, 17 Nov 2004 11:29:05 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Dean Anderson'" , "Hallam-Baker, Phillip" Cc: "'ThomasGal@LumenVox.com'" , "'Harry Katz'" , "'IETF MARID WG'" Subject: RE: Status of MARID WG? Date: Wed, 17 Nov 2004 11:29:04 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > All you need is two interoperable implementations and a userbase > > noticable to the IETF. The fact that 98% of the users of > the internet > > will never use it directly or indirectly does not matter. > > The "userbase noticable" isn't requirement of the RFC > process. The IETF > doesn't standardize based on popularity, but on consensus. Consensus amongst a community that is 100% atypical of the Internet users. Each time I vist the IETF the proportion of members who are unashamed technologist supremacists rises. There is no embarassment about developing systems that ordinary users cannot make use of. > > Nobody in the IETF is elected, nobody is accountable. The > inevitable > > consequence of that situation is that nothing that the IETF > does can > > ever rise above the level of a personal opinion. > > This is also not true. It may appear this way from time to > time, but it isn't literally true. It is literaly true that nobody is elected. All appointments are through a selection committee that is explicitly non-representative and non-accountable. > Indeed, the Microsoft presentation given at the Anti-spam > conference at MIT demonstrated that. The MSN people noted > that their biggest complaints came from other divisions of > Microsoft whose spam they blocked (and that was unblocked). > And while they weren't sharing their techniques (better to > exploit them that way), what little they did reveal made me > think they were using bayesian technique, though I think they > specifically denied using spam-bayes. I thought it odd for > them to come to a technical conference, give a presentation, > and not actually share any technical information. The best presentation at the MIT conference was by the MIT undergrad who was the only person there who gave a rundown of the comparative effectiveness of bayesian inference vs other techniques and found the other techniques worked better. I would be surprised if Microsoft did use Bayesian inference, they are not the best tool for their corpus by a very long way. In the presentation I heard the presenter said that they used a huge number of rules and constantly re-evaluated both the ones that were most effective and the ways in which relative weights were combined. > These same people saying spam-bayes is pure evil (eg > Vixie) have made statements to the effect that anything that > helps reduce spam is good. Except spam-bayes. They say > that's bad. Not just a little bad. But terribly, horribly, > drastically bad. Oh I can think of ways in which Spam-bayes might be bad for Paul Vixie... > I've done some work applying information theory to spam, and > have discovered that there is no ultimate solution to spam. Now there is an interesting statement. Whayt if the solution does not exist in information theory? > But > there is a nomination process for the IETF chairman, and > members of the IAB. The IETF is also an activity of ICANN, No it isn't. And no, a nomination process does not an accountability mechanism make. From owner-ietf-mxcomp@mail.imc.org Wed Nov 17 16:28:20 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19236 for ; Wed, 17 Nov 2004 16:28:19 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHKtgf7042754; Wed, 17 Nov 2004 12:55:42 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAHKtg37042753; Wed, 17 Nov 2004 12:55:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHKtbXK042683 for ; Wed, 17 Nov 2004 12:55:37 -0800 (PST) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id iAHLJ2Ag023143; Wed, 17 Nov 2004 13:19:02 -0800 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id iAHLJ2UD023140; Wed, 17 Nov 2004 13:19:02 -0800 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Wed, 17 Nov 2004 13:19:02 -0800 (PST) From: "william(at)elan.net" To: spf-discuss@v2.listbox.com cc: "'IETF MARID WG'" Subject: I-D ACTION:draft-leibzon-emailredirection-traceheaders-00.txt (fwd) Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY=NextPart Content-ID: Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --NextPart Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: FYI ---------- Forwarded message ---------- Date: Wed, 17 Nov 2004 15:36:06 -0500 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D ACTION:draft-leibzon-emailredirection-traceheaders-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Email Forwarding and Redirection Trace Headers Author(s) : W. Leibzon Filename : draft-leibzon-emailredirection-traceheaders-00.txt Pages : 18 Date : 2004-11-17 This memo defines Redirected email trace header which can be used to identify changes made to source and destination parameters of email message by SMTP forwarding and redirection systems and to identify what type of redirection took place. Original-* headers are also defined to show changes made to other headers by forwarding and redirection systems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-leibzon-emailredirection-traceheaders-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org 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-leibzon-emailredirection-traceheaders-00.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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-leibzon-emailredirection-traceheaders-00.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 Content-ID: Content-Description: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --OtherAccess Content-Type: MESSAGE/EXTERNAL-BODY; ACCESS-TYPE=mail-server; SERVER="mailserv@ietf.org" Content-ID: --OtherAccess Content-Type: MESSAGE/EXTERNAL-BODY; NAME="draft-leibzon-emailredirection-traceheaders-00.txt"; SITE="ftp.ietf.org"; ACCESS-TYPE=anon-ftp; DIRECTORY=internet-drafts Content-ID: --OtherAccess-- --NextPart Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-ID: Content-Description: Content-Disposition: INLINE _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- From owner-ietf-mxcomp@mail.imc.org Wed Nov 17 23:38:35 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26788 for ; Wed, 17 Nov 2004 23:38:35 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAI3lba8013213; Wed, 17 Nov 2004 19:47:37 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAI3lbiZ013212; Wed, 17 Nov 2004 19:47:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAI3lZ5C013184 for ; Wed, 17 Nov 2004 19:47:36 -0800 (PST) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id iAI4BApZ007125; Wed, 17 Nov 2004 20:11:10 -0800 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id iAI4BA1P007122; Wed, 17 Nov 2004 20:11:10 -0800 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Wed, 17 Nov 2004 20:11:10 -0800 (PST) From: "william(at)elan.net" To: "'IETF MARID WG'" cc: spf-discuss@v2.listbox.com Subject: MEDIA: Is Microsoft Ready to Assert IP Rights over the Internet? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: [I have my own comments about all this but they are not for public list, but I'll hint you that while SenderID license may well be resolved soon, this may actually make matters worth for opensource internet community if you look at the larger perspective of what Microsoft is up to] http://www.eweek.com/article2/0,1759,1714680,00.asp Is Microsoft Ready to Assert IP Rights over the Internet? By Steven J. Vaughan-Nichols November 5, 2004 Has Microsoft been trying to retroactively claim IP (intellectual property) rights over many of the Internet's basic protocols? Larry J. Blunk, senior engineer for networking research and development at Merit Network Inc., believes that might be the case. Blunk expressed these concerns about Microsoft's Royalty Free Protocol License Agreement in a recent note to the IETF's Intellectual Property Rights Working Group. Specifically, Blunk suggested that Microsoft seemed to be claiming IP rights to many vital Internet protocols. And by so doing, "Microsoft is injecting a significant amount of unwarranted uncertainty and doubt regarding non-Microsoft implementations of these protocols," Blunk said. Blunk pointed out that Microsoft is claiming some form of IP rights over "a total of 130 protocols which Microsoft is offering for license." Many of the listed protocols are [IETF] RFC [request for comment] documents, including but not limited to the core TCP/IP v4 and TCP/IP v6 protocol specifications," he said in his note. Some of the RFC protocols that Microsoft asserts that it may have IP rights over, such as the TCP/IP protocols and the DNS (Domain Name System), form the very bedrock of the Internet's network infrastructure. "Microsoft does not specify how this list of protocols was derived and to what extent they have investigated their possible rights holdings over these protocols," Blunk said. "The list appears to be a near but not completely exhaustive list of public protocols implemented in Microsoft product" It is quite likely that an individual or organization would be intimidated into signing the license agreement simply due to Microsoft's vast financial and legal resources," he said http://www.groklaw.net/article.php?story=20041107154122603 ... Meanwhile, Microsoft is quietly moving forward with its patent plans. News.com has a fascinating article that quotes a spokesman as saying that they are seeking to enter into cross-licensing deals with the top 30 technology companies, so that they can have access to the patents they are most interested in and can offer their customers indemnification from patent infringement lawsuits. How charming. A little club. The "We Are The Only Ones Allowed to Write Software Any More" ... Speaking of anticompetitive moves, by now you have seen the eWeek report on Microsoft's Royalty Free Protocol License Agreement on Internet protocols and the Larry Blunk email that started it all. Larry Rosen has noted that this license appears to be like the Sender ID license, which means that the obvious remedy is for standards bodies to stand firm against this license. http://groups.google.com/groups?hl=en&lr=&selm=2Z7Tb-70A-9%40gated-at.bofh.it ... I also briefly met with Ryan Hamlin, the GM of Microsoft's Safety Technology & Strategy group, and he's interested in attempting a second try at the patent license negotiation between us (well, Larry Rosen) and a more senior attorney at Microsoft. So, it may not be entirely hopeless that Sender ID be entirely usable by open source. -- Daniel Quinlan ApacheCon! 13-17 November (3 SpamAssassin http://www.pathname.com/~quinlan/ http://www.apachecon.com/ sessions & more) From owner-ietf-mxcomp@mail.imc.org Thu Nov 18 15:53:46 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08963 for ; Thu, 18 Nov 2004 15:53:46 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIJw3gG002915; Thu, 18 Nov 2004 11:58:03 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAIJw3Ph002914; Thu, 18 Nov 2004 11:58:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIJw3in002907 for ; Thu, 18 Nov 2004 11:58:03 -0800 (PST) (envelope-from dotis@mail-abuse.org) Received: from [168.61.10.149] (SJC-Office-DHCP-149.Mail-Abuse.ORG [168.61.10.149]) (authenticated bits=0) by a.mail.sonic.net (8.12.11/8.12.11) with ESMTP id iAIJw7eP008895 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 18 Nov 2004 11:58:07 -0800 Subject: People issues From: Douglas Otis To: MARID Content-Type: text/plain Message-Id: <1100807646.2905.117.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Thu, 18 Nov 2004 11:54:06 -0800 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Here is an interesting presentation that predates MARID. Of course I have favorite slides, and could do better, but the topics covered represent ongoing concerns. http://www.ietf.org/proceedings/02mar/slides/plenary-3/ -Doug From owner-ietf-mxcomp@mail.imc.org Fri Nov 19 00:48:54 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05925 for ; Fri, 19 Nov 2004 00:48:54 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJ5D9bW096369; Thu, 18 Nov 2004 21:13:09 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAJ5D961096368; Thu, 18 Nov 2004 21:13:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from neko-base.nekodojo.org (neko-base.nekodojo.org [69.225.172.218]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJ5D84v096362 for ; Thu, 18 Nov 2004 21:13:08 -0800 (PST) (envelope-from gconnor@nekodojo.org) Received: from localhost (localhost.localdomain [127.0.0.1]) by neko-base.nekodojo.org (Postfix) with ESMTP id ADAE01D657; Thu, 18 Nov 2004 21:13:15 -0800 (PST) Date: Thu, 18 Nov 2004 21:13:18 -0800 From: Greg Connor To: Douglas Otis , MARID Subject: Re: People issues Message-ID: <727385.1100812398@[192.168.0.2]> In-Reply-To: <1100807646.2905.117.camel@localhost.localdomain> References: <1100807646.2905.117.camel@localhost.localdomain> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Thanks Doug. Good information. I do hope the IETF continues to work on the issues MARID tried to address. --Douglas Otis wrote: > > Here is an interesting presentation that predates MARID. Of course I > have favorite slides, and could do better, but the topics covered > represent ongoing concerns. > > http://www.ietf.org/proceedings/02mar/slides/plenary-3/ > > -Doug -- Greg Connor From owner-ietf-mxcomp@mail.imc.org Sat Nov 20 02:42:11 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28030 for ; Sat, 20 Nov 2004 02:42:11 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAK6qfwM025056; Fri, 19 Nov 2004 22:52:41 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAK6qfB2025055; Fri, 19 Nov 2004 22:52:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAK6qaZ6024943 for ; Fri, 19 Nov 2004 22:52:40 -0800 (PST) (envelope-from matthew@elvey.com) Received: from frontend3.messagingengine.com (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id 3E590C3A44E for ; Sat, 20 Nov 2004 01:52:41 -0500 (EST) X-Sasl-enc: Qd4tnOvp5oC90xyt2nCAcA 1100933561 Received: from [192.168.1.141] (ns.nextbus.com [64.164.28.194]) by frontend3.messagingengine.com (Postfix) with ESMTP id CEBE42553F; Sat, 20 Nov 2004 01:52:40 -0500 (EST) Message-ID: <419EE9B5.6030704@elvey.com> Date: Sat, 20 Nov 2004 01:52:37 -0500 From: Matthew Elvey User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: MXCOMP Subject: FTC stuff 0) Lies 1)Yahoo & DK. 2)GoDaddy DNS & SPF & CSV. 3)Dean & FUSSP. 4)Testing 5)EFF, Anonymity. X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit My take on the FTC Email Authentication Summit : 0) Lies 1)Yahoo & DK. 2)GoDaddy DNS & SPF & CSV. 3)Dean & FUSSP. 4)Testing 5)EFF, Anonymity. +++++++++++ 0)Some lies and misleading statements from Microsoft's Harry Katz (& Ryan): He said that in order to validate an email, per SenderID/CallerID/SPF, you need to . We all should know by now that it could be a hundred DNS queries, and is not likely to be one query. He said that no changes are required to MUAs. Well, sure they aren't uh, 'required', but they're 'needed' to address the phishing problem with SenderID. I better buy a new version of Outlook, huh? He said that SenderID protects the address most likely to be seen. Well, no, some spammers have already adapted and use, e.g. the Pretty Name or Sender: to make the recipient see what the addresss they want them to see in their MUA. SPF and SenderID *DO NOT PROTECT* the "From:"! (Equifax (which represents the banks of the phished) confirmed this.) (Given that Bill Gates believes that SenderID protects the "From:" line too, poor Harry is a bit stuck.) He said, roughly, "I _believe_ SenderID is as efficient and as easy to deploy as CSV." Some folks _believe_ the earth is flat. It's not about _belief_, but technical reality, and M$ is dodging the tough questions. I heard no argument to back that statement, and gobs of evidence indicating that it's false. Despite strong evidence to the contrary, he states that he _believes_ not that CSV would provide greater benefit for less cost, but rather the reverse, but no explanation - clearly we should have _faith_ in Microsoft. I found it chilling that right after around a dozen exploitable security holes in his proposal were pointed out to Harry, he proceeded to encourage everyone to adopt it. My main question for Microsoft's David Kaefer, Esq? : Why haven't you adopted a "If you don't sue us, we won't sue you" license, like Cisco's, as Scott Bradner said? It provides everything you said you needed. It just doesn't trip up Free Software, which I conclude (mostly for lack of other plausible explanation) must be the real reason for the current license. Basically, I heard vague, impressive-sounding statements to impress the non-technical. I was disappointed to hear several false statements that have already been discredited made again. Are the transcrips available yet? It'll be good to make these exact quotes, not just paraphrases.) =-=-=-= 1)Did the Yahoo folks at the FTC conference say that they would be signing all outbound mail by now, and would be checking incoming mail soon? Mail I sent from my Yahoo (premium) account on Wednesday isn't signed. Is the replay problem solved? Until it is, I see no point in deploying DK or IMM, since they won't work long term. =-=-=-= 2)GoDaddy DNS & SPF & CSV FYI (Go Jason & Mike, Doug & Bob!) : Dear Mr. Elvey, Thank you for writing. We appreciate your having taken the time to contact us on this matter. This is a good suggestion and we will forward it to our development department for review and consideration. Please let us know if we can be of further assistance. Kindest Regards, president godaddy com Douglas Preston Jr. Office of the President GODADDY.COM 14455 N. Hayden Road, Suite #226 Scottsdale, AZ 85260 480-505-8828 - phone 480-505-8844 - fax -----Original Message----- From: Matthew Elvey [mailto:matthew elvey ] Sent: Wednesday, November 17, 2004 3:43 PM To: president godaddy Subject: GoDaddy and the FTC Email Authentication Summit. Hi. I attended the FTC Email Authentication Summit, where I heard and spoke with Mike Chadwick. Mike suggested I email you about an issue with Email Authentication and Go Daddy-registered domains. Currently, even when 'Total DNS Control' is enabled, one cannot set up records to comply with the leading Email Authentication proposals - SPF and CSV. Can you please remedy this ASAP? Mike said "Godaddy believes that customers need the ability to protect their domains easily" so please make this possible by making it possible to set up SPF and CSV records (i.e. TXT, SRV and PTR records). Thanks in advance! And let me know if you have any questions about what's needed or why. I'm happy to clarify. -- Matthew =-=-=-=-=-= 3)Dean & FUSSP. Dean Anderson of av8 seems best largely ignored, given odd evidence suggesting his views are that DNSBLs are terribly, horribly, drastically, irretreivably bad and other ranting: http://vesuvio.ipv6.tilab.com/pipermail/ietf_censored/2004-May/006714.html (and http://vesuvio.ipv6.tilab.com/pipermail/ietf_censored/2004-June/006933.html and the results of #whois 130.105.36.66 and http://moensted.dk/spam/messages/20020716-dean+av8.com.txt ); forgive me if I'm skeptical about his statements. I am confident an implemented long term solution that will keep inboxes functional and nearly spam-free is in the not-so-distant future. It's not like a perpetual motion machine: un-inventable. Plus, Information Theory is cool and fun. I've found it useful for pointing me in the right direction for handling this plague. =-=-=-=-=-=-= 4)Testing in general, and CSV Testing at AOL I was mostly pleased to see Carl announce that AOL will be testing CSV based on my "Make CSV backwards compatible with legacy SPF records?" ideas. Pleased to see it growing roots, but wishing this testing had been preceeded by better dry runs. (I'm not surprised AOL has been unable to implement SPF inbound, and that AOL is finding forwarders not using SRS to be a major barrier to using SPF to identify spam.) The call (which I heard expressed a few times at the FTC) for lots of testing annoys/worries the heck out of me. Here's why: 1)What has failed to happen so far is sufficient bench testing. Why test something in the field when a simple lab-bench test suggests it won't work? Let's consider how silly our behaviour looks when compared to the way cryptography schemes are developed. A crypto scheme is generally announced, and actively discussed in the community. Attacks are theorized and defenses are presented by the scheme's proponents, in extensive open discussion, long before field tests are used to see if it works. On MARID, we've seen security flaws poo-pooed. Doug has described, in detail, some extremely damning attack vectors on SenderID, essentially arguing that it'll be a disaster (e.g. on-list and http://www.csvmail.org/email-authentication-summit-comments-P044411.pdf ). I haven't seen any response. Given how often he describes them, this omission is all the more glaring. I'm not suggesting we not proceed with real world testing, I just wish there was cooperation on from Microsoft with bench testing. Microsoft performs a disservice by not responding. 2)Also, I worry about conclusions based on tests that are not sufficiently realistic to provide more accurate guidance than bench tests do. Given that SPF requires any domain used in HELO have a valid SPF record that authorizes that use, I expect at least one positive metric from the testing. However, I fear a real world test that doesn't involve good and bad reputations having real consequences; I fear decisions made based on such unrealistic tests. (If AOL's test of CSV will impact SCOMP-like reputations, I'll worry much less!) PS Carl, please contact me for licensing terms. =-=-=-=-=-=-= 5)EFF, Anonymity. I asked the EFF's Policy Analyst Annalee Newitz: "You have essentially said Domain Authentication is unaceptable. The EFF's position on spam is that all wanted mail must be delivered to the users eyeballs. I can think of no useful antispam solution in use today or being considered here that guarantees that. Please identify and discuss at leat one." She said that the EFF supports the use of tools like SpamAssassin if they leave the user in control, and that she plans to publish a paper clarifying/changing the EFF's position soon. I hope so! (The rationale behind my question is that since no filter is perfect (100% FP-free), therefore no filter is acceptable to the EFF.) Ooh! Looks like this is it: http://eff.org/wp/?f=SpamCollateralDamage.html :) but, http://eff.org/Spam_cybersquatting_abuse/Spam/position_on_junk_email.php is still wrong; an update is in order, IMO. OTOH, this rather silly argument put forth regarding anonymity: It's silly because when these other venues aren't protected from junk messages, they become the next target. *So we need a solution that is easily extendable to protect other media venues such as these, and doesn't eliminate email anonymity. It would be cool to see the EFF set up a reputation service (CSV,SPF,CID-supporting) that listed MTAs/domains run by political organizations, and/or a CAPTCHA-protected anonymous mailing facility that kept no logs.* I'd certainly use the former and probably use the latter. =-=-=-=-=-=-= People Issues - great presentation; I fervently hope more of us read it closely and comply. =-=-=-=-=-=-= Most impressive: The folks from the FTC running the conference. They get it. I was pleasantly surprised. From owner-ietf-mxcomp@mail.imc.org Sat Nov 20 09:58:44 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27920 for ; Sat, 20 Nov 2004 09:58:44 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAKELlsP053640; Sat, 20 Nov 2004 06:21:47 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAKELlqo053639; Sat, 20 Nov 2004 06:21:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAKELjdd053620 for ; Sat, 20 Nov 2004 06:21:46 -0800 (PST) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id B42C416CC3 for ; Sat, 20 Nov 2004 09:33:05 -0500 (EST) From: "Alan DeKok" To: MXCOMP Subject: Re: FTC stuff 0) Lies 1)Yahoo & DK. 2)GoDaddy DNS & SPF & CSV. 3)Dean & FUSSP. 4)Testing 5)EFF, Anonymity. In-Reply-To: Your message of "Sat, 20 Nov 2004 01:52:37 EST." <419EE9B5.6030704@elvey.com> Date: Sat, 20 Nov 2004 09:33:05 -0500 Message-Id: <20041120143305.B42C416CC3@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Matthew Elvey wrote: > 1)What has failed to happen so far is sufficient bench testing. Why > test something in the field when a simple lab-bench test suggests it > won't work? Let's consider how silly our behaviour looks when compared > to the way cryptography schemes are developed. A crypto scheme is > generally announced, and actively discussed in the community. Attacks > are theorized and defenses are presented by the scheme's proponents, in > extensive open discussion, long before field tests are used to see if it > works. The key here is "open discussion". The SMTP/anti-spam field involves so many strongly emotional positions that open discussion is rare. > On MARID, we've seen security flaws poo-pooed. In cryptographic circles, the people who develop encryption schemes accept the fact that their schemes are flawed, when provided with proof. The people who attack encryption schemes accept the fact that their attacks are flawed, when provided with proof. The goal of both parties is to provide provable security. The failure of SMTP to protect from forgery, malicious bounces, etc. is a failure of the security model of SMTP. Until that's analysed and fixed, all of the proposed schemes are band-aids. And even if they're all fixed, it will still be possible for a million random people on the net to send you email, because that's a goal of email. And those people can all choose to send you spam. Spam will never go away. But we can make it easier to track, and easier to hold people accountable. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Sat Nov 20 12:45:19 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11612 for ; Sat, 20 Nov 2004 12:45:19 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAKH8148029994; Sat, 20 Nov 2004 09:08:01 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAKH81lU029993; Sat, 20 Nov 2004 09:08:01 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sb7.songbird.com (sb7.songbird.com [208.184.79.137]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAKH7uUQ029958 for ; Sat, 20 Nov 2004 09:08:00 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbfujip (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11/8.12.11) with SMTP id iAKH7wAP009735; Sat, 20 Nov 2004 09:07:59 -0800 From: Dave Crocker To: Alan DeKok , MXCOMP X-Mailer: PocoMail 3.2 (2000) - Licensed Version X-URL: brandenburg.com Reply-To: Dave Crocker Date: Sat, 20 Nov 2004 07:59:39 -0800 Message-ID: <2004112075939.373626@bbfujip> In-Reply-To: <20041120143305.B42C416CC3@mail.nitros9.org> Delivery-Date: Sat, 20 Nov 2004 07:59:38 -0000 Subject: Re: FTC stuff 0) Lies 1)Yahoo & DK. 2)GoDaddy DNS & SPF & CSV. 3)Dean & FUSSP. 4)Testing 5)EFF, Anonymity. Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sat, 20 Nov 2004 09:33:05 -0500, Alan DeKok wrote: >    The key here is "open discussion"... Some major keys to open discussion is that people avoid ad hominem attacks -- for example, they do not call people liars -- and they avoid hyperbole. For example: >    The failure of SMTP to protect from forgery, malicious bounces, >  etc. is a failure of the security model of SMTP. The security model of SMTP is the same as the security model for sending paper letters and for making phone calls. To "fail" requires that there be a goal that was not attained. That's not the case here. The case here is that real threats changed after 25 years of operation and we need to adjust to them. When crime goes up because a small town becomes a big city, and we have to add locks to our doors, we do not say that the security model that used to work "failed". We say that it changed. The key to open discussion is that people say things thoughtfully and with an attempt to be accurate and precise. d/ -- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker  a t ... www.brandenburg.com From owner-ietf-mxcomp@mail.imc.org Sat Nov 20 14:39:41 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20432 for ; Sat, 20 Nov 2004 14:39:40 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAKJ4nNh069491; Sat, 20 Nov 2004 11:04:49 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAKJ4nKd069490; Sat, 20 Nov 2004 11:04:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from xuxa.iecc.com (xuxa.iecc.com [208.31.42.42]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAKJ4kV2069421 for ; Sat, 20 Nov 2004 11:04:47 -0800 (PST) (envelope-from sb0-0742d5a862-johnl@iecc.com) Received: (qmail 29379 invoked by uid 100); 20 Nov 2004 19:04:43 -0000 Date: 20 Nov 2004 19:04:43 -0000 Message-ID: <20041120190443.29378.qmail@xuxa.iecc.com> From: John Levine To: ietf-mxcomp@imc.org Subject: Re: FTC stuff 0) Lies 1)Yahoo & DK. 2)GoDaddy DNS & SPF & CSV. 3)Dean & FUSSP. 4)Testing 5)EFF, Anonymity. In-Reply-To: <419EE9B5.6030704@elvey.com> Organization: I.E.C.C., Trumansburg NY USA Cc: matthew@elvey.com Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >0)Some lies and misleading statements from Microsoft's Harry Katz (& Ryan): The Microsoft people came to make political statements, not technical ones. It was dismayingly clear that Harry et al have decided that Sender ID's technical failures don't matter. I wouldn't call it lying, perhaps corporately enhanced myopia. >1)Did the Yahoo folks at the FTC conference say that they would be >signing all outbound mail by now, and would be checking incoming mail soon? I just checked and they're signing my free Yahoo mail. >Is the replay problem solved? Until it is, I see no point in deploying >DK or IMM, since they won't work long term. What replay problem? The fact that a recipient MTA can forward a message and not break the signature is a feature, not a bug. If you want to avoid accepting old stale mail, you can always check the header date which DK and IIM should be signing. The point of DK or IIM is to say that the putative author really is the author of a message, and if a recipient remails it, that doesn't change. It does put the onus on message authors to avoid sending mail to recipients who will misuse it, but that's nothing new. The alternative is to take a big gulp of SPF kool-aid and decide that mail forwarding has, after 20 years, stopped being part of the way that SMTP mail works. I hope we don't want to go there. If we want SPF, we all know where to find it. >5)EFF, Anonymity. At last year's FTC spam forum Cindy Cohn, who is otherwise a very smart person, didn't have a clue about e-mail, and it was clear last week that the EFF hasn't learned anything in the meantime. It was pretty telling that Annalee said she sorts through 2000 spams a day by hand and apparently thinks that's a useful way to spend her time. >The folks from the FTC running the conference. They get it. I was >pleasantly surprised. Yes indeed. Too bad the Congress hasn't given them better tools to work with. -- John R. Levine, IECC, POB 727, Trumansburg NY 14886 +1 607 330 5711 johnl@iecc.com, Mayor, http://johnlevine.com, Member, Provisional board, Coalition Against Unsolicited Commercial E-mail From owner-ietf-mxcomp@mail.imc.org Sat Nov 20 17:54:47 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04901 for ; Sat, 20 Nov 2004 17:54:46 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAKMHWQi025109; Sat, 20 Nov 2004 14:17:32 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAKMHWiC025107; Sat, 20 Nov 2004 14:17:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (winserver.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id iAKMHQfr025071 for ; Sat, 20 Nov 2004 14:17:27 -0800 (PST) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.3) for ietf-mxcomp@imc.org; Sat, 20 Nov 2004 17:23:15 -0500 Received: from ([65.2.214.91]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.3) with SMTP id 2864826329; Sat, 20 Nov 2004 17:23:14 -0500 Message-ID: <002401c4cf4e$b259ba00$6401a8c0@hdev1> From: "Hector Santos" To: "IETF-MXCOMP" , "Matthew Elvey" References: <419EE9B5.6030704@elvey.com> Subject: Re: FTC stuff 0) Lies 1)Yahoo & DK. 2)GoDaddy DNS & SPF & CSV. 3)Dean & FUSSP. 4)Testing 5)EFF, Anonymity. Date: Sat, 20 Nov 2004 17:17:10 -0500 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit What is so surprising to me is that its done all right in the open. But then again, that's been the modus operandi of the new Marketing/Campaigning era, "just fib enough times, and people will eventually believe you." It is as Gates said, "a strategy competitive advantage" to have the "spam solution." The key thing here is that Microsoft wants the title for "solving the problem." Of course, open source is part of it. Just read Ballmer's Asian trip statement about the 288 patent violations committed Linux and open source! http://www.pcpro.co.uk/news/66121/ballmers-asian-ip-warning-set-to-backfire. html Coupled with the fact that FireFox just got TV National Headlines yesterday and how its growth is troubling Microsoft, this IP soap opera is just the beginning. http://msnbc.msn.com/id/6462569/ I bet Bill doesn't like MSNBC talking about it. --- Hector Santos WINSERVER "Wildcat! Interactive Net Server" support: http://www.winserver.com sales: http://www.santronics.com ----- Original Message ----- From: "Matthew Elvey" To: "MXCOMP" Sent: Saturday, November 20, 2004 1:52 AM Subject: FTC stuff 0) Lies 1)Yahoo & DK. 2)GoDaddy DNS & SPF & CSV. 3)Dean & FUSSP. 4)Testing 5)EFF, Anonymity. > > My take on the FTC Email Authentication Summit : > 0) Lies > 1)Yahoo & DK. > 2)GoDaddy DNS & SPF & CSV. > 3)Dean & FUSSP. > 4)Testing > 5)EFF, Anonymity. From owner-ietf-mxcomp@mail.imc.org Sat Nov 20 17:54:48 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04919 for ; Sat, 20 Nov 2004 17:54:47 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAKMMNTT026417; Sat, 20 Nov 2004 14:22:23 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAKMMN2e026412; Sat, 20 Nov 2004 14:22:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (ntbbs.santronics.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id iAKMMLoJ026382 for ; Sat, 20 Nov 2004 14:22:22 -0800 (PST) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.3) for ietf-mxcomp@imc.org; Sat, 20 Nov 2004 17:28:22 -0500 Received: from ([65.2.214.91]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.3) with SMTP id 2865133438; Sat, 20 Nov 2004 17:28:21 -0500 Message-ID: <002d01c4cf4f$69648d60$6401a8c0@hdev1> From: "Hector Santos" To: "MXCOMP" References: <20041120143305.B42C416CC3@mail.nitros9.org> Subject: Re: FTC stuff 0) Lies 1)Yahoo & DK. 2)GoDaddy DNS & SPF & CSV. 3)Dean & FUSSP. 4)Testing 5)EFF, Anonymity. Date: Sat, 20 Nov 2004 17:19:11 -0500 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Alan DeKok" To: "MXCOMP" Sent: Saturday, November 20, 2004 9:33 AM Subject: Re: FTC stuff 0) Lies 1)Yahoo & DK. 2)GoDaddy DNS & SPF & CSV. 3)Dean & FUSSP. 4)Testing 5)EFF, Anonymity. > > The failure of SMTP to protect from forgery, malicious bounces, > etc. is a failure of the security model of SMTP. Until that's > analysed and fixed, all of the proposed schemes are band-aids. Hear! Hear! So when do we start cleaning up SMTP? --- Hector Santos WINSERVER "Wildcat! Interactive Net Server" support: http://www.winserver.com sales: http://www.santronics.com From owner-ietf-mxcomp@mail.imc.org Sat Nov 20 17:56:04 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05000 for ; Sat, 20 Nov 2004 17:56:04 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAKMRXXY028281; Sat, 20 Nov 2004 14:27:33 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAKMRXuQ028279; Sat, 20 Nov 2004 14:27:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAKMRWiW028253 for ; Sat, 20 Nov 2004 14:27:32 -0800 (PST) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 3352B16D00 for ; Sat, 20 Nov 2004 17:38:57 -0500 (EST) From: "Alan DeKok" To: MXCOMP Subject: Re: FTC stuff 0) Lies 1)Yahoo & DK. 2)GoDaddy DNS & SPF & CSV. 3)Dean & FUSSP. 4)Testing 5)EFF, Anonymity. In-Reply-To: Your message of "Sat, 20 Nov 2004 07:59:39 PST." <2004112075939.373626@bbfujip> Date: Sat, 20 Nov 2004 17:38:56 -0500 Message-Id: <20041120223857.3352B16D00@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dave Crocker wrote: > Some major keys to open discussion is that people avoid ad hominem > attacks -- for example, they do not call people liars -- and they > avoid hyperbole. For example: To quote: http://www1.ietf.org/mail-archive/web/asrg/current/msg10826.html > you want to change the nature of the infrastructure. you want to > redefine established terminology. http://www1.ietf.org/mail-archive/web/asrg/current/msg10855.html > In professional fora, it is entirely inappropriate to make assertions > about other people's desires, capabilities, and the like. Both of the above quotes are from the same person. I have little reason to defend myself from accusations made by someone who is guilty of exactly the same behavior he is accusing others of. That kind of double standard in this area has been a considerable source of frustration to many people I've talked with off-line. Most of them, however, are unwilling to publicly rock the boat by saying things like "SMTP is imperfect", for fear of getting attacked. > >    The failure of SMTP to protect from forgery, malicious bounces, > >  etc. is a failure of the security model of SMTP. > > The security model of SMTP is the same as the security model for > sending paper letters and for making phone calls. For one, you haven't explain why. Statements of belief aren't statements of fact. At the minimum, SMTP is electronic while paper mail is not, so from that information alone, the security models MUST be different. For two, phone calls don't have "malicious bounces", so I'm confused why the security models for SMTP and telephones would be the same. For three, my statement was talking about failures of a model, not about comparisons with other models. Claiming that SMTP has the same security model as something else is nice, but not really relevant to the issue thar the security model of SMTP has had demonstratable failures. > To "fail" requires that there be a goal that was not attained. > That's not the case here. The case here is that real threats changed > after 25 years of operation and we need to adjust to them. i.e. the goal of SMTP has expanded: to protect from new threats, which were previously minimal, or unknown. SMTP as it was designed 10 years ago has failed to reach these new goals. This isn't surprising. As you point out, it was never intended to reach those goals. That doesn't change the fact that the security model of SMTP has failed, and continues to fail, to protect from attacks which it was never intended to deal with. This shouldn't be news. It shouldn't be a sore point, either. The important thing now is to decide WHY the model failed, and HOW it failed. Without that information, it will be impossible to fix it. > The key to open discussion is that people say things thoughtfully > and with an attempt to be accurate and precise. That's half the battle. The other half is that people hearing those statements listen to them, and respond thoughtfully to their content. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Sat Nov 20 18:03:10 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05510 for ; Sat, 20 Nov 2004 18:03:09 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAKMc2RZ031477; Sat, 20 Nov 2004 14:38:02 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAKMc2WX031476; Sat, 20 Nov 2004 14:38:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (mail.winserver.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id iAKMc1q8031462 for ; Sat, 20 Nov 2004 14:38:02 -0800 (PST) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.3) for ietf-mxcomp@imc.org; Sat, 20 Nov 2004 17:44:05 -0500 Received: from ([65.2.214.91]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.3) with SMTP id 2866075672; Sat, 20 Nov 2004 17:44:03 -0500 Message-ID: <004801c4cf51$9afd5210$6401a8c0@hdev1> From: "Hector Santos" To: "Dave Crocker" , "Alan DeKok" , "MXCOMP" References: <2004112075939.373626@bbfujip> Subject: Re: FTC stuff 0) Lies 1)Yahoo & DK. 2)GoDaddy DNS & SPF & CSV. 3)Dean & FUSSP. 4)Testing 5)EFF, Anonymity. Date: Sat, 20 Nov 2004 17:37:59 -0500 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit And with all due respect for your credentials and expertise, I have a problem grasping your philosophy and analogies. Phone and Snail Mail actually has better security than SMTP. POTS enjoys "real" caller-id technology and snail mail atleast as a "permit" system and "official" delivery entity in place. I guess that makes me 'stupid' in your eyes, I guess that makes me "un-informed" in your view, I guess that makes me well, not worth hearing out. That's how I see it played out in the IETF "arena." Look, it is a SMTP problem and the SOLUTION is at SMTP. Either you change it, clean it up or you don't. Can't expect chaos and hence, a propensity to stability to occur unless the target audience is forced to adapt as well. I apologize for my tone if viewed the wrong way, but this attitude has been what's keep the required R&D for SMTP "3821" to materialized. Where the hell is John Klensin? That is has been the biggest disappointment to me as an "greenie" (not to be construed as inexperience) in IETF. The #1 person that should be INVOLVED in any SMTP related discussion hasn't set foot in the WG - then and now. He gave me his reasons privately. Now explained that? I even suggested that he pass the torch to someone who can sincerely champion the next era of Email and SMTP development. Obviously, its a struggle for some in IETF let go. Sorry Sincerely, Hector Santos, CTO Santronics Software, Inc. http://www.santronics.com 305-431-2846 Cell 305-248-3204 Office ----- Original Message ----- From: "Dave Crocker" To: "Alan DeKok" ; "MXCOMP" Sent: Saturday, November 20, 2004 10:59 AM Subject: Re: FTC stuff 0) Lies 1)Yahoo & DK. 2)GoDaddy DNS & SPF & CSV. 3)Dean & FUSSP. 4)Testing 5)EFF, Anonymity. On Sat, 20 Nov 2004 09:33:05 -0500, Alan DeKok wrote: > The key here is "open discussion"... Some major keys to open discussion is that people avoid ad hominem attacks -- for example, they do not call people liars -- and they avoid hyperbole. For example: > The failure of SMTP to protect from forgery, malicious bounces, > etc. is a failure of the security model of SMTP. The security model of SMTP is the same as the security model for sending paper letters and for making phone calls. To "fail" requires that there be a goal that was not attained. That's not the case here. The case here is that real threats changed after 25 years of operation and we need to adjust to them. When crime goes up because a small town becomes a big city, and we have to add locks to our doors, we do not say that the security model that used to work "failed". We say that it changed. The key to open discussion is that people say things thoughtfully and with an attempt to be accurate and precise. d/ -- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... www.brandenburg.com From owner-ietf-mxcomp@mail.imc.org Sat Nov 20 21:14:20 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16916 for ; Sat, 20 Nov 2004 21:14:19 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAL1cKsZ092546; Sat, 20 Nov 2004 17:38:20 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAL1cKYG092545; Sat, 20 Nov 2004 17:38:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAL1cKil092538 for ; Sat, 20 Nov 2004 17:38:20 -0800 (PST) (envelope-from dotis@mail-abuse.org) Received: from [192.168.2.41] (adsl-64-142-13-68.sonic.net [64.142.13.68]) (authenticated bits=0) by a.mail.sonic.net (8.12.11/8.12.11) with ESMTP id iAL1cPpW002379 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 20 Nov 2004 17:38:26 -0800 Subject: Re: People issues From: Douglas Otis To: Greg Connor Cc: MARID In-Reply-To: <727385.1100812398@[192.168.0.2]> References: <1100807646.2905.117.camel@localhost.localdomain> <727385.1100812398@[192.168.0.2]> Content-Type: text/plain Message-Id: <1101000916.13998.77.camel@bash.adsl-64-142-13-68> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Sat, 20 Nov 2004 17:35:16 -0800 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2004-11-18 at 21:13, Greg Connor wrote: > Thanks Doug. Good information. I do hope the IETF continues to work on > the issues MARID tried to address. > > --Douglas Otis wrote: > > > Here is an interesting presentation that predates MARID. Of course I > > have favorite slides, and could do better, but the topics covered > > represent ongoing concerns. > > > > http://www.ietf.org/proceedings/02mar/slides/plenary-3/ Greg, You are welcome. There were many things within this presentation that I found showed insight. I should have opened more threads, as example. The last point, however, was perhaps the most salient. "Know what problem you're solving." Path Registration records are not a rigorous means for mailbox-domain authentication. Client authorization does not authenticate the source as the mailbox-domain. Such Path Registration schemes may inappropriately place accountability upon some mailbox-domain, when the accountable source is not authenticated, but is only authorized and remains nameless. Path Registration is not suitable for the purpose of security, enforcement, or reputation assertion. What specific issue was MARID trying to address? -Doug From owner-ietf-mxcomp@mail.imc.org Sun Nov 21 03:02:56 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21593 for ; Sun, 21 Nov 2004 03:02:55 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAL7IH2A012940; Sat, 20 Nov 2004 23:18:17 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAL7IHJa012939; Sat, 20 Nov 2004 23:18:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sb7.songbird.com (sb7.songbird.com [208.184.79.137]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAL7ICUf012879 for ; Sat, 20 Nov 2004 23:18:12 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbfujip (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11/8.12.11) with SMTP id iAL7I7oX008312; Sat, 20 Nov 2004 23:18:12 -0800 From: Dave Crocker To: Alan DeKok , MXCOMP X-Mailer: PocoMail 3.2 (2000) - Licensed Version X-URL: brandenburg.com Reply-To: Dave Crocker Date: Sat, 20 Nov 2004 23:18:21 -0800 Message-ID: <20041120231821.120205@bbfujip> In-Reply-To: <20041120223857.3352B16D00@mail.nitros9.org> Subject: Re: FTC stuff 0) Lies 1)Yahoo & DK. 2)GoDaddy DNS & SPF & CSV. 3)Dean & FUSSP. 4)Testing 5)EFF, Anonymity. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sat, 20 Nov 2004 17:38:56 -0500, Alan DeKok wrote: > > Some major keys to open discussion is that people avoid ad hominem > > attacks -- for example, they do not call people liars -- and they > > avoid hyperbole.  For example: > >    To quote: >   > you want to change the nature of the infrastructure. you want to >   > redefine established terminology. >   > In professional fora, it is entirely inappropriate to make assertions >   > about other people's desires, capabilities, and the like. It's difficult to imagine your believing that either of these two statements is on a par with calling someone a liar. (Please note that the latter of the two statements you cite was, in fact, taking exception to a posting that also had indulged in ad hominem attack.) So I'll guess that you are assessing them as hyperbole. Again, it is difficult to understand how you consider either of the above statements to be hyperbole, on a par with calling a service that operated well for 25 years to suddenly be "broken" or to be a "failure". >  things like "SMTP is imperfect", for fear of getting attacked. The semantic difference between "imperfect" and "failure" is considerable. Diligent consultation with a competent dictionary is encouraged. Freewheeling use of inaccurate and excessive language is, indeed, a hallmark of public discussion about spam and anti-spam techniques. My point is that it prevents constructive discussion. > > The security model of SMTP is the same as the security model for > > sending paper letters and for making phone calls. > >    For one, you haven't explain why.   For example, senders are not required to identify themselves in any of those systems. Anonymous or misrepresented authorship is easy and common for all of them. >   At the minimum, SMTP is electronic while paper >  mail is not, so from that information alone, the security models MUST >  be different. Well that certainly is an interesting assertion. I can't imagine what makes it automatically true. >    For two, phone calls don't have "malicious bounces", so I'm confused >  why the security models for SMTP and telephones would be the same. Discussing why a popular security model might have serious inadequacies for a new environment is, of course, entirely reasonable. But that's not what you are doing. >    For three, my statement was talking about failures of a model, not When you referred to SMTP you said nothing about a "model", nevermind a security model. To the extent that you really meant to refer to a particular security model, then by all means please state that, rather than broadly describing that a long-standing, well-functioning protocol as a "failure". >  about comparisons with other models. Claiming that SMTP has the same >  security model as something else is nice, but not really relevant to >  the issue thar the security model of SMTP has had demonstratable >  failures. When messing around with global infrastructures, it is typically viewed as useful to worry a great deal about the base of experience with the model being used for that service and the model being proposed. In that light, knowing that the existing model has extensive use in other global infrastructures is important. When you succinctly describe the proposed new model, you will discover that it has essentially no base of experience in a large scale. On the average, it is considered important to worry about the impact of changes to a communication service, since the ability to communicate is usually taken as rather important for various aspects of human life. So, for example, terminating the ability to communicate anonymously would have rather serious political ramifications. >    SMTP as it was designed 10 years ago has failed to reach these new 23 years ago. But really 32 years ago, since smtp is an evolution of the original ftp mail command. >    This shouldn't be news.  It shouldn't be a sore point, either. The sore point is not the limitations of SMTP. The sore point is sloppy, inaccurate hyperbole. >    The important thing now is to decide WHY the model failed, and HOW >  it failed.  Without that information, it will be impossible to fix it. It's unfortunate that you do see neither the formal incorrectness of the term "failed" nor the absence of substantive contributions about the nature of the changed threat and security models. d/ -- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker  a t ... www.brandenburg.com From owner-ietf-mxcomp@mail.imc.org Sun Nov 21 19:39:52 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10159 for ; Sun, 21 Nov 2004 19:39:51 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iALNhBkD081376; Sun, 21 Nov 2004 15:43:11 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iALNhBOM081375; Sun, 21 Nov 2004 15:43:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iALNh0nw081169 for ; Sun, 21 Nov 2004 15:43:03 -0800 (PST) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 5151216D00 for ; Sun, 21 Nov 2004 18:54:21 -0500 (EST) From: "Alan DeKok" To: MXCOMP Subject: Re: FTC stuff 0) Lies 1)Yahoo & DK. 2)GoDaddy DNS & SPF & CSV. 3)Dean & FUSSP. 4)Testing 5)EFF, Anonymity. In-Reply-To: Your message of "Sat, 20 Nov 2004 23:18:21 PST." <20041120231821.120205@bbfujip> Date: Sun, 21 Nov 2004 18:54:21 -0500 Message-Id: <20041121235421.5151216D00@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dave Crocker wrote: > When you referred to SMTP you said nothing about a "model", nevermind > a security model. You mean this message, which you both read and responded to within the last 24 hours: http://www.imc.org/ietf-mxcomp/mail-archive/msg05265.html > The failure of SMTP to protect from forgery, malicious bounces, > etc. is a failure of the security model of SMTP. My politest response is "You, sir, appear to be mistaken". > Again, it is difficult to understand how you consider either of the > above statements to be hyperbole, I don't consider them hyperbole. You have, by your own standards engaged in ad hominems towards me. Yet when I repeated those phrase back to you, it's me that you labeled unprofessional. The word "hyperbole" isn't applicable here. Another word starting with "hyp" is. > on a par with calling a service that operated well for 25 years to > suddenly be "broken" or to be a "failure". The phrase I've used is "SMTP fails to..", not "SMTP is a failure". The difference is crucial. The terms "fails to" and "broken" are well-known, and widely used in the security industry. e.g. "With the advent of cheap computing hardware, DES fails to provide adequate security for message traffic. We suggest using AES". Or, "With the advent of recent attacks, MD5 has been broken, or very nearly so." http://www.google.com/search?hl=en&lr=&q=md5+broken&btnG=Search Which points to multiple links titled "MD5 broken". If the authors of MD5 had responded to those attacks with "A system in wide use for many years cannot be properly described as 'broken'.", they would have been laughed off of the planet. http://www.google.com/search?hl=en&lr=&q=%22DES+fails+to%22+cryptography&btnG=Search Which points to an article containing the phrase "People understand that DES fails to provide strong data confidentiality". Maybe SMTP is magic, and normal security terminology is inapplicable here. But I don't think that's true. > When you succinctly describe the proposed new model, you will > discover that it has essentially no base of experience in a large > scale. The word you're looking for is "encompasses". As in "The new model of general relativity encompasses the old model of Newtonian physics". One goal behind creating a new model is to include all, or almost all of the old model. This automatically gives the new model a large-scale base of experience. Further, the reason for moving to a new model is that there is a large base of experiences/data which are known today, which aren't explained by the old model. The new model can explain them, giving it an even larger base of experience than the old model. Science has worked this way for hundreds of years. These model development methods have also been demonstrated to be applicable to many engineering fields, but are apparently not applicable SMTP. > It's unfortunate that you do see neither the formal incorrectness of > the term "failed" nor the absence of substantive contributions about > the nature of the changed threat and security models. I've already dealt with the first part of that phrase. As for the second part, if my attempts to contribute to the field are so blatantly absent or incompetent, there would be no need to put effort into marginalizing me and my position. You could just sit back, and wait for everyone to realize for themselves that I'm an idiot. But the sheer effort put into marginalizing me exposes the reality behind the concept that I have nothing to contribute. > The sore point is not the limitations of SMTP. The sore point is > sloppy, inaccurate hyperbole. I may know less than you about SMTP, but I do know when I'm being bushwacked. Your attempts to stop my use of industry standard terms and practices are duly noted. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Sun Nov 21 22:38:41 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25849 for ; Sun, 21 Nov 2004 22:38:41 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAM34nw9015270; Sun, 21 Nov 2004 19:04:49 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAM34neY015269; Sun, 21 Nov 2004 19:04:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAM34k08014907 for ; Sun, 21 Nov 2004 19:04:46 -0800 (PST) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CW4VP-0003fC-00 for ; Mon, 22 Nov 2004 04:04:43 +0100 Received: from 212.82.251.36 ([212.82.251.36]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 22 Nov 2004 04:04:43 +0100 Received: from nobody by 212.82.251.36 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 22 Nov 2004 04:04:43 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: FTC stuff 0) Lies 1)Yahoo & DK. 2)GoDaddy DNS & SPF & CSV. 3)Dean & FUSSP. 4)Testing 5)EFF, Anonymity. Date: Mon, 22 Nov 2004 03:50:45 +0100 Organization: Lines: 48 Message-ID: <41A15405.44E7@xyzzy.claranet.de> References: <419EE9B5.6030704@elvey.com> <20041120190443.29378.qmail@xuxa.iecc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.36 X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit John Levine wrote: > The alternative is to take a big gulp of SPF kool-aid The name of this beast is "reverse-path" in STD 10. > decide that mail forwarding has, after 20 years, stopped > being part of the way that SMTP mail works | 251 User not local; will forward to [...] | The receiver takes responsibility for delivering the | message. Followed later by: | The first host in the should be the host | sending this command. > I hope we don't want to go there. That's your decision. I stick to the essence of STD 10. The receiver is free to take the bounces (e.g. using SRS), or he can reject my mail with 551. But he should not say MAIL FROM: if it's actually MAIL FROM:<@receiver,me>. The decision to break forwarding after 20 years is a side- effect of RfC 2821. Just like open relays it has to stop now. The spammers found this loophole: "Hey, we can say whatever we want in MAIL FROM after the real meaning of a was lost in cyberspace". > If we want SPF, we all know where to find it. Yes, RfC 2821 broke it, SPF "-all" fixes it. BATV is an alternative, it cures many symptoms of the same problem. Sure, RfC 2821 only documented the loss of a real STD 10 , and _that_ broke it almost beyond repair. SPF "-all" can patch it for those who want it. Like me. > the EFF hasn't learned anything in the meantime. That's putting it very mildly. Let them join forces with the DMA or whatever comes next. Bye, Frank From owner-ietf-mxcomp@mail.imc.org Sun Nov 21 23:48:55 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00809 for ; Sun, 21 Nov 2004 23:48:55 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAM4I2Cm014497; Sun, 21 Nov 2004 20:18:02 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAM4I2gt014496; Sun, 21 Nov 2004 20:18:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tom.iecc.com (tom.iecc.com [208.31.42.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAM4I1s4014464 for ; Sun, 21 Nov 2004 20:18:01 -0800 (PST) (envelope-from sb0-0744b3a4bd-johnl@iecc.com) Received: (qmail 10899 invoked from network); 22 Nov 2004 04:18:07 -0000 Received: (ofmipd 127.0.0.1); 22 Nov 2004 04:17:45 -0000 Date: 21 Nov 2004 23:18:07 -0500 Message-ID: From: "John R Levine" To: ietf-mxcomp@imc.org Subject: Re: path routing Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >The receiver is free to take the bounces (e.g. using SRS), >or he can reject my mail with 551. But he should not say >MAIL FROM: if it's actually MAIL FROM:<@receiver,me>. Oh, wow, path routes. There's a quixotic quest. There are two problems with path routes. The first is that path routes never did what you're proposing. The second is that they were always a band-aid, not a feature. If you read page 21 of RFC821, it says that if the sender uses a source route, as the message is relayed, the hosts are moved from the forward path to the reverse path, e.g.: MAIL FROM: RCPT TO:<@bar,@cow:@z@zoo> MAIL FROM:<@bar:a@foo> RCPT TO:<@cow:@z@zoo> MAIL FROM:<@cow,@bar:a@foo> RCPT TO: It most definitely does NOT say that if one of the relays replaces the recipient address with a new address that it should hang a reverse path on the return address. As I understand it (and I'm sure Dave C will correct me if I'm wrong) the reason reverse paths appear in 821 is that the DNS was new, and MX records were far from universal. The net wasn't (and isn't) fully connected, and in lacking MX, you just had to know that the only way to get mail to one host was through another host that happened to have a gateway, with path routes being a way to force the mail to the gateway host. Once the gateways were all documented by MX records, path routes became useless, which is why they're gone from 2821. Moreover, even if you did put a route into a return path, what do you propose to do with it? Unless forwarding hosts remember every piece of mail they've ever forwarded, they're not going to be able to tell virtuous bounces actually returning along a previously used path from random spam and blowback that happens to have scraped that route from somewhere. If you want to validate a route, you have to encode some sort of signature in them, and I have my doubts about the practicality even of that. >Yes, RfC 2821 broke it, SPF "-all" fixes it. BATV is an >alternative, it cures many symptoms of the same problem. Huh? BATV does some swell things, but routing is not one of them. From owner-ietf-mxcomp@mail.imc.org Mon Nov 22 04:44:00 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06249 for ; Mon, 22 Nov 2004 04:43:59 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAM8uxkp047324; Mon, 22 Nov 2004 00:56:59 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAM8ux5u047321; Mon, 22 Nov 2004 00:56:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAM8uudF047270 for ; Mon, 22 Nov 2004 00:56:57 -0800 (PST) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CWA0G-0006St-00 for ; Mon, 22 Nov 2004 09:56:56 +0100 Received: from c-134-88-46.hh.dial.de.ignite.net ([62.134.88.46]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 22 Nov 2004 09:56:56 +0100 Received: from nobody by c-134-88-46.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 22 Nov 2004 09:56:56 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: path routing Date: Mon, 22 Nov 2004 09:55:19 +0100 Organization: Lines: 58 Message-ID: <41A1A976.483D@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-134-88-46.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit John R Levine wrote: > Oh, wow, path routes. There's a quixotic quest. As far as current Internet Standards are quixotic: | the reverse-path is a return route (which may be used to | return a message to the sender when an error occurs with | a relayed message). They didn't invent 551 only for the fun of more error codes. > It most definitely does NOT say that if one of the relays > replaces the recipient address with a new address that it > should hang a reverse path on the return address. It does in 3.1 MAIL: | It gives the reverse-path which can be used to report errors. [...] | The can contain more than just a mailbox. The | is a reverse source routing list of hosts and | source mailbox. The first host in the should | be the host sending this command. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > the DNS was new, and MX records were far from universal. Sure, and they had no spam and no forged MAIL FROM addresses. > in lacking MX, you just had to know that the only way to get > mail to one host was through another host that happened to > have a gateway If you'd say that forwarding from one MX to another unrelated MX is a waste of resources and bandwidth, then I won't disagree. > Once the gateways were all documented by MX records, path > routes became useless, which is why they're gone from 2821. As we see that was a dangerous error, it created the loophole, now fixed by SPF / RMX / BATV / SES / etc. as far as possible. > Unless forwarding hosts remember every piece of mail they've > ever forwarded, they're not going to be able to tell virtuous > bounces actually returning along a previously used path from > random spam and blowback that happens to have scraped that > route from somewhere. If they don't know how to handle it they shouldn't forward the mail, but reject it with 551 or a simple "user unkown". It's the problem of the receiver to get it right. > BATV does some swell things, but routing is not one of them. It allows to identify bogus bounces caused by forged MAIL FROM addresses, doesn't it ? Bye, Frank From owner-ietf-mxcomp@mail.imc.org Mon Nov 22 17:34:30 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29518 for ; Mon, 22 Nov 2004 17:34:30 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAMLmi8O042104; Mon, 22 Nov 2004 13:48:44 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAMLmipZ042103; Mon, 22 Nov 2004 13:48:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAMLmfn4042001 for ; Mon, 22 Nov 2004 13:48:44 -0800 (PST) (envelope-from dean@av8.com) Received: from dakota.av8.net (dakota.av8.net [130.105.19.131]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id iAMLm3s6027716 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 22 Nov 2004 16:48:07 -0500 Date: Mon, 22 Nov 2004 16:48:03 -0500 (EST) From: Dean Anderson X-X-Sender: dean@localhost.localdomain To: "Hallam-Baker, Phillip" cc: "'ThomasGal@LumenVox.com'" , "'Harry Katz'" , "'IETF MARID WG'" Subject: RE: Status of MARID WG? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 17 Nov 2004, Hallam-Baker, Phillip wrote: > > > > All you need is two interoperable implementations and a userbase > > > noticable to the IETF. The fact that 98% of the users of > > the internet > > > will never use it directly or indirectly does not matter. > > > > The "userbase noticable" isn't requirement of the RFC > > process. The IETF > > doesn't standardize based on popularity, but on consensus. > > Consensus amongst a community that is 100% atypical of the Internet users. Sure, the consensus among network engineers and scientists. Sure they aren't typical of internet users. Phone engineers are atypical of phone users. Auto engineers are atypical of auto drivers, too. But who do you want making decisions at the Department of Transportation or running the engineering department at a car company? Some guy who really loves his Mini Cooper, and thinks dump trucks and other cars should be banned, and argues that since most people don't need dump trucks, that they should be banned? Does being a car driver (or passenger) qualify one for a decision-making role in transportation? Of course not. I'm not so concerned about the selection of decision makers and leaders from the technical community, so much as I'm concerned about whether the decision makers selected actually represent the technical community, rather than a certain small group in the community. It always seems that some are not held to obey the rules, and that some seem to view the IETF as a private club. > Each time I vist the IETF the proportion of members who are unashamed > technologist supremacists rises. There is no embarassment about developing > systems that ordinary users cannot make use of. Technology is sometimes obscure. New technology is sometimes even more obscure. Most people can't make use of SS7, either. But you wouldn't be making as many phone calls without it. > > > Nobody in the IETF is elected, nobody is accountable. The inevitable > > > consequence of that situation is that nothing that the IETF does can > > > ever rise above the level of a personal opinion. > > > > This is also not true. It may appear this way from time to > > time, but it isn't literally true. > > It is literaly true that nobody is elected. All appointments are through a > selection committee that is explicitly non-representative and > non-accountable. The process is somewhat opaque alright. And it resembles more of a private club than an public service organ or NGO or standards body. But nominations imply elections however informal or exclusive the consensus is. The process could be much better, and more open, and otherwise greately improved--absolutely,I'm on board that wagontrain. But its an exaggeration to say that there is no democratic process whatsoever. There is a fundamental concept of democracy and consensus to the IETF. Its just insufficient and flawed. Most standards organizations have a membership concept, and /all/ members get to vote on certain things. > I would be surprised if Microsoft did use Bayesian inference, they are not > the best tool for their corpus by a very long way. In the presentation I > heard the presenter said that they used a huge number of rules and > constantly re-evaluated both the ones that were most effective and the ways > in which relative weights were combined. Right. "Combining relative weights" sounds very much like Bayes rule. > > I've done some work applying information theory to spam, and > > have discovered that there is no ultimate solution to spam. > > Now there is an interesting statement. Whayt if the solution does not exist > in information theory? > > > But there is a nomination process for the IETF chairman, and members > > of the IAB. The IETF is also an activity of ICANN, > > No it isn't. I mis-spoke, my apologies. The IETF is an activity of ISOC, which has incorporation, rules, elections and bylaws. http://www.isoc.org/isoc/ > And no, a nomination process does not an accountability mechanism make. It is a matter of degree. But I agree that it is insufficient. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From owner-ietf-mxcomp@mail.imc.org Tue Nov 23 11:10:16 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25713 for ; Tue, 23 Nov 2004 11:10:16 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iANFMFii022278; Tue, 23 Nov 2004 07:22:15 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iANFMFlB022277; Tue, 23 Nov 2004 07:22:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (mail.santronics.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id iANFME9P022259 for ; Tue, 23 Nov 2004 07:22:15 -0800 (PST) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.3) for ietf-mxcomp@imc.org; Tue, 23 Nov 2004 10:28:17 -0500 Received: from ([65.2.214.91]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.3) with SMTP id 3099127516; Tue, 23 Nov 2004 10:28:15 -0500 Message-ID: <006101c4d170$336eac90$6401a8c0@hdev1> From: "Hector Santos" To: "MXCOMP" References: <20041120231821.120205@bbfujip> Subject: A new SMTP "3821" [Re: FTC stuff...........] Date: Tue, 23 Nov 2004 10:22:02 -0500 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Dave Crocker" To: "Alan DeKok" ; "MXCOMP" Sent: Sunday, November 21, 2004 2:18 AM Subject: Re: FTC stuff 0) Lies 1)Yahoo & DK. 2)GoDaddy DNS & SPF & CSV. 3)Dean & FUSSP. 4)Testing 5)EFF, Anonymity. > > For three, my statement was talking about failures of a model, not > When you referred to SMTP you said nothing about a "model", > nevermind a security model. To the extent that you really > meant to refer to a particular security model, then by all means > please state that, rather than broadly describing that a long-standing, > well-functioning protocol as a "failure". We all know that SMTP has not been a failure. What Alan is suggesting, for which I strongly agree, is that the focus in solving the "problem" needs a revisiting of the SMTP model or more specifically, the functional specification. We have tried to "plug in" ideas that simply fail to account for the entire MODEL for not only maximum compliancy but for productive and maximum adaptability. In some cases, we attempted to plug in concepts that simply doesn't fit or is out of place. Just consider this one very simple realistic fact: A system that employs stronger SMTP compliancy enjoys a higher SMTP level protection against abuse. We have more than 1 year of steady on-going Anti-Spoof technology in place with a consistent result on a day to day, month to month basis. A simple emphasis on compliancy will provide you atleast a 60-90% solution. I can't dispute these. These are the hard core empirical facts. The point? The majority of the problem is solved by concentrating at enforcing a new level of "proper" operations. We need to get over the "silly" arguments about what "MAIL FROM:" means. We know what it means because its been operating in a consistent DEFINED way for decades. We need to be consistent. If we discuss functional SMTP design flows for system notifications which is based on the expectation that the return path is "usable" then we need to stop with idiotic suggestions that the return path is only "usable" at the point is it required - a system notification, and not before then. We need to make sure the specifications makes it very CLEAR that the RETURN PATH is expected to be valid, regardless of who it points too when it is initially issued. The idea of how a particular system may which to implement that is an independent idea. It has nothing to do with the validity of it. Now, can we improve SMTP to better describe what the RETURN PATH is? user, system, some list or whatever? Sure, but what is common in all, is that its a valid address. Can we add new commands to help a "new process?" I think so. But we need to first look at what are the "holes" or factors that are "missing" to help define what these commands should be. Do we need to consider future payload transaction protocol methods? Sure, I strongly think so. This is one area I felt very strongly that didn't not help Sender-ID, it failed to 100% recognize the payload issue and how important that is. But I personally see the payload issue in a bigger concept than just for security, but for efficiency. This is the kind of SMTP R&D WG discussion that needs to take place. I doubt this can happen in IETF-SMTP. The type of people and attitude is just wrong for it. We need new open minded people who can think out of the "box", and also understand the issues, and then with the help of the 'experts" like yourself, help bring it all back together. What we don't need is are show stoppers who nix everything right at the start. Once we get a consistent understanding of the issues with SMTP at each step, removing the ambiguities, adding/merging BCP concepts/RFCs for "today" operations, then we have a basis, an baseline, a framework to begin implementing "Security Plug-ins" that will not only work better, but make sense. This may all sound simplistic to you, but that is what we need; getting back to basics, taking a step back in the balcony. The #1 improvement we can make or the IETF can make is a major cleanup of the 2821 and related specifications as one new document. Sincerely, Hector Santos, CTO Santronics Software, Inc. http://www.santronics.com 305-431-2846 Cell 305-248-3204 Office From owner-ietf-mxcomp@mail.imc.org Tue Nov 23 11:55:12 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29693 for ; Tue, 23 Nov 2004 11:55:12 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iANGN3O2041058; Tue, 23 Nov 2004 08:23:03 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iANGN3up041057; Tue, 23 Nov 2004 08:23:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iANGN2IT041038 for ; Tue, 23 Nov 2004 08:23:02 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id iANGMw9X004961; Tue, 23 Nov 2004 08:22:58 -0800 (PST) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Tue, 23 Nov 2004 08:22:58 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Dean Anderson'" , "Hallam-Baker, Phillip" Cc: "'ThomasGal@LumenVox.com'" , "'Harry Katz'" , "'IETF MARID WG'" Subject: RE: Status of MARID WG? Date: Tue, 23 Nov 2004 08:22:52 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > [mailto:owner-ietf-mxcomp@mail.imc.org] On Behalf Of Dean Anderson > Sure, the consensus among network engineers and scientists. > Sure they aren't typical of internet users. Phone engineers > are atypical of phone users. Auto engineers are atypical of > auto drivers, too. But who do you want making decisions at > the Department of Transportation or running the engineering > department at a car company? I think it is ok for us to take decisions for others, but we have to be willing to understand that their needs and concerns are not the same as ours. There is a difference between a prototype and a product. Unfortunately we have a habbit of inflicting PERL lash up style schemes that are really no more than prototypes onto end users. I spend too much of my time dealling with the technology problems of friends and familly. RTFM is not an acceptable answer here, there should never have been the need for a manual. The only manuals I ever read are the ones that come with safety warnings, things like tables saws, joiners, planers etc. > I'm not so concerned about the selection of decision makers > and leaders from the technical community, so much as I'm > concerned about whether the decision makers selected actually > represent the technical community, rather than a certain > small group in the community. I am starting to get to a clearer explanation of the perception gap I see in standards making. When writing a standard people imagine that they are writing the rules. The problem is that the people who read the standards are looking to find WHAT WORKS, not what is right. I do not do normative ethics, you cannot arrive at an ought from an is. Regardless of what people imagine SHOULD be the situation the fact is that the way standards documents are used is very different from the way people writing them imagine. If we want to get the implementers to produce stuff that complies with the specs we have to make it so that what works and what is right are the same thing. Test suites help close that gap. Designing specs for compatability with actual legacy deployments is another part. > The process is somewhat opaque alright. And it resembles > more of a private club than an public service organ or NGO or > standards body. But nominations imply elections however > informal or exclusive the consensus is. Open and inclusive implies open and inclusive elections. > There is a fundamental concept of democracy and consensus to > the IETF. Its just insufficient and flawed. Most standards > organizations have a membership concept, and /all/ members > get to vote on certain things. If someone wants to trump my opinion in my field of expertise on an issue I believe is critical to the security of the Internet on the basis of an unelected appointment through the old boy club then they are going to have a big fight on their hands. I find it utterly ludicrous that we are on the brink of taking a spec to an alternative working group due to a technical dispute where the pragmatic approach is so clear. If people don't want a fight then the answer is clear, give me an alternative way to deploy MASS that does not create a dependency on the deployment of new DNS infrastructure. The dependency is real and it is neither necessary nor even advantageous. > Right. "Combining relative weights" sounds very much like Bayes rule. But Bayesian inference makes some assumptions that are not valid for a real corpus, the probabilities are not disjoint and Bayes developed his theory of probability for that area. It's a bit like saying Einstein's cosmology is Euclidean because on almost any terrestrial measurable scale it approximates to the same thing, but the whole point is that Einsten's cosmology is non-Euclidean. From owner-ietf-mxcomp@mail.imc.org Tue Nov 23 12:39:43 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02391 for ; Tue, 23 Nov 2004 12:39:39 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iANHA1oe054806; Tue, 23 Nov 2004 09:10:01 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iANHA1sN054805; Tue, 23 Nov 2004 09:10:01 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iANHA0BJ054769 for ; Tue, 23 Nov 2004 09:10:01 -0800 (PST) (envelope-from andy@hxr.us) Received: from [192.168.1.108] ([::ffff:63.240.221.237]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Tue, 23 Nov 2004 12:10:01 -0500 id 000B40E9.41A36EE9.0000634B Received-SPF: unknown (Address does not pass the Sender Policy Framework) SPF=HELO; sender=[192.168.1.108]; remoteip=::ffff:63.240.221.237; remotehost=; helo=[192.168.1.108]; receiver=zak.ecotroph.net; Received-SPF: fail (Address does not pass the Sender Policy Framework) SPF=MAILFROM; sender=andy@hxr.us; remoteip=::ffff:63.240.221.237; remotehost=; helo=[192.168.1.108]; receiver=zak.ecotroph.net; In-Reply-To: <006101c4d170$336eac90$6401a8c0@hdev1> References: <20041120231821.120205@bbfujip> <006101c4d170$336eac90$6401a8c0@hdev1> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=sha1; protocol="application/pkcs7-signature"; boundary="=_zak.ecotroph.net-25419-1101229802-0001-2" Message-Id: <80E256FA-3D72-11D9-92D5-000A95B3BA44@hxr.us> Cc: "MXCOMP" From: Andrew Newton Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] Date: Tue, 23 Nov 2004 12:09:57 -0500 To: "Hector Santos" X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zak.ecotroph.net-25419-1101229802-0001-2 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Nov 23, 2004, at 10:22 AM, Hector Santos wrote: > What Alan is suggesting, for which I strongly agree, is that the focus > in > solving the "problem" needs a revisiting of the SMTP model or more > specifically, the functional specification. That has been and still is the basis for all the disagreements in this area. -andy --=_zak.ecotroph.net-25419-1101229802-0001-2 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGgTCCAzow ggKjoAMCAQICAw05ITANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQxMDEzMjA1ODM1WhcNMDUxMDEzMjA1ODM1WjB7MQ8wDQYDVQQE EwZOZXd0b24xDzANBgNVBCoTBkFuZHJldzEWMBQGA1UEAxMNQW5kcmV3IE5ld3RvbjEjMCEGCSqG SIb3DQEJARYUYW5ld3RvbkBlY290cm9waC5uZXQxGjAYBgkqhkiG9w0BCQEWC2FuZHlAaHhyLnVz MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0XTscSF9lNVyNyq7wCFwEb56C7WBLvAh BaPqdV8oOr5EroTgv+0zUfaP8kYlwavWeSu0XcWIcgd/ymt7PWOd8j/J91Y71cmsSg62gv6dhA8h wzxojj5Vp2x3TYf7dafzoVfhd/7Kzvzu6FqOn9C/9NKtZ0g0hzn6ChcgymCrcoyXQrmQI689sh4o RzIQC+kSPaWkOmA0eqbCpi8ASQfuyEBiXQAATxrBWURp+hzD8YYcnn88S/5Kd4GGMARtwsBR6Moe xF53oAUavRPfiM3ixDunUqgXOQ92noBoc3nIWmxGuLdTZPZgELHX1Q1FMi013PW3tIA9rhZATcIf PF/jOQIDAQABo2EwXzAOBgNVHQ8BAf8EBAMCB4AwEQYJYIZIAYb4QgEBBAQDAgWgMCwGA1UdEQQl MCOBFGFuZXd0b25AZWNvdHJvcGgubmV0gQthbmR5QGh4ci51czAMBgNVHRMBAf8EAjAAMA0GCSqG SIb3DQEBBAUAA4GBAJiErfGNCI9wRF0H8NmkSJCjzaH3yHfv0q1CwyJr6zZhkA2M+GcCoIr12PNP J10XG3WJ/96bLP2SxzFz1FC6CfMN2/XrOn1Su5wRdVBAr7lRkyqco9A7JXaW8rUwOm6DQ20eWZen FJMo/mwzDxgThS9Oyci/ASNT4ej+Yzcyq5kpMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBU b3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSsw KQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAw MFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7s vc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV 84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGR MBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUu Y29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCk HjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oL LswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoL gnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHT HUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAgMNOSEwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDQxMTIzMTcwOTU4WjAjBgkqhkiG9w0BCQQxFgQU6eNCUI2aEwaFav0Xht4a r+XpdrIweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENv bnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElz c3VpbmcgQ0ECAw05ITB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBAgMNOSEwDQYJKoZIhvcNAQEBBQAEggEAPEmoosq8Slbg2nAfvZy0 /H/w7A8IOhUhMttAC33PJ0ReSVJGoUvfFufv/P3U7hZml2FA+wM+1X/t5UaA3U3bQFx7c6K15uDm XK8HbmG+sfocS3K9x4n3ivLp2+SNx77txTpg30KbsmgBQN267JYQ1XpXRrDryoJ037IZzcCsu3K1 opqpb8i6gj6aGIR36fsM547nUs2n5XgJzbgW4GMadZaRd4yo2p7IsR2dGPldiV00IFvjliXIGLX6 G2H/2aM+2Dl7O7UducMGh9LwimBJnN2lfs++Cpey/ODVPBc6p4UAP4ktwZHiddvGuO4kVWI4hiBp 5uBszWXggJMXaNQUqgAAAAAAAA== --=_zak.ecotroph.net-25419-1101229802-0001-2-- From owner-ietf-mxcomp@mail.imc.org Tue Nov 23 12:41:02 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02510 for ; Tue, 23 Nov 2004 12:41:01 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iANHAbFl054918; Tue, 23 Nov 2004 09:10:37 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iANHAb14054917; Tue, 23 Nov 2004 09:10:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from corpmail.verticalresponse.com (corpmail.verticalresponse.com [209.66.113.8]) by above.proper.com (8.12.11/8.12.9) with SMTP id iANHAbQx054910 for ; Tue, 23 Nov 2004 09:10:37 -0800 (PST) (envelope-from jeff@verticalresponse.com) Received: (qmail 32478 invoked from network); 23 Nov 2004 17:10:37 -0000 Received: from h-67-102-227-246.snfccasy.covad.net (HELO JEFF) (67.102.227.246) by corpmail.verticalresponse.com with SMTP; 23 Nov 2004 17:10:37 -0000 Message-ID: <003401c4d17f$584ba220$ab00a8c0@JEFF> From: "Jeff McConathy" To: "Hector Santos" , "MXCOMP" References: <20041120231821.120205@bbfujip> <006101c4d170$336eac90$6401a8c0@hdev1> Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] Date: Tue, 23 Nov 2004 09:10:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Awesome! you must have a better source than me ;) ----- Original Message ----- From: "Hector Santos" To: "MXCOMP" Sent: Tuesday, November 23, 2004 7:22 AM Subject: A new SMTP "3821" [Re: FTC stuff...........] > > > ----- Original Message ----- > From: "Dave Crocker" > To: "Alan DeKok" ; "MXCOMP" > Sent: Sunday, November 21, 2004 2:18 AM > Subject: Re: FTC stuff 0) Lies 1)Yahoo & DK. 2)GoDaddy DNS & SPF & CSV. > 3)Dean & FUSSP. 4)Testing 5)EFF, Anonymity. > > > >> > For three, my statement was talking about failures of a model, not > >> When you referred to SMTP you said nothing about a "model", >> nevermind a security model. To the extent that you really >> meant to refer to a particular security model, then by all means >> please state that, rather than broadly describing that a long-standing, >> well-functioning protocol as a "failure". > > We all know that SMTP has not been a failure. > > What Alan is suggesting, for which I strongly agree, is that the focus in > solving the "problem" needs a revisiting of the SMTP model or more > specifically, the functional specification. We have tried to "plug in" > ideas that simply fail to account for the entire MODEL for not only > maximum > compliancy but for productive and maximum adaptability. In some cases, we > attempted to plug in concepts that simply doesn't fit or is out of place. > > Just consider this one very simple realistic fact: > > A system that employs stronger SMTP compliancy enjoys a higher SMTP level > protection against abuse. > > We have more than 1 year of steady on-going Anti-Spoof technology in place > with a consistent result on a > day to day, month to month basis. A simple emphasis on compliancy will > provide you atleast a 60-90% > solution. I can't dispute these. These are the hard core empirical > facts. > > The point? > > The majority of the problem is solved by concentrating at enforcing a new > level of "proper" operations. > > We need to get over the "silly" arguments about what "MAIL FROM:" means. > > We know what it means because its been operating in a consistent DEFINED > way > for decades. > > We need to be consistent. > > If we discuss functional SMTP design flows for system notifications which > is > based on the expectation that the return path is "usable" then we need to > stop with idiotic suggestions that the return path is only "usable" at the > point is it required - a system notification, and not before then. We > need to make sure the specifications makes it very CLEAR that the RETURN > PATH is expected to be valid, regardless of who it points too when it is > initially issued. The idea of how a particular system may which to > implement that is an independent idea. It has nothing to do with the > validity of it. > > Now, can we improve SMTP to better describe what the RETURN PATH is? > user, > system, some list or whatever? Sure, but what is common in all, is that > its > a valid address. > > Can we add new commands to help a "new process?" > > I think so. But we need to first look at what are the "holes" or factors > that are "missing" to help define what these commands should be. > > Do we need to consider future payload transaction protocol methods? > > Sure, I strongly think so. This is one area I felt very strongly that > didn't not help Sender-ID, it failed to 100% recognize the payload issue > and > how important that is. But I personally see the payload issue in a > bigger > concept than just for security, but for efficiency. > > This is the kind of SMTP R&D WG discussion that needs to take place. I > doubt this can happen in IETF-SMTP. The type of people and attitude is > just > wrong for it. We need new open minded people who can think out of the > "box", and also understand the issues, and then with the help of the > 'experts" like yourself, help bring it all back together. What we don't > need is are show stoppers who nix everything right at the start. > > Once we get a consistent understanding of the issues with SMTP at each > step, > removing the ambiguities, adding/merging BCP concepts/RFCs for "today" > operations, then we have a basis, an baseline, a framework to begin > implementing "Security Plug-ins" that will not only work better, but make > sense. > > This may all sound simplistic to you, but that is what we need; getting > back > to basics, taking a step back in the balcony. > > The #1 improvement we can make or the IETF can make is a major cleanup of > the 2821 and related specifications as one new document. > > Sincerely, > > Hector Santos, CTO > Santronics Software, Inc. > http://www.santronics.com > 305-431-2846 Cell > 305-248-3204 Office > > > > > > > > > From owner-ietf-mxcomp@mail.imc.org Tue Nov 23 12:56:45 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03715 for ; Tue, 23 Nov 2004 12:56:44 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iANHQVRt059426; Tue, 23 Nov 2004 09:26:31 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iANHQVdu059422; Tue, 23 Nov 2004 09:26:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iANHQQOd059404 for ; Tue, 23 Nov 2004 09:26:26 -0800 (PST) (envelope-from andy@hxr.us) Received: from [192.168.1.108] ([::ffff:63.240.221.237]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Tue, 23 Nov 2004 12:26:28 -0500 id 00207509.41A372C5.00006620 Received-SPF: unknown (Address does not pass the Sender Policy Framework) SPF=HELO; sender=[192.168.1.108]; remoteip=::ffff:63.240.221.237; remotehost=; helo=[192.168.1.108]; receiver=zak.ecotroph.net; Received-SPF: fail (Address does not pass the Sender Policy Framework) SPF=MAILFROM; sender=andy@hxr.us; remoteip=::ffff:63.240.221.237; remotehost=; helo=[192.168.1.108]; receiver=zak.ecotroph.net; In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=sha1; protocol="application/pkcs7-signature"; boundary="=_zak.ecotroph.net-26144-1101230789-0001-2" Message-Id: Cc: "'Dean Anderson'" , "'Harry Katz'" , "'ThomasGal@LumenVox.com'" , "'IETF MARID WG'" From: Andrew Newton Subject: Re: Status of MARID WG? Date: Tue, 23 Nov 2004 12:26:25 -0500 To: "Hallam-Baker, Phillip" X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zak.ecotroph.net-26144-1101230789-0001-2 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Nov 23, 2004, at 11:22 AM, Hallam-Baker, Phillip wrote: > There is a difference between a prototype and a product. Unfortunately > we > have a habbit of inflicting PERL lash up style schemes that are really > no > more than prototypes onto end users. What's the saying... "Build a foolproof system and only fools will use it." Not that the assertion you are making is incorrect, but I do not think it can be a generalization. The computer sciences have been taking a beating lately because the technology being produced cannot be quickly grasped by simpletons. Well, guess what? Despite all the research and will of the auto industry, training and a drivers license are still required. And certainly while many jurisdictions see no need for making sure gun-owners know more than point-and-shoot, I think most reasonable people wish they did. So I think the "my mother must understand it" requirement is not always applicable. After all, isn't the driver for mta-to-mta authorization caused because our collective mothers simply will not take on this responsibility with their click-driven MUAs? -andy --=_zak.ecotroph.net-26144-1101230789-0001-2 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGgTCCAzow ggKjoAMCAQICAw05ITANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQxMDEzMjA1ODM1WhcNMDUxMDEzMjA1ODM1WjB7MQ8wDQYDVQQE EwZOZXd0b24xDzANBgNVBCoTBkFuZHJldzEWMBQGA1UEAxMNQW5kcmV3IE5ld3RvbjEjMCEGCSqG SIb3DQEJARYUYW5ld3RvbkBlY290cm9waC5uZXQxGjAYBgkqhkiG9w0BCQEWC2FuZHlAaHhyLnVz MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0XTscSF9lNVyNyq7wCFwEb56C7WBLvAh BaPqdV8oOr5EroTgv+0zUfaP8kYlwavWeSu0XcWIcgd/ymt7PWOd8j/J91Y71cmsSg62gv6dhA8h wzxojj5Vp2x3TYf7dafzoVfhd/7Kzvzu6FqOn9C/9NKtZ0g0hzn6ChcgymCrcoyXQrmQI689sh4o RzIQC+kSPaWkOmA0eqbCpi8ASQfuyEBiXQAATxrBWURp+hzD8YYcnn88S/5Kd4GGMARtwsBR6Moe xF53oAUavRPfiM3ixDunUqgXOQ92noBoc3nIWmxGuLdTZPZgELHX1Q1FMi013PW3tIA9rhZATcIf PF/jOQIDAQABo2EwXzAOBgNVHQ8BAf8EBAMCB4AwEQYJYIZIAYb4QgEBBAQDAgWgMCwGA1UdEQQl MCOBFGFuZXd0b25AZWNvdHJvcGgubmV0gQthbmR5QGh4ci51czAMBgNVHRMBAf8EAjAAMA0GCSqG SIb3DQEBBAUAA4GBAJiErfGNCI9wRF0H8NmkSJCjzaH3yHfv0q1CwyJr6zZhkA2M+GcCoIr12PNP J10XG3WJ/96bLP2SxzFz1FC6CfMN2/XrOn1Su5wRdVBAr7lRkyqco9A7JXaW8rUwOm6DQ20eWZen FJMo/mwzDxgThS9Oyci/ASNT4ej+Yzcyq5kpMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBU b3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSsw KQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAw MFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7s vc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV 84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGR MBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUu Y29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCk HjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oL LswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoL gnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHT HUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAgMNOSEwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDQxMTIzMTcyNjI1WjAjBgkqhkiG9w0BCQQxFgQUidHm/jV5uOCBjkfcuhI5 +jVY2nUweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENv bnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElz c3VpbmcgQ0ECAw05ITB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBAgMNOSEwDQYJKoZIhvcNAQEBBQAEggEAIhMxmmGdOX7g/s+jd23T NpGTqh/9iQxmgEW6U2pkcD5e16kAoImE1vUDq2CNGY9B/sLAmeT8LmhAvfM629CFhb5g7QkQOx24 ryzYgg6O59ubUhssslANW6cz0bs8Ilx8U+zEdRjUsxQfrhgA56JU5Jz1Twk9a9H3B6gHawdopRTJ bmwOi84aO0xwCcxOHQRvvVZ1SDd9EC98bd2PftkBkVJQ14hYr3BT0v2P9V9QfhLuhjJDKECrrD8R 4ZmB19K8nVobP7sQV6TRBcjzIIeqeK82jg31MfqGCY65WKJg0gWirr/fJ+dzDTh0nEAIrzSiYCyx mk8r/IvuY1cgaORm1gAAAAAAAA== --=_zak.ecotroph.net-26144-1101230789-0001-2-- From owner-ietf-mxcomp@mail.imc.org Tue Nov 23 13:32:37 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06444 for ; Tue, 23 Nov 2004 13:32:37 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iANHxY8V069798; Tue, 23 Nov 2004 09:59:34 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iANHxXOk069797; Tue, 23 Nov 2004 09:59:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iANHxXrO069779 for ; Tue, 23 Nov 2004 09:59:33 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC04.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id iANHxElY012067; Tue, 23 Nov 2004 09:59:14 -0800 (PST) Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Tue, 23 Nov 2004 09:59:14 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Andrew Newton'" , "Hallam-Baker, Phillip" Cc: "'Dean Anderson'" , "'Harry Katz'" , "'ThomasGal@LumenVox.com'" , "'IETF MARID WG'" Subject: RE: Status of MARID WG? Date: Tue, 23 Nov 2004 09:59:13 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > From: Andrew Newton [mailto:andy@hxr.us] > On Nov 23, 2004, at 11:22 AM, Hallam-Baker, Phillip wrote: > > > There is a difference between a prototype and a product. > Unfortunately > > we > > have a habbit of inflicting PERL lash up style schemes that > are really > > no > > more than prototypes onto end users. > > What's the saying... "Build a foolproof system and only fools > will use > it." That has been the cry of the COBOL lobby, the FORTRAN lobby and every group that has promoted an obsolete legacy product as the future. > The computer sciences have been taking a > beating lately because the technology being produced cannot > be quickly grasped by simpletons. Deservedly so. > Well, guess what? Despite all the research and will of the auto > industry, training and a drivers license are still required. But not for turning on the heater or a/c. > After all, isn't the driver for mta-to-mta authorization > caused because our collective mothers simply will not take on this > responsibility with their click-driven MUAs? I would argue that the need for the group is due to internet community dumping an inadequate prototype for a spec onto the user base. SMTP is a bit of an improvement over the days when email was a feature of FTP which was in turn a feature of TELNET. From owner-ietf-mxcomp@mail.imc.org Tue Nov 23 13:44:10 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07692 for ; Tue, 23 Nov 2004 13:44:09 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iANI9YSG073074; Tue, 23 Nov 2004 10:09:34 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iANI9YpG073073; Tue, 23 Nov 2004 10:09:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iANI9W5U073064 for ; Tue, 23 Nov 2004 10:09:34 -0800 (PST) (envelope-from andy@hxr.us) Received: from [192.168.1.108] ([::ffff:63.240.221.237]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Tue, 23 Nov 2004 13:09:35 -0500 id 00207677.41A37CDF.00006CB5 Received-SPF: unknown (Address does not pass the Sender Policy Framework) SPF=HELO; sender=[192.168.1.108]; remoteip=::ffff:63.240.221.237; remotehost=; helo=[192.168.1.108]; receiver=zak.ecotroph.net; Received-SPF: fail (Address does not pass the Sender Policy Framework) SPF=MAILFROM; sender=andy@hxr.us; remoteip=::ffff:63.240.221.237; remotehost=; helo=[192.168.1.108]; receiver=zak.ecotroph.net; In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=sha1; protocol="application/pkcs7-signature"; boundary="=_zak.ecotroph.net-27829-1101233376-0001-2" Message-Id: Cc: "'Dean Anderson'" , "'Harry Katz'" , "'ThomasGal@LumenVox.com'" , "'IETF MARID WG'" From: Andrew Newton Subject: Re: Status of MARID WG? Date: Tue, 23 Nov 2004 13:09:32 -0500 To: "Hallam-Baker, Phillip" X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zak.ecotroph.net-27829-1101233376-0001-2 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Nov 23, 2004, at 12:59 PM, Hallam-Baker, Phillip wrote: > That has been the cry of the COBOL lobby, the FORTRAN lobby and every > group > that has promoted an obsolete legacy product as the future. COBOL failed because RPG-III was superior! -andy --=_zak.ecotroph.net-27829-1101233376-0001-2 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGgTCCAzow ggKjoAMCAQICAw05ITANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQxMDEzMjA1ODM1WhcNMDUxMDEzMjA1ODM1WjB7MQ8wDQYDVQQE EwZOZXd0b24xDzANBgNVBCoTBkFuZHJldzEWMBQGA1UEAxMNQW5kcmV3IE5ld3RvbjEjMCEGCSqG SIb3DQEJARYUYW5ld3RvbkBlY290cm9waC5uZXQxGjAYBgkqhkiG9w0BCQEWC2FuZHlAaHhyLnVz MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0XTscSF9lNVyNyq7wCFwEb56C7WBLvAh BaPqdV8oOr5EroTgv+0zUfaP8kYlwavWeSu0XcWIcgd/ymt7PWOd8j/J91Y71cmsSg62gv6dhA8h wzxojj5Vp2x3TYf7dafzoVfhd/7Kzvzu6FqOn9C/9NKtZ0g0hzn6ChcgymCrcoyXQrmQI689sh4o RzIQC+kSPaWkOmA0eqbCpi8ASQfuyEBiXQAATxrBWURp+hzD8YYcnn88S/5Kd4GGMARtwsBR6Moe xF53oAUavRPfiM3ixDunUqgXOQ92noBoc3nIWmxGuLdTZPZgELHX1Q1FMi013PW3tIA9rhZATcIf PF/jOQIDAQABo2EwXzAOBgNVHQ8BAf8EBAMCB4AwEQYJYIZIAYb4QgEBBAQDAgWgMCwGA1UdEQQl MCOBFGFuZXd0b25AZWNvdHJvcGgubmV0gQthbmR5QGh4ci51czAMBgNVHRMBAf8EAjAAMA0GCSqG SIb3DQEBBAUAA4GBAJiErfGNCI9wRF0H8NmkSJCjzaH3yHfv0q1CwyJr6zZhkA2M+GcCoIr12PNP J10XG3WJ/96bLP2SxzFz1FC6CfMN2/XrOn1Su5wRdVBAr7lRkyqco9A7JXaW8rUwOm6DQ20eWZen FJMo/mwzDxgThS9Oyci/ASNT4ej+Yzcyq5kpMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBU b3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSsw KQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAw MFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7s vc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV 84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGR MBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUu Y29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCk HjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oL LswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoL gnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHT HUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAgMNOSEwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDQxMTIzMTgwOTMyWjAjBgkqhkiG9w0BCQQxFgQUNxbExAY3b9ryP1utXgje l6wbGRIweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENv bnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElz c3VpbmcgQ0ECAw05ITB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBAgMNOSEwDQYJKoZIhvcNAQEBBQAEggEAIt7zeksp0c20v7uOxasO K0KDbmstA4BxQOeycN6ViK0bP4IcZOj3AtQz1mPNSSapq59mC+3pDAcfT59AW09Bb6GFmLmrqjRx KmMr5PpnxWUhV1YctanLYmELN+CTC3akTC9w2Xq+2Cxw2XOXQpMYF12Agx0D9KLpRZy6r5lQ7mti fFE08856e3LB6u0eBLMeWA1UVfw33sGmSdwqPP8Xy7u0SZYMIAfrF0uU+2rKimXA2Q08LVlJTCwu shL/o12EuFusHlx3bhI0M7+djqXImgqWKHfvejJW9b5+E0ZpXNjTqkoNPTy3L/LmpLUKrPgP6Tp+ yMnpPHL0vv7CKN2eKQAAAAAAAA== --=_zak.ecotroph.net-27829-1101233376-0001-2-- From owner-ietf-mxcomp@mail.imc.org Tue Nov 23 17:14:44 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12606 for ; Tue, 23 Nov 2004 17:14:44 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iANLl59e036013; Tue, 23 Nov 2004 13:47:05 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iANLl58M036012; Tue, 23 Nov 2004 13:47:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from orca.agcom.amgreetings.com (orca.ag.com [207.58.192.149]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iANLl40F035976 for ; Tue, 23 Nov 2004 13:47:05 -0800 (PST) (envelope-from MWeiner@ag.com) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4D1A5.F6A379F6" Subject: RE: Status of MARID WG? Date: Tue, 23 Nov 2004 16:46:22 -0500 Message-ID: <4FD2C985D5E2A642AE25823DFD61C2B0027985@orca.agcom.amgreetings.com> Thread-Topic: Status of MARID WG? Thread-Index: AcTRpYoiCkRSS9s/TAekImZBlb7EygAAFWDS From: "MW Mike Weiner \(5028\)" To: , "Andrew Newton" Cc: "IETF MARID WG" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C4D1A5.F6A379F6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable -----Original Message----- From: owner-ietf-mxcomp@mail.imc.org on behalf of = EdLevinson@ResultsLifeCoaching.com Sent: Tue 11/23/2004 4:32 PM To: Andrew Newton Cc: 'IETF MARID WG' Subject: Re: Status of MARID WG? =20 At 01:09 PM 11/23/04 -0500, Andrew Newton wrote: >On Nov 23, 2004, at 12:59 PM, Hallam-Baker, Phillip wrote: > >>That has been the cry of the COBOL lobby, the FORTRAN lobby and every = group >>that has promoted an obsolete legacy product as the future. > >COBOL failed because RPG-III was superior! And RPG-III was superior because programmers didn't have to think about = the=20 underlying processing algorithm. RPG had reduced the concern to what do = I=20 do with this (these) record(s). Summed up in 3 words, "...its DEAD Jim..." Michael Weiner ------_=_NextPart_001_01C4D1A5.F6A379F6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Status of MARID WG?

-----Original Message-----
From: owner-ietf-mxcomp@mail.imc.org on behalf of = EdLevinson@ResultsLifeCoaching.com
Sent: Tue 11/23/2004 4:32 PM
To: Andrew Newton
Cc: 'IETF MARID WG'
Subject: Re: Status of MARID WG?


At 01:09 PM 11/23/04 -0500, Andrew Newton wrote:

>On Nov 23, 2004, at 12:59 PM, Hallam-Baker, Phillip wrote:
>
>>That has been the cry of the COBOL lobby, the FORTRAN lobby and = every group
>>that has promoted an obsolete legacy product as the future.
>
>COBOL failed because RPG-III was superior!

And RPG-III was superior because programmers didn't have to think about = the
underlying processing algorithm.  RPG had reduced the concern to = what do I
do with this (these) record(s).

Summed up in 3 words, "...its DEAD Jim..."

Michael Weiner

------_=_NextPart_001_01C4D1A5.F6A379F6-- From owner-ietf-mxcomp@mail.imc.org Tue Nov 23 17:15:42 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12726 for ; Tue, 23 Nov 2004 17:15:42 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iANLWlZj031892; Tue, 23 Nov 2004 13:32:47 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iANLWlGV031891; Tue, 23 Nov 2004 13:32:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from agamemnon.cnchost.com (agamemnon.cnchost.com [207.155.252.31]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iANLWk7m031884 for ; Tue, 23 Nov 2004 13:32:46 -0800 (PST) (envelope-from EdLevinson@ResultsLifeCoaching.com) Received: from bayit.ResultsLifeCoaching.com (pool-141-150-11-151.mad.east.verizon.net [141.150.11.151]) by agamemnon.cnchost.com id QAA16996; Tue, 23 Nov 2004 16:32:38 -0500 (EST) [ConcentricHost SMTP Relay 1.17] From: EdLevinson@ResultsLifeCoaching.com Message-Id: <5.1.0.14.0.20041123163009.030c5150@pop3.resultslifecoaching.com> X-Sender: edlevinson@resultslifecoaching.com@pop3.resultslifecoaching.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 23 Nov 2004 16:32:32 -0500 To: Andrew Newton Subject: Re: Status of MARID WG? Cc: "'IETF MARID WG'" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 01:09 PM 11/23/04 -0500, Andrew Newton wrote: >On Nov 23, 2004, at 12:59 PM, Hallam-Baker, Phillip wrote: > >>That has been the cry of the COBOL lobby, the FORTRAN lobby and every group >>that has promoted an obsolete legacy product as the future. > >COBOL failed because RPG-III was superior! And RPG-III was superior because programmers didn't have to think about the underlying processing algorithm. RPG had reduced the concern to what do I do with this (these) record(s). Ed From owner-ietf-mxcomp@mail.imc.org Thu Nov 25 12:00:40 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29564 for ; Thu, 25 Nov 2004 12:00:39 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAPG7hAR092221; Thu, 25 Nov 2004 08:07:43 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAPG7huN092220; Thu, 25 Nov 2004 08:07:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from canuck.infradead.org (canuck.infradead.org [205.233.218.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAPG7Pcj091948 for ; Thu, 25 Nov 2004 08:07:36 -0800 (PST) (envelope-from SRS0+b26427ec83d3d1930f6f+459+infradead.org+dwmw2@canuck.srs.infradead.org) Received: from [213.86.99.236] (helo=[172.16.18.64]) by canuck.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1CXM9L-0001gI-MD; Thu, 25 Nov 2004 11:07:17 -0500 Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] From: David Woodhouse To: Andrew Newton Cc: Hector Santos , MXCOMP In-Reply-To: <80E256FA-3D72-11D9-92D5-000A95B3BA44@hxr.us> References: <20041120231821.120205@bbfujip> <006101c4d170$336eac90$6401a8c0@hdev1> <80E256FA-3D72-11D9-92D5-000A95B3BA44@hxr.us> Content-Type: text/plain Message-Id: <1101398831.8191.9383.camel@hades.cambridge.redhat.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2.dwmw2.1) Date: Thu, 25 Nov 2004 16:07:12 +0000 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-SRS-Rewrite: SMTP reverse-path rewritten from by canuck.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 2004-11-23 at 12:09 -0500, Andrew Newton wrote: > On Nov 23, 2004, at 10:22 AM, Hector Santos wrote: > > > What Alan is suggesting, for which I strongly agree, is that the focus > > in solving the "problem" needs a revisiting of the SMTP model or more > > specifically, the functional specification. > > That has been and still is the basis for all the disagreements in this > area. The nature of Alan and Hector's belief is such that it could only ever really be disproven, and never proven -- even it if _is_ in fact true. The existence of a solution which does not require the world to be changed wholesale would disprove their theory that such change is required. On the other hand, the lack of such a solution merely shows that _either_ there isn't one, or it just hasn't been found yet. As it happens, I believe that multiple such solutions _have_ been found. They just need the details to be ironed out and the deployment to pick up. There is a lot of merit in all of CSV, SES, BATV, DK, IIM and the other solutions being discussed, and very little evidence that wholesale changes to existing practice are required, such as the changes which would be required by SPF or SenderID. Thus, I believe that anyone who seriously wants widespread deployment of a scheme to reduce the amount of faked email should put their energy into assisting one of those schemes, and only if they all turn out to be impractical should we revisit the possibility of requiring wholesale changes to the existing email infrastructure. There seem to be far too many people with a personal attachment to some particular scheme, who don't really seem interested in pursuing which is _technically_ more appropriate. I'd like to see a little less emotion, and a little more rationality. -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Thu Nov 25 18:39:32 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26594 for ; Thu, 25 Nov 2004 18:39:32 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAPN0T3n085992; Thu, 25 Nov 2004 15:00:29 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAPN0TKO085991; Thu, 25 Nov 2004 15:00:29 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAPN0Rec085891 for ; Thu, 25 Nov 2004 15:00:28 -0800 (PST) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 9B4D516F4C for ; Thu, 25 Nov 2004 18:11:51 -0500 (EST) From: "Alan DeKok" To: MXCOMP Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] In-Reply-To: Your message of "Thu, 25 Nov 2004 16:07:12 GMT." <1101398831.8191.9383.camel@hades.cambridge.redhat.com> Date: Thu, 25 Nov 2004 18:11:51 -0500 Message-Id: <20041125231151.9B4D516F4C@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Woodhouse wrote: > The nature of Alan and Hector's belief is such that it could only ever > really be disproven, and never proven -- even it if _is_ in fact true. I'm not sure which of my beliefs you're talking about. > The existence of a solution which does not require the world to be > changed wholesale would disprove their theory that such change is > required. Ah. You're not talking about any of my beliefs. Do not use my name in the context of opinions I've never held. > There is a lot of merit in all of CSV, SES, BATV, DK, IIM and the > other solutions being discussed, and very little evidence that > wholesale changes to existing practice are required, such as the > changes which would be required by SPF or SenderID. CSV, SES, BATV, etc. require *some* changes to SMTP. To address Andrew's phrasing of the disagreement, I ask "How can you change things without changing them?" The existence of CSV, SES, BATV, etc. is an admission that the SMTP model did not previously contain the ideas put forth in those proprosals. Therefore, whether people admit it or not, the SMTP model *is* open for changes, and *is* being changed. The question now becomes: What changes are to be permitted, and who is to be permitted to propose those changes? One answer is this: It's not 1984. No one is proposing that X.400 or any other protocol should replace SMTP. SMTP has won the email protocol wars. It has significantly more deployment than any other protocol, and is therefore the only one in wide-spread use on the Internet. SMTP has a multi-decade track record of being the best, the most useful, the most inter-operable, and the most wide-spread email protocol. To first order, nothing else exists but SMTP. Once that's understood, it would be idiotic to replace SMTP with one of the proposals which was discussed and rejected 20 years ago. It would be idiotic to go through SMTP, making massive changes to all aspects of the protocol. What DOES make sense is to understand WHY spam is a problem in SMTP. This involves re-visiting the model, because the model of SMTP as created 30 years ago manifestly did not include the concept that "spam is a problem." We need to understand what's going on in the design and deployment of SMTP which allows spam to be a problem. In the short term, we can come up with endless band-aids. We can play "whack-a-mole" with spammers. But unless we look at the system as a whole, we won't have a solution for the whole system. The most frustrating part of this discussion is that no matter how many times I repeat my position, I still get accused of wanting to replace SMTP with something completely different. I still get accused of wanting to "change the world whole-sale". I still get told "we can't change the model", even as the people saying that are changing the model. It's not 1984. 20 years have gone by. SMTP won those wars and all of the protocol wars which followed. No one is arguing that we should replace SMTP with X.400, or any other non-SMTP scheme. I'm not one of the X.400 people. Get over it. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Thu Nov 25 19:23:06 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29281 for ; Thu, 25 Nov 2004 19:23:05 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAPNr7le073064; Thu, 25 Nov 2004 15:53:07 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAPNr72s073063; Thu, 25 Nov 2004 15:53:07 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAPNr6DK073046 for ; Thu, 25 Nov 2004 15:53:06 -0800 (PST) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id iAQ0I356013083; Thu, 25 Nov 2004 16:18:03 -0800 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id iAQ0I3mJ013080; Thu, 25 Nov 2004 16:18:03 -0800 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Thu, 25 Nov 2004 16:18:03 -0800 (PST) From: "william(at)elan.net" To: Alan DeKok cc: MXCOMP Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] In-Reply-To: <20041125231151.9B4D516F4C@mail.nitros9.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 25 Nov 2004, Alan DeKok wrote: > It's not 1984. 20 years have gone by. SMTP won those wars and all > of the protocol wars which followed. No one is arguing that we should > replace SMTP with X.400, or any other non-SMTP scheme. I'm not one of > the X.400 people. I've argued and will be happy to argue again that SMTP needs to be replaced with new protocol entirely instead of putting more and more band-aids on 20 year old protocol that was designed for "simple" mail transactions. But creating new mail protocol to replace SMTP would take long time (both in terms of IETF process to create this new protocol and process for it to achieve wide-spread adaption) and spam is a serious problem in our current and immediate situation of using email so we have to do something with what we have (i.e. SMTP) to get this under control and only after that can we take a look at entire thing and see if we can come up with something better taking into the account all the lessons with have learned with what works and what does not in SMTP. -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Fri Nov 26 03:57:58 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19764 for ; Fri, 26 Nov 2004 03:57:57 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAQ8GORF084773; Fri, 26 Nov 2004 00:16:24 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAQ8GOGc084771; Fri, 26 Nov 2004 00:16:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from canuck.infradead.org (canuck.infradead.org [205.233.218.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAQ8GCf5084159 for ; Fri, 26 Nov 2004 00:16:19 -0800 (PST) (envelope-from SRS0+15c6cb83ba4904a0e02f+460+infradead.org+dwmw2@canuck.srs.infradead.org) Received: from shinybook.infradead.org ([81.187.226.99]) by canuck.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1CXbGu-0002ed-NW; Fri, 26 Nov 2004 03:16:07 -0500 Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] From: David Woodhouse To: Alan DeKok Cc: MXCOMP In-Reply-To: <20041125231151.9B4D516F4C@mail.nitros9.org> References: <20041125231151.9B4D516F4C@mail.nitros9.org> Content-Type: text/plain; charset=UTF-8 Date: Fri, 26 Nov 2004 08:11:51 +0000 Message-Id: <1101456711.19141.57.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3.dwmw2.1) Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-SRS-Rewrite: SMTP reverse-path rewritten from by canuck.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Thu, 2004-11-25 at 18:11 -0500, Alan DeKok wrote: > David Woodhouse wrote: > > The nature of Alan and Hector's belief is such that it could only ever > > really be disproven, and never proven -- even it if _is_ in fact true. > > I'm not sure which of my beliefs you're talking about. I'm talking about beliefs stated in the paragraph to which I was replying, and which I quoted. In which Hector Santos used the words "What Alan is suggesting, for which I strongly agree...". But it seems you were talking of problems with mail in general while I was concentrating solely on spoofing, which is a special case -- one of the band-aids you mention. I apologise for misinterpreting you and attributing to you a belief which is not yours. The same logical point applies though -- you can only ever demonstrate that it _can_ by fixed without wholesale changes, by doing so. You can't demonstrate that it cannot. But since no scheme to really _fix_ the generic problem without such wholesale change exists, we're far more likely to give you the benefit of the doubt when you say that such change is necessary. You're probably right. It's not clear to what extent the change is needed, but you're also right that it probably doesn't require throwing away SMTP and starting again. > > The existence of a solution which does not require the world to be > > changed wholesale would disprove their theory that such change is > > required. > > Ah. You're not talking about any of my beliefs. Do not use my name > in the context of opinions I've never held. I apologise again for my misstatement. Are you saying you do _not_ believe that in order to fix the spoofing problem we must make incompatible changes to the way SMTP works universally? That you believe we can achieve it by only making changes at the endpoint sites which want to take advantage of any new scheme? That I would agree with. > > There is a lot of merit in all of CSV, SES, BATV, DK, IIM and the > > other solutions being discussed, and very little evidence that > > wholesale changes to existing practice are required, such as the > > changes which would be required by SPF or SenderID. > > CSV, SES, BATV, etc. require *some* changes to SMTP. To address > Andrew's phrasing of the disagreement, I ask "How can you change > things without changing them?" Perhaps I was overly ambiguous in an attempt to be succinct. Backward- compatible change at _participating_ sites is fine. I'm speaking of a need to 'upgrade the world wholesale' -- to force changes even at uninterested and non-participating sites, because our new scheme relies on assumptions about their behaviour weren't previously true. That would be a very silly thing to do unless it's _really_ necessary. Concepts like SRS and the proposed abuse of the 'Resent-From:' header are the kind of thing I was referring to when I said 'change the world wholesale'. Each would need to be deployed ubiquitously before the scheme which requires them becomes truly viable. > The existence of CSV, SES, BATV, etc. is an admission that the SMTP > model did not previously contain the ideas put forth in those > proprosals. Therefore, whether people admit it or not, the SMTP model > *is* open for changes, and *is* being changed. Backward-compatible change within the scope of the existing system, yes. Changing the model in the same way that MIME changed the SMTP model. How many times do you remember demanding that some site out there upgrade their mailer dæmon because you have started sending, or want to receive, MIME mail? How long did it take them to 'upgrade'? > The question now becomes: What changes are to be permitted, and who > is to be permitted to propose those changes? Indeed -- and it's a very hard one to answer. What we _can_ say is that changes which are limited to participating sites are a lot easier than changes which must be implemented ubiquitously in order for the system to work correctly. Hence we should eschew schemes which require _ubiquitous_ change to current practice, in favour of schemes which can be deployed incrementally at participating sites without losing compatibility. (That isn't to say that we should ignore a scheme which purports to solve world hunger because it requires ubiquitous change, and we should favour an alternative scheme which can solve just address spoofing without such change. Obviously I'm talking about comparing schemes with vaguely equivalent features.) Compare SES/BATV with SPF, for example. Observe sourceforge.net (and many other places) rejecting _faked_ MAIL FROM: _WITHOUT_ having made any changes -- and when valid mail is forwarded to a sf.net user from an account elsewhere, where the MTA in between hasn't been changed either. Yes, it's a change to the model, but it doesn't _require_ anyone else to adapt. That's the difference. Likewise compare IIM with SenderID. Each purports to protect against spoofing of the RFC2822 identities, but one was designed to work in the real world today, and the other requires that the world adapt to fix it. > One answer is this: It's not 1984. No one is proposing that X.400 > or any other protocol should replace SMTP. Some actually are, but it's entirely unrealistic. > What DOES make sense is to understand WHY spam is a problem in SMTP. > This involves re-visiting the model, because the model of SMTP as > created 30 years ago manifestly did not include the concept that "spam > is a problem." We need to understand what's going on in the design > and deployment of SMTP which allows spam to be a problem. > > In the short term, we can come up with endless band-aids. We can > play "whack-a-mole" with spammers. But unless we look at the system > as a whole, we won't have a solution for the whole system. I agree with that. Hell, if we can have a practicable solution for the whole system, I'll readily agree even to 'changing the world wholesale', if that's actually required and realistic. What I (and many others) object to is far-reaching changes which are unnecessary; when we have alternative schemes which promise to achieve the same goals, but without such change. > The most frustrating part of this discussion is that no matter how > many times I repeat my position, I still get accused of wanting to > replace SMTP with something completely different. I still get accused > of wanting to "change the world whole-sale". I still get told "we > can't change the model", even as the people saying that are changing > the model. It does sound like I misinterpreted you in the same way, for which I apologise. I'm not arguing with your actual position. To fix spoofing of addresses is just a band-aid, as you said. But it's all that's on offer right now. I'm saying we can do _that_ without fundamental changes. -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Fri Nov 26 04:52:10 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23638 for ; Fri, 26 Nov 2004 04:52:09 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAQ9Lk6D018465; Fri, 26 Nov 2004 01:21:46 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAQ9Lk7p018461; Fri, 26 Nov 2004 01:21:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smarthost0.mail.uk.easynet.net (smarthost0.mail.uk.easynet.net [212.135.6.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAQ9LjQc018142 for ; Fri, 26 Nov 2004 01:21:45 -0800 (PST) (envelope-from chris@harvington.org.uk) Received: from [62.53.0.15] (helo=ringo) by smarthost0.mail.uk.easynet.net with smtp (Exim 4.10) id 1CXcII-000MMo-00 for ietf-mxcomp@imc.org; Fri, 26 Nov 2004 09:21:34 +0000 Message-ID: <042d01c4d398$9ca78310$0200000a@ringo> From: "Chris Haynes" To: "MXCOMP" References: <20041120231821.120205@bbfujip> <006101c4d170$336eac90$6401a8c0@hdev1> <80E256FA-3D72-11D9-92D5-000A95B3BA44@hxr.us> <1101398831.8191.9383.camel@hades.cambridge.redhat.com> Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] Date: Fri, 26 Nov 2004 09:16:21 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On November 25, 2004 4:07 PM at "David Woodhouse" asserted: > > On Tue, 2004-11-23 at 12:09 -0500, Andrew Newton wrote: > > On Nov 23, 2004, at 10:22 AM, Hector Santos wrote: > > > > > What Alan is suggesting, for which I strongly agree, is that the focus > > > in solving the "problem" needs a revisiting of the SMTP model or more > > > specifically, the functional specification. > > > > That has been and still is the basis for all the disagreements in this > > area. > > The nature of Alan and Hector's belief is such that it could only ever > really be disproven, and never proven -- even it if _is_ in fact true. > > The existence of a solution which does not require the world to be > changed wholesale would disprove their theory that such change is > required. On the other hand, the lack of such a solution merely shows > that _either_ there isn't one, or it just hasn't been found yet. > > As it happens, I believe that multiple such solutions _have_ been found. > They just need the details to be ironed out and the deployment to pick > up. There is a lot of merit in all of CSV, SES, BATV, DK, IIM and the > other solutions being discussed, and very little evidence that wholesale > changes to existing practice are required, such as the changes which > would be required by SPF or SenderID. > > Thus, I believe that anyone who seriously wants widespread deployment of > a scheme to reduce the amount of faked email should put their energy > into assisting one of those schemes, and only if they all turn out to be > impractical should we revisit the possibility of requiring wholesale > changes to the existing email infrastructure. > > There seem to be far too many people with a personal attachment to some > particular scheme, who don't really seem interested in pursuing which is > _technically_ more appropriate. I'd like to see a little less emotion, > and a little more rationality. Very good suggestion; let's get some rationality into this debate. Let me bring to this august forum a debate which was happening in 'another place' and see if we can re-visit it - because we need to find some kind of resolution for it. The problem is related to forwarding, and its interaction with Sender-ID (and with SPF-Classic). I'll discuss the problem w.r.t. SPF (-Classic, because I understand that better). Please understand, I'm not inviting a reprise of arguments which have taken place elsewhere, I'm trying to lift the level of debate to one of process related to the 'definition' of SMTP. I'll first just re-state the problem and give it bounds. The problem arises with forwarding which undertakes the following sequence of actions... An entity does not wish to make widely available his 'true' eMail address of recipient@end.com', he employs a forwarding agency. He publishes the address alias@forwarding.com. A message originator sends HELO origin.com MAIL FROM: sender@origin.com RCPT TO: alias@forwarding.com Now forwarding.com receives the content, consults its client database or whatever, and places the content in a new envelope, sending it as HELO forwarding.com MAIL FROM sender@origin.com RCPT TO recipient@end.com Note that if the second message cannot be delivered to the recipient@end.com mailbox, a DSN 'bounce' generated by end.com gets sent direct to sender:origin.com. The bounce has details of the forwarding arrangements which 'sender' knows nothing about, and 'forwarding.com' gets no opportunity to know that its forwarding arrangements with the recipient are not working. Now here's the central technical problem: Suppose that origin.com has published an SPF policy. That policy knows nothing of forwarding.com and does not include any of forwarding.com's hosts among those authorised to send on behalf of origin.com. end.com implements SPF testing. It. too knows nothing of forwarding.com (so cannot white-list it). The forwarded message fails the SPF test, because the MAIL FROM claims that _the second_ message is from origin.com, whereas inspection of its IP address shows that origin.com has not authorised it to send message on its behalf. Now, please don't reply by suggesting work-arounds, etc., or by saying that scheme PQR avoids this problem. That's not what this message is about. Let me focus on the heart of the debate, and I'm doing my best to be fair to both sides here, and to use neutral language. Still in the spirit of 'neutral language' , let me use the terms 'conservative' and 'progressive' for the two positions I am aware of. The conservatives look at the above example and say "SPF is breaking the mail system. Forwarding has worked perfectly well in the past; it is SPF which is changing; it is SPF which is wrong. SPF should not be deployed". Again, let us ignore for now the possible work-arounds - just concentrate on SPF in SMTP. The progressives say: "The world has changed, there are threats now which were never envisaged when the SMTP protocols and practices were first deployed. Changes of some sort or another _have_ to happen to regain the utility and trust that SMTP deserves." The conservatives reply: "But not using SPF - SPF breaks forwarding". To which the progressives reply: "No. Actually, if you look at the SMTP architecture, as can be reverse-engineered from the relevant RFCs, it is forwarding which is breaking the SMTP architecture. "forwarding (as per the above example) involves the transmission of two discrete messages, with different envelope recipients. Yet what the forwarder is doing is using the MAIL FROM of the first message when it sends the second message. "It is wrong" (say the progressives) "for forwarding.com to use MAIL FROM sender@origin.com. SPF (rightly) detects this as an unauthorised use of 'origin.con', the second message is declared a forgery. "It is also wrong" (say the progressives) "and has always been wrong - long before SPF - that bounces are sent direct from end.com to origin.com. forwarding.com should handle the bounce. Only if it cannot resolve the problem should it notify origin.com, and it should not do this by sending a 'bounce' back to origin.com, since. in the terms of the SMTP 'contract' to 'deliver-or-report' the message was correctly delivered to its intended mailbox of alias@forwarding.com.", so no (2821-level non-delivery) report is appropriate." "Foul" cry the conservatives. "There was only ever one message involved. SMTP has always supported more than one 'hop'. This 'two messages' business is just not true. Forwarding has always worked in the past, using the SMTP protocols. There is nothing wrong with forwarding." Some progressives propose to invite all forwarders to modify their practices so as to conform to what they understand to be the SMTP architecture - and various schemes have been suggested to help then do this in sensible, practical ways. Conservatives accuse the progressives of mandating "wholesale changes to existing practices" and requiring "changes which must be implemented ubiquitously". In this particular situation 'ubiquitous' (OED: everywhere or in an indefinite number of places all at once) is an exaggeration. It is only those forwarders who re-use the originator's MAIL FROM who have to change, no-one else does; and the progressives would claim that this is simply asking the forwarders to now conform to the SMTP architecture. Now, continuing in my attempt to be fair, let me withdraw any implication that the conservatives are against any change whatsoever. I'm using 'progressive' and 'conservative' purely in the context of this one topic. There are all sorts of problem-resolution schemes being proposed, and those who oppose one may be a strong supporter of another. But their is no ideal scheme on offer, anywhere. All schemes will have plus and minus points, all will require change of one sort or another. All change must be evaluated rationally. To return to the specifics of SPF and forwarding, the core question I wish to raise here is this: ------------- How, and from where, would one get an 'authoritative' ruling about the conformance or non-conformance of forwarding (using the origin's MAIL FROM with a new RCPT TO) to the extant SMTP architecture? Chris Haynes From owner-ietf-mxcomp@mail.imc.org Fri Nov 26 05:08:16 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24574 for ; Fri, 26 Nov 2004 05:08:15 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAQ9fs24061485; Fri, 26 Nov 2004 01:41:54 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAQ9frc6061482; Fri, 26 Nov 2004 01:41:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAQ9fmMa061223 for ; Fri, 26 Nov 2004 01:41:48 -0800 (PST) (envelope-from dean@av8.com) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id iAQ9fdps024067 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 26 Nov 2004 04:41:44 -0500 Date: Fri, 26 Nov 2004 04:41:39 -0500 (EST) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: "Hallam-Baker, Phillip" cc: "'ThomasGal@LumenVox.com'" , "'Harry Katz'" , "'IETF MARID WG'" Subject: RE: Status of MARID WG? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 23 Nov 2004, Hallam-Baker, Phillip wrote: > > There is a fundamental concept of democracy and consensus to > > the IETF. Its just insufficient and flawed. Most standards > > organizations have a membership concept, and /all/ members > > get to vote on certain things. > > If someone wants to trump my opinion in my field of expertise on an issue I > believe is critical to the security of the Internet on the basis of an > unelected appointment through the old boy club then they are going to have a > big fight on their hands. > > I find it utterly ludicrous that we are on the brink of taking a spec to an > alternative working group due to a technical dispute where the pragmatic > approach is so clear. > > If people don't want a fight then the answer is clear, give me an > alternative way to deploy MASS that does not create a dependency on the > deployment of new DNS infrastructure. The dependency is real and it is > neither necessary nor even advantageous. "If someone wants to trump [your] opinion ..."? "If people don't want a fight, [...] give me ..."? These are another set of dictatorial statements. It is odd that you talk about democratic process and make threats about trumping your opinion at the same time. It seems you like the democratic process until it doesn't go your way. Then its threats. Well, I think it is ludicrous that we (that is, the ietf) are still talking about a non-working, demonstrably harmful specification such as SPF and Sender-ID in /any/ working group. But I guess that is part and parcel of a democratic process: The spam-profiteers and others will continue to promote it, in any way they can. The rest of us have to continue exposing the problems. So far, 2 working groups have rejected SPF/Sender-ID. Why not a third try? It couldn't be that the IETF has better things to do. > > Right. "Combining relative weights" sounds very much like Bayes rule. > > But Bayesian inference makes some assumptions that are not valid for a real > corpus, the probabilities are not disjoint and Bayes developed his theory of > probability for that area. First, Bayes rule makes no ssumptions that aren't valid for a real corpus. That assertion seems to be nonsense. Second, there is a partition of events on the spam sample space. Indeed, there are many, as in any probability application. And like any probability application or textbook problem, choosing the partition is the hard part. Then integrating that into a working mail system in ways that are easy for users is even harder. But, by comparison, when Radio was first invented, you basically had to be able to build your own radio receiver to listen--that was pretty hard. Now you just go to Circuit City and buy one. -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From owner-ietf-mxcomp@mail.imc.org Fri Nov 26 05:12:27 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24905 for ; Fri, 26 Nov 2004 05:12:27 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAQ9iihP068267; Fri, 26 Nov 2004 01:44:44 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAQ9iiRo068266; Fri, 26 Nov 2004 01:44:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAQ9igq9068173 for ; Fri, 26 Nov 2004 01:44:43 -0800 (PST) (envelope-from dean@av8.com) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id iAQ9igZI024070 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 26 Nov 2004 04:44:42 -0500 Date: Fri, 26 Nov 2004 04:44:42 -0500 (EST) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: MXCOMP Subject: Complaint on personal attack by Matthew Elvey In-Reply-To: <419EE9B5.6030704@elvey.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: First, I didn't participate in the FTC conference Mr Elvey seems to be reporting on in his message, nor have I even made any comments on it, yet. Why I would be attacked in a report about an FTC conference is beyond reason. Mr. Elvey is making a purely malicious attack on me in violation of IETF and ISOC rules. The following message by Matthew Elvey includes an inappropriate personal attack in violation of the following sections of the ISOC Code of Conduct: http://www.isoc.org/members/codeconduct.shtml 7 Only offer or claim to offer opinions or services that lie within the member's actual knowledge or competence. 8 In the case of financial or material conflict between personal and professional interests, or between two professional interests, declare this conflict to all interested parties and if appropriate in public. 9 Respect the generally accepted norms of Internet etiquette for human communications, especially by avoiding communications that are false or are likely to be considered as discourteous, objectionable, malicious, unwanted, or causing unjustified loss of prestige. Avoid fraudulent or deceptive statements. 11 Treat all users and colleagues fairly and on equal terms. And the message violates the following sections of the IETF Guidelines for Conduct RFC 3184: http://www.ietf.org/rfc/rfc3184.txt?number=3184 1. IETF participants extend respect and courtesy to their colleagues at all times. IETF participants come from diverse origins and backgrounds and are equipped with multiple capabilities and ideals. Regardless of these individual differences, participants treat their colleagues with respect as persons--especially when it is difficult to agree with them. Seeing from another's point of view is often revealing, even when it fails to be compelling. English is the de facto language of the IETF, but it is not the native language of many IETF participants. Native English speakers attempt to speak clearly and a bit slowly and to limit the use of slang in order to accommodate the needs of all listeners. 2. IETF participants develop and test ideas impartially, without finding fault with the colleague proposing the idea. We dispute ideas by using reasoned argument, rather than through intimidation or ad hominem attack. Or, said in a somewhat more IETF-like way: "Reduce the heat and increase the light" ========================================================================= Message-ID: <419EE9B5.6030704@elvey.com> Date: Sat, 20 Nov 2004 01:52:37 -0500 From: Matthew Elvey User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: MXCOMP Subject: FTC stuff 0) Lies 1)Yahoo & DK. 2)GoDaddy DNS & SPF & CSV. 3)Dean & FUSSP. 4)Testing 5)EFF, Anonymity. [...] =-=-=-=-=-= 3)Dean & FUSSP. Dean Anderson of av8 seems best largely ignored, given odd evidence suggesting his views are that DNSBLs are terribly, horribly, drastically, irretreivably bad and other ranting: http://vesuvio.ipv6.tilab.com/pipermail/ietf_censored/2004-May/006714.html (and http://vesuvio.ipv6.tilab.com/pipermail/ietf_censored/2004-June/006933.html and the results of #whois 130.105.36.66 and http://moensted.dk/spam/messages/20020716-dean+av8.com.txt ); forgive me if I'm skeptical about his statements. I am confident an implemented long term solution that will keep inboxes functional and nearly spam-free is in the not-so-distant future. It's not like a perpetual motion machine: un-inventable. Plus, Information Theory is cool and fun. I've found it useful for pointing me in the right direction for handling this plague. From owner-ietf-mxcomp@mail.imc.org Fri Nov 26 05:32:57 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25847 for ; Fri, 26 Nov 2004 05:32:57 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAQA7OJo001016; Fri, 26 Nov 2004 02:07:24 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAQA7O3U001015; Fri, 26 Nov 2004 02:07:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAQA7Ndb001007 for ; Fri, 26 Nov 2004 02:07:23 -0800 (PST) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id iAQAWJXA008051; Fri, 26 Nov 2004 02:32:19 -0800 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id iAQAWI4e008048; Fri, 26 Nov 2004 02:32:18 -0800 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Fri, 26 Nov 2004 02:32:18 -0800 (PST) From: "william(at)elan.net" To: Dean Anderson cc: MXCOMP Subject: Re: Complaint on personal attack by Matthew Elvey In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dean, Without commenting on the details of your complaint may I remind you that this is no longer IETF WG mail list and so no longer operates under IETF rules. If you don't like something here, you should either contact mail list administrator (in private preferably) or simply unsubscribe. On Fri, 26 Nov 2004, Dean Anderson wrote: > > First, I didn't participate in the FTC conference Mr Elvey seems to be > reporting on in his message, nor have I even made any comments on it, yet. > Why I would be attacked in a report about an FTC conference is beyond > reason. Mr. Elvey is making a purely malicious attack on me in violation > of IETF and ISOC rules. > > > The following message by Matthew Elvey includes an inappropriate personal > attack in violation of the following sections of the ISOC Code of Conduct: > http://www.isoc.org/members/codeconduct.shtml > > 7 Only offer or claim to offer opinions or services that lie within the > member's actual knowledge or competence. > > 8 In the case of financial or material conflict between personal and > professional interests, or between two professional interests, declare > this conflict to all interested parties and if appropriate in public. > > 9 Respect the generally accepted norms of Internet etiquette for human > communications, especially by avoiding communications that are false or > are likely to be considered as discourteous, objectionable, malicious, > unwanted, or causing unjustified loss of prestige. Avoid fraudulent or > deceptive statements. > > 11 Treat all users and colleagues fairly and on equal terms. > > > And the message violates the following sections of the IETF Guidelines for > Conduct RFC 3184: > http://www.ietf.org/rfc/rfc3184.txt?number=3184 > > 1. IETF participants extend respect and courtesy to their colleagues > at all times. > > IETF participants come from diverse origins and backgrounds and > are equipped with multiple capabilities and ideals. Regardless of > these individual differences, participants treat their colleagues > with respect as persons--especially when it is difficult to agree > with them. Seeing from another's point of view is often > revealing, even when it fails to be compelling. > English is the de facto language of the IETF, but it is not the > native language of many IETF participants. Native English > speakers attempt to speak clearly and a bit slowly and to limit > the use of slang in order to accommodate the needs of all > listeners. > > 2. IETF participants develop and test ideas impartially, without > finding fault with the colleague proposing the idea. > > We dispute ideas by using reasoned argument, rather than through > intimidation or ad hominem attack. Or, said in a somewhat more > IETF-like way: > > "Reduce the heat and increase the light" > > > > ========================================================================= > Message-ID: <419EE9B5.6030704@elvey.com> > Date: Sat, 20 Nov 2004 01:52:37 -0500 > From: Matthew Elvey > User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) > X-Accept-Language: en-us, en > MIME-Version: 1.0 > To: MXCOMP > Subject: FTC stuff 0) Lies 1)Yahoo & DK. 2)GoDaddy DNS & SPF & CSV. > 3)Dean & FUSSP. 4)Testing 5)EFF, Anonymity. > > [...] > =-=-=-=-=-= > 3)Dean & FUSSP. > Dean Anderson of av8 seems best largely ignored, > given odd evidence suggesting his views are that DNSBLs are terribly, > horribly, drastically, irretreivably bad and other ranting: > http://vesuvio.ipv6.tilab.com/pipermail/ietf_censored/2004-May/006714.html > (and > http://vesuvio.ipv6.tilab.com/pipermail/ietf_censored/2004-June/006933.html > and the results of #whois 130.105.36.66 and > http://moensted.dk/spam/messages/20020716-dean+av8.com.txt ); forgive me > if I'm skeptical about his statements. > I am confident an implemented long term solution that will keep inboxes > functional and nearly spam-free is in the not-so-distant future. It's > not like a perpetual motion machine: un-inventable. Plus, Information > Theory is cool and fun. I've found it useful for pointing me in the > right direction for handling this plague. From owner-ietf-mxcomp@mail.imc.org Fri Nov 26 06:42:28 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29945 for ; Fri, 26 Nov 2004 06:42:28 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAQBBUgu070984; Fri, 26 Nov 2004 03:11:30 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAQBBUMj070973; Fri, 26 Nov 2004 03:11:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAQBBS1l070875 for ; Fri, 26 Nov 2004 03:11:28 -0800 (PST) (envelope-from dean@av8.com) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id iAQBBLQ9025700 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 26 Nov 2004 06:11:21 -0500 Date: Fri, 26 Nov 2004 06:11:21 -0500 (EST) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: "william(at)elan.net" cc: MXCOMP Subject: Re: Complaint on personal attack by Matthew Elvey In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The IETF left the list operational at the request of members. So it is still run 'under the IETF', and still under the IETF rules. The IETF and ISOC rules apply to all IETF related activities, whether at meetings, bofs or on IETF lists. The list is however, not part of a working group, and thus cannot approve RFCs. --Dean On Fri, 26 Nov 2004, william(at)elan.net wrote: > > Dean, > > Without commenting on the details of your complaint may I remind you that > this is no longer IETF WG mail list and so no longer operates under IETF > rules. If you don't like something here, you should either contact mail > list administrator (in private preferably) or simply unsubscribe. > > On Fri, 26 Nov 2004, Dean Anderson wrote: > > > > > First, I didn't participate in the FTC conference Mr Elvey seems to be > > reporting on in his message, nor have I even made any comments on it, yet. > > Why I would be attacked in a report about an FTC conference is beyond > > reason. Mr. Elvey is making a purely malicious attack on me in violation > > of IETF and ISOC rules. > > > > > > The following message by Matthew Elvey includes an inappropriate personal > > attack in violation of the following sections of the ISOC Code of Conduct: > > http://www.isoc.org/members/codeconduct.shtml > > > > 7 Only offer or claim to offer opinions or services that lie within the > > member's actual knowledge or competence. > > > > 8 In the case of financial or material conflict between personal and > > professional interests, or between two professional interests, declare > > this conflict to all interested parties and if appropriate in public. > > > > 9 Respect the generally accepted norms of Internet etiquette for human > > communications, especially by avoiding communications that are false or > > are likely to be considered as discourteous, objectionable, malicious, > > unwanted, or causing unjustified loss of prestige. Avoid fraudulent or > > deceptive statements. > > > > 11 Treat all users and colleagues fairly and on equal terms. > > > > > > And the message violates the following sections of the IETF Guidelines for > > Conduct RFC 3184: > > http://www.ietf.org/rfc/rfc3184.txt?number=3184 > > > > 1. IETF participants extend respect and courtesy to their colleagues > > at all times. > > > > IETF participants come from diverse origins and backgrounds and > > are equipped with multiple capabilities and ideals. Regardless of > > these individual differences, participants treat their colleagues > > with respect as persons--especially when it is difficult to agree > > with them. Seeing from another's point of view is often > > revealing, even when it fails to be compelling. > > English is the de facto language of the IETF, but it is not the > > native language of many IETF participants. Native English > > speakers attempt to speak clearly and a bit slowly and to limit > > the use of slang in order to accommodate the needs of all > > listeners. > > > > 2. IETF participants develop and test ideas impartially, without > > finding fault with the colleague proposing the idea. > > > > We dispute ideas by using reasoned argument, rather than through > > intimidation or ad hominem attack. Or, said in a somewhat more > > IETF-like way: > > > > "Reduce the heat and increase the light" > > > > > > > > ========================================================================= > > Message-ID: <419EE9B5.6030704@elvey.com> > > Date: Sat, 20 Nov 2004 01:52:37 -0500 > > From: Matthew Elvey > > User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) > > X-Accept-Language: en-us, en > > MIME-Version: 1.0 > > To: MXCOMP > > Subject: FTC stuff 0) Lies 1)Yahoo & DK. 2)GoDaddy DNS & SPF & CSV. > > 3)Dean & FUSSP. 4)Testing 5)EFF, Anonymity. > > > > [...] > > =-=-=-=-=-= > > 3)Dean & FUSSP. > > Dean Anderson of av8 seems best largely ignored, > > given odd evidence suggesting his views are that DNSBLs are terribly, > > horribly, drastically, irretreivably bad and other ranting: > > http://vesuvio.ipv6.tilab.com/pipermail/ietf_censored/2004-May/006714.html > > (and > > http://vesuvio.ipv6.tilab.com/pipermail/ietf_censored/2004-June/006933.html > > and the results of #whois 130.105.36.66 and > > http://moensted.dk/spam/messages/20020716-dean+av8.com.txt ); forgive me > > if I'm skeptical about his statements. > > I am confident an implemented long term solution that will keep inboxes > > functional and nearly spam-free is in the not-so-distant future. It's > > not like a perpetual motion machine: un-inventable. Plus, Information > > Theory is cool and fun. I've found it useful for pointing me in the > > right direction for handling this plague. > > > -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From owner-ietf-mxcomp@mail.imc.org Fri Nov 26 08:05:15 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06284 for ; Fri, 26 Nov 2004 08:05:15 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAQCSwpN027451; Fri, 26 Nov 2004 04:28:58 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAQCSw3O027450; Fri, 26 Nov 2004 04:28:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail82.messagelabs.com (mail82.messagelabs.com [195.245.231.67]) by above.proper.com (8.12.11/8.12.9) with SMTP id iAQCSvYX027099 for ; Fri, 26 Nov 2004 04:28:58 -0800 (PST) (envelope-from Danny_Angus@slc.co.uk) X-VirusChecked: Checked X-Env-Sender: Danny_Angus@slc.co.uk X-Msg-Ref: server-6.tower-82.messagelabs.com!1101472267!5584455!1 X-StarScan-Version: 5.4.2; banners=slc.co.uk,-,- X-Originating-IP: [195.99.121.125] Received: (qmail 24901 invoked from network); 26 Nov 2004 12:31:07 -0000 Received: from mail1.slc.co.uk (HELO drsneaky.slc.co.uk) (195.99.121.125) by server-6.tower-82.messagelabs.com with SMTP; 26 Nov 2004 12:31:07 -0000 Received: from emerald.slc.co.uk (emerald.slc.co.uk) by drsneaky.slc.co.uk (Content Technologies SMTPRS 4.3.12) with ESMTP id ; Fri, 26 Nov 2004 12:28:45 +0000 Subject: Re: Complaint on personal attack by Matthew Elvey To: Dean Anderson Cc: MXCOMP X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: Danny Angus Date: Fri, 26 Nov 2004 12:28:44 +0000 X-MIMETrack: Serialize by Router on Emerald/SLC (Release 6.5.2|June 01, 2004) at 26/11/2004 12:28:45 MIME-Version: 1.0 Content-type: text/plain; charset="us-ascii" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dean At the risk of provoking you further I would say that Matthew's post is not particularly unfair. You do indeed appear to hold views on dealing with spam at odds with very many others, and you communicate that robustly. Matthew reminds us of views you have expressed in public, in fact I remember reading them first time round. You can't complain about that surely? I admit that he could have worded this more tactfully, as an attack on what your opinion rather than your personality, but sometimes it becomes necessary for our sanity to cut through the crap and get on with the work in hand. You should perhaps consider whether your reaction is more likely to engender yourself to others or to reinforce Matthew's point. d. *************************************************************************** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limi! ted. This footnote also confirms that this email message has been swept for the presence of computer viruses. ************************************************************************** From owner-ietf-mxcomp@mail.imc.org Fri Nov 26 11:39:35 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27190 for ; Fri, 26 Nov 2004 11:39:35 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAQGCAFs065376; Fri, 26 Nov 2004 08:12:10 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAQGCAAq065375; Fri, 26 Nov 2004 08:12:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAQGC9hQ065334 for ; Fri, 26 Nov 2004 08:12:09 -0800 (PST) (envelope-from dean@av8.com) Received: from antigua.nuspex.com (citation2.av8.net [130.105.19.2]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id iAQGCAkN031121 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 26 Nov 2004 11:12:11 -0500 Date: Fri, 26 Nov 2004 11:12:09 -0500 (EST) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Danny Angus cc: MXCOMP Subject: Re: Complaint on personal attack by Matthew Elvey In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 26 Nov 2004, Danny Angus wrote: > Dean > > At the risk of provoking you further I would say that Matthew's post is not > particularly unfair. > You do indeed appear to hold views on dealing with spam at odds with very > many others, and you communicate that robustly. "At odds" with zealots perhaps. But I've been in this business a long time, and have been dealing with nutty zealots for many, many years. > Matthew reminds us of views you have expressed in public, in fact I > remember reading them first time round. > You can't complain about that surely? I complain about the attack. He doesn't dispute the views. If he had facts to dispute them, he would present them. Instead, he just says they should be ignored. Facts being far too inconvenient for radicals. > I admit that he could have worded this more tactfully, as an attack on > what your opinion rather than your personality, but sometimes it becomes > necessary for our sanity to cut through the crap and get on with the > work in hand. Yes, I'm all for cutting through the crap. > You should perhaps consider whether your reaction is more likely to > engender yourself to others or to reinforce Matthew's point. The point that is made by my complaint is that Matthew has no point. If he had a point, he would have made it, rather than engage in personal attack. Personal attack is the method of those who don't want to admit they are wrong. -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From owner-ietf-mxcomp@mail.imc.org Fri Nov 26 11:41:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27503 for ; Fri, 26 Nov 2004 11:41:06 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAQG4PFm050970; Fri, 26 Nov 2004 08:04:25 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAQG4PTT050969; Fri, 26 Nov 2004 08:04:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAQG4KmU050786 for ; Fri, 26 Nov 2004 08:04:21 -0800 (PST) (envelope-from dean@av8.com) Received: from antigua.nuspex.com (citation2.av8.net [130.105.19.2]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id iAQG4IZo030938 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 26 Nov 2004 11:04:19 -0500 Date: Fri, 26 Nov 2004 11:04:17 -0500 (EST) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Matthew Elvey cc: MXCOMP Subject: Re: FTC stuff 0) Lies 1)Yahoo & DK. 2)GoDaddy DNS & SPF & CSV. 3)Dean & FUSSP. 4)Testing 5)EFF, Anonymity. In-Reply-To: <419EE9B5.6030704@elvey.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, 20 Nov 2004, Matthew Elvey wrote: > =-=-=-=-=-= > 3)Dean & FUSSP. > Dean Anderson of av8 seems best largely ignored, > given odd evidence suggesting his views are that DNSBLs are terribly, > horribly, drastically, irretreivably bad and other ranting: That DNSBLs are revenge-oriented is a court-established fact. Alan Brown of ORBS lost three lawsuits as an immediate result. MAPS was successfully sued for blocking a non-spam site. SPEWS is specifically organized to remain anonymous so that it can't be sued. Others have "reorganized" in foriegn counties to avoid suits (ORDB, ORBL) Some have organized with college students with no assets as operators to be immune from lawsuits. That the DNSBLs are very nearly universally abuse-oriented is also long and well-established by history. A frequent plaint on spam lists is "Where can I find a good blacklist?" because there aren't any good blacklists. If they provided spam solutions of any sort, we wouldn't be here. See www.iadl.org for some history on abusive blacklist operators. See also www.dotcomeon.com for volumes of information and press coverage on blacklist operators and abuse committed by blacklist operators. > http://vesuvio.ipv6.tilab.com/pipermail/ietf_censored/2004-May/006714.html > (and > http://vesuvio.ipv6.tilab.com/pipermail/ietf_censored/2004-June/006933.html There is nothing particularly incredible about thest two above. I've outlined the information theory in detail, and have discussed it privately with PH.D's who've written seminal papers in the field of information theory. So far, no one has been able to find any flaw in the analysis, though it is still a ways from a formal proof. Speaking of ranting: Registrant: The Elvey.com IT Consulting Group 3042 SacramentoGD ST, Suite 04. Illegally harvested from godaddy DB if mail received at this address San Francisco, California 94115 United States Registered through: GoDaddy.com Domain Name: ELVEY.COM Created on: 21-Mar-99 Expires on: 21-Mar-05 Last Updated on: 14-Mar-04 Administrative Contact: Elvey, Matthew EmailToThisAddressNotFromGodaddyIsSpamAndIsExpresslyForbiddenWithoutPayingAFee ToTEP.ByUsingThisAddressYouAgreeToTheseTermsOfUsage.YouAgreeToUseAllowOrEnableItsUseOnlyUnderTheTerm sOfwww.elvey.comSlashspamoff.htm@me2004.fastmail.fm The Elvey.com IT Consulting Group 3042 SacramentoGD ST, Suite 04. Illegally harvested from godaddy DB if mail received at this address San Francisco, California 94115 United States (415) 555-1212 will provide the number Fax -- Technical Contact: Elvey, Matthew EmailToThisAddressNotFromGodaddyIsSpamAndIsExpresslyForbiddenWithoutPayingAFee ToTEP.ByUsingThisAddressYouAgreeToTheseTermsOfUsage.YouAgreeToUseAllowOrEnableItsUseOnlyUnderTheTerm sOfwww.elvey.comSlashspamoff.htm@me2004.fastmail.fm The Elvey.com IT Consulting Group 3042 SacramentoGD ST, Suite 04. Illegally harvested from godaddy DB if mail received at this address San Francisco, California 94115 United States (415) 555-1212 will provide the number Fax -- This guy thinks his address is illegally harvested if he receives Postal mail at his godaddy Postal Address. That's pretty fringe. Another hoot: http://www.elvey.com/Spam%20Offer%20by%20Matthew%20Elvey.htm And yet another that shows Mr. Elvey: http://lists.essential.org/pipermail/am-info/Week-of-Mon-20001106/004270.html Here's a quote of Mr. Elvey: "Hmm. The owner of a company* that developed a version of Emacs once told me that GNU Emacs had tons of (unauthorized) source code from his company's product in it. I don't know what the merits were (he appeared to be an upstanding guy!) but the point I want to make is that he decided that there was nothing his company could do about it. *which I don't think it would be appropriate to name in a public forum like this" > and the results of #whois 130.105.36.66 and And just what about the results of this query discredits me? I suppose you are unaware that the Open Software Foundation developed open systems (Motif, OSF/1, DCE, Unix98, etc) and joined with the X Consortium (maybe you've heard of the X Window System), and X/Open (XPG/4, SQL, etc) to form The Open Group. I worked for the OSF for many years, and they are a customer now. They have made me authoritative for 130.105/16. Or perhaps you are just associated with the liars over at SORBS.NET, who claim that 130.105/16 is stolen. They also claim that 198.3.136/21 is stolen, too. But those are lies, and are just two reasons why DNSBLs are (as you say) "terribly, horribly, drastically, irretreivably bad". I've never said this. I've just said they engaged in revenge and are untrustworthy, and that's been shown in many cases. > http://moensted.dk/spam/messages/20020716-dean+av8.com.txt ); forgive me > if I'm skeptical about his statements. For those who didn't bother, the site above has advertised a relay for abuse for a long time. I even took that IP out of production server (leaving a relay to collect the abuse generated by this "Dr. Moensted"'s site.) The URL referenced is a complaint about their unauthorized relay testing, in which they sent 32 messages with fake headers, such as From postmaster@av8.net, etc. This URL is rather obscure, and probably indicates an association between Mr. Elvey and the "Dr. Moensted", who is actually just a kid, not a doctor of any sort. We've gotten thousands of messages as a result of the "anti-spammers" false advertising. So, forgive me if I'm skeptical of Mr. Elvey's statements. > I am confident an implemented long term solution that will keep inboxes > functional and nearly spam-free is in the not-so-distant future. Vixie said this in 1996. We're still waiting. http://www.rhyolite.com/anti-spam/you-might-be.html > It's not like a perpetual motion machine: un-inventable. Plus, > Information Theory is cool and fun. I've found it useful for pointing > me in the right direction for handling this plague. Actually, "un-inventable" is exactly what information theory says about it. And it's no coincidence that thermodynamics was invented to dispel the (concrete, as in spend money) proposals for building perpetual motion machines. Just like the FUSSP proposals today. And its no coincidence that information theory developed from thermodynamics, to figure out the same sorts of questions. -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From owner-ietf-mxcomp@mail.imc.org Fri Nov 26 12:16:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00214 for ; Fri, 26 Nov 2004 12:16:20 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAQGhW5v019949; Fri, 26 Nov 2004 08:43:32 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAQGhWMO019946; Fri, 26 Nov 2004 08:43:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from lv-svr.lumenvox.com (mail.lumenvox.com [206.169.193.45]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAQGhVFT019720 for ; Fri, 26 Nov 2004 08:43:31 -0800 (PST) (envelope-from ThomasGal@LumenVox.com) Received: from PROGTHOMAS ([10.0.0.141]) by lv-svr.lumenvox.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 26 Nov 2004 08:40:24 -0800 Reply-To: From: "Thomas Gal" To: "'william\(at\)elan.net'" , "'Alan DeKok'" Cc: "'MXCOMP'" Subject: RE: A new SMTP "3821" [Re: FTC stuff...........] Date: Fri, 26 Nov 2004 08:43:23 -0800 Organization: LumenVox LLC MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <2D0CA64CDC33E14DA7AB043B8CC4D2BB02758EBC@svr-exc.domain.com> Thread-Index: AcTTTbETRxEnTgFiS9+iCFi+t1we2gAh6TiQ Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0083_01C4D393.FCA1C550" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Message-ID: X-OriginalArrivalTime: 26 Nov 2004 16:40:24.0687 (UTC) FILETIME=[A0C3DFF0:01C4D3D6] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0083_01C4D393.FCA1C550 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Again.....it's incredibly short sited to think that email will be a forever pervasive medium. While we need stopgap measures, trying to redesign SMTP is a waste of time. I think we're all much better off putting our efforts into making sure next generation messaging technologies don't have the same flaws, than bothering a lick with changing SMTP. Perhaps helping to prod everyone into using all the standards that are out there already for mail transport and handling, and implementing them properly is a good idea. The next generation is already on it's way...... -Tom thomasgal@lumenvox.com > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org] On Behalf Of > william(at)elan.net > Sent: Thursday, November 25, 2004 4:18 PM > To: Alan DeKok > Cc: MXCOMP > Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] > > > > On Thu, 25 Nov 2004, Alan DeKok wrote: > > > It's not 1984. 20 years have gone by. SMTP won those > wars and all > > of the protocol wars which followed. No one is arguing > that we should > > replace SMTP with X.400, or any other non-SMTP scheme. I'm > not one of > > the X.400 people. > > I've argued and will be happy to argue again that SMTP needs > to be replaced with new protocol entirely instead of putting > more and more band-aids on 20 year old protocol that was > designed for "simple" mail transactions. > > But creating new mail protocol to replace SMTP would take > long time (both in terms of IETF process to create this new > protocol and process for it to achieve wide-spread adaption) > and spam is a serious problem in our current and immediate > situation of using email so we have to do something with what > we have (i.e. SMTP) to get this under control and only after > that can we take a look at entire thing and see if we can > come up with something better taking into the account all the > lessons with have learned with what works and what does not in SMTP. > > -- > William Leibzon > Elan Networks > william@elan.net > ------=_NextPart_000_0083_01C4D393.FCA1C550 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMCTCCBMQw ggKsoAMCAQICAwDMSDANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNDExMTkxNjA0NDlaFw0w NTExMTkxNjA0NDlaMEExGDAWBgNVBAMTD0NBY2VydCBXb1QgVXNlcjElMCMGCSqGSIb3DQEJARYW dGhvbWFzZ2FsQGx1bWVudm94LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKmW HVujvQPzLRxeFDw0oQywCwWy8UfIw2zW16AvERBWu1Q9lpnuN/lD+G0FK8QGcyenXMKmBZ8I61Oe KnnuLzEoSkkGklIH5CMhf1ANUecnlfHVF6ofAzdwcUoFUnhe4ZcvgOVv1JjGT7Qxp/7xHEQqIPJQ qt2WaSqXcLUeF6n69HRDGtSgPHsPGkaZzg+ArKuI1Jou0vrjPHHZcYCL0X26ig5GW6itAYNi9uz2 yzdUUYWL/vy0ZEQkIrStHlGr5nZGoxYW+X99z4G4pYOlWHvfTTD8Pe8sbbGfHWXX8++KilDAInEx K3XMBx4Dmm8nbOo5058XZPSSMJVwxxqWvO0CAwEAAaOBjDCBiTAMBgNVHRMBAf8EAjAAMFYGCWCG SAGG+EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVy IHRvIGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAhBgNVHREEGjAYgRZ0aG9tYXNnYWxAbHVtZW52b3gu Y29tMA0GCSqGSIb3DQEBBAUAA4ICAQB9Ld6CCMyIKqePp8KXWoWOJcijRMxF5BJe/F/xApg12EQE hLEaOzqS8ltdrXjvkRxuifjM/79ApcKkb+BMxTJ43+hkzSO61rR5hwdQRZvrCgGPg66JcXTqpqYe j5mEOJSkpa9qS0nZRD6eMN2ci+vmCyHvdH+l6veUPJRPt42qZ26zZMYJSz591VNycx0Bie1xJ23A /n6JuBu7sAsLKtfncNTQaCX+KdcxEidTmy6YhzfUBtQPA92WRIOqcTz9tLzgAggRu/4ka/Qx2zVE fEJzGJ84DQE8Q3gcKhoLEyjNUemypRaij1Fgc+I2YXoolTgFMlcr/YPgzu/q7vQSbOm+3f2OoZG9 SK7zLg8S39f8XNNlsv9wwXG9TFeuveiMnDClAsFhLVFfB41nYkk9JISiCQC/+x55hspmKTk3B2Rr cjROCT5wCkBjZl9KEcMGu0wF1V7JQCTv2tY2rl04BuW+/pSNeV5xUkxUZYl6pIuwdP5e0H5ioNNc Exu6yVNguL7mP8IntnS1UUEuHXRPDUo256+4lZT56zs7iNbLIWjVo7K2ZpBT/T88RG/xjZ8JFSuh VzjRGXJvE3Rm+9Ja8GlH9JqCLXqRDwRwmtZg11Kw68t3lqzTcVo3G8GTZSs1Xxye3PGW1fwhvdUw aJXy+qUSdQRbUqQRI2qwXsq3iwhUIDCCBz0wggUloAMCAQICAQAwDQYJKoZIhvcNAQEEBQAweTEQ MA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQD ExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2Vy dC5vcmcwHhcNMDMwMzMwMTIyOTQ5WhcNMzMwMzI5MTIyOTQ5WjB5MRAwDgYDVQQKEwdSb290IENB MR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzCCAiIwDQYJKoZI hvcNAQEBBQADggIPADCCAgoCggIBAM4iwOJGfew2KAdQlvKgM0CMS/E7Zj8x5WsCNtvWfPbxiI9O dzYFQZX5CfASz0aGc2C3bn7owFhkrs2wrUUXDGP6Zwro1tK/PueYxPBM+uADuzVdbCHeniDZus1m Mjdy+vcI9cfNWMmO5w5e6j7+HKEUChVshoRbZGYqeqlLU3n1iKJ77i8KYSuNsn5NVqUT7Orakp6s REEeWGBlBWb4wES9y5T3Qn4L92VomFEF8PMFkQQdGxeC7MhXu8NreojxsHLMJVsgkewWAhKPMukX GEjQxwUuAjBCuCWcBWs/qjqn61NI9+jStgeY3BvGNH9/yRyCegVYKwhb8ziiqxddZsmY154Qi6LS 3XSa93EMcmDfzW+YM52WNHY+JHqSsA6VHm/moEU4R6rXQe1KtxL21xuDig8u2Am2WdeqBP/Sk31o Lt2LS6tYui+N6pWnoMNUiaX724tRIp2yw74RviyRhouWeK0g04ovGj/G0FFlhyGxGQFlf0Uch/V8 0EFMTymYIf0zH3UMBFH6GXfb1BQc7oHDHfWYt2kGkSLdAFDMgTGsEgd7ONpoW+Yr1H7JX63o63JM 8wHlSyC/mqZXypEAAYuhdSE3tWMNZz5GT3AgZ87F1lnbAuDw0svNumK3kEHo3SDkKbxkKULIItx4 mv9D7JgbCVFLWlrCcfHEy3Op5aELAgMBAAGjggHOMIIByjAdBgNVHQ4EFgQUFrUyG9TH8+DmjvO9 0rA67rI5GNEwgaMGA1UdIwSBmzCBmIAUFrUyG9TH8+DmjvO90rA67rI5GNGhfaR7MHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0Eg Q2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3Jn ggEAMA8GA1UdEwEB/wQFMAMBAf8wMgYDVR0fBCswKTAnoCWgI4YhaHR0cHM6Ly93d3cuY2FjZXJ0 Lm9yZy9yZXZva2UuY3JsMDAGCWCGSAGG+EIBBAQjFiFodHRwczovL3d3dy5jYWNlcnQub3JnL3Jl dm9rZS5jcmwwNAYJYIZIAYb4QgEIBCcWJWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZy9pbmRleC5waHA/ aWQ9MTAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJF RSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5jYWNlcnQub3JnMA0GCSqGSIb3DQEBBAUAA4ICAQAo x+6cggK6XIASyjUKHYFviWqZzPJoD3+n4Y1YlT698gbDkFqstWD2mUMBo4hwnJ1inaSHr2dYDTA2 O+atSNPLdAKGcT7iKwNo8TRiQEY7U+oo9Kz7ZpVTik1d/TvZYNfKeWk7sWWSpsaBglyczetNAYql 3xFVqhXKHzfAgphwYdtqfJajji5UPk8hqZDv3IK/3OhFrU2Qcwg8lGWwBJl2f+K8wmoVqpcENyTY HpRObQ5RvtbEj8qWbfdD3+gwZSc7e7tDQ2PEQ/ey7GjM4RmOIvuY4XtaPgE3O4sIsKLzlU4ay5vN mrHbsnDwLUrb2LDjb0VIMxL//jwyKlT3xPeK8Igjwkf+ZHpxwNEepmOwB36kL9MBj9yfK7bGCKkP k0gl/BL9n0Lc88Q+9lew191p0QZ3NApL0sqg/xzGjMkWvsTMMjdoc18I+1H3SVM2BQqVAkzyeRoQ 9tg6dZzzHfGiDXBnhhuzFvUv5aTreYb5PQvCcwulmaxv/Ge45S8LphgkjXvRSDUpGECsk2DhloZQ tHpZ2I8hC5/PgpHGO79r3AeRuZdWI6q2bJTGSAY85M5OquT2LwncU28u/HTrOmOZwqasibynskSg DYoQ42zyJMv6m59wRy7eFIvUsiAJlqJk8SQc3KE1nBWy1LxVLn0G9ZwOVfRa1pPadq0lc0zFQzGC A5wwggOYAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2Fj ZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJ ARYSc3VwcG9ydEBjYWNlcnQub3JnAgMAzEgwCQYFKw4DAhoFAKCCAfAwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQxMTI2MTY0MzIyWjAjBgkqhkiG9w0BCQQxFgQU x27MU24hUuhdYcmPrXRe+MGzfZ0wZwYJKoZIhvcNAQkPMVowWDAKBggqhkiG9w0DBzAOBggqhkiG 9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhow CgYIKoZIhvcNAgUwgZEGCSsGAQQBgjcQBDGBgzCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYD VQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRo b3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDAMxIMIGTBgsqhkiG9w0B CRACCzGBg6CBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2Vy dC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEW EnN1cHBvcnRAY2FjZXJ0Lm9yZwIDAMxIMA0GCSqGSIb3DQEBAQUABIIBAB7EYNcvYjJt8wp3gjhr 4/iPDCiNkGsLLbZ8ldCVrB6FgfGoGB64gViNWHcOkplcHii0gzKp2xzuUGTVJtvYfl2fCpUYLlbf 337jVs5ELMjxp3VUAIANS9FhsiZWki16oFBf3LEDJDi678QkEyIcTsVO3Gn5uW0bl4OY53YgdSL2 dF2Ci3RCzDfbIO8vuEYIJxU84X7CQ6opgf2KJ9ZyQl4/u1dsnNHctTvs8eOSEj9DFeodRiOA5CRk llT+6UL5SlLO+uh1lk6/fsyR9azGFP5l7j8jF80eo05RMb2TphdTYD/RbhL8kxk37YFOY+MrnRrV YUji7ZxXTLz+I7qfKyIAAAAAAAA= ------=_NextPart_000_0083_01C4D393.FCA1C550-- From owner-ietf-mxcomp@mail.imc.org Fri Nov 26 19:23:03 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10995 for ; Fri, 26 Nov 2004 19:23:01 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAQNhYng037243; Fri, 26 Nov 2004 15:43:34 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAQNhYkX037231; Fri, 26 Nov 2004 15:43:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (listserv.winserver.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id iAQNhSZA036965 for ; Fri, 26 Nov 2004 15:43:29 -0800 (PST) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.3) for ietf-mxcomp@imc.org; Fri, 26 Nov 2004 18:49:24 -0500 Received: from ([65.2.214.91]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.3) with SMTP id 3388395063; Fri, 26 Nov 2004 18:49:23 -0500 Message-ID: <004a01c4d411$ada15320$6401a8c0@hdev1> From: "Hector Santos" To: "David Woodhouse" , "Alan DeKok" Cc: "MXCOMP" References: <20041125231151.9B4D516F4C@mail.nitros9.org> <1101456711.19141.57.camel@localhost.localdomain> Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] Date: Fri, 26 Nov 2004 18:42:59 -0500 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "David Woodhouse" To: "Alan DeKok" Cc: "MXCOMP" Sent: Friday, November 26, 2004 3:11 AM Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] > It does sound like I misinterpreted you in the same way, for which I > apologise. I'm not arguing with your actual position. To fix spoofing of > addresses is just a band-aid, as you said. But it's all that's on offer > right now. I'm saying we can do _that_ without fundamental changes. And I'm saying you can not. To suggest this, it is to presume that the solution is: - end point to endpoint, or - post smtp related. Now, you might be thinking of a software (in fact, I'm sure you are) that offer a "plug and play" capability, a mfilter or a ACL - but means change. But it is more technically deeper than this and since you fail to recognize all this, it means you are exhibiting a "emotional response," not I, to what has been pointed out many times. You (speaking in general) need to look at the mixed policy issues to understand this better. You need to look at each state point in the state machine to see how it "fits" in the scheme being proposed or vice-versa. What we have here are kludged solutions that may or may not have a "chicken and egg" problem. Believe it or not, good systems do not violate SMTP protocols. It is only the abusers that are taking advantage of the system. The "fundamental" reevaluation of SMTP is not to "alter it" so that it breaks the infrastructure, but rather to strenghthen what is already there. For vendors in the market place, including our own, it is not in our best interest to break customers operations. Yet, we seek to secured it better. In addition, as a vendor, I am very interested in supporting the mandates imposed by our Federal Government laws such as CANSPAM - that means complete email address validation and Topic Identification concepts. Lets look at more specifics. We have essentially one or more of the following: 1) EHLO/HELO validation 2) MAIL FROM validation 3) RCPT TO validation 4) DATA validation, if any 5) Mixed Validation 6) No Validation at 2821 7) Post SMTP validation 8) Bounce Requirements SPF concentrates on #2, and it lost on handling #1 and proper handling of #5. It ignores #3. CSV concentrates on #1, gets lost on SMTP AUTH issues, proper handling of #5 and also ignores #3. SENDER ID like SPF, also gets lost on #4. IIM, YDK concentrates on #4. Keep in mind that the above presumes "changes" to the SMTP system so that the dynamic validation can be included at the transaction level. Some of the schemes "may" also work in post-smtp mode, #7, which from a practical standpoint offers a greater compatibility with the current installed base. However, this has proven to help the distribution of SORBIG generation based e-viruses with #8 so it goes without saying today's AVS ready system promotes dynamic RCPT TO validation #3. I can go on and on with all the other schemes. What they all have in common are conflicts that are relaed to the ambitiguous, "which school of thought" understanding of the SMTP protocol, how SMTP is implemented in various modes of operation, and many cases, a complete ignorance for efficiency. So what I have been proposing since day 1 is let us revisit the protocol, not with a desire to fundamental change it but with a GOAL to better grasp the state machine and how it is being exploited at each state state and also as a mixed policy. The goals are: - To remove the ambiguity on the functional specification. - Introduce the functional specification for state machine validation. - Introduce, if any, new ESMTP protocols to help augment the new SMTP security requirements. Note I did not say "technical specification." There is a major difference in functional vs technical specs. We need to remove the "comments" in the specs that suggest "lets not break the system because of one abuser." In other words, we need to change the "old spirit" of a loosely guarded network of nodes to one that is more mature for today. Now, we can ask, why do we want to do this? Well, you want to do this now only to better understand what are the key issues and how to improve it, but to also allow for the R&D and future developers to have a better summary document to design SMTP software. Of course, you can also say "Why write a new SMTP server when you have open source to work with?" Well, many times, people need to write proprietary systems. But this is would be going off on a tangent. The key issue is understanding the problem in order to solve the problem. Band-aids, while, they can work, what is quite evidence, they lack analysis of how it will actually work within the "current infrasture." I leave you with one example: IIM/YDK, what if a message is properly signed with a proper address by the outbound system, does this mean the client domain name can still be invalid? What if it is not valid? While you may be looking for a partial solution, I on the other hand am looking for a real solution. And yes, I have a full understanding that may not be practical, but at the very least, it is in my nature as an engineer to gain a full understanding of the problem first to better analyze the theorical as well as the practical solution. Sincerely, Hector Santos, CTO Santronics Software, Inc. http://www.santronics.com 305-431-2846 Cell 305-248-3204 Office From owner-ietf-mxcomp@mail.imc.org Fri Nov 26 20:25:26 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16441 for ; Fri, 26 Nov 2004 20:25:25 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAR0t94N008566; Fri, 26 Nov 2004 16:55:09 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAR0t922008565; Fri, 26 Nov 2004 16:55:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (mail.santronics.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id iAR0t8lp008494 for ; Fri, 26 Nov 2004 16:55:08 -0800 (PST) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.3) for ietf-mxcomp@imc.org; Fri, 26 Nov 2004 20:01:08 -0500 Received: from ([65.2.214.91]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.3) with SMTP id 3392699204; Fri, 26 Nov 2004 20:01:07 -0500 Message-ID: <005e01c4d41b$b3012a20$6401a8c0@hdev1> From: "Hector Santos" To: "Chris Haynes" , "MXCOMP" References: <20041120231821.120205@bbfujip> <006101c4d170$336eac90$6401a8c0@hdev1> <80E256FA-3D72-11D9-92D5-000A95B3BA44@hxr.us> <1101398831.8191.9383.camel@hades.cambridge.redhat.com> <042d01c4d398$9ca78310$0200000a@ringo> Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] Date: Fri, 26 Nov 2004 19:54:43 -0500 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit "Chris Haynes" wrote to David WoodHouse: > Please understand, I'm not inviting a reprise of arguments which have taken > place elsewhere, I'm trying to lift the level of debate to one of process > related to the 'definition' of SMTP. > > .... Good analyze and examples of the different viewpoints. You emphasized on the classical forwarding/routing problem currently experienced by the LMAP solutions and summarized with a (rthoritical?) question: > How, and from where, would one get an 'authoritative' ruling about the > conformance or non-conformance of forwarding (using the origin's MAIL FROM with > a new RCPT TO) to the extant SMTP architecture? The more fundamental question as I see it is: Does the process allow for "information" to be available so that a downlink can understand what has occurred at a transition point? If so, when and where? If no, when and/or where it is exposed? On specifics, The SUBMITTER proposal lends itself to this forwarding problem. But it only works in compliant downlinks. The DMP (LMAP) also lends itself using the secondary HELO/EHLO LMAP check when the 2821.MAILFROM LMAP check fails. But it presumes a working DNS secured/exposed HELO/EHLO client domain name. The question I ask (rhetorical) is what "common ground" SMTP level 'trace" information can be done to better transition points. I believe the Received: header lines are our "best" hopes. However, this requires a PAYLOAD transaction. In any case, no matter how I look at the solutions, it always comes down for a downlink to have more information at the transaction SMTP level. A new ESMTP HEAD command keeps common to mind. It solves many of the issues we face, it will help the IIM/YDK and SENDER-ID proposals. It will help resolve the "transition points" forwarding problem. It will help new ideas such as TOPIC identification concepts. I believe very strongly, this would be a great enhancement to the protocol. The expert debaters can argue the merits of how compatibility is address. My simple input here is that ESMTP advertisement indicates a level of scrutiny/security based on compliance. For example, in response to EHLO, it can have: HEAD - Optional HEAD-R - Required HEAD-S - Optional for SPF systems HEAD-A - Required for ANONYMOUS senders etc, don't know, this side of it needs a good analysis. But it is on par with the idea of new systems enforcing new requirements, and new systems also offering some level of backward compatibility. Sincerely, Hector Santos, CTO Santronics Software, Inc. http://www.santronics.com 305-431-2846 Cell 305-248-3204 Office From owner-ietf-mxcomp@mail.imc.org Fri Nov 26 20:58:08 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18540 for ; Fri, 26 Nov 2004 20:58:08 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAR1Rhqv050010; Fri, 26 Nov 2004 17:27:43 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAR1RhO4050009; Fri, 26 Nov 2004 17:27:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (ftp.catinthebox.net [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id iAR1Rg3O049992 for ; Fri, 26 Nov 2004 17:27:43 -0800 (PST) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.3) for ietf-mxcomp@imc.org; Fri, 26 Nov 2004 20:33:48 -0500 Received: from ([65.2.214.91]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.3) with SMTP id 3394659672; Fri, 26 Nov 2004 20:33:47 -0500 Message-ID: <006b01c4d420$437d1790$6401a8c0@hdev1> From: "Hector Santos" To: , "'william\(at\)elan.net'" , "'Alan DeKok'" Cc: "'MXCOMP'" References: Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] Date: Fri, 26 Nov 2004 20:27:21 -0500 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Thomas Gal" To: "'william(at)elan.net'" ; "'Alan DeKok'" Cc: "'MXCOMP'" Sent: Friday, November 26, 2004 11:43 AM Subject: RE: A new SMTP "3821" [Re: FTC stuff...........] > Again.....it's incredibly short sited to think that email will be a forever > pervasive medium. While we need stopgap measures, trying to redesign SMTP is > a waste of time. I think we're all much better off putting our efforts into > making sure next generation messaging technologies don't have the same > flaws, than bothering a lick with changing SMTP. Perhaps helping to prod > everyone into using all the standards that are out there already for mail > transport and handling, and implementing them properly is a good idea. The > next generation is already on it's way...... > That's all fine and dandy. The last revamping in the industry came from one where there was a multiple market of formats and transport systems. No real standard. The "new" internet offered a common ground and thus it became very prudent for market vendors to being the migration towards the new common standard. However, I don't see the "NG" going to have to same effect today, not as a answer to the spam problem. The industry cost would be too vast to have a revamp to a NG. While NG is on its way and many already feel they already have a NG system, such as our own, specifically our issue is the external interface into the system, the INTERNET gating into our backend framework. So in my opinion, it is unrealistic to believe a NG is going to be our "solution." You will still need to deal with the outside world. But this is besides the point. No one, atleast not me, nor anyone else I believe, is suggesting a complete change to the SMTP system. What I am suggesting to look at the protocol to see what is wrong and what can be done TODAY to fix the key issues with it. People who have analyzed it thoroughly along with analyzing the proposal add-ons, can gain from having a common new ESMTP or expected mode of operations. IMO, MARID failed because of this lack of analysis. This lack of analysis has provided a no-win situation for many of the proposals which all come back to the same thing - how is SMTP used. Besides the IP issues with it, one required it to work this way, the other required it to work that way. One doesn't require a change at all while another requires a drastic compliancy change, etc, etc. What are the common issues here? I know some answers to that. Do you (speaking in general)? These needs to be debated widely and IMO, I believe strongly that the proposals will benefit from having a common expectation of how SMTP will work, and then some. Sincerely, Hector Santos, CTO Santronics Software, Inc. http://www.santronics.com 305-431-2846 Cell 305-248-3204 Office From owner-ietf-mxcomp@mail.imc.org Fri Nov 26 21:59:41 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22514 for ; Fri, 26 Nov 2004 21:59:41 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAR2QObl007316; Fri, 26 Nov 2004 18:26:24 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAR2QOIH007315; Fri, 26 Nov 2004 18:26:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from lv-svr.lumenvox.com (mail.lumenvox.com [206.169.193.45]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAR2QJI8007204 for ; Fri, 26 Nov 2004 18:26:19 -0800 (PST) (envelope-from ThomasGal@LumenVox.com) Received: from PROGTHOMAS ([10.0.0.141]) by lv-svr.lumenvox.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 26 Nov 2004 18:23:17 -0800 Reply-To: From: "Thomas Gal" To: "'Hector Santos'" , "'william\(at\)elan.net'" , "'Alan DeKok'" Cc: "'MXCOMP'" Subject: RE: A new SMTP "3821" [Re: FTC stuff...........] Date: Fri, 26 Nov 2004 18:26:16 -0800 Organization: LumenVox LLC MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <2D0CA64CDC33E14DA7AB043B8CC4D2BB02758F63@svr-exc.domain.com> Thread-Index: AcTUH99hPjmejXwgT7uRK0QUXhuUtAAAjEKQ Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00EA_01C4D3E5.6A331280" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Message-ID: X-OriginalArrivalTime: 27 Nov 2004 02:23:17.0671 (UTC) FILETIME=[0E49BB70:01C4D428] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_00EA_01C4D3E5.6A331280 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit inline > However, I don't see the "NG" going to have to same effect > today, not as a answer to the spam problem. The industry > cost would be too vast to have a > revamp to a NG. While NG is on its way and many already > feel they already > have a NG system, such as our own, specifically our issue is > the external interface into the system, the INTERNET gating > into our backend framework. > So in my opinion, it is unrealistic to believe a NG is going to be our > "solution." You will still need to deal with the outside world. > Yes, the industry cost is to great do to ANYTHING that requires abrupt adoption, which is an obvious plug for tools like BATV that depend on no one else to be effective. But I honestly believe that the tradeoff needs to be made, and made in favor of the future at all times. ESPECIALLY in cases like spam and viruses, which are merging anyway, where the problem adapts as soon as a hole is plugged. We need to deal with customers (which is really who we're talking about here) in the now. I'd love to see a comprehensive db/wiki/website cataloging spam behavior much like viruses are by security companies, with testing code and examples for people to reference because that would help us all. And that certainly would involve analyzing the characteristics (I'll avoid failures and weaknesses) of SMTP, but the fact remains that things like SPF/Sender-ID/CSV/BATV/Y! DK/Cisco IIM/ etc. are here to address the situation now. All I was ever trying to point out was that any analysis of SMTP specifically precludes itself from aiding the current situation. > But this is besides the point. No one, at least not me, nor > anyone else I believe, is suggesting a complete change to the > SMTP system. What I am suggesting to look at the protocol to > see what is wrong and what can be done > TODAY to fix the key issues with it. People who have analyzed it > thoroughly along with analyzing the proposal add-ons, can > gain from having a common new ESMTP or expected mode of operations. > Be careful here. Any change is a complete change, and MANY people are saying that. MANY people are saying "so and so is afraid to say SMTP is flawed because it's holy" and "We need to analyze SMTP to fix the problem." Now mind you in that case that's exactly what people are doing. The reality is that most MUAs and MSAs (which frequently are the same or badly classified) as well as many MTA's don't conform to standards completely and that as well is an issue. All of these problems originate from the openness desired by designers of the original internet's conditions. The reality is, that not only is SMTP not perfect for secure(from a authent/author standppoint) transfer, it has no business being involved in it at all. That again is why I keep pressing the forward looking attitude. > IMO, MARID failed because of this lack of analysis. This > lack of analysis > has provided a no-win situation for many of the proposals > which all come back to the same thing - how is SMTP used. > Besides the IP issues with it, one required it to work this > way, the other required it to work that way. > One doesn't require a change at all while another requires a > drastic compliancy change, etc, etc. > Right....how SMTP is used which is improperly. People don't conform. People are not authenticated. Systems are not idiot proofed. People are confused. Obviously the first issue is that perhaps any communications protocol for human interaction MUST have only MUST and SHALL NOT qualifiers. Of course we've moved into an era where *hopefully* people realize the ramifications of non compliance in light of the past. > What are the common issues here? I know some answers to > that. Do you > (speaking in general)? These needs to be debated widely > and IMO, I > believe strongly that the proposals will benefit from having > a common expectation of how SMTP will work, and then some. > I agree in the end. This all kinda leads back to real engineering. QA and process refinement, which can also solve many of the technical burden issues revealed in the RFC on IETF problems and IESG workload. We do indeed need a compliancy change. And a process change. I think a good analysis of the issues here, as well as the aruable issues with IPv6 as well as some of the other protocols which have never been adopted, or failed seriously is in order. This isn't just a simple little protocol. Really it's the future of communication we're looking at here. Alas how to factor in the pragmatic realization of endless struggle? -Tom ------=_NextPart_000_00EA_01C4D3E5.6A331280 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMCTCCBMQw ggKsoAMCAQICAwDMSDANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNDExMTkxNjA0NDlaFw0w NTExMTkxNjA0NDlaMEExGDAWBgNVBAMTD0NBY2VydCBXb1QgVXNlcjElMCMGCSqGSIb3DQEJARYW dGhvbWFzZ2FsQGx1bWVudm94LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKmW HVujvQPzLRxeFDw0oQywCwWy8UfIw2zW16AvERBWu1Q9lpnuN/lD+G0FK8QGcyenXMKmBZ8I61Oe KnnuLzEoSkkGklIH5CMhf1ANUecnlfHVF6ofAzdwcUoFUnhe4ZcvgOVv1JjGT7Qxp/7xHEQqIPJQ qt2WaSqXcLUeF6n69HRDGtSgPHsPGkaZzg+ArKuI1Jou0vrjPHHZcYCL0X26ig5GW6itAYNi9uz2 yzdUUYWL/vy0ZEQkIrStHlGr5nZGoxYW+X99z4G4pYOlWHvfTTD8Pe8sbbGfHWXX8++KilDAInEx K3XMBx4Dmm8nbOo5058XZPSSMJVwxxqWvO0CAwEAAaOBjDCBiTAMBgNVHRMBAf8EAjAAMFYGCWCG SAGG+EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVy IHRvIGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAhBgNVHREEGjAYgRZ0aG9tYXNnYWxAbHVtZW52b3gu Y29tMA0GCSqGSIb3DQEBBAUAA4ICAQB9Ld6CCMyIKqePp8KXWoWOJcijRMxF5BJe/F/xApg12EQE hLEaOzqS8ltdrXjvkRxuifjM/79ApcKkb+BMxTJ43+hkzSO61rR5hwdQRZvrCgGPg66JcXTqpqYe j5mEOJSkpa9qS0nZRD6eMN2ci+vmCyHvdH+l6veUPJRPt42qZ26zZMYJSz591VNycx0Bie1xJ23A /n6JuBu7sAsLKtfncNTQaCX+KdcxEidTmy6YhzfUBtQPA92WRIOqcTz9tLzgAggRu/4ka/Qx2zVE fEJzGJ84DQE8Q3gcKhoLEyjNUemypRaij1Fgc+I2YXoolTgFMlcr/YPgzu/q7vQSbOm+3f2OoZG9 SK7zLg8S39f8XNNlsv9wwXG9TFeuveiMnDClAsFhLVFfB41nYkk9JISiCQC/+x55hspmKTk3B2Rr cjROCT5wCkBjZl9KEcMGu0wF1V7JQCTv2tY2rl04BuW+/pSNeV5xUkxUZYl6pIuwdP5e0H5ioNNc Exu6yVNguL7mP8IntnS1UUEuHXRPDUo256+4lZT56zs7iNbLIWjVo7K2ZpBT/T88RG/xjZ8JFSuh VzjRGXJvE3Rm+9Ja8GlH9JqCLXqRDwRwmtZg11Kw68t3lqzTcVo3G8GTZSs1Xxye3PGW1fwhvdUw aJXy+qUSdQRbUqQRI2qwXsq3iwhUIDCCBz0wggUloAMCAQICAQAwDQYJKoZIhvcNAQEEBQAweTEQ MA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQD ExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2Vy dC5vcmcwHhcNMDMwMzMwMTIyOTQ5WhcNMzMwMzI5MTIyOTQ5WjB5MRAwDgYDVQQKEwdSb290IENB MR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzCCAiIwDQYJKoZI hvcNAQEBBQADggIPADCCAgoCggIBAM4iwOJGfew2KAdQlvKgM0CMS/E7Zj8x5WsCNtvWfPbxiI9O dzYFQZX5CfASz0aGc2C3bn7owFhkrs2wrUUXDGP6Zwro1tK/PueYxPBM+uADuzVdbCHeniDZus1m Mjdy+vcI9cfNWMmO5w5e6j7+HKEUChVshoRbZGYqeqlLU3n1iKJ77i8KYSuNsn5NVqUT7Orakp6s REEeWGBlBWb4wES9y5T3Qn4L92VomFEF8PMFkQQdGxeC7MhXu8NreojxsHLMJVsgkewWAhKPMukX GEjQxwUuAjBCuCWcBWs/qjqn61NI9+jStgeY3BvGNH9/yRyCegVYKwhb8ziiqxddZsmY154Qi6LS 3XSa93EMcmDfzW+YM52WNHY+JHqSsA6VHm/moEU4R6rXQe1KtxL21xuDig8u2Am2WdeqBP/Sk31o Lt2LS6tYui+N6pWnoMNUiaX724tRIp2yw74RviyRhouWeK0g04ovGj/G0FFlhyGxGQFlf0Uch/V8 0EFMTymYIf0zH3UMBFH6GXfb1BQc7oHDHfWYt2kGkSLdAFDMgTGsEgd7ONpoW+Yr1H7JX63o63JM 8wHlSyC/mqZXypEAAYuhdSE3tWMNZz5GT3AgZ87F1lnbAuDw0svNumK3kEHo3SDkKbxkKULIItx4 mv9D7JgbCVFLWlrCcfHEy3Op5aELAgMBAAGjggHOMIIByjAdBgNVHQ4EFgQUFrUyG9TH8+DmjvO9 0rA67rI5GNEwgaMGA1UdIwSBmzCBmIAUFrUyG9TH8+DmjvO90rA67rI5GNGhfaR7MHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0Eg Q2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3Jn ggEAMA8GA1UdEwEB/wQFMAMBAf8wMgYDVR0fBCswKTAnoCWgI4YhaHR0cHM6Ly93d3cuY2FjZXJ0 Lm9yZy9yZXZva2UuY3JsMDAGCWCGSAGG+EIBBAQjFiFodHRwczovL3d3dy5jYWNlcnQub3JnL3Jl dm9rZS5jcmwwNAYJYIZIAYb4QgEIBCcWJWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZy9pbmRleC5waHA/ aWQ9MTAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJF RSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5jYWNlcnQub3JnMA0GCSqGSIb3DQEBBAUAA4ICAQAo x+6cggK6XIASyjUKHYFviWqZzPJoD3+n4Y1YlT698gbDkFqstWD2mUMBo4hwnJ1inaSHr2dYDTA2 O+atSNPLdAKGcT7iKwNo8TRiQEY7U+oo9Kz7ZpVTik1d/TvZYNfKeWk7sWWSpsaBglyczetNAYql 3xFVqhXKHzfAgphwYdtqfJajji5UPk8hqZDv3IK/3OhFrU2Qcwg8lGWwBJl2f+K8wmoVqpcENyTY HpRObQ5RvtbEj8qWbfdD3+gwZSc7e7tDQ2PEQ/ey7GjM4RmOIvuY4XtaPgE3O4sIsKLzlU4ay5vN mrHbsnDwLUrb2LDjb0VIMxL//jwyKlT3xPeK8Igjwkf+ZHpxwNEepmOwB36kL9MBj9yfK7bGCKkP k0gl/BL9n0Lc88Q+9lew191p0QZ3NApL0sqg/xzGjMkWvsTMMjdoc18I+1H3SVM2BQqVAkzyeRoQ 9tg6dZzzHfGiDXBnhhuzFvUv5aTreYb5PQvCcwulmaxv/Ge45S8LphgkjXvRSDUpGECsk2DhloZQ tHpZ2I8hC5/PgpHGO79r3AeRuZdWI6q2bJTGSAY85M5OquT2LwncU28u/HTrOmOZwqasibynskSg DYoQ42zyJMv6m59wRy7eFIvUsiAJlqJk8SQc3KE1nBWy1LxVLn0G9ZwOVfRa1pPadq0lc0zFQzGC A5wwggOYAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2Fj ZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJ ARYSc3VwcG9ydEBjYWNlcnQub3JnAgMAzEgwCQYFKw4DAhoFAKCCAfAwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQxMTI3MDIyNjE1WjAjBgkqhkiG9w0BCQQxFgQU 52qfavFKuHSmR0CitySUQl07Q4kwZwYJKoZIhvcNAQkPMVowWDAKBggqhkiG9w0DBzAOBggqhkiG 9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhow CgYIKoZIhvcNAgUwgZEGCSsGAQQBgjcQBDGBgzCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYD VQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRo b3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDAMxIMIGTBgsqhkiG9w0B CRACCzGBg6CBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2Vy dC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEW EnN1cHBvcnRAY2FjZXJ0Lm9yZwIDAMxIMA0GCSqGSIb3DQEBAQUABIIBAFwdkSSEq+SA0ox5ApVT Mb1I8pEv8bGgRRG9rTYrKv7oN7dLeXSOGGyMd20ikud1161eZgvBpACtrY551KlSrp9SC5sjCLsQ tgHFsJYZajQFblYdNWXgU1tZM/afJUFkYeIaeWD5HAH7YeYrlJ+XAgAjH+uPwH0A6hCZLtocjy5C Ff9UnwQU39U95nZ1vodHZAqQmlyPG+ez0sGgCUIhPle7buLCzSVXexHNsyaTv/OatqHse5IHey/+ vZZUD5edywK4oUVu/ZsnwRxPnWjO9CANOlrVxEFqhVXsK+Nh1vW3x7K3mKE3Ffr5hk3I1zPVswh6 bPGcjWv1x9T49OeXaq4AAAAAAAA= ------=_NextPart_000_00EA_01C4D3E5.6A331280-- From owner-ietf-mxcomp@mail.imc.org Sun Nov 28 10:53:40 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23559 for ; Sun, 28 Nov 2004 10:53:40 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iASFC1Hv057482; Sun, 28 Nov 2004 07:12:01 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iASFC1hO057481; Sun, 28 Nov 2004 07:12:01 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iASFC0VL057444 for ; Sun, 28 Nov 2004 07:12:00 -0800 (PST) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id CFB3116E2A for ; Sun, 28 Nov 2004 10:23:41 -0500 (EST) From: "Alan DeKok" To: "MXCOMP" Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] In-Reply-To: Your message of "Fri, 26 Nov 2004 09:16:21 GMT." <042d01c4d398$9ca78310$0200000a@ringo> Date: Sun, 28 Nov 2004 10:23:41 -0500 Message-Id: <20041128152341.CFB3116E2A@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Chris Haynes" wrote: > Please understand, I'm not inviting a reprise of arguments which have taken > place elsewhere, I'm trying to lift the level of debate to one of process > related to the 'definition' of SMTP. > > I'll first just re-state the problem and give it bounds. That's the best summary I've seen to date. My question now is, (using the generic "you"): What do you mean, the "same" message is being forwarded? > How, and from where, would one get an 'authoritative' ruling about > the conformance or non-conformance of forwarding (using the origin's > MAIL FROM with a new RCPT TO) to the extant SMTP architecture? I would like an answer to that question, too. .forward files are not required for SMTP to work. Entirely equivalent functionality can be obtained without using a third parties name in "MAIL FROM". That functionality requires changes to the sites using .forward files, and nothing else. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Sun Nov 28 10:53:42 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23579 for ; Sun, 28 Nov 2004 10:53:42 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iASF1EJD041812; Sun, 28 Nov 2004 07:01:14 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iASF1EZ1041811; Sun, 28 Nov 2004 07:01:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iASF14V8041389 for ; Sun, 28 Nov 2004 07:01:07 -0800 (PST) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 4CFA716E2A for ; Sun, 28 Nov 2004 10:12:32 -0500 (EST) From: "Alan DeKok" To: MXCOMP Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] In-Reply-To: Your message of "Fri, 26 Nov 2004 08:11:51 GMT." <1101456711.19141.57.camel@localhost.localdomain> Date: Sun, 28 Nov 2004 10:12:32 -0500 Message-Id: <20041128151232.4CFA716E2A@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Woodhouse wrote: > But it seems you were talking of problems with mail in general while I > was concentrating solely on spoofing, which is a special case -- one of > the band-aids you mention. I apologise for misinterpreting you and > attributing to you a belief which is not yours. Thank you. I can't ask for anything more. > Are you saying you do _not_ believe that in order to fix the spoofing > problem we must make incompatible changes to the way SMTP works > universally? I've seen no evidence that such a change is required. However, IF there are no better methods, then I am prepared to accept that such a change is required. For many discussions I've been involved in, people ignore the "IF", and go on a tangent. That's been a serious source of miscommunication. > That you believe we can achieve it by only making changes at the > endpoint sites which want to take advantage of any new scheme? I hope that's true. It certainly looks that way. > > Therefore, whether people admit it or not, the SMTP model > > *is* open for changes, and *is* being changed. > > Backward-compatible change within the scope of the existing system, yes. Again, who decides what's in scope, and what's not? If my domain has no users with ".forward" files at other domains, then implementing RMX/SPF/whatever doesn't break forwarding for *my* users. The argument against those proposals then becomes "We have .forward files, so we won't be implementing RMX, and we don't want you to implement it, either". > [ re: who can propose what changes ] > > Indeed -- and it's a very hard one to answer. What we _can_ say is that > changes which are limited to participating sites are a lot easier than > changes which must be implemented ubiquitously in order for the system > to work correctly. As a toy proposal, a simple solution to the .forward problem is to replace the .forward files with a script, which adds a header like: X-RFC2821-Original-Bounce-Path: : The script can then send the message, using the original "rcpt-to" as the new "mail-from", and accept the bounces. When a bounce comes back, the script can look for it's name in that field, and bounce the message in turn to the original "mail-from". Add some authentication so the field can't be spoofed, maybe some encryption so it's private, and a site using ".forward" files can upgrade them all to a functionally equivalent form, which does NOT require using a third parties name in "MAIL FROM". No interaction with other sites is required. Anyone familiar with Sendmail's rules could probably add something like that in a few hours, and most users wouldn't even have to update the contents of their ".forward" files. The only reason that people were using .forward files is that it was easy, it worked, it didn't cause problems for other people until recently, and there is always resistence to change. > I'm not arguing with your actual position. To fix spoofing of > addresses is just a band-aid, as you said. But it's all that's on offer > right now. I'm saying we can do _that_ without fundamental changes. Yes. But there has been near-zero discussion about what the "SMTP mode" really is. The current SMTP "model" is a collection of RFC's, implementation decisions, deployment decisions, and other ideas in peoples heads. For the model to be clear to everyone, the concepts have to be written down, and explained for everyone too discuss. The alternative is to allow only the people with the "secret decoder ring" to discuss or update SMTP. Alan DeKok From owner-ietf-mxcomp@mail.imc.org Sun Nov 28 16:46:09 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17721 for ; Sun, 28 Nov 2004 16:46:09 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iASLBeFK088428; Sun, 28 Nov 2004 13:11:40 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iASLBeB5088427; Sun, 28 Nov 2004 13:11:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iASLBccl088412 for ; Sun, 28 Nov 2004 13:11:38 -0800 (PST) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id iASLb9Z6011950; Sun, 28 Nov 2004 13:37:09 -0800 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id iASLb82u011946; Sun, 28 Nov 2004 13:37:08 -0800 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Sun, 28 Nov 2004 13:37:07 -0800 (PST) From: "william(at)elan.net" To: Alan DeKok cc: MXCOMP Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] In-Reply-To: <20041128151232.4CFA716E2A@mail.nitros9.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sun, 28 Nov 2004, Alan DeKok wrote: > > changes which are limited to participating sites are a lot easier than > > changes which must be implemented ubiquitously in order for the system > > to work correctly. > > As a toy proposal, a simple solution to the .forward problem is to > replace the .forward files with a script, which adds a header like: > > X-RFC2821-Original-Bounce-Path: : Although longer, below header provies a better annd more complete view (for debugging) on what happened and who did the forwarding: Redirected: by <.forward host system name> on-behalf-of process-type forwarding original-envelope return-path= recipient= new-envelope return-path= recipient=; time-stamp See http://www.ietf.org/internet-drafts/draft-leibzon-emailredirection-traceheaders-00.txt note that it was published with bad new lines, for correct text see http://www.elan.net/~william/emailsecurity/draft-leibzon-emailredirection-traceheaders-00.txt and for printable format see http://www.elan.net/~william/emailsecurity/draft-leibzon-emailredirection-traceheaders-00.pdf As for Original-* headers, the standartization of their use is TBD in one of my next drafts. For what you wanted, I'll recommend using "Original-Envelope-From" (this is actually already being used) for return-path and "Original-Envelope-Recipient" for RCPT TO. But obviously for reporting original values before forwarding/redirection I'd prefer people start using Redirected trace headers. > Add some authentication so the field can't be spoofed Email signature can be addded above in a way similer to what DK proposed, stay tuned to mailsig mail list tomorrow. > The only reason that people were using .forward files is that it was > easy, it worked, it didn't cause problems for other people until > recently, and there is always resistence to change. It still does not cause problems for other people! What SPF is now doing is saying that .forward need to do more then just simply relaying message with new addresses and need to identify who they are and what they did. This is good for better email security although people who want to remain anonymous might not like this trend (as usual). -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Mon Nov 29 06:06:15 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06534 for ; Mon, 29 Nov 2004 06:06:15 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iATAGgk1058492; Mon, 29 Nov 2004 02:16:42 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iATAGf2o058491; Mon, 29 Nov 2004 02:16:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mx2.nic.fr (mx2.nic.fr [192.134.4.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iATAGSYG057567 for ; Mon, 29 Nov 2004 02:16:41 -0800 (PST) (envelope-from bortzmeyer@nic.fr) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 7AE9626C07E for ; Mon, 29 Nov 2004 11:16:16 +0100 (CET) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id 4EBB126C06D for ; Mon, 29 Nov 2004 11:16:15 +0100 (CET) Received: from vespucci.nic.fr (postfix@vespucci.nic.fr [192.134.4.68]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id iATAGF8q538646 for ; Mon, 29 Nov 2004 11:16:15 +0100 (CET) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 02D9CFF1C; Mon, 29 Nov 2004 11:16:14 +0100 (CET) Date: Mon, 29 Nov 2004 11:16:14 +0100 From: Stephane Bortzmeyer To: MXCOMP Subject: Re: Complaint on personal attack by Matthew Elvey Message-ID: <20041129101614.GA9904@nic.fr> References: <419EE9B5.6030704@elvey.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.4.26-1-k7 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.6+20040818i X-Virus-Scanned: by amavisd-new at mx2.nic.fr Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Nov 26, 2004 at 04:44:42AM -0500, Dean Anderson wrote a message of 92 lines which said: > The following message by Matthew Elvey includes an inappropriate > personal attack in violation of the following sections of the ISOC > Code of Conduct: http://www.isoc.org/members/codeconduct.shtml Welcome, Matthew, on the blacklist of Mr Anderson. People are hereby informed that Mr Anderson is a world-renowned expert on complaining about personal attacks. Indeed, googling on "anderson complaint ietf personal" will show that his personal hall of shame if quite large :-) From owner-ietf-mxcomp@mail.imc.org Mon Nov 29 11:22:00 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05867 for ; Mon, 29 Nov 2004 11:22:00 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iATFgWgd029030; Mon, 29 Nov 2004 07:42:32 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iATFgWJb029028; Mon, 29 Nov 2004 07:42:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iATFgLre028739 for ; Mon, 29 Nov 2004 07:42:25 -0800 (PST) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 2109216CC3 for ; Mon, 29 Nov 2004 10:53:58 -0500 (EST) From: "Alan DeKok" To: MXCOMP Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] In-Reply-To: Your message of "Sun, 28 Nov 2004 13:37:07 PST." Date: Mon, 29 Nov 2004 10:53:58 -0500 Message-Id: <20041129155358.2109216CC3@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "william(at)elan.net" wrote: > Although longer, below header provies a better annd more complete view > (for debugging) on what happened and who did the forwarding: Sure, there are a whole host of similar solutions, some of which were developed with more than 5 minutes thought. :) The simple addition of a header allows .forward files to work, and requires no off-site changes. > As for Original-* headers, the standartization of their use is TBD in > one of my next drafts. For what you wanted, I'll recommend using > "Original-Envelope-From" (this is actually already being used) for > return-path and "Original-Envelope-Recipient" for RCPT TO. To be robust, they have to be tied together, and they have to be able to have multiple copies added across multiple ".forward" hops. The Redirected: header you propose is much better at doing that. > What SPF is now doing is saying that .forward need to do more then just > simply relaying message with new addresses and need to identify who they > are and what they did. This is good for better email security although > people who want to remain anonymous might not like this trend (as usual). It's not just SPF. It's a way to address the spam problem. As Hadmut has said, stopping forgery requires everyone to give up forging. If I didn't agree to let others use my domain name in "MAIL FROM", it's forgery, because *I* define the use of my domain name. If someone else doesn't mind, that's their issue. And what do you mean by "anonymous"? To send SMTP, you HAVE to have a routable source IP address. This means that the SMTP server you're talking to knows who you are, and that knowledge is probably going to be put in a Received: line in the SMTP message. If an "anonymous" sender has no reverse path, then they can't accept bounces, and no one can respond to their messages. To me, this means a protocol other than SMTP is better suited for anonymity. The lack of a definition for ideas like "anonymity" in relation to SMTP is one of the causes of miscommunication. Everybody uses the term, and everybody "knows" what it means. But in the absence of a quantitative definition, none of the definitions are talking about the same thing. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Mon Nov 29 11:48:13 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07880 for ; Mon, 29 Nov 2004 11:48:13 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iATGHa9k069678; Mon, 29 Nov 2004 08:17:36 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iATGHatT069676; Mon, 29 Nov 2004 08:17:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iATGHZQI069481 for ; Mon, 29 Nov 2004 08:17:35 -0800 (PST) (envelope-from matthew@elvey.com) Received: from frontend2.messagingengine.com (frontend2.internal [10.202.2.151]) by frontend1.messagingengine.com (Postfix) with ESMTP id 4C93AC3CCC7 for ; Mon, 29 Nov 2004 11:17:22 -0500 (EST) X-Sasl-enc: Cu7+TwhgLNzZjX60OVzdmw 1101745041 Received: from [192.168.2.85] (adsl-67-122-215-55.dsl.snfc21.pacbell.net [67.122.215.55]) by frontend2.messagingengine.com (Postfix) with ESMTP id 4B60857030B; Mon, 29 Nov 2004 11:17:21 -0500 (EST) Message-ID: <41AB4B8E.5040900@elvey.com> Date: Mon, 29 Nov 2004 11:17:18 -0500 From: Matthew Elvey User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 Cc: MXCOMP Subject: Re: Complaint on personal attack by Matthew Elvey by Dean Anderson of av8. References: <419EE9B5.6030704@elvey.com> <20041129101614.GA9904@nic.fr> In-Reply-To: <20041129101614.GA9904@nic.fr> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 11/29/2004 5:16 AM, Stephane Bortzmeyer sent forth electrons to convey: >Welcome, Matthew, on the blacklist of Mr Anderson. People are hereby >informed that Mr Anderson is a world-renowned expert on complaining >about personal attacks. Indeed, googling on "anderson complaint ietf >personal" will show that his personal hall of shame if quite large :-) > > > My apologies to the list. My failure to follow my own advice: > Dean Anderson of av8 seems best largely ignored... has proven what good advice it was even better than the evidence I had provided. It won't happen again. From owner-ietf-mxcomp@mail.imc.org Mon Nov 29 14:15:26 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20803 for ; Mon, 29 Nov 2004 14:15:26 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iATIe7me027840; Mon, 29 Nov 2004 10:40:07 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iATIe7us027839; Mon, 29 Nov 2004 10:40:07 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from emerald.pobox.com (postfix@emerald.pobox.com [207.8.226.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iATIe526027735 for ; Mon, 29 Nov 2004 10:40:06 -0800 (PST) (envelope-from mengwong@dumbo.pobox.com) Received: from dumbo.pobox.com (dumbo.pobox.com [209.2.32.34]) by emerald.pobox.com (Postfix) with ESMTP id D4AD3132CD1; Mon, 29 Nov 2004 13:39:10 -0500 (EST) Received: by dumbo.pobox.com (Postfix, from userid 505) id E2A6F5D4; Mon, 29 Nov 2004 13:40:06 -0500 (EST) Date: Mon, 29 Nov 2004 13:40:06 -0500 From: Meng Weng Wong To: Alan DeKok Cc: MXCOMP Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] Message-ID: <20041129184006.GA28045@dumbo.pobox.com> References: <042d01c4d398$9ca78310$0200000a@ringo> <20041128152341.CFB3116E2A@mail.nitros9.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041128152341.CFB3116E2A@mail.nitros9.org> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I want to thank Chris Haynes for his summary of "conservative" and "progressive" positions. I have recorded a very similar summary on page 16 of http://spf.pobox.com/whitepaper.pdf On Sun, Nov 28, 2004 at 10:23:41AM -0500, Alan DeKok wrote: | | > How, and from where, would one get an 'authoritative' ruling about | > the conformance or non-conformance of forwarding (using the origin's | > MAIL FROM with a new RCPT TO) to the extant SMTP architecture? | | I would like an answer to that question, too. | I wonder if we could ask the IESG to vote on it. | .forward files are not required for SMTP to work. Entirely | equivalent functionality can be obtained without using a third parties | name in "MAIL FROM". That functionality requires changes to the sites | using .forward files, and nothing else. BTW, verbatim forwarding is practiced not just by unixheads with .forward files, but also by hosted domains, of which there are millions in existence, and alumni / lifetime email services like alumni.*.edu and acm.org. The hosting providers can implement workarounds, and forwarding service providers can implement workarounds. From the receiver end, trusted-forwarder.org lets receivers whitelist forwarding hosts. That leaves only the ad-hoc forwarding setups. For those cases, I would like to be able to tell them "just upgrade". Shevek has been leading the effort to get SRS into MTAs. For 2005 I plan to expand that MTA-patching effort to include the Leibzon trace headers and MS's Resent-*. (DK+IIM will be part of the patch effort also.) That is where things stand as of November 2004. From owner-ietf-mxcomp@mail.imc.org Mon Nov 29 15:25:56 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28114 for ; Mon, 29 Nov 2004 15:25:55 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iATJp1nT099676; Mon, 29 Nov 2004 11:51:01 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iATJp1aA099670; Mon, 29 Nov 2004 11:51:01 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iATJp0oa099639 for ; Mon, 29 Nov 2004 11:51:00 -0800 (PST) (envelope-from dotis@mail-abuse.org) Received: from [168.61.10.138] (SJC-Office-DHCP-138.Mail-Abuse.ORG [168.61.10.138]) (authenticated bits=0) by b.mail.sonic.net (8.12.11/8.12.11) with ESMTP id iATJp31m011668 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 29 Nov 2004 11:51:04 -0800 Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] From: Douglas Otis To: Hector Santos Cc: MXCOMP In-Reply-To: <004a01c4d411$ada15320$6401a8c0@hdev1> References: <20041125231151.9B4D516F4C@mail.nitros9.org> <1101456711.19141.57.camel@localhost.localdomain> <004a01c4d411$ada15320$6401a8c0@hdev1> Content-Type: text/plain Message-Id: <1101757668.2885.71.camel@littlejoy> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Mon, 29 Nov 2004 11:47:48 -0800 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 2004-11-26 at 15:42, Hector Santos wrote: > In addition, as a vendor, I am very interested in supporting the mandates > imposed by our Federal Government laws such as CANSPAM - that means complete > email address validation and Topic Identification concepts. > > Lets look at more specifics. We have essentially one or more of the > following: > > 1) EHLO/HELO validation > 2) MAIL FROM validation > 3) RCPT TO validation > 4) DATA validation, if any > 5) Mixed Validation > 6) No Validation at 2821 > 7) Post SMTP validation > 8) Bounce Requirements > > > SPF concentrates on #2, and it lost on handling #1 and proper handling of > #5. It ignores #3. > > CSV concentrates on #1, gets lost on SMTP AUTH issues, proper handling of > #5 and also ignores #3. CSV only ensures the EHLO/HELO can be authenticated and does not hinder other authentications. "Concentrates on validation" does not define what is provided. Authentication is different than offering authorization lists and presuming the entire system is secure. There is a fair amount of information obtained with the specific authentication and authorization made available with CSV. With this information, a specific domain is indeed accountable for the host and has authorized the sending of mail. With this authenticated name, other associations can be safely made. BATV is useful to protect related network resources of the return path. CSV is useful to protect the related network resources of the recipient path, when used with a reputation service. Digital signatures are useful to prevent domain forgeries and to also establish accountability. Schemes that require the processing of the message do not offer network resource protection however. There are safer solutions for path registration, but such schemes are not useful for locating security problems or for application of a reputation service. Messages that have only been authorized, but not authenticated, is not sufficient to establish accountability as a basis for reputation. -Doug From owner-ietf-mxcomp@mail.imc.org Mon Nov 29 18:40:37 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27099 for ; Mon, 29 Nov 2004 18:40:37 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iATN0ZWm088583; Mon, 29 Nov 2004 15:00:35 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iATN0Zqe088580; Mon, 29 Nov 2004 15:00:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iATN0FJp088197 for ; Mon, 29 Nov 2004 15:00:16 -0800 (PST) (envelope-from dean@av8.com) Received: from piper.av8.net (piper.av8.net [130.105.11.2]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id iATN0GSt019406 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 29 Nov 2004 18:00:18 -0500 Date: Mon, 29 Nov 2004 18:00:16 -0500 (EST) From: Dean Anderson X-X-Sender: dean@piper.av8.net To: Stephane Bortzmeyer cc: MXCOMP Subject: Re: Complaint on personal attack by Matthew Elvey In-Reply-To: <20041129101614.GA9904@nic.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: And speaking of the complain On Mon, 29 Nov 2004, Stephane Bortzmeyer wrote: > On Fri, Nov 26, 2004 at 04:44:42AM -0500, > Dean Anderson wrote > a message of 92 lines which said: > > > The following message by Matthew Elvey includes an inappropriate > > personal attack in violation of the following sections of the ISOC > > Code of Conduct: http://www.isoc.org/members/codeconduct.shtml > > Welcome, Matthew, on the blacklist of Mr Anderson. People are hereby > informed that Mr Anderson is a world-renowned expert on complaining > about personal attacks. Really? Well, I suppose it is because I debunk world renowned bullshit artists. > Indeed, googling on "anderson complaint ietf personal" will show that > his personal hall of shame if quite large :-) Actually, the list of abusers is not all that large. However, I notice that Stephane Bortzmeyer is also on it. So, I guess that his message here is more self-serving that it first appears. But wait, lets take another look at Bortzmeyer's abuse: Stephane Bortzmeyer wrote >> If Av8 turns on PPLB, traffic to F-root will go through both sprint >> and att on a per-packet basis. > >Troll Bot keeps mentioning PPLB. May be some people >more knowledgeable about BGP than I am will explain to me why PPLB is >such a new issue for anycasting? BTW, It turned out that I was right on this issue, and the Bortzeyer was just being an idiot, and who didn't even know what PPLB was, and who was unable to formulate an intelligent opinion in the first place. In the US, we have a phrase that describes this behavior: It's called "talking out of your ass". So it seems Bortzmeyer and Elvey are in the same group. Funny, that. -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From owner-ietf-mxcomp@mail.imc.org Mon Nov 29 18:52:44 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27874 for ; Mon, 29 Nov 2004 18:52:44 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iATNJS6j008917; Mon, 29 Nov 2004 15:19:28 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iATNJS3r008916; Mon, 29 Nov 2004 15:19:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iATNJSsH008885 for ; Mon, 29 Nov 2004 15:19:28 -0800 (PST) (envelope-from dean@av8.com) Received: from piper.av8.net (piper.av8.net [130.105.11.2]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id iATNJUL0019679 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 29 Nov 2004 18:19:31 -0500 Date: Mon, 29 Nov 2004 18:19:30 -0500 (EST) From: Dean Anderson X-X-Sender: dean@piper.av8.net To: Matthew Elvey cc: MXCOMP Subject: Re: Complaint on personal attack by Matthew Elvey by Dean Anderson of av8. In-Reply-To: <41AB4B8E.5040900@elvey.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: It is interesting that there is still no explanation of what the attack on me has to do with the FTC. I think its more appropriate to ignore someone who claimed that GNU emacs contained much pirated code (Elvey, 2000). http://lists.essential.org/pipermail/am-info/Week-of-Mon-20001106/004270.html That claim evidences such profound ignorance of history, emacs, GNU, that there is no basis for intelligent conversation with such a person. They are either completely ignorant, or compulsive liars, or both. I am relieved to see Elvey and Bortzmeyer getting along so well. Like peas in a pod. Same pod. Probably the ignorant compulsive liars pod, shared with Vixie, Alan Brown, and Matthew Sullivan. --Dean On Mon, 29 Nov 2004, Matthew Elvey wrote: > > On 11/29/2004 5:16 AM, Stephane Bortzmeyer sent forth electrons to convey: > > >Welcome, Matthew, on the blacklist of Mr Anderson. People are hereby > >informed that Mr Anderson is a world-renowned expert on complaining > >about personal attacks. Indeed, googling on "anderson complaint ietf > >personal" will show that his personal hall of shame if quite large :-) > > > > > > > My apologies to the list. My failure to follow my own advice: > > > Dean Anderson of av8 seems best largely ignored... > > has proven what good advice it was even better than the evidence I had > provided. > It won't happen again. > > > > -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From owner-ietf-mxcomp@mail.imc.org Mon Nov 29 20:47:45 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07833 for ; Mon, 29 Nov 2004 20:47:45 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAU1Csa1055902; Mon, 29 Nov 2004 17:12:54 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAU1CsH9055893; Mon, 29 Nov 2004 17:12:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from xuxa.iecc.com (xuxa.iecc.com [208.31.42.42]) by above.proper.com (8.12.11/8.12.9) with SMTP id iAU1CrO3055870 for ; Mon, 29 Nov 2004 17:12:53 -0800 (PST) (envelope-from prvs=johnl/07524184e2@iecc.com) Received: (qmail 11065 invoked by uid 100); 30 Nov 2004 01:12:59 -0000 Date: 30 Nov 2004 01:12:59 -0000 Message-ID: <20041130011259.11064.qmail@xuxa.iecc.com> From: John Levine To: ietf-mxcomp@imc.org Subject: Source routing -- why not? Organization: I.E.C.C., Trumansburg NY USA Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit After further deliberation about source routing and SPF, I have come around to the conclusion that Frank is to some degree right, and if you want to use SPF/Sender-ID, you should use source routes. SPF, after all, simply reintroduces source routes into Internet mail, a decade or so after they disappeared. SPF and Sender-ID assert that some paths for a particular message are valid and others aren't. Well, OK, that's just what source routes do. In particular, SES and its ilk are just clumsy recreations of source routes. If a@a sends mail to b@b which then forwards it to c@c, the return path on the second hop should be <@b:a@a> which says exactly what SES would, this message was from a@a but if you want to write back, you need to send your response via b. Host b needs somehow to remember that this particular relay is OK, but that's not new. RFC 2821 says that source routes are deprecated except in unusual circumstances, but MTAs should handle them if they see them. Relative to the past 20 years of e-mail, I'd have no trouble calling SPF unusual. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY http://www.taugh.com From owner-ietf-mxcomp@mail.imc.org Mon Nov 29 21:50:47 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12005 for ; Mon, 29 Nov 2004 21:50:47 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAU2CaUY013315; Mon, 29 Nov 2004 18:12:36 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAU2CabC013314; Mon, 29 Nov 2004 18:12:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAU2CZbn013301 for ; Mon, 29 Nov 2004 18:12:35 -0800 (PST) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id iAU2cAGt002449; Mon, 29 Nov 2004 18:38:10 -0800 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id iAU2cA3G002446; Mon, 29 Nov 2004 18:38:10 -0800 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Mon, 29 Nov 2004 18:38:10 -0800 (PST) From: "william(at)elan.net" To: John Levine cc: ietf-mxcomp@imc.org Subject: Re: Source routing -- why not? In-Reply-To: <20041130011259.11064.qmail@xuxa.iecc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I think you mean SRS (sender rewriting system) not SES (which is cryptographic signatutures in envelope from). Other then that I agree but would note that original source routes were such that sender set how the email is to be routed for direct email and with SPF and SRS this only only for bounce messages. On 30 Nov 2004, John Levine wrote: > > After further deliberation about source routing and SPF, I have come > around to the conclusion that Frank is to some degree right, and if > you want to use SPF/Sender-ID, you should use source routes. > > SPF, after all, simply reintroduces source routes into Internet mail, > a decade or so after they disappeared. SPF and Sender-ID assert that > some paths for a particular message are valid and others aren't. > Well, OK, that's just what source routes do. In particular, SES and > its ilk are just clumsy recreations of source routes. > > If a@a sends mail to b@b which then forwards it to c@c, the return > path on the second hop should be <@b:a@a> which says exactly what SES > would, this message was from a@a but if you want to write back, you > need to send your response via b. Host b needs somehow to remember > that this particular relay is OK, but that's not new. > > RFC 2821 says that source routes are deprecated except in unusual > circumstances, but MTAs should handle them if they see them. Relative > to the past 20 years of e-mail, I'd have no trouble calling SPF > unusual. > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > http://www.taugh.com > > -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Tue Nov 30 05:05:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28698 for ; Tue, 30 Nov 2004 05:05:13 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAU9F3Zg096389; Tue, 30 Nov 2004 01:15:03 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAU9F3qL096388; Tue, 30 Nov 2004 01:15:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail78.messagelabs.com (mail78.messagelabs.com [195.245.230.131]) by above.proper.com (8.12.11/8.12.9) with SMTP id iAU9F1ra096216 for ; Tue, 30 Nov 2004 01:15:02 -0800 (PST) (envelope-from Danny_Angus@slc.co.uk) X-VirusChecked: Checked X-Env-Sender: Danny_Angus@slc.co.uk X-Msg-Ref: server-11.tower-78.messagelabs.com!1101806097!5667111!1 X-StarScan-Version: 5.4.2; banners=slc.co.uk,-,- X-Originating-IP: [195.99.121.125] Received: (qmail 3374 invoked from network); 30 Nov 2004 09:14:58 -0000 Received: from mail1.slc.co.uk (HELO drsneaky.slc.co.uk) (195.99.121.125) by server-11.tower-78.messagelabs.com with SMTP; 30 Nov 2004 09:14:58 -0000 Received: from emerald.slc.co.uk (emerald.slc.co.uk) by drsneaky.slc.co.uk (Content Technologies SMTPRS 4.3.12) with ESMTP id for ; Tue, 30 Nov 2004 09:14:57 +0000 Subject: Re: Complaint on personal attack by Matthew Elvey To: MXCOMP X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: Danny Angus Date: Tue, 30 Nov 2004 09:15:17 +0000 X-MIMETrack: Serialize by Router on Emerald/SLC (Release 6.5.2|June 01, 2004) at 30/11/2004 09:14:57 MIME-Version: 1.0 Content-type: text/plain; charset="us-ascii" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > the Bortzeyer was > just being an idiot, and who didn't even know what PPLB was, and who was > unable to formulate an intelligent opinion in the first place. In the US, > we have a phrase that describes this behavior: It's called "talking out > of your ass". > So it seems Bortzmeyer and Elvey are in the same group. Funny, that. I like to flame and rant as much as the next man, but now that the score is one each on the personal attacks front can you please seethe privately and bite your tounges for a while? d. *************************************************************************** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limi! ted. This footnote also confirms that this email message has been swept for the presence of computer viruses. ************************************************************************** From owner-ietf-mxcomp@mail.imc.org Tue Nov 30 06:22:06 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07209 for ; Tue, 30 Nov 2004 06:22:05 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAUAhpb0023877; Tue, 30 Nov 2004 02:43:51 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAUAhpeH023876; Tue, 30 Nov 2004 02:43:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-8.csi.cam.ac.uk (ppsw-8.csi.cam.ac.uk [131.111.8.138]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAUAhian023736 for ; Tue, 30 Nov 2004 02:43:46 -0800 (PST) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:47998) by ppsw-8.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1CZ5Tw-0002u4-Sj (Exim 4.44) (return-path ); Tue, 30 Nov 2004 10:43:40 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1CZ5Tw-0007rk-S6 (Exim 4.43) (return-path ); Tue, 30 Nov 2004 10:43:40 +0000 Date: Tue, 30 Nov 2004 10:43:40 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: John Levine cc: ietf-mxcomp@imc.org Subject: Re: Source routing -- why not? In-Reply-To: <20041130011259.11064.qmail@xuxa.iecc.com> Message-ID: References: <20041130011259.11064.qmail@xuxa.iecc.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 30 Nov 2004, John Levine wrote: > > After further deliberation about source routing and SPF, I have come > around to the conclusion that Frank is to some degree right, and if > you want to use SPF/Sender-ID, you should use source routes. Source routes require all mail servers to be open relays. Tony. -- f.a.n.finch http://dotat.at/ MALIN HEBRIDES: NORTHEAST 4 OR 5 INCREASING 6. RAIN LATER. GOOD BECOMING MODERATE. From owner-ietf-mxcomp@mail.imc.org Tue Nov 30 07:31:19 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12641 for ; Tue, 30 Nov 2004 07:31:18 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAUBnnbp016674; Tue, 30 Nov 2004 03:49:49 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAUBnnNZ016673; Tue, 30 Nov 2004 03:49:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from slot.hollandcasino.net (slot.hollandcasino.net [193.172.40.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAUBnmot016422 for ; Tue, 30 Nov 2004 03:49:49 -0800 (PST) (envelope-from alex@slot.hollandcasino.net) Received: by slot.hollandcasino.net (Postfix, from userid 500) id AF637600B9; Tue, 30 Nov 2004 12:49:40 +0100 (CET) Date: Tue, 30 Nov 2004 12:49:40 +0100 From: Alex van den Bogaerdt To: ietf-mxcomp@imc.org Subject: Re: Source routing -- why not? Message-ID: <20041130114940.GA27133@slot.hollandcasino.net> Mail-Followup-To: ietf-mxcomp@imc.org References: <20041130011259.11064.qmail@xuxa.iecc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Legal-Note: ---------------------------------------------- Everything I write or say expresses my opinion only! Unless otherwise stated, I do not represent my employer or anyone else for that matter. ---------------------------------------------------- Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Nov 30, 2004 at 10:43:40AM +0000, Tony Finch wrote: > > After further deliberation about source routing and SPF, I have come > > around to the conclusion that Frank is to some degree right, and if > > you want to use SPF/Sender-ID, you should use source routes. > > Source routes require all mail servers to be open relays. Why? If a@a sends mail to b@b, and if b@b forwards to c@c, then only c@c can send a bounce via b@b towards a@a. MTA 'b' accepted responsibility for the message. MTA 'b' needs to deliver it to MTA 'c' because user b@b wants it to do so. From that moment on, the conversation is between 'b@b' and 'c@c', errors should go to 'b@b' who can, if needed, send a bounce to 'a@a'. Alex From owner-ietf-mxcomp@mail.imc.org Tue Nov 30 08:00:01 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14378 for ; Tue, 30 Nov 2004 08:00:01 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAUCH9NK073993; Tue, 30 Nov 2004 04:17:09 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAUCH9iA073992; Tue, 30 Nov 2004 04:17:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-5.csi.cam.ac.uk (ppsw-5.csi.cam.ac.uk [131.111.8.135]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAUCH8TG073966 for ; Tue, 30 Nov 2004 04:17:08 -0800 (PST) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:53286) by ppsw-5.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.155]:25) with esmtpa (EXTERNAL:fanf2) id 1CZ6w8-0006a8-Hj (Exim 4.44) (return-path ); Tue, 30 Nov 2004 12:16:52 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1CZ6vy-00031x-E3 (Exim 4.43) (return-path ); Tue, 30 Nov 2004 12:16:42 +0000 Date: Tue, 30 Nov 2004 12:16:42 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Alex van den Bogaerdt cc: ietf-mxcomp@imc.org Subject: Re: Source routing -- why not? In-Reply-To: <20041130114940.GA27133@slot.hollandcasino.net> Message-ID: References: <20041130011259.11064.qmail@xuxa.iecc.com> <20041130114940.GA27133@slot.hollandcasino.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 30 Nov 2004, Alex van den Bogaerdt wrote: > On Tue, Nov 30, 2004 at 10:43:40AM +0000, Tony Finch wrote: > > > > After further deliberation about source routing and SPF, I have come > > > around to the conclusion that Frank is to some degree right, and if > > > you want to use SPF/Sender-ID, you should use source routes. > > > > Source routes require all mail servers to be open relays. > > Why? Source routes don't record the relationship between a@a, b@b, and c@c. In your scenario the message to c@c would start MAIL FROM:<@b:a@a>. A spammer who knows that b is a forwarding host can then spam anyone by sending MAIL FROM:<> RCPT TO:<@b:victim@target>. This is why SRS has all the cryptography, in order to provide a secure replacement for the obsolete and unimplemented RFC821 forward and reverse paths. Tony. -- f.a.n.finch http://dotat.at/ MALIN HEBRIDES: NORTHEAST 4 OR 5 INCREASING 6. RAIN LATER. GOOD BECOMING MODERATE. From owner-ietf-mxcomp@mail.imc.org Tue Nov 30 08:11:12 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15316 for ; Tue, 30 Nov 2004 08:11:12 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAUCc2fQ008349; Tue, 30 Nov 2004 04:38:02 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAUCc2tb008348; Tue, 30 Nov 2004 04:38:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from slot.hollandcasino.net (slot.hollandcasino.net [193.172.40.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAUCc2Hi008330 for ; Tue, 30 Nov 2004 04:38:02 -0800 (PST) (envelope-from alex@slot.hollandcasino.net) Received: by slot.hollandcasino.net (Postfix, from userid 500) id 503D2600B9; Tue, 30 Nov 2004 13:38:03 +0100 (CET) Date: Tue, 30 Nov 2004 13:38:03 +0100 From: Alex van den Bogaerdt To: ietf-mxcomp@imc.org Subject: Re: Source routing -- why not? Message-ID: <20041130123802.GA27315@slot.hollandcasino.net> Mail-Followup-To: ietf-mxcomp@imc.org References: <20041130011259.11064.qmail@xuxa.iecc.com> <20041130114940.GA27133@slot.hollandcasino.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Legal-Note: ---------------------------------------------- Everything I write or say expresses my opinion only! Unless otherwise stated, I do not represent my employer or anyone else for that matter. ---------------------------------------------------- Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Nov 30, 2004 at 12:16:42PM +0000, Tony Finch wrote: > > > Source routes require all mail servers to be open relays. > > > > Why? > > Source routes don't record the relationship between a@a, b@b, and c@c. In > your scenario the message to c@c would start MAIL FROM:<@b:a@a>. A spammer > who knows that b is a forwarding host can then spam anyone by sending MAIL > FROM:<> RCPT TO:<@b:victim@target>. I disagree. Source routes by themselves are not the problem. Indeed, lack of security would be a problem. There's no reason why MTA b would not be able to keep state somewhere else than in the envelope. There's no reason why MTA b would have to relay a message to @b:victim@target There's no reason at all why MTA b would relay messages at all. The only "relay" functionality would be a 'reverse forward' so that bounces going to b@b will be forward to a@a, not to c@c. I don't even see any reason why the classic form of source routing needs to be used. When 'b' forwards the message to 'c', and when it uses its own name, bounces will go to 'b' and can be 'reverse-forward' to the true originator. > This is why SRS has all the cryptography, in order to provide a secure > replacement for the obsolete and unimplemented RFC821 forward and reverse > paths. Without saying if its good or bad: That is _a_ solution, not _the_ solution. cheers, Alex -- I ask you to respect any "Reply-To" and "Mail-Follow-Up" headers. If you reply to me off-list, you'd better tell me you're doing so. If you don't, and if I reply to the list, that's your problem, not mine. From owner-ietf-mxcomp@mail.imc.org Tue Nov 30 08:53:08 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18061 for ; Tue, 30 Nov 2004 08:53:07 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAUDEsL2052158; Tue, 30 Nov 2004 05:14:54 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAUDEs6J052157; Tue, 30 Nov 2004 05:14:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-2.csi.cam.ac.uk (ppsw-2.csi.cam.ac.uk [131.111.8.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAUDErpo052146 for ; Tue, 30 Nov 2004 05:14:54 -0800 (PST) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:40115) by ppsw-2.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.152]:25) with esmtpa (EXTERNAL:fanf2) id 1CZ7aK-0007Gj-7D (Exim 4.44) (return-path ); Tue, 30 Nov 2004 12:58:24 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1CZ7aK-0003YX-6J (Exim 4.43) (return-path ); Tue, 30 Nov 2004 12:58:24 +0000 Date: Tue, 30 Nov 2004 12:58:24 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Alex van den Bogaerdt cc: ietf-mxcomp@imc.org Subject: Re: Source routing -- why not? In-Reply-To: <20041130123802.GA27315@slot.hollandcasino.net> Message-ID: References: <20041130011259.11064.qmail@xuxa.iecc.com> <20041130114940.GA27133@slot.hollandcasino.net> <20041130123802.GA27315@slot.hollandcasino.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 30 Nov 2004, Alex van den Bogaerdt wrote: > > There's no reason at all why MTA b would relay messages at all. The only > "relay" functionality would be a 'reverse forward' so that bounces going > to b@b will be forward to a@a, not to c@c. It can't correlate the bounces with original messages (and thereby send it to the right place) without putting some kind of cookie in the return path. Traditional source routing (as suggested by John Levine) cannot be made to work. Tony. -- f.a.n.finch http://dotat.at/ MALIN HEBRIDES: NORTHEAST 4 OR 5 INCREASING 6. RAIN LATER. GOOD BECOMING MODERATE. From owner-ietf-mxcomp@mail.imc.org Tue Nov 30 11:19:17 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02943 for ; Tue, 30 Nov 2004 11:19:17 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAUFWYnl086892; Tue, 30 Nov 2004 07:32:34 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAUFWY7L086891; Tue, 30 Nov 2004 07:32:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tom.iecc.com (tom.iecc.com [208.31.42.38]) by above.proper.com (8.12.11/8.12.9) with SMTP id iAUFWXaV086861 for ; Tue, 30 Nov 2004 07:32:34 -0800 (PST) (envelope-from prvs=johnl/07524184e2@iecc.com) Received: (qmail 24378 invoked from network); 30 Nov 2004 15:32:35 -0000 Received: (ofmipd 127.0.0.1); 30 Nov 2004 15:32:13 -0000 Date: 30 Nov 2004 10:32:35 -0500 Message-ID: From: "John R Levine" To: "Tony Finch" Cc: ietf-mxcomp@imc.org Subject: Re: Source routing -- why not? In-Reply-To: References: <20041130011259.11064.qmail@xuxa.iecc.com> Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > After further deliberation about source routing and SPF, I have come > > around to the conclusion that Frank is to some degree right, and if > > you want to use SPF/Sender-ID, you should use source routes. > > Source routes require all mail servers to be open relays. Only in a naive implementation. SPF already requires that participating hosts be prepared to handle arbitrarily complex procedures, so adding one more shouldn't be a big deal. If it is a big deal, well, perhaps we're seeing a problem with SPF more than with source routes. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://iecc.com/johnl, Mayor "I dropped the toothpaste", said Tom, crestfallenly. From owner-ietf-mxcomp@mail.imc.org Tue Nov 30 16:58:13 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18577 for ; Tue, 30 Nov 2004 16:58:13 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAULJsUP011146; Tue, 30 Nov 2004 13:19:54 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAULJsSA011145; Tue, 30 Nov 2004 13:19:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAULJrtT011079 for ; Tue, 30 Nov 2004 13:19:53 -0800 (PST) (envelope-from dean@av8.com) Received: from piper.av8.net (piper.av8.net [130.105.11.2]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id iAULJtbe011549 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 30 Nov 2004 16:19:57 -0500 Date: Tue, 30 Nov 2004 16:19:55 -0500 (EST) From: Dean Anderson X-X-Sender: dean@piper.av8.net cc: MXCOMP Subject: Re: Complaint on personal attack by Matthew Elvey In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ;-) yeah, sure. --Dean On Tue, 30 Nov 2004, Danny Angus wrote: > > > the Bortzeyer was > > just being an idiot, and who didn't even know what PPLB was, and who was > > unable to formulate an intelligent opinion in the first place. In the > US, > > we have a phrase that describes this behavior: It's called "talking out > > of your ass". > > > So it seems Bortzmeyer and Elvey are in the same group. Funny, that. > > > I like to flame and rant as much as the next man, but now that the score is > one each on the personal attacks front can you please seethe privately and > bite your tounges for a while? > > d. > > > *************************************************************************** > The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Li! mi! > ted. > > This footnote also confirms that this email message has been swept for the presence of computer viruses. > > ************************************************************************** > > > -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000