RE: [Asrg] Introduction and another idea
gep2@terabites.com Tue, 17 June 2003 19:41 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 PAA06886 for <asrg-archive@odin.ietf.org>; Tue, 17 Jun 2003 15:41:08 -0400 (EDT)
Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HJedX16397 for asrg-archive@odin.ietf.org; Tue, 17 Jun 2003 15:40:39 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SLs2-0000hD-G9 for asrg-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 15:11:54 -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 PAA04696; Tue, 17 Jun 2003 15:11:50 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SLpm-0003cn-00; Tue, 17 Jun 2003 15:09:34 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SLpl-0003ck-00; Tue, 17 Jun 2003 15:09:33 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SL03-0003SL-Rs; Tue, 17 Jun 2003 14:16:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SKBA-0000OV-Kt for asrg@optimus.ietf.org; Tue, 17 Jun 2003 13:23:32 -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 NAA27303 for <asrg@ietf.org>; Tue, 17 Jun 2003 13:23:28 -0400 (EDT)
From: gep2@terabites.com
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SK8v-000202-00 for asrg@ietf.org; Tue, 17 Jun 2003 13:21:13 -0400
Received: from h002.c000.snv.cp.net ([209.228.32.66] helo=c000.snv.cp.net) by ietf-mx with smtp (Exim 4.12) id 19SK8u-0001zy-00 for asrg@ietf.org; Tue, 17 Jun 2003 13:21:12 -0400
Received: (cpmta 9933 invoked from network); 17 Jun 2003 10:23:28 -0700
Received: from 12.239.18.238 (HELO WinProxy.anywhere) by smtp.terabites.com (209.228.32.66) with SMTP; 17 Jun 2003 10:23:28 -0700
X-Sent: 17 Jun 2003 17:23:28 GMT
Received: from 192.168.0.30 by 192.168.0.1 (WinProxy); Tue, 17 Jun 2003 12:23:14 -0600
Received: from 192.168.0.240 (unverified [192.168.0.240]) by nts1.terabites.com (EMWAC SMTPRS 0.83) with SMTP id <B0000024047@nts1.terabites.com>; Tue, 17 Jun 2003 12:50:10 -0500
Message-ID: <B0000024047@nts1.terabites.com>
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Subject: RE: [Asrg] Introduction and another idea
To: asrg@ietf.org
X-Mailer: SPRY Mail Version: 04.00.06.17
Content-Transfer-Encoding: 7bit
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: Tue, 17 Jun 2003 12:50:10 -0500
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
>> 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. > Personally, I believe that this kind of approach will be much more likely to result in useful throttling of spam. Thanks! Obviously, I agree. In particular, when you actually look at the spam (and viruses, and worms) going through the Net, the *great* majority of it is pernicious (and hard to filter) due to various tricks generally exploiting HTML, encoded text, and attachments. It's notable, I think, that very little LEGITIMATE E-mail content (and relatively few senders) need to send E-mail containing those types of content. In my case, I would probably enable less than 10-15% of my correspondents to send me that type of stuff. Once spammers realize that sending HTML of any kind is the "kiss of death" regarding deliverability of their crap, they'll either stop using it or else at least they'll cease to be much of a problem for recipients whose ISP uses a "permissions system" like I'm proposing. And once these key "obscuring/cloaking" technologies are denied to spammers, stuff like SpamAssassin or other content filters ought to pretty readily quash much of the remainder. Remember, we don't have to eliminate ALL spam. We only need to reduce its viability below the break-even point where it's profitable and thus appealing to would-be spammers. Then they'll simply go off and do some other line of work instead... And note that it's not just spam that my approach puts a major dent in... it also puts a major crimp in viruses and worms, too, since nearly all of those depend either on HTML and/or attachments. Those types of E-mails (from unknown senders) would ALL be t-canned, and even stuff like that from KNOWN senders would _usually_ be t-canned... making these nuisances FAR less virulent. > It addresses the issue of "consent" that is supposed to be the focus of this research group and has the excellent benefit of being an approach that can be adopted by individuals without requiring changes to the existing infrastructure. Absolutely. No global consensus is required, no global re-engineering of the DNS or E-mail or other systems. It is implementable incrementally on as little as a single-ISP basis (even on a single-RECIPIENT basis, for that matter) and the benefits to those thus protected would be felt IMMEDIATELY. Even those who are NOT directly protected by such a permissions-based system would still benefit once spammers wise up and stop using HTML or attachments for their outgoing junk. > I view the problem of "consent" as one similar to that of "licensing" or "authorization." Basically, what you want to do is grant different levels of privilege to people who might attempt to access your inbox. Exactly. But (and this is important) I don't think you must (or should!) tell users what their privilege level might be. (For example, I don't want spammers going through their list of harvested addresses and querying to find out which ones allow them (*or, for that matter, certain well-known and widely used sender addresses*!) to send that recipient HTML or attachments...) I think it's better for those things to simply disappear down a black hole without a trace (at least not visible to anybody other than, perhaps, the intended recipient...) > This can be done either be creating an explicit whitelist which is checked when mail arrives, or by providing a "license to send" to a sender which would be a digital certificate detailing their rights and could be attached to mail as it travels through the network. I don't think that senders ought to be told what their permissions level is. They should simply send ALL mail in the compact, non-HTML-burdened format since that format WOULD get through permissions-based approaches like mine. Those who absolutely need to send HTML, attachments, or encoded text simply must arrange in advance with their intended recipients to enable such receipt from that sender. >> [SPF, RMX and other DNS based approaches] comes at a high > (perhaps unreasonably high) cost to many types of users who > for legitimate reasons sometimes post from atypical locations > The supporters of SPF, RMX, and other similar approaches appear to be well aware of these concerns yet they also appear to be relatively unmoved by them. Absolutely, and that alarms me too. They seem to want to press forward, even knowing upfront that their approach leads to a brick wall down the path for many legitimate users. > The response to this concern is to say simply that users at "atypical locations" should be compelled to use SMTP authentication or some other means to access their normal mail servers even when at distant locations. That's simply not an option for users sending mail from kiosks at airport waiting lounges, public access terminals at public libraries, or at Internet cafes (including, for example, those onboard cruise ships). The other problem with the whole spf-type thing is that (despite the costs and problems) it REALLY doesn't do much in the end to solve the spam problem. It complicates the entire global DNS and E-mail systems and doesn't really prevent the sending of spam (nor does it do much to solve the bandwidth or obscuring techniques that spammers use). It only "qualifies" the sender, and in fact it doesn't even really do that (since again, it would "approve" spammers as long as they counterfeited an address from any other sender of their same (possibly HUGE!) domain...). Even basing it on a SINGLE ISP wouldn't correctly identify a fraudulent sender if (for instance) they saw a user sending from a public library Internet terminal (with SPF authorization), then sat down at the same terminal and fraudulently used the same "from" address from the exact same IP address. (Sorta the same reason why cookies are such a braindead way to try to track Web site permissions and usage...) > I think that the belief that SMTP authentication is a reasonable alternative is a bit humorous... The assumption is that connectivity exists between the sending client and the users SMTP server. It MIGHT, but it certainly doesn't always. Some ISPs, in particular, simply don't allow their users to connect to any off-local-net SMTP servers. Even if they COULD connect, it's NOT true that users at public-access terminals have much[/any!] choice of how those E-mail client softwares are configured, or what SMTP server they'll use. > Admittedly, these days, with a much improved network infrastructure, this is often the case -- unlike in the old days when connectivity was *never* assumed. However, even today, connectivity cannot always be guaranteed. Good example would be onboard a cruise ship or drilling rig or something where (at about $7-10/minute) they cannot be assumed to have 24/7 connectivity. ;-) > For instance, in the last few years, I have often found myself in places like India where from time to time it can be almost impossible to connect to a New York based SMTP server... Same was true when about a year and a half ago I spent a week in Beijing. And you can FORGET about trying to ask the local admin (there, folks at the post office where the Internet terminals were located) to set up a special alternative mail server setup for you. It's hard enough given the language and habit barriers to just get your keyboard back to English. :-) > If we end up adopting approaches that require connectivity to a "home" server, I'm afraid that we're going to have to define some additional protocol that will allow a mail to be submitted at one server, then forwarded to a home server for authentication and processing processing simply so that we can get the headers properly written. This "deferred authentication" process would be cumbersome, error-prone and would probably rely on PKI technologies. Not pleasant... I think we can make something that's VERY much simpler, and still quite successful enough to push the viability rate for spamming (maybe even viruses and worms) below the threshhold where it is an appealing method for abusers. >> Gordon Peterson, live in Dallas. I've been active in > computer E-mail and networking longer than most > It's good to see an old-timer on the list... I've only been on the net since 1979 and so appreciate the contributions of you old folk... Thanks :-) although you were one of the earlier adopters yourself, from the sounds of things. :-)) 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