[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