[Asrg] Introduction and another idea
gep2@terabites.com Mon, 16 June 2003 01:04 UTC
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15728 for <asrg-archive@odin.ietf.org>; Sun, 15 Jun 2003 21:04:31 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5G142p07590 for asrg-archive@odin.ietf.org; Sun, 15 Jun 2003 21:04:02 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5G142m07587 for <asrg-web-archive@optimus.ietf.org>; Sun, 15 Jun 2003 21:04:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15724; Sun, 15 Jun 2003 21:04:00 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RiNX-0006H9-00; Sun, 15 Jun 2003 21:01:47 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19RiNW-0006H6-00; Sun, 15 Jun 2003 21:01:46 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5FLT1a26949; Sun, 15 Jun 2003 17:29:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5FLS9m26925 for <asrg@optimus.ietf.org>; Sun, 15 Jun 2003 17:28:09 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11320 for <asrg@ietf.org>; Sun, 15 Jun 2003 17:28:06 -0400 (EDT)
From: gep2@terabites.com
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Rf0c-0005RU-00 for asrg@ietf.org; Sun, 15 Jun 2003 17:25:54 -0400
Received: from h000.c000.snv.cp.net ([209.228.32.64] helo=c000.snv.cp.net) by ietf-mx with smtp (Exim 4.12) id 19Rf0b-0005RQ-00 for asrg@ietf.org; Sun, 15 Jun 2003 17:25:53 -0400
Received: (cpmta 8654 invoked from network); 15 Jun 2003 14:28:05 -0700
Received: from 12.239.18.238 (HELO WinProxy.anywhere) by smtp.terabites.com (209.228.32.64) with SMTP; 15 Jun 2003 14:28:05 -0700
X-Sent: 15 Jun 2003 21:28:05 GMT
Received: from 192.168.0.30 by 192.168.0.1 (WinProxy); Sun, 15 Jun 2003 16:26:42 -0600
Received: from 192.168.0.240 (unverified [192.168.0.240]) by nts1.terabites.com (EMWAC SMTPRS 0.83) with SMTP id <B0000023994@nts1.terabites.com>; Sun, 15 Jun 2003 16:53:32 -0500
Message-ID: <B0000023994@nts1.terabites.com>
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
To: asrg@ietf.org
X-Mailer: SPRY Mail Version: 04.00.06.17
Content-Transfer-Encoding: 7bit
Subject: [Asrg] Introduction and another idea
Sender: asrg-admin@ietf.org
Errors-To: asrg-admin@ietf.org
X-BeenThere: asrg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=unsubscribe>
List-Id: Anti-Spam Research Group - IRTF <asrg.ietf.org>
List-Post: <mailto:asrg@ietf.org>
List-Help: <mailto:asrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=subscribe>
List-Archive: <https://www1.ietf.org/pipermail/asrg/>
Date: Sun, 15 Jun 2003 16:53:32 -0500
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Howdy! Since I'm a recent addition to this list, let me briefly introduce myself. Name's Gordon Peterson, live in Dallas. I've been active in computer E-mail and networking longer than most, I guess... including being the creator and programmer of the system software for the world's first commercially available LAN system. (Datapoint's ARC System, developed during 1976, delivered and announced in 1977) I'll never forget the "oh, no..." moment (back in the internetworked BBS days) when it started to dawn on me that there was probably going to be an increasing role in such systems for moderators and monitors, due to abuse/spam/such issues. Recently I joined the spf-discuss list, where their focus is DNS-based approaches to identify "home domains" for specified users/senders, so that anyone on the Net can tell if the "From" address doesn't match the IP address or MTA that the mail is coming from (which *might* indicate a forged return address... or might not!) While in general making E-mail more accountable is *usually* (perhaps not always...!) a good idea, it strikes me that it does NOT achieve what they claim to be their goal... and comes at a high (perhaps unreasonably high) cost to many types of users who for legitimate reasons sometimes post from atypical locations (e.g. internet cafe on board a cruise ship, kiosk in an airport waiting lounge, etc). Their approach also has the major disadvantage that implementation virtually requires an essentially global change to the setup of mail servers everywhere, which I think is unrealistic. And, of course, million-subscriber ISPs sorta make it fairly meaningless to affirm that the From: address is valid on their IP-address-range... During the discussion it struck me that a better approach to the problem is the following: A recipient should be able to create a specific-permission "whitelist" which lists the senders (by E-mail address) to which they wish to assign "special" privileges. Senders who are not on the whitelist would only be allowed to send that recipient plain, unencoded, ASCII text E-mails without HTML, scripting, encoding, or any kind of attachments. So the permissions a recipient could assign to certain "approved/trusted" senders would be (one or more, individually selectable): * may send HTML * may send attachments * may include scripting * may include ActiveX and similar * may use encoded text (e.g. text in base64 encoding) * (perhaps) a maximum message size for the indicated sender By default, each of those specific permissions would be set to "prohibited", including for senders where the sender was not (yet?) included on the recipient's whitelist. Mail violating the permissions specified would be either simply t-canned or else bounced back to the sender as undeliverable. The whitelist would be maintained either at the recipient's mail server, or local ISP's mail server, or else (for their own domain) at the domain provider/mail forwarder... probably, as soon as the mail resolves to the addressee domain. You'll note that this scheme does not provide for the blocking (at this level, anyhow) of plain ASCII text spams. True. More on that later. But the great majority of spams use a variety of tricks to get past content filters, and to deceive recipients. A *large* subset of those tricks are based on HTML: 1) HTML comments (and bogus HTML tags) to break up and obscure mail content, and to confuse content filters; 2) graphic-mode-text (likewise); 3) links which purport to be one thing but where the actual hyperlink in fact (and usually invisibly) points somewhere else; 4) scripting where the message displayed only can be viewed as a result of the computational process, again to make things difficult for content filters. Attachments (especially in unsolicited E-mails) tend to frequently contain viruses, worms, "background music" that's actually a PIF or EXE file, and things of that sort. Getting attachments from someone who doesn't ordinarily send those is a warning sign that it might well be malicious. I've seen several spams which use base64 encoding of the message text, again to confuse content filters. Legitimate E-mails rarely if ever send encoded text. The important thing to understand here is that any user who WISHES to receive any of these 'dangerous'/dubious things in their e-mails from specific, trusted originating E-mail addresses would be easily able to enable that for that specific sender. Genuinely unsolicited E-mails, however, virtually *never* _need_ to have HTML-burdened bodies. HTML-burdened E-mail (including its 3-5x greater bulk over plain ASCII text) is inefficient, and generally not worth the extra bandwidth, inbox space, and risk that it entails. A sender who exceptionally needs to send "unusual" content could send a plain ASCII E-mail requesting advance permission to do so, and the intended recipient could either agree or not, as appropriate. By enabling a user to simply t-can any unexpected HTML-burdened (or attachment-carrying) incoming message (and ideally as soon as it got to their domain provider or ISP), spammers would be denied many of their most cherished and valuable tricks. Content filters would be far more useful and efficient. And much more of the remaining unsolicited spam that WOULD still be sent would be sent in plain ASCII text (knowing that sending unsolicited HTML E-mail was the kiss of death...) meaning it would reduce wasted bandwidth for such remaining spam mail net-wide by at least a factor of three to five. Other advantages of this approach is that it doesn't require any kind of global agreement or flash-cutover date. Individual ISPs could offer such a specific-sender-permissions system IMMEDIATELY to their users, and this would have a HUGE impact, in my observation, both on the amount of spam (and other wasteful HTML-burdened mail) they receive, as well as in a great reduction of the residual spam that would slip through SpamAssassin-type keyword and other content filtering. So again, to sum up: Unsolicited E-mails from unfamiliar/untrusted senders (and this would be the default) that contained HTML, scripting, attachments, or encoded text would be bounced or t-canned. A recipient could easily and quickly enable those various types of E-mail extended features individually or in combination for specified originating E-mail addresses. Remaining mail (including, potentially, residual spam) would be generally smaller in bulk (3-5x, due to no HTML-burdening in mail from untrusted senders) and far more easily processed using content-based filters such as SpamAssassin. The spam/bandwidth/bulk would be truncated as soon as the mail reached the destination domain, reducing bandwidth/storage costs for ISPs over simple user-end approaches. Space would be accordingly conserved in limited-size ISP inboxes. The approach can be implemented piecemeal and incrementally (starting at once) without requiring Net-wide consensus on new technologies or protocols. Ideas/comments/(support!) would be welcome. Gordon Peterson http://personal.terabites.com/ 1977-2002 Twenty-fifth anniversary year of Local Area Networking! Support the Anti-SPAM Amendment! Join at http://www.cauce.org/ 12/19/98: Partisan Republicans scornfully ignore the voters they "represent". 12/09/00: the date the Republican Party took down democracy in America. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg
- [Asrg] Introduction and another idea gep2
- RE: [Asrg] Introduction and another idea Bob Wyman
- Re: [Asrg] Introduction and another idea gep2
- RE: [Asrg] Introduction and another idea gep2
- Re: [Asrg] Introduction and another idea Vernon Schryver
- Re: [Asrg] Introduction and another idea Yakov Shafranovich
- RE: [Asrg] Introduction and another idea Yakov Shafranovich
- Re: [Asrg] Introduction and another idea Vernon Schryver
- RE: [Asrg] Introduction and another idea Vernon Schryver
- RE: [Asrg] Introduction and another idea Bob Wyman
- RE: [Asrg] Introduction and another idea Bob Wyman
- Re: [Asrg] Introduction and another idea Yakov Shafranovich
- RE: [Asrg] Introduction and another idea Vernon Schryver
- RE: [Asrg] Introduction and another idea Yakov Shafranovich
- Re: [Asrg] Introduction and another idea Vernon Schryver
- RE: [Asrg] Introduction and another idea Vernon Schryver
- Re: [Asrg] Introduction and another idea Benjamin Geer
- Re: [Asrg] Introduction and another idea Vernon Schryver
- [Asrg] Introduction and another idea Selby Hatch
- RE: [Asrg] Introduction and another idea gep2
- RE: [Asrg] Introduction and another idea gep2
- Re: [Asrg] Introduction and another idea Vernon Schryver
- Re: [Asrg] Introduction and another idea Benjamin Geer
- Re: [Asrg] Introduction and another idea Selby Hatch
- Re: [Asrg] Introduction and another idea gep2
- RE: [Asrg] Introduction and another idea Vernon Schryver
- Re: [Asrg] Introduction and another idea Vernon Schryver
- Re: [Asrg] Introduction and another idea Benjamin Geer
- Re: [Asrg] Introduction and another idea Kee Hinckley
- Re: [Asrg] Introduction and another idea Vernon Schryver
- Re: [Asrg] Introduction and another idea Jon Kyme
- Re: [Asrg] Introduction and another idea Vernon Schryver
- Re: [Asrg] Introduction and another idea Benjamin Geer
- Re: [Asrg] Introduction and another idea Kee Hinckley
- Re: [Asrg] Introduction and another idea Vernon Schryver
- Re: [Asrg] Introduction and another idea Steven F Siirila
- Re: [Asrg] Introduction and another idea Vernon Schryver
- Re: [Asrg] Introduction and another idea Yakov Shafranovich
- Re: [Asrg] Introduction and another idea Vernon Schryver
- RE: [Asrg] Introduction and another idea Bob Wyman
- RE: [Asrg] Introduction and another idea Bob Wyman
- RE: [Asrg] Introduction and another idea Bob Wyman
- Re: [Asrg] Introduction and another idea Benjamin Geer
- Re: [Asrg] Introduction and another idea Benjamin Geer
- RE: [Asrg] Introduction and another idea Vernon Schryver
- Re: [Asrg] Introduction and another idea Steven F Siirila
- Re: [Asrg] Introduction and another idea Vernon Schryver
- Re: [Asrg] Introduction and another idea Vernon Schryver
- RE: [Asrg] Introduction and another idea Bob Wyman
- RE: [Asrg] Introduction and another idea gep2
- Re: [Asrg] Introduction and another idea Kee Hinckley
- RE: [Asrg] Introduction and another idea Bob Wyman
- Re: [Asrg] Introduction and another idea Vernon Schryver
- RE: [Asrg] Introduction and another idea gep2
- Re: [Asrg] Introduction and another idea Tony Hansen
- RE: [Asrg] Introduction and another idea Kee Hinckley
- Re: [Asrg] Introduction and another idea Kee Hinckley
- RE: [Asrg] Introduction and another idea Kee Hinckley
- Re: [Asrg] Introduction and another idea mathew
- Re: [Asrg] Introduction and another idea Vernon Schryver
- Re: [Asrg] Introduction and another idea mathew
- Re: [Asrg] Introduction and another idea Bruce Stephens
- Re: [Asrg] Introduction and another idea Vernon Schryver
- Re: [Asrg] Introduction and another idea mathew