On Sat, 22 Mar 2003, Steve Schear wrote: > The idea if for stamps to be created at the client end. For most people > that is not the SMTP server. Even for Web-based email, I envision the > client being "encouraged" by the ISP to do the computation work on their > own HW, perhaps via a Java applet.
Great. So now all sorts of server-running applications that communicate with the other machines or the users by mail (eg, certain custom database systems that inform a set of customers about record changes) will have another set of problems to maintain. Java applets rule out the console browsers, and all infrastructures that have Java disabled for security reason. Another unneeded technological dependence. > Using a PoW stamp regime low speed processors will either by enable to > initiate contact with an unknown addresser or arrange for a third-party > (maybe their ISP/cellular provider) to create the introduction stamp for them. ...and create YET ANOTHER dependence of questionable reliability. "Sorry, boss, I was unable to send that topmost-important message to your new customer because our cellular provider's stamping server was down again." > >And you most likely lose the ability to send mails using raw telnet. > True. Which takes away a handy method to improvise, to solve simple things simple way. Why all the "solutions" HAVE to create new, flakey dependencies? Things that look good on paper too often turn into a technological nightmare when you attempt to actually deploy them, and this method is a hot candidate for a disaster. (Well... even pigs can fly, when you kick them hard enough, but you don't have good control over where they land, and it isn't advisable to be under their trajectory.) Why things can't be SIMPLE?!?
