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?
You mean the e-mail I got from BUYYYY_CH33P_M3DZ@gmail.com might not have been authentic!?!?
To figure out how to implement DomainKeys. Seriously, that thing is a best.
-
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.I saw DomainKeys and read DonKeys. I took me forever to work out how such an animal could be used to sign emails for spam-filtering... I'll be releasing a white paper on it shortly.
So we have all these featurs even Yahoo doesn't have.. and yet we're still beta?
I like muppets.
-
So will this prevent spammers from sending spams via a Gmail account?
I doubt that's really the concern, most spammers don't use mainstream ISPs/E-mail providers as it is, they just fake return addresses from domains of known ISPS/E-mail providers. This would help E-mail servers on the receiving end (who've implemented the DomainKeys stuff too) to know for sure if the return address is real or not. So they could just toss out all @gmail.com addresses that aren't authentic, most of them would be spam anyway. It also simplifies Google's spam investigations, if a spam E-mail supposedly from gmail.com doesn't have the DomanKeys validation no further time needs to be spent on it, just send it back with a form "This didn't originate from our domain" message and go on to the next one.Of course that just means spammers will start using different domain names as return addresses.
Will it ever catch on? If enough people implement and use it, then yes.
Why not? If Google can grow to be numero uno in free webmail providers, that in itself will be a strong convincing factor.
The thing I like about Google - they do good things which forces other companies to follow them. Take search, for instance. Other companies had such horribly cramped search interfaces and ads, until Google came up with a clean and mean interface.
Now everyone - Yahoo!, Altavista, MSN Search - follow's Google's example.
I'm sure that if Gmail was to pick up momentum, the sheer number of users and need for interoperability would kinda force others to follow suit.
All these other providers had the means and the option, but did not do so. MS has so much funds and Hotmail in itself is responsible for a good chunk of spam - if MS had taken this stance, they could easily force other providers to adopt this technology and help decrease spam in the process.
But no.
_This_ is why I like Google. Way to go, guys.
Of course that just means spammers will start using different domain names as return addresses.
Yes, true, that is why DomainKeys is an authentication system. To the extent that it helps stop spam, it will be through forcing spammers to use their own names.
-russ
Don't piss off The Angry Economist
I don't see how it's any better than SPF?
In fact, it could be worse since now a calculation is required to verify the sender in addition to the DNS query.
Anybody care to enlighten me?
No sig
Here is an example from NW's blog.
Opera Watch - An Opera browser blog.
Alright, I DID RTFA, and basically what this describes is just another way to authenticate that the user is from that domain. Isn't that the same thing SPF does? They both seem to accomplish the same task, but SPF appears to be easier to manage and easier to support. My personal (commercial) mail server already supports SPF, sendmail et al. support it (via external component), and my Barracudas (awesome product!) are beta testing spf support right now.
Oh yeah, and gmail already support SPF. Why promote different standards that are apparently identical in purpose?
If you are out to describe the truth, leave elegance to the tailor - Albert Einstein
"So will this prevent spammers from sending spams via a Gmail account?
I doubt that's really the concern, most spammers don't use mainstream ISPs/E-mail providers as it is, they just fake return addresses from domains of known ISPS/E-mail providers"
I would think the really important thing about this is that Google is respected in the internet industry and that others will certainly follow suit. If enough big players make the effort to ensure email from their domain names is authenticated, email clients could eventually offer the option to only accept emails from proven senders.
http://brandonbloom.name
For those (like me) that have no idea what this would actually look like, here's the DomainKey header from an email I just sent myself from GMail:
c t:mime-version:content-type:content-transfer-encod ing; b=ONG9HfGg74ZbrOOI8IwjwhGUX+PlGp1+clGIyvWriiltDmXE xdmdDWoblELIrVMw3yex7xRyib6m4Q5pInSfi2mr1IQRZINzf2 qTI/9QtFMkpwJUcWJeBt8VPzdxpNCdItxyNnALLIXjrsBAcYsY 8Gv7C6HJR0E6OFZCM0qWrCo
DomainKey-Signature: a=rsa-sha1; c=nofws;
s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subje
Correct me if I am wrong, but if I understand this correctly, and if filtering with this becomes widely adopted, then it will also prevent me from sending mails with my gmail-address from my smtp server.
So I would have to use their web-interface, or hope they wil eventually make a smtp-server useable for a fee
Not that this is not their right and all, and I could just stop using it if I don' like it, free service, yada yada..
Still, this gives a little too much control to my email-domain-provider about which smtp-server I can use, than I am comfortable with.
I have a web domain mainly to receive e-mail.
When I send mail, I use my domain in the "from."
However, my domain provider doesn't allow smtp, so my outgoing mail is through my ISP.
If my ISP supports domain-keys, they will sign my outgoing mail, but it will NOT match my totally-legitimate "from."
According to the domain-keys summary, this would flag my mail. In medical terms, this is called a false-positive.
How does domain-keys prevent something like this from being a problem, other than by forcing users to adopt a completely different e-mail stragegy?
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
I've quoted some of the interesting looking parts below.
See what I've been reading.
Why is everyone flipping out about domainkeys and SPF? Gmail already HAD spf...looky what I get from 'dig':
;; ANSWER SECTION:
...and from the headers of my email:
gmail.com. 300 IN TXT "v=spf1 a:mproxy.gmail.com a:rproxy.gmail.com ?all"
Received-SPF: pass (mojo: domain of gmail.com designates 64.233.170.203 as permitted sender) client-ip=64.233.170.203; envelope-from=xxx@gmail.com; helo=mproxy.gmail.com;
What we should question is why this is in my Exim logs for each gmail mail I receive:
2004-10-17 23:00:25 H=rproxy.gmail.com (mproxy.gmail.com) [64.233.170.203] Warning: remote host presented unverifiable HELO/EHLO greeting.
One of the things that really irked me about SPF was that it used the TXT record of the main domain to store information. Now granted, not many people use the TXT record in DNS, but I found it very short-sighted of SPF to use the TXT record of the domain itself, rather than having a separate subdomain. For DomainKeys, this is the case. According to the spec, information is stored in TXT records in domains like so:
sanfrancisco._domainkey.example.net
In this case, "example.net" is the domain this is all about, and "sanfrancisco" is the name of they key (yep, it seems you can have multiple keys per domain).
I haven't looked too hard into DomainKeys, but it looks very promising.
(not even Yahoo has started that yet)
/.) that they had now the absolutely perfect SPAM filtering solution in place, I wrote them why they implemented this for their freebie "mail.yahoo" accounts, but not for folks that are paying them 15 bucks a month.
..... the fuckers..... So, I replied to them that I didn't think it fair that freebie customers got a better SLA than those people paying 150 bucks a year.
Doesn't surprise me. My domain was once hosted with a pretty satisfactory ISP called SimpleNet (what a name, but their service was good!!). They were absorbed by Yahoo and continued under the brandname Yahoo WebServices. So far, so good...
Over the years, I got more and more spam, so when Yahoo one time announced (I'm sure I read it on
Oh dear, had I underestimated Yahoo logic!! The reply was that I could upgrade my account to a business account (for 30+ bucks a month) to obtain the SERVICE (!!!) of spam filtering
No answer of course and I moved my domain to another ISP at the end of the year.....
Browsers shouldn't have a back button!! It's all about going forward...
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.
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.
you need a _domainkey in there:c om text "t=y\; k=rsa\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC69TURXN3o Nfz+G/m3g5rt4P6nsKmVgU1D6cw2X6BnxKJNlQKm10f8tMx6P6 bN7juTR1BeD8ubaGqtzm2rWK4LiMJqhoQcwQziGbK1zp/MkdXZ EWMCflLY6oUITrivK7JNOLXtZbdxJG2y/RAHGswKKyVhSP9niR sZF/IBr5p8uQIDAQAB"
$ host -t TXT beta._domainkey.gmail.com
beta._domainkey.gmail.
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.
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.
Do not ever do this! It is an extremely bad advice.
From addresses are almost always forged, usually there are just random junk in the From. Quite often there are valid addresses there, and your autoresponders will spam those innocent bystanders. They will be very thankful, you bet!
Finally, it is not uncommon that spammers forge in anti-spammers who have successfully shut them down before in there. When I was still actively pursuing spammers, I had my addresses forged this way. I have had my share of moronic autoresponders. It is not fun at all. If you do this, you only contribute to the spam, and you bet that if you annoy a real anti-spammer enough, you will find your own connection to be a smoking hole faster than you can imagine.
In fact, having autoresponders at all is not recommendable at all at this time. If you first accept an e-mail and then generate a bounce message, if the MAIL FROM was forged, that bounce will go to a random bystander, which is bad. If you use autoresponders, or generate bounce messages, you should be careful not to bounce at forged from addresses.
Allthough it is a bit controversial still, you may configure your system to reject spam and viruses at SMTP time. Then you will not generate a bounce, a relay may, but then, hijacked relays usually don't either (I think it is good reasons for this). So, I am of the opinion that this is good practice.
Autoresponders are Evil however.
Employee of Inrupt, Project Release Manager and Community Manager for Solid
I think your scalability point is going to prove important. I think it would be computationally rather expensive for the moment. My pubring has around 900 keys and the database is 12 MB. But then, it could become feasible in the future, as processing capacity does increase fast.
However, the real thing here is that PGP does not help you verify identity directly. It helps you verify that a message was sent by "Foo Bar ", and that it has not been altered while in transmission. Still, there is additional effort involved in knowing who "Foo Bar " is. Sure, you may know someone called "Foo Bar", but you don't know that it isn't some spammer who generated this keypair with your friend Foo Bar's credentials to get through your filters. Unless you have signed this key.
I don't think you will ever be able to sign all the keys of everyone who might legitimately send you e-mail, but you can build a web-of-trust based on PGP's concept of ownertrust, and I have put some effort into it myself, so I now trust roughly 1500 keys.
Doing this is a largish undertaking, however, and I think that is the main reason why I really can't envision PGP being useful for combatting spam in near future.
Employee of Inrupt, Project Release Manager and Community Manager for Solid