Email Authentication Schemes - Friends or Foes?
jtprice writes "At a time when spam levels have exceeded 80%, there's growing momentum behind
Microsoft's email CallerID,
the SPF
effort, Yahoo!'s
DomainKeys, and the IETF's new MARID Working
Group initiatives to address various email abuse problems including spam, joe-jobbing,
phishing, and so on. Sendmail has already implemented DomainKeys and CallerID. 10,000+
domains have turned on SPF now. Where the heck are we going with this? Are these efforts at cross purposes, confusing at best or likely to be consolidated? Seems to be less about the end of spam and more about the end of open, uniform, standards-based email as we know it. Apparently the people behind these initiatives are getting
together for the first time for something called the Open Email Accountability Symposium next month, at the Inbox Email Conference in San Jose, with the intent of outlining their proposals and answering questions. Any thoughts about all of this, or hard questions that should be asked of these people? Is the email dilemma creating
just another monopoly opportunity to force email into proprietary territory?"
"Is the email dilemma creating just another monopoly opportunity to force email into proprietary territory?"
Perhaps, but this doesn't make it a bad idea. Any good idea or technology can be taken advantage of; that in itself shouldn't keep those with good intentions from trying to bring about change for the better.
dmiessler.com -- grep understanding knowledge
..but my corporate overlords got hit by Sasser and I couldn't get a new certificate :(
Opportunity knocks. Karma hunts you down.
Because millions of small-company and household e-mail servers will never have the funds to implement any proprietary system. Make it public domain, and it will be worse- the spammers will just hack it.
I've been thinking about the problem. And have looked around for the different proposals. There's been a mailing list for ng mail with many interesting ruminations. But then it was sinked with spam :-(
IMO there main alternative is:
1) a solution compatible with original RFC (that is it does not rule out any sender that the original spec would permit)
2) a completely new and different system. Redesigned from scratch.
Obviously a solution is not a solution if it may have a false positive (block nonspam).
False negatives are just a matter of efficiency.
Methink option 1 is not possible. And this has the added bonus of giving us the chance for a visionary change. But it's unclear if we can afford the time it takes. As the problem is really becoming urgent (much more urgent than the 32bit limitation in IP adress space. Expecially because NAT is addressing it very well.)
There are MANY proposals that use SMTP and add up on the requirements actually ruling out cases that were originally legal. These I really think should be avoided. But I'm affraid that's were many will likely go because they are fast to deploy.
I think spam filtering should be left up to the user.
There are plenty of client side systems that work well; I use Apple's Mail. Maybe 2 spams a day gets through to my main inbox (out of several hundred incoming spams a day).
No, no it's not. NAT is a quick-fix that just complicates matters.
LOAD "SIG",8,1
What per chance would lead you to the conclusion that a "single" standard is a "proprietary solution"?
Are you paranoid?
The proposed solutions are [for the most part] standards based and they're also "open" in nature.
Personally, I'm going to orient my servers toward the IETF/Marid standard; but you have the "freedom" to choose and implement whichever standard you choose.
The fact that a pseduo-"standard" is being settled on in this realm is progress (in my opinion).
Don't think that a small group of dedicated individuals can't change the world. It's the only thing that ever has.
The person that asked the question provided the answer. The IETF MARID working group is designed to take all the existing proposals, find the best, and settle on it.
This article is just making something out of nothing.
What do we expect:
1. To be able to send email from anywhere
2. To be able to use various "from" addresses, irrespective of from where we are sending.
3. To be able to cheaply register new domain names. The problem can only be solved if we accept limitations on how we send email.
The fundamental problem is not authentication. A spammer can easily set up a valid domain name and use it to send email "from". The cost of this is minimal (an *.org.uk domain is about $3-$4).
Furthermore, even a medium size company cannot possibly predict all the sources of email if people are allowed to send from their home ISP.
So, we could force people to pretty much always use their company's mailserver to send emails (requiring mass deployment of SASL or other solutions), yet this will not stop the spammer getting a cheap throw-away domain name and using that.
So, I really think that our expectaions of email will have to fundamentally change, or we need to use plan b:
A mix of technical and legal solutions to kill spam.In other words, kill the root cause of the problem.
The real "Libtards" are the Libertarians!
The problem is, in many places, people still pay per quantity of bandwidth or time online. Saying "filter it at the client" doesn't do anything to stop the spam from being sent to the user, and still requires the user to retreive and parse the message before deciding it's spam and filing it in the circular bin.
No, client-side spam filtering should be the last line of defense against spam. Spam should be killed off before it ever reaches a mailbox, final or intermediate, by the servers that handle the mail.
This space for rent. Call 1-800-STEAK4U
Stick to SPF, give DomainKeys a try once someone actually publishes some info about it. Skip caller ID.
read the site.. many good points.
You are only scratching the surface of the problem.
What do we expect:
Defining the expectations is a big task by itself. Those doing some serius work on it identifyed many many different requirements. And of course many of them are contradictory.
The fundamental problem is not authentication. A spammer can easily set up a valid domain name and use it to send email "from". The cost of this is minimal
Traceability. Autentication. Anonymous posting. Privacy. Each of these is a research task in and by itself. The cost of the domain is unrelated to the mail. The cost of mailing may be. There are proposals that follow exatcly that path. Receiving tons of mail (and storing it and sorting it out) is a cost. Sending mail, even bulk mail, generally costs close to nothing. They aim at reversing this. Put the cost on the sender instead of putting it on the receiver. This is just ONE of many possibilities (and a smart and promising one, IMO).
we could force people to pretty much always use their company's mailserver
IMO that's nonsense. Not even forcing people to use their provider mail server, is acceptable. As long as SMTP is the protocol, you need not have a mail server at all to send. The server is needed to receive. And one should not be forced to send from the server it uses to receive.
SASL or other solutions
SASL and similar solutions IMO just break the paradigm of SMTP. Beside being broken in many other respects too.
a mix of technical and legal solutions to kill spam.In other words, kill the root cause of the problem.
Making spam illegal is OK with me. Legally defining spam is not. Therefore I tend to be on the "keep the fucking law out of the net" side. But I agree that killing the cause of the problem is good. Unfortunatelly that cause may actually be SMTP itself.
An RFC could help here?
When you look at the state of the world, how can you not become a radical, liberal anarchist?
Sorry if this is really OT but ... ...
I just was curious to see if Eric Raymond had some post/opinion on this subject. I went and checked it out and
Anybody noticed he's *completely disappeared* after posting "The Luxury of Ignorance: Part Deux" on february 29?
No more posts on his site. Neither in the writing section, nor in the blog. Cannot google out any reference to a travel or something. Nothing.
And looking at his back records, he's not used to being so silent for such a long time. Expecially not if we consider what's happened in this months. Not a word on MS vs. european antitrust. Nothing on latest SCO news. Nothing on the euro-patent issues.
Where's ESR?
SPF only authenticates mail as being approved mail from a domain. In itself, this only prevents joe jobbing and phishing, but domains can still send spam.
As SPF adoption grows, there will be two types of email: authenticated and unauthenticated. Authenticated mail will consist of both spam and legitimate mail. Unauthenticated mail will be just like the mail we are sending around today.
What does authenticated mail get us? As we can track mail down to the owners, we will begin to set up a trust system. DNS block lists will become viable. The owners of domain names can protect or abuse their domain names as they see fit.
Eventually, there will be a system where domain names will have value again. If I don't abuse my home domain, and only use it for legitimate purposes, people will not add my name to black lists. If my domain has sent a large number of emails with a very low score of spam, it will be more legitimate than one who has sent only a few emails or has sent mostly spam.
SPF is only the first step in stopping unsolicited email. Once it is in place, the next step -- accountability -- is easy to implement.
The beauty of SPF is that it doesn't invalidate email as it is now. Participation is optional. Those who are early adopters get an early boost, so the incentive is there to adopt it early on. But email as it is now will not be stopped.
The radical sect of Islam would either see you dead or "reverted" to Islam.
Seriously...I've been using it for a while now. It works well. It's bloody simple. Why more people don't use it, I don't know.
Help us build a better map!
Modded the wrong way, sorry, posting to undo moderation
Sighted near his dwelling on March fifth. I heard it from Art Bell, so I know it's true.
Backwards compatibility and security can't be combined. Just like you can't simultaneously find the position and momentum of a particle with perfect accuracy, any attempt to make a certified mail system backwards compatible with existing systems means that spam will still exist. So far the most promising method of slowing spam is cryptographic challenges. By sending the client a simple cryptographic challenge which can be solved in anywhere from 10 seconds to 1 minute, spam can be slowed significantly, since the limiting factor is a technical one, which can only be bypassed by running the servers on a *HUGE* server farm in order to keep the spam flowing at the rate it is today. The other problem is that if the key size is too small, then the challenges can be precomputed, although using a different IV would increase the storage space need to precompute a list of RC4 values by a factor of 2^24. Or, a distributed computing task could be used (you must text X RC5 keys or OGR nodes to send Y emails) to not only slow spam, but provide practical information about what amount of time it would take to crack a given encryption algorithm. Other distributed computing tests could be used of course. The only way to stop spam is to create a controlled (timewise) mail system completely incompatible with existing SMTP clients, as SMTP is anonymous and uncontrolled. A public/private key system could also be used to verify the identity of a sender, and spammers can easily be identified (ie. you get a spam, you verify it with the public key included in the mail header, and send the key to a central server. Want to send mail, but haven't got a key? Too bad, since your mail can't be traced back to you. What's that you say? Make your own key pair? Well then your mail is rejected by the server too, since you do not have a valid key) bye their registered public key. SMTP and similar, unauthenticated mail systems, though, can not be beaten for reliability, since there are no central servers to go down, and as long as the sending and receiving mail servers are working, what is sent is always received.
OpenPGP is a standard implemented by a few programs including PGP (non-free), and GnuPG (aka GPG) (Free). GnuPG support is either integrated into or supported via plugins on Kmail, Eudora, Mutt, Outlook, and many other clients. See http://www.gnupg.org/(en)/related_software/fronten ds.html
for more details. There are a couple of Mac related links there.
About the last two, GPG's privacy lies in the key,
and thus you wouldn't want anyone else to be able to use your key -- they could sign messages as you otherwise. A hackish way to use GPG with these would be to manually use gpg to sign (and possibly encrypt a message) on the commandline, and then pasting them in.
Someone could write client side code for dealing with webmail (Browser plugins that allow one to replace the current contents of a text input field
with a signed message, but they could easily be
security holes if not written correctly).
There exist at least two solutions today, however, nobody bothers to use them:
1) PGP,
2) S/MIME.
Provided one sets up an effordable Web-Of-Trust (esp. PGP), Non-SPAM gets authentificated by the client or even checked against a trusted trusted certificate database by mail relays. E.g. all certificates could chain to a final "Valid Mail certificate" trusted by anyone. Not only provides this technique user or organization signatures, you may deploy security against 3rd party lurkers along the transfer.
Of course, the current commercial way to get a re-signed S/Mine certifcate is too heavy.
All the techniques I saw so far limit the sending of one mail to specific hosts, breaking the oppertunity to take up roles while sending. Or inflict larger problems setting up secure connections to the "specific hosts" in organizations spread across multiple locations or with mobile or home workers.
And, BTW, how get you sealed the ISP, for instance, against trojans, worms and virii, in order to prevent misuse of a box as it is standard today? Who really believes that Spamers use there own boxes to send ??