Subject: [Asrg] Introduction and another idea

From: [email-masked]
Date: Sun, 15 Jun 2003 16:53:32 -0500

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

---

From: "Bob Wyman" <[email-masked]>
Date: Tue, 17 Jun 2003 12:28:09 -0400

Gordon Peterson wrote:

> 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. 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. 
	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. 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. 

> [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. 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. 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. 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. 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...
	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...

> 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...

		bob wyman