Update of /cvsroot/tmda/tmda/htdocs
In directory usw-pr-cvs1:/tmp/cvs-serv28253/htdocs
Modified Files:
index.ht index.html
Log Message:
Add some new wording to emphasize that TMDA has features (e.g, `dated'
addresses) that greatly reduce the number of legitimate senders who
are actually faced with a confirmation request.
The biggest misconception about TMDA is still that it's nothing more
than a "whitelist checker", and that it shifts the burden of the SPAM
problem onto the poor innocent sender. While this is true to some
extent, using TMDA in its full form will reduce this burden
significantly. As pointed out in the FAQ, over the past year and a
half, only ~6% of my legitimate senders have actually had to reply to
a confirmation request. These are generally folks e-mailing me out of
the blue, or replying to an old USENET or mailing list post of mine.
That's very little time wasted, even if it is someone else's time.
I'm also tired of chasing down the misconceptions and erroneous
gibberish propagated by all the knuckle-heads out there who like to
make assumptions without reading documentation. Hopefully word of
mouth will be loud enough to quelch most of the ignorance.
Index: index.ht
===================================================================
RCS file: /cvsroot/tmda/tmda/htdocs/index.ht,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- index.ht 1 Mar 2002 01:28:54 -0000 1.10
+++ index.ht 3 Sep 2002 18:39:15 -0000 1.11
@@ -8,11 +8,12 @@
OSI certified</a> software application designed to significantly
reduce the amount of
<a href="http://spam.abuse.net/"; TARGET="Resource Window">SPAM/UCE</a>
-(junk-mail) you receive.
-TMDA combines a "whitelist" (for known/trusted senders), a "blacklist"
-(for undesired senders), and a cryptographically enhanced confirmation
-system (for unknown, but legitimate senders). TMDA strives to be more
-effectual, yet less time-consuming than traditional filters.
+(junk-mail) you receive. As a SPAM filter, TMDA combines a "whitelist"
+(for known/trusted senders), a "blacklist" (for undesired senders),
+and a cryptographically enhanced confirmation system (for unknown, but
+legitimate senders). TMDA strives to be more effectual, yet less
+time-consuming than traditional filters.
+
<br><br>
TMDA also acts as a local mail delivery agent, with a flexible
@@ -36,15 +37,17 @@
whitelist insures they won't have to confirm future messages. TMDA
can even be configured to automatically whitelist confirmed senders.
To see what the confirmation process looks like,
-<a href="mailto:[EMAIL PROTECTED]";>try sending me a test message</a>.
-(<strong>NOTE:</strong> Confirmed test messages are automatically discarded)
+<a href="mailto:[EMAIL PROTECTED]";>send me a test message</a>,
+and then reply to the confirmation request.
<br><br>
This methodology has the advantage of being very selective about what
it allows in, while at the same time permitting legitimate, but
previously unknown senders to reach you. TMDA also has several
-techniques (See the <a href="config-client.html">Client Configuration</a> section)
-that allow senders to circumvent the whitelist.
+techniques (See the <a href="config-client.html">Client
+Configuration</a> section) that allow senders to circumvent the
+whitelist, which greatly reduces the number of legitimate senders who are
+burdened with a confirmation request (only ~6% in my case).
<br><br>
</ul>
@@ -60,10 +63,10 @@
The problem with this approach is that spammer's intrusion techniques
are evolving as fast as your prevention techniques are, so the battle
-is never ending. Maintaining the blacklist is often just as
-time-consuming as pressing the "Delete" key on the easily recognized
+is never ending. Maintaining the blacklist or spam "corpus" is often just as
+time-consuming as pressing the `Delete' key on the easily recognized
junk messages. If wasted time is your biggest complaint with junk
-e-mail, you can see why this traditional methodology is flawed.
+e-mail, you can see why these traditional methodologies are flawed.
<br><br>
The chance of accidental "false positives" is also significantly
Index: index.html
===================================================================
RCS file: /cvsroot/tmda/tmda/htdocs/index.html,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- index.html 19 Aug 2002 17:30:06 -0000 1.22
+++ index.html 3 Sep 2002 18:39:16 -0000 1.23
@@ -1,6 +1,6 @@
<HTML>
<!-- THIS PAGE IS AUTOMATICALLY GENERATED. DO NOT EDIT. -->
-<!-- Mon Aug 19 11:29:08 2002 -->
+<!-- Tue Sep 3 12:22:30 2002 -->
<!-- USING HT2HTML 1.2 -->
<!-- SEE http://barry.wooz.org/software/ht2html -->
<!-- User-specified headers:
@@ -145,11 +145,12 @@
OSI certified</a> software application designed to significantly
reduce the amount of
<a href="http://spam.abuse.net/"; TARGET="Resource Window">SPAM/UCE</a>
-(junk-mail) you receive.
-TMDA combines a "whitelist" (for known/trusted senders), a "blacklist"
-(for undesired senders), and a cryptographically enhanced confirmation
-system (for unknown, but legitimate senders). TMDA strives to be more
-effectual, yet less time-consuming than traditional filters.
+(junk-mail) you receive. As a SPAM filter, TMDA combines a "whitelist"
+(for known/trusted senders), a "blacklist" (for undesired senders),
+and a cryptographically enhanced confirmation system (for unknown, but
+legitimate senders). TMDA strives to be more effectual, yet less
+time-consuming than traditional filters.
+
<br><br>
TMDA also acts as a local mail delivery agent, with a flexible
@@ -173,15 +174,17 @@
whitelist insures they won't have to confirm future messages. TMDA
can even be configured to automatically whitelist confirmed senders.
To see what the confirmation process looks like,
-<a href="mailto:[EMAIL PROTECTED]";>try sending me a test message</a>.
-(<strong>NOTE:</strong> Confirmed test messages are automatically discarded)
+<a href="mailto:[EMAIL PROTECTED]";>send me a test message</a>,
+and then reply to the confirmation request.
<br><br>
This methodology has the advantage of being very selective about what
it allows in, while at the same time permitting legitimate, but
previously unknown senders to reach you. TMDA also has several
-techniques (See the <a href="config-client.html">Client Configuration</a> section)
-that allow senders to circumvent the whitelist.
+techniques (See the <a href="config-client.html">Client
+Configuration</a> section) that allow senders to circumvent the
+whitelist, which greatly reduces the number of legitimate senders who are
+burdened with a confirmation request (only ~6% in my case).
<br><br>
</ul>
@@ -197,10 +200,10 @@
The problem with this approach is that spammer's intrusion techniques
are evolving as fast as your prevention techniques are, so the battle
-is never ending. Maintaining the blacklist is often just as
-time-consuming as pressing the "Delete" key on the easily recognized
+is never ending. Maintaining the blacklist or spam "corpus" is often just as
+time-consuming as pressing the `Delete' key on the easily recognized
junk messages. If wasted time is your biggest complaint with junk
-e-mail, you can see why this traditional methodology is flawed.
+e-mail, you can see why these traditional methodologies are flawed.
<br><br>
The chance of accidental "false positives" is also significantly
_______________________________________
tmda-cvs mailing list
http://tmda.net/lists/listinfo/tmda-cvs
