Whew! That is a long list, and fortunately I don't exhibit any of your stated
symptoms of "Anti-Spam Kook" so I guess I should feel sane??
Too many to addresses all, but here are a few...
I've been compiling a list in the style of Jeff Foxworthy.
You Might Be An Anti-Spam Kook If
- you have discovered the Ultimate Final Perfect Solution To The
Spam Problem (UFPSTTSP).
I am predicting spam to continue increase and in fact accelerate with either my
proposal or my other work.
Face it, filtering of bulk email is going to happen and bulk email will
increase because of it.
This might seem contradictory to other posts I have made, but it is not.
Whew! Thus no other UFPSTTSP below apply to me.
- you were motivated to find the UFPSTTSP because you know it is
impossible to filter more than 99% of spam with fewer than 0.1%
false positives by any of several currently available mechanisms.
Whew! Luckily, I know what a mathematic asymptote, limit theorem, and
confidence interval are. I guess I am still sane, praise the lord!
- despite being the inventor of the UFPSTTSP, you are unfamiliar with
"false positive," "false negative," "UBE," "tarpit," "teergrube,"
"Brightmail," "Postini," "SpamAssassin," "DNS blacklist," "HELO,"
"RBL," or "mail envelope."
And AccuSpam.com :)
- you plan to make money by licensing the idea of the UFPSTTSP.
I hate licensing and find sales to end users much more direct way to earn
income, especially when you've already automated that process in your other
businesses.
- you plan to publish an RFC mandating the UFPSTTSP but have no idea
that RFC 2223 or RFC 2026 exist.
- you have no idea of the relevance of "consensus" or "IESG approval"
to publishing RFCs.
I know I started here:
http://www.faqs.org/rfcs/inet-standards.html
and here:
http://www.faqs.org/rfcs/editor-info.html
Which refers to all your points and many which you missed!
- you think that spammers won't ignore, subvert, or exploit the
UFPSTTSP if you publish it as an RFC.
One immutable fact is spammers will ALWAYS have to send in bulk.
- you think that a violation of an RFC by an SMTP client or server
is good and sufficient reason to reject all mail from the system's
domain.
SOBO (statement of the blatantly obvious)
- despite discovering the UFPSTTSP, you don't know the meanings of
MTA, MUA, SMTP server, or SMTP client.
Yeah that would be bonehead.
- the UFPSTTSP requires a small number of central servers that for
validating email, serving as "pull servers" for bulk mail, or
anything else.
Agreed centralized solutions do not work.
- the UFPSTTSP requires that anyone wanting to send mail obtain a
certificate and that such certificates would be checked by
all SMTP servers.
Email signing is failed concept.
- you think that most Internet users would willingly pay more
$5/month to avoid spam, and don't know the per-user price
point for anti-virus software or data.
Free is nice for most.
- the UFPSTTSP involves replacing SMTP.
Morphing SMTP is a losing concept to anti-spam.
- you routinely send single "LARTS" or reports of single examples
of objectionable mail to more than two dozen addressees.
Sending 24+ emails of anything might also qualify.
- your definition of spam differs significantly from "unsolicited
bulk email".
Hint: unless that definition also corresponds to what is subjectively
"unsolicited bulk email" most of the time.
Nice fishing expedition..."you know what I mean Vern".
Shelby Moore
http://AntiViotic.com