> From: Valdis.Kletnieks@xxxxxx > > "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@xxxxxxxxxxxx _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf