Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Spam and Authentication 10 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • I remember hearing

    [i]ntroducing public-key cryptography into the protocol would not be too hard...

    several years ago, so I think it might be more difficult than you imagine.

    The important thing to me is not making sure that a spammer can never send a message. The important thing is that he can be found and punished for theft and trespass.

  • ... because there are perfectly legitimate reasons to want to send mail anonymously or from a throw-away account. For example, I might want to send mail to a corporation criticising their customer service, but not want them to have my real address anywhere on file. Or I might want to ask a question about my embarrassing disease on a mailing list. Or a question about an area I'm meant to be an expert in, and I'm afraid my employer might fire me if they find my post in the list archives.

    No, the way to st

    • Calculating the signature wouldn't be a difficult problem that takes 30 seconds to calculate. But it would slow sending email down a little. An important feature of the system would have to be that something is calculated for every single recipient address. Also, there would have to be a mechanism that prevents calculating the signatures in advance. Perhaps the receiving servers sends a nonce that must be included in the signature.
      • The hashcash FAQ is here [hashcash.org].
        • I was thinking about using something similar for the authentication of sending to recipients. One lack of that scheme is that it doesn't include the sender in the calculation. It still allows forging the sender address. I was also thinking about having the receiving server send a nonce that need to be included in the calculation. This makes it difficult to precomputer

          One reason to put the authentication in the SMTP protcol is that the sender and recipient addresses are well defined there. Email clie

    • This won't break mailing lists either, because all legitimate mailing lists are opt-in. So the user knows to expect bulk email (SOLICITED bulk email) from that source, and can exempt it from having to do the Hard Sums.

      And if I fake being the mailing list sender?

      I don't know what the answer is (I'm not sure if there is "an answer" or even a set of services which together might be "the answer") to fixing email, but for a Hard Sum to work, those machines/addresses which are exempted need to be authentica

      • Not sure how you'd authenticate listservs - by ensuring that the sender is one of a known set of IPs, perhaps.

        I don't have a problem with authentication if there is an anonymous alternative which is at least as widely available. However, getting Hard Sums widely implemented strikes me as being easier than getting a world-wide trust relationship and authentication scheme working. For one reason why that's such a difficult problem, look at who is one of the supposedly trustworthy CAs for SSL certificates.
  • Two reasons auth won't work. Firstly that Ralsky is going around cracking SMTP AUTH servers because of weak passwords - you can enforce AUTH all you like but you can't enforce strong passwords.

    So you switch to keys, right? Well no, in the long term that won't work either. Witness the Swem virus - it prompts users for their username, password and SMTP servers and users *gladly* put that info in!
    • Bad security on user computers is one reason I think authenticating the servers is more important than clients.

      Not to mention that is easier to deploy to the servers instead of forcing every client to upgrade their software.

      When money is involved, the users would have an incentive to keep their accounts secure. If a breakin into an account results in a $100 charge and email being disabled for the rest of the month, then people might take the security seriously.

      The involvement of money and more rob

      • It all comes down to cost at the end of the day.

        Make sure all servers are authenticated. Great. No problem.

        Make sure all clients are neither spammers, nor insecure. Not an easy problem.

        It takes large amounts of resources in terms of abuse desk costs, and support costs (if you shut down 200,000 users at an ISP because they run infected versions of windows, how much do you think that will cost in terms of support? Think 1 hour on the phone to each customer). And you have to offer that support because peopl
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.