Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Security

More Applications For Hashcash 97

Posted by timothy from the to-stem-the-tide dept.
Anon writes: "Although the use of HashCash has been featured before, Adam Back has recently (August 1st) published a paper about it, outlining many other applications for the mechanism. Quite an interesting read. It seems the guys at camram have been working on a standard for use in e-mail too."
This discussion has been archived. No new comments can be posted.

More Applications For Hashcash More

More Applications For Hashcash

Comments Filter:
  • Isn't that what you take with you to the coffee shops in Amsterdam? :)

  • More applications? (Score:4, Funny)

    by Anonymous Coward on Wednesday September 11, 2002 @12:05PM (#4238539)
    To prevent spam I ask for the solution of a difficult math problem before I give my e-mail address. I haven't had a date since then.

  • HashCash software (Score:2, Insightful)

    by Delta ( 16579 )
    HashCash can be used to solve a lot of problems with publicly available resources and services, but in order to get the full gain from such techniques there needs to be software and libraries available which allows easy integration of HashCash techniques.

    Does anyone have any good resources on HashCash source code or other things to aid development?

    • Re:HashCash software (Score:4, Informative)

      by Adam Back ( 600774 ) <adam@cypherspace.org> on Wednesday September 11, 2002 @01:12PM (#4239023) Homepage
      there is some library and command line tool source available at: http://www.cypherspace.org/hashcash/source/ [cypherspace.org] also there is a windows gui version and a java applet version which is kind of "clientless" for people with java browers. (The camram group are using the java version for senders who don't have a hashcash client). http://www.cypherspace.org/hashcash/ [cypherspace.org]
    • You can go pretty much anywhere with a perl library. I've been meaning to do this for aaaagggesss. The plan is to start small and do the XS library integration later. It doesn't seem quite so daunting this way.

      My problem is, I have fingers in too many pies.

      Adam's site (above) is the definitive place to look though.

      • With a decent C version, creating a PERL wrapper should not be hard work.

        I would not recommend writing HashCash software in pure Perl, as you want the clients to be as optimized as possible. Keep in mind that the time used to process a workload goes up as your codes efficiency goes down. Writing in pure Perl will thus make slow clients. :(
        • I had both of these thoughts - except I haven't got around to learning enough about XS yet.

          Then I did the experiment. It was a while ago, but IIRC the speed loss in doing the minting calculation in perl is only about 4x. The digest library itself is in C, of course, which is probably the saving factor. Anyway for verification you probably don't care about this at all, and for minting you can simlpy spawn the C program.

          The obvious plan is to roll out a library that works, first, then make it run at a sensible speed later. People are complaining there's no software .. so I will have to write it. Yes, I knew there was something I meant to do today...

          • Not really an objection, just pointing it out because it's nice to have in the back of our minds when doing work on this...

            When it comes to speed and HashCash I think we can divide the problems in two. Those of interactive use, and non-interactive use.

            It's clear that it's when the user actually have to wait that speeds makes the biggest difference (with the possible exception of servers doing a lot of work). If you design the workload to take a comfortable amount of time on an average machine, and the minting is then run on a machine which runs at half average speed, with software that runs at 1/4 the performance of what's expected, the user will have to wait about 8 times what would be normally considered comfortable.

            Any marketing suit will tell you that you risk the user growing impatient and possibly loose interest. ... just a thought.

  • Old News? (Score:4, Insightful)

    by Halloween Jack ( 182035 ) on Wednesday September 11, 2002 @12:13PM (#4238584) Homepage
    This was first proposed in 1997. If it can work, where is it?
    • It can work, and it is actually being used by some newgroups on a trial basis. The reason its not used is because few clients/filters support it. Hopefully this will change with SpamAssassin supporting it, as it is fairly popular. It will create a standard way to get 'around' this filter. See my earliar post on integration into SpamAssassin.
    • Someone has to write it. I for one take the "laziness" virtue a little too far.

  • Anti-Hashcash (Score:4, Interesting)

    by Animats ( 122034 ) on Wednesday September 11, 2002 @12:17PM (#4238615) Homepage
    What a sink for CPU cycles!

    The next step will be HashCash viruses, which use up CPU time on the owned machine making tokens and sending them somewhere.

    I used to know a bunch of fanatical libertarian theorists. the people behind Xanadu (a pre-WWW pay-per-view network), and this sounds like something they would come up with. "When the only tool you have is a market, everything looks like a commodity". Sometimes, the accounting overhead costs more than the thing is worth.

    We need a solution to spam, but this isn't it. There really aren't that many spammers; put fifty people in jail and it will stop.

    • The author specifically lists a few approaches that would limit the utility of pre-generated tokens, e.g. interactive challenges and beacons (which limit the time-window during which tokens can be pre-generated).

      It sounds like the idea is that the CPU overhead would be very small under normal use, just another step in the connection setup process.
    • I used to know a bunch of fanatical libertarian theorists. the people behind Xanadu (a pre-WWW pay-per-view network), and this sounds like something they would come up with.

      Some of the people from that group are working on the E programming language [erights.org] now if you're interested. Could be used in a similar application as Xanadu.

    • Sometimes, the accounting overhead costs more than the thing is worth.

      Very true. For example, the New York City subway pays as much to pay for the expenses of fare collection as it actually collects in fares. Making the subway free wouldn't hurt the bottom line, except for the fact they'd lose federal matching funds for the fares - so they have to throw money down a hole to get money from the Feds.

      Las Vegas local phone calls are free. They probably save money on NOT billing.

      Of course, that's all assuming your phone isn't hacked. [techtv.com]

    • "We need a solution to spam, but this isn't it."

      How about just "Type this 50-character random string from the image into the textbox" on your web-based anonymous remailer?

      Would I still be RBL'd to put-up such a page on the web?
      • I think we would prefer not to stress the user out. We can get involved in the "Turing test arms race" later if necessary.

        In the meantime, legit users should be able to hit "y" and let rip. Also, legit cronjobs should be able to run without hassle.
    • The next step will be HashCash viruses, which use up CPU time on the owned machine making tokens and sending them somewhere.
      This is a valid concern. Apart from any cunning solutions (yeah I need to catch up on Adam's paper), you're talking about 4000 tokens per day for a modern machine. Maybe less if the world decides to require bigger work - it scales all the way up to 2^160.

      My back-of-envelope calculations say that each spammer with the T1 line will need to r00t a thousand boxes to put postage on all his spam. Then those boxes need to be left on 24/7. Most random victims switch their machines off after two hours.

      Sometimes, the accounting overhead costs more than the thing is worth.
      Nah, the tedious bit is setting it all up so it works. After that you just forget about it. If it's done right, of course.

      We need a solution to spam, but this isn't it. There really aren't that many spammers; put fifty people in jail and it will stop.
      No, but it can be part of the solution. There is no SilverBullet [c2.com].

      Putting spammers in jail won't stop the otherwise-reputable companies joining in the spam game, it will simply set up a framework in which they can get state approval for spamming.

      You can't put Chinese or Korean spammers in US or British jails. Not unless you romp over there with a load of tanks and kidnap them. It's not really polite to blacklist the whole of China, is it?

      Also, putting spammers in jail will make it more attractive to forge spam to appear to come from someone else. Like we have now.

    • Speaking as Chief Scientist of Project Xanadu, I would like to point out that:

      (a) Yes, I believe some former Xanadu staff are libertarians. However as with any organisation there are a range of political beliefs and it is certainly not correct to characterise "the people behind Xanadu" as "fanatical libertarian theorists". Certainly Ted Nelson, the founder and philosopher behind Xanadu is not a libertarian to the best of my knowledge, nor am I.

      (b) To refer to Xanadu as a "pay-per-view" network is to perpetuate one of the classic misunderstandings of people who have heard about Xanadu without really looking into it. While the Xanadu designs have always sought to include micropayment and encourage online publishing by creators who do not wish to make their work available for free, it has always been designed to support content available for free - and with the expectation that this would (especially initially) probably make up the majority of the content published.

      Hope that helps,

      Andrew Pam
      Project Xanadu
      http://www.xanadu.com.au/
      http://www.xana du.net/
  • For those not aware, Adam Back [cypherspace.org] is also the fellow behind the export-a-crypto-system sig [cypherspace.org]:
    • -export-a-crypto-system-sig -RSA-2-lines-PERL
      print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
      )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsX x++lMlN/dsM0<J]dsJxp"|dc`

  • The hashcash proposition is somewhat dangerous (Score:5, Insightful)

    by hillct ( 230132 ) on Wednesday September 11, 2002 @12:39PM (#4238735) Homepage Journal
    I have a problem with the basic proposition of hashcash. It it really reasonable to - in order to improve the efficiency of a system - introduce ineficiency into that system and and expect a positive outcome?

    The entire premise seems ridiculous. Granted the system might work in small controlled enviroments where the overall inefficiency it introduces into the network would be limited, but if you read the proposal, you'll see that of course the system wouldn't work at all unless it was adopted on a large scale, so, while it's certainly a novel idea, I don't see how it could possibly succeed.

    --CTH
    • It it really reasonable to - in order to improve the efficiency of a system - introduce ineficiency into that system and and expect a positive outcome?


      Look at your keyboard... What does is say next to the tab key? QWERTY or DVORAK? Inefficiency won, next question.

    • Re:The hashcash proposition is somewhat dangerous (Score:4, Insightful)

      by nestler ( 201193 ) on Wednesday September 11, 2002 @01:44PM (#4239269)
      It it really reasonable to - in order to improve the efficiency of a system - introduce ineficiency into that system and and expect a positive outcome?

      Yes, because the current system is more dangerous.

      Requiring the solution to a computationally intensive puzzle is a common technique in denial-of-service prevention, especially in protocols where the amount of computation is already lopsided.

      For example, SSL servers are an easily DOSable target because the server does lots more work (RSA decryption) during a handshake than a malicious client does. One solution to this problem is a protocol modification that requires the client to answer a "puzzle" of the server's choosing. This is no problem for a legitimate client making a few connections, but it keeps out the guy trying to DOS the server with thousands of connections.

      It's the same thing with spam. It's too easy for a spammer to make mail servers pass around huge spams to thousands of people on their behalf. But if the mail server required the spammer to answer a "puzzle" (hashcash) for each copy of the message sent, that would make the spammer's life much harder without making the legitimate mail sender's life that hard.

      Think about mistyping your password at the telnet prompt. Telnet intentionally waits for a few seconds before letting you retry to make it harder to brute force. It doesn't kill you to wait a few seconds, does it? It's the same concept.

      You are right though that it has to be adopted on a widespread basis or the spammer just goes to the relay that doesn't use hashcash.

      • You are right though that it has to be adopted on a widespread basis or the spammer just goes to the relay that doesn't use hashcash

        Actually, it needn't be adopted on a widespread basis. It can also be used to avoid false positives, as I describe in a later post. The basic idea is, you use it as a way to get around existing filters if you really _need_ to say something 'spammy'. It provides a backdoor which spammers are unable to exploit.

        Kind of like a 'password' around the filter, but everyone knows it, and only legitimate users are able to use it. It can also be run on the client end to be used to 'prioitise' mail. If someone like Hotmail were to use it, it would make it possible to 'highlight' messages sent to people with those addresses in a standard way which couldnt be abused.
        • Unless you have sufficiently few users that you can calculate hashcash with "spare" cycles, you don't want to generate it on your webmail server.

          Then again, if you're going to require full scripting privileges on the browser you can probably get the work done there instead.
          • I thought I replied to this already, but anyway. Its also possible to download a client and run it on your machine seperate of the mail 'client', offline and overnight if you wish. Also, if you combine it with a filter, it wouldn't actually be required, just used to bypass filters if your message looks like it will be flagged.
            • Overnight! How many mails are you sending?!

              I'm not sure I followed all of that .. but there is a Java applet (it needs more work doing...) which will generate Hashcash. As I mumbled in my grandparent posting to this one, the Webmail system can send you the applet, and wait for you (the client machine) to generate the token.

              Problem solved, for certain values of web browser.

              • Overnight! How many mails are you sending?!
                The tokens can be generated in advance, so you can generate a whole bunch when your computer isn't doing anything, like at night or just in spare CPU cycles, then your client can use this store of tokens whenever it needs.
                • In most cases, the collision is required to contain the recipient's email address in some form. (The obvious problems here with Bcc: are .. problems, but not insurmountable)

                  The best time for pre-calculation seems to be when a mail is delivered to you. Kick off the hashcash generation so it's finished by the time you want to send your reply.

                  If you're calculating for a mailing list, there are better solutions. The pathologically fair case is to get the poster to generate for all recipients on the list - presumably after some blinding process. Eek!

                  (ENOSLEEP)

    • I don't see the problem, except perhaps on mailing lists. It would take more processing power to send email, so ISPs might have to upgrade some hardware, but in general I think it could work if it were adopted by enough people. And it would prevent mass spamming of gigantic amounts of people. You have a problem with this?
    • The point about introducing inefficiency is to introduce a cost for the sender.

      It's like junk faxes: in countries with free local calls, junk faxes are a much bigger problem than they are where local calls cost the caller.

      Similarly for being called on cell phones with by marketers. In some countries calling a cell phone is free for the recipient and all costs are on the caller.

      So while it is true that hashcash would use some CPU on the client, the amount of CPU used would be small enough to not present a noticeable problem for the sender who sends some sane number of mails per day.

      The problem as I see it is deployment, as the first message in the thread "Slow acceptance if ever" puts it. ie If I use a hashcash filter on my received mail then I may lose mail if senders don't follow whatever steps are necessary for them to get their mail to me.

      This is what the camram [camram.org] list is about -- making it reasonable for senders to send mail to people using hashcash filters, when sender has no client. For example there is a proposal to require hashcash only on the first mail, subsequent mails would be exempted. There is a simple web page with a java implementation of hashcash.

      (The are proposals to deal separately with mailing lists where the recipients wants to receive the mail, and the list has to send lots of mail).

      Another approach to reduce the deployment problems is to do it in two phases. In phase 1 hashcash filtering is advisory only (bounce messages on mail having no hashcash if any would just encourage sender to participate but not reject mail; filtering would improve priority of mail, not delete mail without postage); in phase 2 if phase 1 was succesful enough the filters could start bouncing mail without postage.

      Will any of these approaches reach sufficient deployment to be useful? I don't know. That's what the camram group are working on.

      There are also other applications of hashcash (other than email spam) in combatting DoS which have been succesfully deployed (see the paper).

      • I can just see it now... spammers hiring script kiddies to write computation mailers to bulk email and DDOS the whole internet, taking over IIS servers and flooding your inbox at the same time.

      • Will any of these approaches reach sufficient deployment to be useful? I don't know. That's what the camram group are working on.

        Depends on the percentage of deployment desired. Even if 25%-50% used this, I would enjoy it very much. I would imagine a "hashcash value" column in my inbox that I could sort by, and it would make it yet even easier for me to manually filter out the message (in addtion to using "to", "from", "subject", and "message size").

    • Indeed. These added inefficiencies are relevant for someone like Amazon.com who sends out thousands of confirmation emails a day, or merely your average mailing list. Sure, there will be ways to explicitely allow specific individuals to send without postage, but yet again, it adds an inconvience to the end user.
      • "Indeed. These added inefficiencies are relevant for someone like Amazon.com who sends out thousands of confirmation emails a day, or merely your average mailing list."

        Well, you wanted a solution to people sending vast quantities of email... and it solves that problem nicely. Now, how do we cope with legitimate 'spammers' (bulk-mailers)?

        (a) we don't need to - people who use mailing lists tend to maintain whitelists for them anyway: simply create a public-function for any user to create a whitelist on the server. Default whitelisting for anyone you reply to, perhaps?

        (b) When Amazon accepts an order, they have to pay someone to go to the shelf, find the book, package it, and mail it, after which they must pay the post office to drive/fly/cycle it to the customer's house. Is it so much effort for their computer to spend 3 seconds calculating a hash-collision or factored number?

    • It is a (VERY) well proven text book case that introducing intelligent ineffiecy in the system often dramatically improves throughput. This has been shown in almost all shared, no cost resources. In particular, reducing the number of streets and thus street crossing actually can improve traffic flow. Similar cases exist for internet routers and routing algorithms (part of the internet II project at NASA ames). Likewise, charging a price for grazing land use often increaces productive use of land by lowering overgazing resulting in higher sustainable grass yields and fatter cows

      . The term for this, if you dont know, is taken from the sheep farming term "tragedy of the commons".

      So this is a great idea, because the commodity I have to pay with is something I have for free but in limited quantity. No not belly button lint, though that would do too. But excess computer cycles. when I am composing an e-mail message, my computer is mostly idling.

      Further more, who says the problem being solved has to be unproductive. Why dont we turn this into a distributed computing problem. for example, some unsolved math problemor Seti-at-home kind of thing. Or maybe one could even have a central arbiter that would rent out this distributed computing time for actual money.

      Now onto some minor objections to this. A computer that issues a challenge when receiving an e-mail is by defintion saying "I exist!" thus alerting the spammer of your existence. No not a big deal since ping and other network resolvers can do similar things.

      • look many ISPs already claim spam is costing them >25% of their bandwidth. and waht is it costing you. this seems cheap to me.
        • Yes, currently the ISPs are choking on spam, and it costs them in hardware and manpower to keep up.

          The problem is that the payoff for generating the work stamps is elsewhere. This is the nature of sender pays.

          Since not all mail will have hashcash, the bandwidth will still be wasted. There is the possibility of "second class" or reduced throughput per IP address, for sources that don't stamp though. Whether this is a good thing in the long run, is another question.
      • I don't think it can do Seti at home, because the server needs to confirm the answer, which would take just as much computation on the server. The question has to be something the server already knows the answer to.
    • I have a problem with the basic proposition of hashcash. It it really reasonable to - in order to improve the efficiency of a system - introduce ineficiency into that system and and expect a positive outcome?

      As an electronic engineer, this concept is very comfortable for me. Though it's more a case of "negative feedback" than inefficiency. Friction-free systems are usually very unstable.

      In electronics you usually design a system to respond as fast as possible and then wrap a negative feedback loop around that. The result is a dynamic balance... The system responds well because it is straining to break free, and the feedback holds it to within designed constraints.

      Negative feedback is by far the most common element in analog designs - go an look inside any audio amplifier. :-)

      Whether this analogy applies to hashcash I don't know. But I do know that I feel nervous when I see a design without some sort of negative feedback in it, to force a dynamic equalibrium.
    • I think the bigger issue with HashCash is how you introcue it's use, rather than if it should be done.

      I don't think it's feasible to simply have all email servers, relays and clients adopt the use of HashCash over a short timeframe, but that's not the only place to start.

      When introcuing a new technology such as this, one of the main points is availability of software. If the use of HashCash is taken up by other protocols, software developement will pick up, and introductions into legacy protocols will be easier.

      Also, you don't need direct support in every protocol in order for HashCash to be useful. One example is email. If you're sick and tired of spam and wish to reject all email not on a whitelist, you could bounce the rejected email with a link to a URL, from which the sender could simply do the required workload to get the email accepted and sent using a Java applet. The server could store a copy of the email, which would then be released into the customers email.

      If you want HashCash to work, I think it's much more important to look at where and how you want to use it, rather than to focus on using it to solve every problem out there which it might or might not be able to do.

      Right tool for the right job, simple as that.
    • This is like IBM messing up the keyboard layout to slow down fast typers. (This was actually done because some people could acutally jam the old non-electric manual typewriters by typing too fast. Thus the QWERTY key layout was invented to slow down typing.)

      It may work for the present email design, but it will probably be a bad design for the future. We need a DVORAK solution to spam, rapidity for the machine to blow through spam and keep up with the user.

  • advantages over tarpits? (Score:4, Interesting)

    by EricHsu ( 578881 ) on Wednesday September 11, 2002 @01:54PM (#4239367)
    Many of the proponents of this idea suggest that the advantage is creating a non-trivial cost for access to resources.

    Can someone spell out the advantages this method has over the "tarpit" strategies that some mailers follow? (I.e. each successive access takes longer, so the first access may take 1 sec, the next 2 sec, the next 4 sec, so soon abusers find themselves timing out.)

    Is it fair to consider tarpits a special case of hashcash where the non-trivial cost is time waiting applied server-side?

    If so, isn't this a less wasteful approach? (Genuine questions on my part.)

    • I think custom spam sending software would not be significantly slowed down by tar-pits. Consider: the spam engine just keeps the connections open until they connect, then drops off the mail directly or via a mail hub or open relay as before.

      What does it cost the spammer -- I think just more open connections. But there aren't any limits on the number of open connections. The spammer has to adapt his tools, but once he's done that the through put of spams/second over a given link speed is the same as before.

      Hashcash forces the spammer to buy (or steal) lots of CPU cycles, even though a few CPU cycles is essentially free for normal mail users, for a spammer who wants to send millions of mails this could be a significant expense.

  • ...would this cause for legitimate corporate e-mailers? I don't want to have to pay more for stuff I ordered online just so amazon or outpost, or whomever, could send me a timely confirmation e-mail. This is a ridiculously stupid scheme.
    • If the company isn't hip to this newfangled tech, give them a "special" address.

      foocompany-username@example.com.invalid

      spongcompany-username@example.com.invalid

      You can just keep the plain username@example.com.invalid address and require hashcash for that. This isn't much more work than setting up hashcash. Of course, if you don't have a whole domain to play with (or an ISP that can do mail prefixes) then .. get another ISP.

      Anything else, if you get spam to it then it's because the company has leaked your address. *Plonk!* Problem solved.

      Experience teaches that you should put the modifier in front of the username. Spammers sometimes randomly cut off the front of the address if they think it might not be important.
  • In other words your group uses e-mail programs that support the same crypto method(GPG, PGP, BlowFish, ect.).

    Anything not crypted, or crypted with a key that is not in your chain goes into a junk basket. The junk basket could then have some rules. That would allow your mum or certain clients, who are still trying figure out how e-mail works, to be fowarded to your In bin.

    Adds security and cuts down spam.
    • "Anything not crypted, or crypted with a key that is not in your chain goes into a junk basket."

      A nice temporary measure is to reply to any email not containing --START PGP MESSAGE with a reply "Your email is being returned -- it needs to be encrypted", and then just deliver it anyway. That reminds people they need to use encryption, without dropping any important emails.

      To update that for the spam problem, simply reply to anyone you don't know with a password. They can re-send the email with the password in the header to be added to your whiitelist.

      (And make sure not to use outlook, else LoveYou will forward your address-book to spammers, and they can forge messages from people you apparently know -- Any easy way to attach signatures to an email rather than wrapping the text in ugly PGP dashes?)
  • Why not use a useful computation rather than something useless like hash colissions?

    If we're going to have all of this crunch going on to prevent spammers, it ought to achieve something rather than just burn cycles (and energy!) for no good reason.
  • you shouldn't; its actually quite clever.

    Thermodynamic has a classic case (illustration) of this; a smothe bowling ball, dropped into a fluid, has a particular drag (X). If you roughen the front of the bowling ball (an effort that results in MORE drag intuitively), you counterintertuitively DECREASE the overall drag of the system! Ergo, adding a little "inefficiency" can do wonders for overall system performance.

    Personally, I am very excited, and would LOVE to have this system available. My concern, is that of the inevitable hack to get around it, which is distributed email spam via trojans :)

    • Currently it's easier for spammers to spew from a fixed source. If ever RBL type solutions started really biting them, they would probably move to distributed/trojan based solutions anyway.

      It seems like an obvious thing to do, although the more clueful ISPs would probably detect the outgoing and pull the plug on the victim.

      Reasons why DDoS spam may not be a problem are given in an earlier (um, later) thread.
  • I'm not a sysadmin, nor an email guru of any sort, so I have to ask the most basic question: Why use SMTP at all? It seems to me, a protocol that is a little more sophistocated, with mandatory digitally signed content (including headers), and rejection of all connections without a certificate, would block all spammers pretty quickly. Generating a certificate is non-trivial and time consuming, and often is a manual process. There's also multiple levels of certificates, from the online-verified only, to the independent 3rd party verified from a trusted certificate authority (human).

    However, then you'd need support in servers for the new protocol (probably not too quickly done), and support in clients for the new inbound and outbound protocol. Then users could have the choice of accepting or blocking old SMTP messages, accepting or blocking low-confidence certificates, or blocking specific users, or even blocking users who were authenticated by specific trusted certificate authrities (in case spammers bribed someone for authentication).

    I know, this is probably a radical departure from the tried and true SMTP protocol, but servers are the problem, not spammers. Servers should not propagate junk mail, because they shouldn't accept it in the first place. I don't mind receiving mail from a person that I can reply to, but I want to know it's a person, not just an email address they just made up on a free server, or a spoofed reply to.
    • Why use SMTP at all?
      Because it's there. It works, sort of. It has this extension protocol called EHLO, but it's easily backwards-compatible with HELO only systems.

      Camram probably needs to write more RFCs. 8-/

      ... a protocol that is a little more sophistocated, with mandatory digitally signed content (including headers), and rejection of all connections without a certificate, would block all spammers pretty quickly.
      Who signs the certificate? I don't want to pay Verisign $200/year just so I can send email. I certainly don't want more spam from Waitrose just because they paid Verisign $200 for a certificate.

      The PGP/GPG web of trust can provide a useful whitelist type of solution, but that hasn't exactly caught on in a big way either.

      • Who signs the certificate? I don't want to pay Verisign $200/year just so I can send email. I certainly don't want more spam from Waitrose just because they paid Verisign $200 for a certificate.

        Thawte [thawte.com] does. For free. As far as I remember, it's an automated system that requires a good deal of info to generate a certificate, and has a higher privilege certificate for people who have been independently stamped, probably like the PGP/GPG web of trust.

        The point isn't to make a whitelist, but to exclude anyone who doesn't use a certificate. It would probably then be an ISP service to give you a certificate with every account signup (or let you get your own, or use your previous one if you have one already), so it would be significantly less a barrier to entry for new users. I think it would raise the stakes significantly for spammers, especially since forging a certificate is a legal offense, since signed documents are admissible as evidence, IIRC.
        • OK, so I've been caught being uninformed. Sorry about that - but don't be surprised. 8-/

          IMHO sidelining anonymous speech to the point where almost everyone will ignore it is not an acceptable price to pay for only getting spam from people or companies who do it By The Book.

  • When I was in school, you could trade hash for most anything.

    Oh wait

  • Integration w/ SpamAssassin (Score:3, Informative)

    by shird ( 566377 ) on Wednesday September 11, 2002 @05:26PM (#4240950) Homepage Journal
    This is also currently being look at being added to SpamAssassin [spamassassin.org], the idea is;

    Its not required, but if you use it, you can avoid being flagged by the filter. In effect it provides a backdoor around the filter, without the potential for abuse by spammers.

    I have also being trying to get Microsoft to add this to Hotmail, as a means to 'highlight' messages which have valid tokens to avoid accidental deletion. If anyone has a good contact address for them, please reach me at;
    shird :at: dstc.edu.au
  • My mailing list of 2500 people already takes approx 40 mins. This additional overhead would make it totally impractical.
    • Mailing lists are a known problem. We've kicked around various possible solutions. I have another mail on my postoned queue, quietly fermenting in my brain.

      Worst thing that can happen is some subscribers start bouncing mail, and you drop them (and tell them why). Not your problem anymore.

      I'm suddenly reminded of DoNotWantItGoodWantItTuesday [c2.com]. I'm sure the WikiWeb will love me for sending the hordes over there. 8-)

  • I'd suggest that the Camram guys run a spelling checker over their website. If you go to the "introduction" page, it's spelt "Canram" in a lot of places. Their "About" and "Contact" links don't do anything either.

    Graham

Slashdot Top Deals

We must believe that it is the darkest before the dawn of a beautiful new world. We will see it when we believe it. -- Saul Alinsky

Close