I proposed a system to fix that problem. I recieved no constructive
criticism, and when I proposed government funding that became the issue not
wether or not it could work.
What purpose relevant to this mailing list is served by this thread?
Repeated statements in favor of challenge/response, authentication,
honeypots, or sender-pays spam solutions are not going to convince
the rest of us. Perhaps because of my biases, I doubt it is a
coincidence that those proposed solutions have received most of the
vervbage in this mailing list but have very limited and in many cases
no real implementations and in all cases no real life trials or tests,
while other mechanisms (plural) that are dealing with a large fraction
of spam today have had few or no comments. The reason many of us are
here is that those real mechanisms are imperfect, but they are vastly
better than any amount of talk. (Any spam solution with a real life
implementation is rejecting at least millions of spam/day. Anything
doing less is probably less than a proof of concept.)
Could the advocates of challenge/response, authentication, honeypots,
and sender-pays temporarly retire with honor from verbal jousting,
and contribute to the ostensible purposes of this mailing list?
Or at least shift some effort from advocacy to implementating,
deploying, and proving the rest of us wrong?
Failing that, could those who see problems with those classes of
proposed solutions limit themselves to countering efforts to borrow
the imprimatur of the IETF for commercial products? For example,
it's not necessary to point out that any spam solution that assumes
government funding should be proposed to those who control government
funding and that talking about it here is a waste time.
Contrary to some advocates, the IETF/IRTF does not work by:
1. IRTF/IETF deliberates and figures out what to.
2. IRTF/IETF issues orders to programmers.
3. programmers deliver code.
4. code is deployed.
The following is closer to what happens:
1. someone figures out what to do.
2. IRTF/IETF argues.
3. someone writes code that implements it.
4. (optional) IRTF/IETF argues.
5. someone tests that code, sometimes in simulatation as well as
real networks and sometimes only in real networks.
6. (optional) IRTF/IETF argues.
7. code is deployed widely.
8. if the tests are successful, the IRTF/IETF moves on.
If not, repeat from step #1.
The IRTF/IETF arguing has limited effects and is optional.
The IRTF/IETF does not and cannot order anyone to do anything.
Steps #3, #5, and #7 are always required.
No matter how many verbal proofs of the wonderfulness of
challenge/response, authentication, honeypots, or sender-pays spam
solutions are written, until someone writes code and does real,
non-trivial, convincing tests, nothing happen with those spam solutions.
Vernon Schryver vjs(_at_)rhyolite(_dot_)com
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg