This is a quote taken from section 4.1 of
(http://www.ietf.org/internet-drafts/draft-crocker-spam-techconsider-02.txt),
emphasis added:
-----snip----
"A key construct to examination of adoption and benefit is
"core-vs-edge". Generally, adoption at the edge of a system is easier and
quicker than adoption in the core. If a mechanism affects the core
(infrastructure) then it usually must be adopted by most or all of the
infrastructure before it provides meaningful utility. IN SOMETHING THE
SCALE OF THE INTERNET, IT CAN TAKE DECADES TO REACH THAT LEVEL OF ADOPTION,
IF IT EVER DOES.
Remember that the Internet comprises a massive number of independent
administrations, each with their own politics and funding. What is
important and feasible to one might be neither to another. If the latter
administration is in the handling path for a message, then it will not have
implemented the necessary control mechanism. Worse, it well might not be
possible to change this. FOR EXAMPLE A PROPOSAL THAT REQUIRES A BRAND NEW
MAIL SERVICE IS NOT LIKELY TO GAIN MUCH TRACTION.
By contrast, some "edge" mechanisms provide utility to the first one, two
or three adopters who interact with each other. No one else is needed for
the adopters to gain some benefit. Each additional adopter makes the total
system incrementally more useful. For example a filter can be useful to the
first recipient to adopt it. A consent mechanism can be useful to the first
two or three adopters, depending upon the design of the mechanism."
-----snip----
Thanks for posting that. That last paragraph, in particular, is a very good
discussion about why my Permissions List idea is likely to be so successful and
effective.
First, it's incrementally deployable. It interacts with the person who first
uses it, so there is an immediate positive feedback that rewards the
installation, even if NOBODY else installs it.
Second, my approach doesn't _require_ ANYBODY else to adopt it for it to be
useful.
The initial adopters will see the *great* majority of spam intercepted because
of its use of HTML-burdening.
Third, as my approach becomes more widespread, and spammers realize that using
HTML, attachments, and base64 encoding in their messages is the kiss of death
to
their messages ever being read, they'll revert to plain ASCII text which will
all by itself cut spam bulk by probably about 70%.
In the process of reverting to plain ASCII text, the GREAT majority of the
tricks they use to obscure the contents of their spam and confuse/defeat
content
scanners will be denied to them. This ensures that stuff like SpamAssassin
should be able to very effectively clean up most of what's left.
Fourth, my approach can be implemented at end-user sites, requiring *NO*
changes
at ISPs or network infrastructure AT ALL. As the usefulness becomes more
widespread, I believe that the permissions list filtering will probably move so
that it occurs as soon as the spam hits the destination domain... either the
ISP
or domain provider. This will reduce the storage/bandwidth costs at the
destination ISP, plus will offer the ISP a competitive advantage over ISPs that
don't offer the service. Customers not wanting spam (and we've seen with the
new nationwide do-not-call list how consumers are rushing to take advantage of
features like this) will obviously prefer ISPs which help control the flood of
spam. (And unlike other techniques, mine has the advantage of not being
totally
invisible... the user is more aware of how much spam is being intercepted,
which
means that they appreciate the service much more).
One thing that I've done as a result of the discussions here is that I've
started implementing some of the stuff we've talked about into my personal
E-mail processing system. In particular, it struck me as useful to not just
route the spam to a "spam" dead-letter-mailbox but also to produce a summary
list of what's been routed there, and why. Currently this list is just being
kept as a file on disk, although I'll probably add the features to periodically
E-mail it to me, as well as providing an interactive tool of some kind to
facilitate me dealing with the information in it... (examine. discard, deliver
anyway, update rules, etc etc)
Note that my present incoming mail filter does not yet implement the
Permissions
List feature (which accounts for some of the stuff I'm seeing in my spam
routing
reports...) but FWIW here's some of the early results, just as an example:
I've inserted [comments] here to explain some of the results and reasons.
[quote]
-----
\\NTS1\HOME\SPAM\INETMAIL\INBOX\MSG57.msg
To: terabites(_dot_)com%gep2(_at_)terabites(_dot_)com
From: WaterTower Theatre <info(_at_)watertowertheatre(_dot_)org>
Subject: Final weekend for "the best dramatic production of the season"
Reason: ccprod.roving.com
[ccprod.roving.com is a disreputable domain so any post referring to them gets
filtered. In this case, watertowertheare.org is a 'good' outfit so I'll put
them in my permissions list to allow them to send to me regardless.]
-----
\\NTS1\HOME\SPAM\INETMAIL\INBOX\MSG115.msg
To: terabites(_dot_)com%gep2(_at_)terabites(_dot_)com
From: "Otis Fournier" <txam1212189610(_at_)execs(_dot_)com>
Subject: iacitified966592(_at_)paris(_dot_)com wlxp hftu
Reason: 1
[reason '1' is that the E-mail contains heavily-obscured URLs]
-----
\\NTS1\HOME\SPAM\INETMAIL\INBOX\MSG116.msg
To: terabites(_dot_)com%gep2(_at_)terabites(_dot_)com
From: suespammers-request(_at_)spamcon(_dot_)org
Subject: suespammers digest, Vol 1 #810 - 2 msgs
Reason: ?xml:namespace prefix =3D o ns =3D=20
"urn:schemas-microsoft-com:office:office" /
[this message contained HTML codes my filter didn't like]
-----
\\NTS1\HOME\SPAM\INETMAIL\INBOX\msg117.msg
To: terabites(_dot_)com%gep2(_at_)terabites(_dot_)com
From: "Willis Piper" <willis(_dot_)piper_vq(_at_)lycos(_dot_)com>
Subject: Hi oqedz33weg7
Reason: www.herbalpillsonline.biz, kxb3p662yy61yl1
[disreputable domain reference, and use of garbage HTML tags to obscure message
content]
-----
\\NTS1\HOME\SPAM\INETMAIL\INBOX\MSG124.msg
To: terabites(_dot_)com%gep2(_at_)terabites(_dot_)com
From: HomeOfTheBrave(_at_)yahoogroups(_dot_)com
Subject: [HomeOfTheBrave] Digest Number 873
Reason: adserver.trb.com
[disreputable domain reference]
-----
\\NTS1\HOME\SPAM\INETMAIL\INBOX\MSG115.msg
To: terabites(_dot_)com%gep2(_at_)terabites(_dot_)com
From: "Otis Fournier" <txam1212189610(_at_)execs(_dot_)com>
Subject: iacitified966592(_at_)paris(_dot_)com wlxp hftu
Reason: 1
[heavily obscured URL]
-----
\\NTS1\HOME\SPAM\INETMAIL\INBOX\MSG116.msg
To: terabites(_dot_)com%gep2(_at_)terabites(_dot_)com
From: suespammers-request(_at_)spamcon(_dot_)org
Subject: suespammers digest, Vol 1 #810 - 2 msgs
Reason: ?xml:namespace prefix =3D o ns =3D=20
"urn:schemas-microsoft-com:office:office" /
[undesirable HTML tags]
-----
\\NTS1\HOME\SPAM\INETMAIL\INBOX\MSG11.msg
To: terabites(_dot_)com%gep2(_at_)terabites(_dot_)com
From: "lastminute.com" <fr2(_at_)lastminute(_dot_)com>
Subject: Decollez pour Madrid ou repartez avec 2000 euros
Reason: www.lastminute.com, weeklynews2.lastminute.com
[known spammer domains]
-----
\\NTS1\HOME\SPAM\INETMAIL\INBOX\MSG13.msg
To: terabites(_dot_)com%gep2(_at_)terabites(_dot_)com
From: "Lewis Cartwright" <hixhvas632(_at_)yahoo(_dot_)com>
Subject: look good for your wife our husband
Reason: <!sdgdg!>t A<!sdgdg!>ga
[garbage HTML tags used to obscure message content]
-----
\\NTS1\HOME\SPAM\INETMAIL\INBOX\y3988397.msg
To: terabites(_dot_)com%gep2(_at_)terabites(_dot_)com
From: Patrick Douglas Crispen <crispen(_at_)NETSQUIRREL(_dot_)COM>
Subject: Tourbus -- 8 July 03 -- Attachment Warning / Validators
Reason: -------------+
* Does your desk look like a toxic waste dump?
* Do you have piles of paper everywhere?
* Do you waste an hour a day looking for stuff that's "lost"
on the top of your desk?
New eBook, "Winning The Fight Between You and Your Desk" shows you
how to take a desk that looks like a waste dump, and transform it
into one that resembles the flight deck of an aircraft carrier.
<A href=" http://SucceedingInBusiness.com/Tourbus.htm "
[false trigger, which I'll resolve by revising my filter rule and probably
granting this sender permission to send appropriate things]
-----
\\NTS1\HOME\SPAM\INETMAIL\INBOX\y2262277.msg
To: terabites(_dot_)com%gep2(_at_)terabites(_dot_)com
From: HomeOfTheBrave(_at_)yahoogroups(_dot_)com
Subject: [HomeOfTheBrave] Digest Number 879
Reason: javascript:Currency();
[no reason to allow javascript in an E-mail digest!]
-----
\\NTS1\HOME\SPAM\INETMAIL\INBOX\MSG14.msg
To: terabites(_dot_)com%gep2(_at_)terabites(_dot_)com
From: "Bill" <wtc(_at_)mchsi(_dot_)com>
Subject: ABCNEWS.com U.S. Military Wanted to Provoke War With Cuba.txt
Reason: ehg-dig.hitbox.com
[disreputable domain referenced]
-----
\\NTS1\HOME\SPAM\INETMAIL\INBOX\MSG15.msg
To: terabites(_dot_)com%gep2(_at_)terabites(_dot_)com
From: "Larry Pfeffer" <lpfeffer(_at_)actcom(_dot_)co(_dot_)il>
Subject: Re; XML
Reason: !--$/TEMPLATE
[another case where I need to allow a trusted sender to send appropriate things]
[end quote]
Anyhow, what's important here is that this list gives me an indea of what the
filter-held E-mail in question was represented as containing (the subject), who
supposedly sent it, how it was addressed, and what the filtering system found
in
it that it didn't like. Based on that, I can (manually, for now) revise the
filter, review the message, trash it, deliver it anyway, or whatever. This is
the first stage towards a more automated "rapid triage" that will help me to
refine the permission list.
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