Subject: RE: [Asrg] Introduction and another idea

From: [email-masked]
Date: Tue, 17 Jun 2003 12:50:10 -0500

>> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 19 Jun 2003 14:16:31 -0400

At 12:50 PM 6/17/2003 -0500, [email-masked] wrote:

>[..]

Can ISPs on the list provide some statistics on percentage of legimitate 
email coming in as HTML, attachments, base64, etc.

---

From: Vernon Schryver <[email-masked]>
Date: Thu, 19 Jun 2003 12:48:43 -0600 (MDT)

> email coming in as HTML, attachments, base64, etc. 

That's an example of a question that, as phrased, should not be asked.

An ISP cannot say anything about the legitimacy of incoming mail.  An
ISP can say some mail is not legitimate, but that implies nothing
either way about whether the remaining mail is legitimate. 

That popular MUAs send HTML by default also makes the question
as phrased a distraction and a likely seed of misinformation.

Vernon Schryver    [email-masked]