Slashdot Mirror
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
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.
No, no it's not. NAT is a quick-fix that just complicates matters.
LOAD "SIG",8,1
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.
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.
> What happens when $VIRUS turns your domain name
> into a spamfest?
You get blacklisted, as you should be.
> If you're supporting any normal users at all,
> you're likely going to find it hard to maintain
> that reputation.
Securing your domain is your responsibility.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
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.