From: Keith Moore <moore(_at_)cs(_dot_)utk(_dot_)edu>
However, what is the harm in making an RFC and then find out if enforcers
will enforce??????
you appear to presume that you can get consensus support for such a plan
from within IETF. even if you could get such support (which you cannot)
note that there's no enforcement of IETF's other opinions, ...
...
yeah.
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).
- you are the first to think of the UFPSTTSP.
- 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.
- 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."
- you plan to make money by licensing the idea of the UFPSTTSP.
- you are deeply offended when people do not agree that you have
found the UFPSTTSP.
- you cannot name several potentially fatal flaws in the UFPSTTSP.
- you think all you need to do to get the UFPSTTSP implemented and
deployed is to publish an RFC.
- you don't recognize the difference between deploying and implemeting
the UFPSTTSP.
- 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.
- you think all RFCs have the same standing.
- you think that spammers won't ignore, subvert, or exploit the
UFPSTTSP if you publish it as an RFC.
- the UFPSTTSP depends on spammers or mail recipients changing
their behavior without any immediately gain.
- the UFPSTTSP won't be effective until it has been deployed at more
than 60% of SMTP servers and you don't think that's a problem.
- the UFPSTTSP is trivial to implement and deploy, but you have
done neither.
- you feel your job is done after having explained the UFPSTTSP, and
that "programmers" will drop everything to implement it.
- 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.
- you think that SMTP has no authentication and have never heard of
SMTP-AUTH, SMTP-TLS, S/MIME, or PGP or think they're irrelevant
to the lack of authentication in SMTP.
- you think that the fact that most SMTP servers do not authenticate
the SMTP clients of strangers is a major bug in SMTP instead of
a major feature and expression of a primary design goal.
- despite discovering the UFPSTTSP, you don't know the meanings of
MTA, MUA, SMTP server, or SMTP client.
- the UFPSTTSP requires a small number of central servers that for
validating email, serving as "pull servers" for bulk mail, or
anything else.
- the UFPSTTSP requires that anyone wanting to send mail obtain a
certificate and that such certificates would be checked by
all SMTP servers.
- you think that useful certificates of a person's identity that
certifies not only that the person has name but has no other
certified names are cheap and easy.
- 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.
- you don't see why a certificate that binds a name to a user is
useless against spam unless it also certifies that the user has
no other names.
- the UFPSTTSP involves ISPs issuing certificates to users and that
the same ISPs that don't terminate the accounts of spammers or
don't investigate prospective customers enough to refuse service
to spammers will refuse certificates to spammers.
- you've never heard of RFC 2554 or RFC 2487 and the UFPSTTSP
has something to do with authentication.
- the UFPSTTSP involves replacing SMTP.
- you routinely send single "LARTS" or reports of single examples
of objectionable mail to more than two dozen addressees.
- your definition of spam differs significantly from "unsolicited
bulk email".
Vernon Schryver vjs(_at_)rhyolite(_dot_)com