From: Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu
"The people who claim that something can't be done shouldn't get in the
way of the people doing it."
I didn't say it *cant* be done. I said there were known problems that any
successful solution would have to address.
Another response is to point out that all of the sender validating
systems are today only proposals that can be seen as getting in the
way of effective tactics. The talkers trying to get in the way of the
doers are, as usual, those who endless prescribe spam solutions that
they themselves have not thought out, not to mention documented, tested,
or deployed.
The vast majority of the spam that sender validating systems might
block after they have been installed in most SMTP clients 5 or 10 years
from now is rejected today at any organization that really cares about
spam using any of various tactics including DNS blacklists (e.g. the
CBL or the so called "dynamic IP" lists) and greylisting.
Essentially all of the spam that any sender validating system might
someday block after large outfits like Comcast have installed validating
code on their SMTP clients and servers would be blocked today at the
source if those same outfits would block port 25 for all types of IP
service except the one that draft-klensin-ip-service-terms-01.txt calls
"Full Internet Connectivity." That is because current spam that
would be blocked by sender validating comes "trojan proxies."
The current state of the art in spam defenses reject more than 99%
of spam with less than 1% false positives (or variations of those
numbers such as 95% and 0.1%). No one who is actually do anything
about spam is content with those numbers or confident that new
tactics will not be needed, but please don't tell the experts who
don't know the difference betwee an SMTP rejection and a bounce, lest
they be encouraged to tell us some more what we really should be doing.
As usual, the usual suspects who might someday get around to reading
an RFC, any RFC, tell us that The Final Ultimate Solution to the Spam
Problem is just around the corner. Their Finual Ultimate Solution is
waiting for the obstructionists to get out of the way of those who
will realsoonnow write the FUSSP RFC. Of course, the usual suspects
can't be bothered to come down from Mt. Olympus to write a I-D or
learn the relationship between I-Ds and RFCs. They don't care about
the differences among documenting, testing, or deploying, or the chasm
between practice and sidewalk superintendent theory.
Probably the best response is to send people to the MADID mailing list.
I've often said that the IETF is well served by working groups that do
no more than absorb the energies of standards committee goers.
Vernon Schryver vjs(_at_)rhyolite(_dot_)com
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf