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

use Perl Log In

Log In

[ Create a new account ]

iburrell (4155)

iburrell
  ianburrellNO@SPAMgmail.com
http://znark.com/
AOL IM: imburrell (Add Buddy, Send Message)
Jabber: ianburrell@gmail.com

Journal of iburrell (4155)

Wednesday October 15, 2003
03:18 PM

Spam and Authentication

[ #15229 ]

I have been reading lots of articles recently about how to combat spam. One thing some of the articles have touched on is the problem of authentication. Email doesn't authenticate where the email comes from or is going. It is trivial for spammers or viruses to fake the From address and the return path. It is trivial for them to send their email through open relays or blast it directly to the victim mail servers.

One possible solution is to introduce authentication into the SMTP protocol. This wouldn't protect the From: header in mail messages. But it would protect the return path that is used for bounce messages. It can also be used for access control. This is the difference between knowing the message came from your friend Bob, and knowing that some bob@example.com sent the message.

Introducing public-key cryptography into the protocol would not be too hard. SMTP has a mechanism for extensions and adding commands. However, any public-key signature system would depend on distributing the keys and enabling the access control. This requires infrastructure to regulate the sending of email. It requires more centralization in deciding who can send email. It also requires organizations to buy into the system before it helps in limiting the spread of email.

One way to help with the infrastructure problem is to have companies that provide the authentication services. They would run relays that sign messages for its customers. The customers would sign up for accounts, with either monthly or per-email fees to limit the amount of email that could be sent through the system. The relay companies need to be able to authenticate its customers but existing SMTP authentication or SSL cliet certificates are widely supported by email clients.

There would also need to be a mechanism for ISPs to join the system. They would need to get certificates that could be used for signing messages. And even become CAs for creating new certificates for servers and clients.

Authentication would be used to create a group of mail servers that can trust where email is coming from. They can send bounce messages. The postmaster and abuse email works and is answered.

It also helps tie the email system into the legal system. If a spammer breaks into an account and sends a million email that should normally cost $10,000 to send through a commercial relay, that is much more serious offense using some unkown number of open relays. Or forging a cryptographic signature is much more serious than just putting some characters in an email.


List all Journal entries
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.