[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Asrg] [IP] do-not-email list canned



On Wed, 16 Jun 2004, "Jon Kyme" <jrk at merseymail.com> wrote:

>> Until they really solve the virus/worm problem (and none of these
>> approaches
>> solve that, either, except the one I've been proposing) you don't solve
>> the
>> zombie spambot problem, and if you don't solve the zombie spambot
>> problem, then
>> you CANNOT solve the DDOS problem or the spam problem by these
>> ill-conceived and
>> almost wholly nonsensical "authentication" approaches.
 

>You're in favour of some kind of consent scheme? Is there any one in
>particular?

Yes...

It's really quite simple, and it can be implemented at the user level (it could 
be done in Outlook and Outlook Express, or could be implemented rather simply as 
a local package that runs either on the same machine, or (in a business 
scenario) on another computer elsewhere in the network.

It's a two-stage approach.

The first stage is a finely-grained whitelist.  Each recipient could specify a 
whitelist of who they trust to send them what type of material.

By default, senders could send the intended recipient plain ASCII text messages, 
no HTML, no attachments.  This implies no scripting, no activeX, no 
misrepresented/spoofed links, no obscured URLs, no executables, no 
text-as-image.  (Together, this denies spammers nearly all of the tricks and 
deceits they use to defeat antispam content scanners.)

If the recipient trusts someone, they can relax the restrictions on those 
approved senders to send them other types of material.  For example, Aunt 
Gertrude might be expected (and allowed) to send you JPGs or GIFs (say, of her 
poodle Fifi) but you'd not expect or authorize her to send you .CPL, .PIF, or 
.VBS files, nor would you expect or authorize her to send you ActiveX, 
Javascript, or other such junk.  Individual implementations and configuration 
options would decide how to deal with nonconforming mail... either strip the 
objectionable content and deliver the remainder, treat it as garbage and T-can 
it (that would probably be the desirable mode following a phase-in period), or 
whatever.  Note that most users would not have ANYBODY allowed to send them 
executables or HTML, and thus we'd have virtually eliminated (and without 
twice-a-week downloads of virus signatures, which inevitably still miss the 
newest ones) the problem of viruses and worms in E-mail... and thus, the E-mail 
distribution of zombie spambot code.  (Something like this is also about the 
only practical way to eliminate E-mail as a mechanism for setting up zombie DDOS 
attacks, which "enterprise" security solutions CAN NEVER solve on their own).  

As a side benefit, once spammers learn that using HTML-burdened E-mail is the 
kiss of death for their spam, they'll be forced to send their junk in plain 
ASCII text, which all by itself will cut the global bandwidth (and storage space 
too) used for spam messages (on a per-message basis at least) by 65-85%.

The second stage would be a good antivirus content filter, perhaps something 
like Spam Assassin, which would pick up (and then far more successfully than at 
present) on the residual spam indicators.

Together, this would result in not only getting rid of most spam, but it would 
virtually eliminate the E-mail distribution of viruses and worms (and without 
needing to download big and bigger signature files forever), it would eliminate 
misrepresented hyperlinks (a common trick in spoofed and phishing E-mails), it 
would help protect against zombie DDOS attacks, and reduce the physical bulk and 
cost of the residual spam.  It requires no global infrastructure changes to the 
Internet at all, can be implemented incrementally and delivers significant 
benefits *immediately* to those who have implemented it, and does not 
substantially restrict any legitimate uses of the Net.  It works for those who 
receive large amounts of unsolicited but legitimate E-mail from unexpected 
senders (say, customer service departments of large companies) and allows for 
mobile/kiosk/cruiseship use of even vanity domains.  Spambot zombies (the 
"gotcha" flaw of virtually all of these misguided authentication/authorization 
proposals) would be virtually eliminated (at least in terms of distribution by 
E-mail, which is what we're dealing with here).

Even if Aunt Gertrude's machine were to be infected, the fact that she isn't 
authorized to send me HTML or .PIF/.EXE attachments means that anything 
inhabitual (and thus suspicious) coming from her machine would simply be 
discarded (as it should be!) while any LEGITIMATE expected-type mail she might 
send me, even during the period of the infection, would continue to be delivered 
to me as usual.

And yet a further advantage... it's not a highly technical solution that you 
have to intimately understand Internet technology to grasp.  

And it's not a solution for "someday" once some kind of global consensus is 
reached... it would work TODAY, starting from the FIRST implementors and users. 
 And the benefits accrue starting immediately to those installing it, so it's 
not something that you have to do primarily to benefit SOMEONE ELSE somewhere as 
a gesture of good Internet citizenship or something.

A simple solution, one that works.... one that TRULY solves the problem, rather 
than solving a misguided misimpression of what the real problem is, like most of 
these other approaches.  

Gordon Peterson                  http://personal.terabites.com/
1977-2002  Twenty-fifth anniversary year of Local Area Networking!
Support free and fair US elections!  http://stickers.defend-democracy.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.org
https://www1.ietf.org/mailman/listinfo/asrg