Google Apps battle spam with auto email signing Google's Apps service has rolled out a technology designed to snuff out spam and phishing emails by cryptographically verifying that senders are they entities they claim to be. The email-signing standard, known as DKIM or DomainKeys Identified Mail, is available immediately from Google Apps and can be turned on with a few …
> Remarkably, even the Google-owned Postini filter has trouble determining that email sent over Google Apps is legitimate. The ability to cryptographically prove email came from the service ought to help
The major source of spam from the likes of gmail / hotmail / yahoo is actually from accounts that have been broken into (keyloggers / weak passwords / same password across multiple sites etc). While DKIM is a Good Thing it doesn't solve this problem as google will still sign your outgoing message.
The likes of SPF and DKIM, if widely adopted, do prevent others from spoofing your domain and therefore make it more likely that messages your domain sends out are not spam but they certainly are not a be-all-and-end-all 'spam killer'.
...but what will that do to stop all the spammers who are spoofing fake gmail addresses on spam that doesn't even come from gmail?
For years, I had my local email client app -- and Spam Assassin at the server end -- set to automatically shit-can any email with aol.com, hotmail.com, yahoo.com and gmail.com in the "from" header because of the buttloads of spam I was getting claiming to be from addresses at AOL, hotmail, yahoo and gmail. Sadly, I had to unblock them a couple of years ago after my wife got herself a yahoo.com email account, and after I set myself up "backup" accounts at yahoo and gmail for those occasions when my own domain's email server was down (extremely rare, happily).
Fortunately, my spam load is barely a trickle thanks to some judicious filtering, but whenever any spam does get through, it almost always has either a yahoo.com or gmail.com address faked in the "from" header.
...and should not be a reflection on the trustworthiness (or lack thereof) of the spoofed address or system. Back in 2002 there was a virus floating around called Klez.H that cycled through the infected users' address book to randomly pick to and from addresses. Trust me, you haven't known hell until you've had to explain for the 50th time that there was no way for us to control infected 3rd parties spoofing company addresses. To prove the point I had to send the CIO a message from Bill.Gates@Microsoft.com and eventually the finger pointing died down.
If anyone ever tells you internet e-mail security and spam prevention isn't rocket science, they're wrong and I say that as someone who is not any type of expert on the subject. I know just enough to know how much I don't know about it (which could probably fill a Wiki :)
If you're really concerned about spam... I'm not sure if it's around anymore but there used to be a whitelist tool that you could install into some of the old mail clients that would direct all mail to a SPAM folder unless you opt to whitelist them.
... those e-mails probably are from those accounts, they're not spoofed. The accounts have either been bot generated or hacked. After all, why would a spammer spoof e-mail addresses that are likely to be blocked when they can just as easily spoof @bbc.co.uk?
If I understand this correctly, then this is precisely where this scheme kicks in. RSA public-key cryptography means that when someone signs any kind of data with a secret key, a recipient can calculate what should be the proper corresponding public key from information included with the candidate data and if the key matches the signer's public key (obtained in some trustworthy fashion, in this case, DNS), the signature and data are legitimate.
Calculating a private key from public-key data is computationally prohibitive. In this case, to successfully spoof a gmail or google source address the faker would need to sign the bogus mail using Google's secret key, which would be possible only if it leaked or a vulnerability were found in the signing software itself. PGP/GPG and other products that also use RSA public encryption have demonstrated their resilience against cracking by even the highest-horsepower computing hardware available today. The FAQ mentions S/MIME and OpenPGP and points out that the comparisons with this system lie not in the nature of the technology, but with the implementation cost and ease of use (You can already sign email with PGP and GPG by hand, and much more easily with the Enigmail add-on for Thunderbird). The public key is obtained by the checking software at the receiving end via that DNS lookup mentioned.
This scheme has a lot of additional features, but this is the idea at the core of it.
Both Google and Sendmail have had a long history with DKIM. Sendmail helped draft the first DKIM standards as well as launched one of the first open source DKIM implementations. Google has also been verifying eBay and PayPal incoming messages since 2008 and now says, “Google Apps is the first major email platform – including on-premises providers – to offer simple DKIM signing at no extra cost.”
While I welcome Google to the party, I have to disagree with that statement. Sendmail has included both full DKIM signature verification from all domains as well as full DKIM signing on all outbound mail in our on-premises messaging platform, the Sentrion MPE, since 2008, at no extra cost. For those who use Google Apps in a hybrid mail architecture, the Sentrion MP integrates with Google Apps to take advantage of on-premises protection for their outbound mail against compliance violations, policy, use encryption, and even DKIM signing. http://sendmail.com/sm/sentrion_appliances/sentrion_google/
I look forward to more cloud e-mail providers following Google’s lead by providing full inbound DKIM verification and outbound DKIM signing.
Greg Shapiro, VP Engineering and CTO, Sendmail, Inc.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
