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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg