Slashdot Mirror
Gmail Begins Signing Email with DomainKeys
NW writes "According to a post at IETF's MAIL-SIG list, Google has begun to sign outgoing email from Gmail with Yahoo's DomainKeys signatures. This is the first large provider of email that is actually doing so (not even Yahoo has started that yet)."
Google has almost everything now, why don't they make their own Anti-Spam domainkey type service?
-
Don't get me wrong, I'm not one of them Google bashers (I don't believe the Google Desktop is spywer, for example), but in this case I would like to have an opt-out option!
Since Gmail's a free service, I believe your opt-out mechanism is to use something else. Given this is largely an anti-spam technique (to prove an E-mail is legitimately from the domain it says it is) I can't see Google being willing to provide an opt-out on this, it would undermine the whole effort.So will this prevent spammers from sending spams via a Gmail account?
This DomainKeys system relies on both sending and receiving servers to validate an email, will it ever catch on?
Rock that crushes, Paper & Scissors that don't matter.
All of these spam identification methods merely provide reliable authentication of the sender's domain. The rest is up to you. You still have the responsibility to maintain spam filters.
Having reliable identification is a first step. A very important first step.
Hey, Windows users, there is no such thing as "forward" slash, there is only slash and backslash.
If you want to sign your own mail, why not use PGP? Unlike this, it's already in widespread use, independent of the server providing service (unless you use webmail, in which case it would be a bit tougher).
Every email needs to come with some token of authenticity, be it a source IP address ala SPF, or cryptographic signature ala DomainKeys, or a low SpamAssassin score, or no listing in any of a number of DNSBLs. The days when you could send anybody an email from anywhere and expect them to receive and read it are long gone.
-russ
Don't piss off The Angry Economist
Stimutax!
Step 1: Make something addictive.
Step 2: Give it out for free.
Step 3: Start charging money.
Step 4: Rake in the money!
One of the greatest episodes ever.
"It feels like a Koala crapped a rainbow in my brain"
And my spam filters would have killed that message dead. Too much non-human-readable text.
Your spam filter cares about the non-readable text in the header?
What about all of those zombie machines out there that send spam via Outlook - since that email is going out with a valid account, it would be flagged as legit.
Tell me where I'm wrong.
Well, if Google, Yahoo (who created the spec, and indicated that they would be using it shortly), and AOL (who says they will begin testing in Q1) all use DomainKeys, we probably have a de facto email authentication standard.
The Google engineers aren't stupid, they know that mail messages are routinely modified in transit, both the headers, which can be wrapped, rearranged, removed or added, and the MIME bodies, which can be decoded, reencoded, and even modified.
As engineers, they also know that cryptographic signatures are designed to detect message tampering.
Combine these two ideas and you get a system which will flag routine message modifications as forgeries, making the DomainKeys signature completely useless in practice. And yes, I've read the rfc draft, and found it wanting.
It *would* work if there was a standard set of well defined transformations performed on emails from the sender's MUA to the recipient's MUA. So if one Gmail user sends to another Gmail user, it'll be ok, because the message won't leave Google's servers.
But Google has no control over other people's systems. When I download mail by POP3 from my ISP, they've added SpamAssassin headers, which will simply destroy the DK cryptographic signature. When I get mail at work, they remove ZIP attachments, which destroys the DK signature. When mail passes through an older gateway, some MIME attachments can be decoded and reencoded, destroying the DK signature.
I could go on but you see the point. Once I get the mail in my mailreader, the DK header is useless junk, and it might as well have been forged, for all the good it does. In fact, if my trust in Google is so high that I'm willing to accept the DK header even though it fails, just because Google are the only ones using it so far, I guarantee that the spammers will pick up on that real fast.
DK is a draft, and is far from ready yet. It should be allowed to mature. Google shouldn't be deploying incomplete solutions. Unless... could this the beginning of the PHB era at Google? If so, I'm disappointed.
If you sign up with one of these "trusted sender" schemes, be very careful that there's no way mail bounces, virus-generated mail, or mail via open proxies can become "trusted". Your ID will be on the mail, and you'll be blamed. Spammers are going to be targeting those sites, since they provide a bypass around some spam filters.
Is it just me, or is the length of email headers these days starting to eclipse the length of the body?
The miniscule and unimportant fact that they Yahoo have thrown in an open license for it. And that everybody (including FOSS) can implement it at will.
But the point is, that if it spoofed and not originating from Google as it claims, then it falls to your non-auhenticated suspects bin. Mail can not be both spooded _and_ authenticated.
Anssi Porttikivi / app@iki.fi
Hmmmm. Sounds like a good place for the Reply-to field. Because even if you legitimately own an address, if the message didn't go through that server, then it's not 100% accurate to say it's from there.
Donate background CPU time to fight cancer.
The problem here is that most people won't change their email provider simply for the hassle of keeping contacts up to date. People who hate hotmail's service, yet know that it would be near-impossible to ensure that everyone who may need to email them has any updated email address details. (the problem is not the same as number portability between phone networks due to the difference in routability and the 'brand recognition' part of email. For this to work, therefore, we need to divorce an email recieving account from a sending account - and very few services exist to be able to hire a secured smtp account exclusively for the purpose of sending from a 'trusted' domain.
Putting the public keys only into the DNS system seems to make adoption of such a system quite a bit more difficult than it needs to be. Why not also allow people to put the public keys on web pages? The goal is to have senders prove their identity, and the level of proof required by recipients as well as the nature might differ depending on the application. Many people may be quite happy knowing a web site under the control of the sender of a piece of mail.
So, say, you get mail from "someone@mydomain.com". The signature specifies that the public key is on "http://www2.mydomain.com/mail_signature.html" and uses that to verify the signature on the mail message. The recipient gets to decide whether the URL "http://www2.mydomain.com/mail_signature.html" is close enough to "someone@mydomain.com" to accept the public key from there (a reasonable default would be to accept it when the mail host is a suffix of the URL host).
This wouldn't exclude putting public keys in the DNS system, and those keys might be "more trusted" by users, but it would make it much easier for regular users to deploy and use such a system, regardless of whether their ISP is keeping up with the times. In particular, I would imagine users writing mail rules to treat different cases differently (signed with DNS key, signed with matching web site, signed with non-matching web site, incorrect signature, unsigned).
_domainkey?
Is that underscore really meant to be there? Because _ is not supposed to be an allowable character for names in the DNS.
I hope that this is not Yet Another Impoverishment of internet standards...