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.
hum.. thats an interesting thought.. i dont see why that would be a concern, but you could always just usea free yahoo account for those emails you want to be deniable...
Nathan Friedly
-
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.
Use something else. Gee, that was hard.
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
I hate to break this to you... but you're not Google!
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).
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.
There are how many million domain names registered? As long as not ALL of them implement this, spamers will always have domain names they can use.
Users can choose not to accept mail that isn't signed with a DomainKeys signature. If a user is only accepting signed mail, then his spam filter can make a decision to accept mail or not accept it, based on the reputation of the sending domain: white lists, black lists, refusal to accept mail from a domain that hasn't yet established a track record.
Find free books.
It looks like this is addressed in the Yahoo DomainKeys FAQ. Your ISP just adds a new key showing that your mail uses their server and the message should be signed correctly.
DomainKeys allows for multiple public keys to be published in DNS at the same time. This allows companies to use different key pairs for the various mail servers they run and also to easily revoke, replace, or expire keys at their convenience. Thus, the domain owner may revoke a public key and shift to signing with a new pair at any time.
DomainKeys will typically be implemented/enabled by the team within a company, ISP, or email service provider that deploys and runs the incoming and outgoing mail servers. Some companies may have service providers that handle their email. As MTA vendors, such as Sendmail, add support for DomainKeys to their products, the implementation of DomainKeys will become simpler.
"We can't solve problems by using the same kind of thinking we used when we created them."
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.
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"
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.
No, this will really work. It enables differential filtering based on the managed reputation of the sending service. (faughnan.com/spam.html).
I advocated this many years ago, but it doesn't need advocacy -- it will simply happen.
Unsigned email gets filtered very aggressively. Some will get lost of course -- aggressive filters err to false positives. People who want their mail to be read will move to authenticated sending services.
Signed email from domains with bad reputations will be deleted in the pre-filter. Reputation services will manage domain reputations.
Email from an authenticated sending service with a good reputation gets lightweight filtering. If the domain doesn't manage their members the domain reputation suffers -- and filtering gets more aggressive. Domain members head for the exits.
BTW, the same policy of managed reputation of sending services has a 'real world' equivalent. In the future world of high security, privacy may yet exist within communities that manage their reputations.
John Faughnan
jfaughnan@spamcop.net
has anybody succeeded in verifying one of the domainkey headers from a gmail message?
- delany-d omainkeys-base-01.txt
... s=beta; d=gmail.com; ...
after reading the ietf draft:
http://www.ietf.org/internet-drafts/draft
if this is in the message header:
DomainKey-Signature:
i think you should be able to retrieve the public key necessary to verify it by querying dns for a txt record for
beta.gmail.com
but i don't get anything back in the answer section when i run
dig TXT beta.gmail.com
anyone have better luck verifying one of these messages? or is the gmail domainkeys implementation incomplete at present?
about sean dreilinger
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.
From what I can see DomainKeys appears to be patented by Yahoo!
If Microsoft had done this the sky would be falling - what's the difference here?
Is it just me, or is the length of email headers these days starting to eclipse the length of the body?
Leaving aside the question of how the DNS records get updated, is it possible to implement Yahoo's domain signatures (both signing and verification) in a mail client (Evolution, Thunderbird), or does it have to be in the server? It looks to me like that should be possible, but it's not completely clear from the spec.
If it is, then one way of getting these more widely used might be to integrate support for them into mail clients. That way, people with personal domains can sign their outgoing messages, and they can write filter rules (e.g., in Mozilla/Firefox) to deal with unsigned messages, correctly signed messages, and incorrectly signed messages as they like.
On my news submission form, there's a field for people to enter their email address. When I receive the completed form (it's forwarded to my Gmail account) and the sender has used a Gmail address, a yellow warning bar appears cautioning about trusting the email.
PocketGamer.org - For the gamer on the go!
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).
If the ISP requires authentication, then the person with the infected machine will be easy to find after a spam complaint and shut down for a few days till they clean up their machine.
I just grabbed the statistics for one A/V vendor's top virus alert today (http://www.trendmicro.com/vinfo/virusencyclo/defa ult5.asp?VName=PE_FUNLOVE.4099&VSect=S)
Roughly 10 million infected.
Imagine that having trojan capabilities. If it took one minute to shut off a trojaned, infected computer, that would result in roughly 100 days of spamming (if my back-of-the-napkin calculations are correct).
But that is a rather crude way of doing it. If I was evil enough to do it, I'd write up a little virus that would send itself out with the address book over time, to escape detection, then spam the address book, then die.
Read this article. Google also endorsed SPF, I do not know what happened.
But you're missing my point.
Even I've come up with a solution to combat spam.
That is not the point - the point is actual implementation. Google is at liberty to implement what serves their needs best.
But why does Microsoft not go ahead and implement it in their systems? The system was introduced in June-July, and the last time I checked, guess which of Microsoft's mail services have SPF implemented? Microsft? Hotmail? MSN? Xbox? Nope.
NONE of the above.
That is the difference - not suggesting new technologies, but going ahead and implementing them so that people adopt. I mean, they are so good at doing that for other things, why not for something useful?
That's what I feel bad about.
You know, when a discussion about those new anti-spam techniques comes up, I get this voice in my head that says the problem has already been solved by PGP. So I have to wonder, why is it that SPF, CallerId, SenderId and DomainKeys are falling over each other to be the anti-spam standard, whereas PGP is left in the dark?
PGP provides sender authentication (not just server authentication like SPF, CID and SID, or domain authentication like DK), by signing the mail with the sender's private key. The receiver can verify the sender's identity, because the signature can be decryted only with the sender's public key. Additionally, PGP can be used to encrypt the message. The functionality provided by these hot and hyped techniques doesn't even come close to what PGP can do.
So what's wrong with PGP? One argument I can come up with is that it puts a burden on the user, who has to generate keys, and make sure he can always access the keys when sending mail, but nobody else can. However, nothing in PGP demands that the user do all this work. A webmail system could generate a key for the user when he signs up, and the same applies to ISPs. Voila, PGP without any effort from the user.
Another problem could be scalability of the key database. PGP obviously needs more keys that the other systems. However, the amount of keys is in the same order as the number of mail accounts. Surely the mail system could store a few extra bytes per account, and answer the occasional request for public keys?
Can anyone provide more insight here?
Please correct me if I got my facts wrong.
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
Why not use the SMTP service for whomever your email address is through?
This is one of the advantages of using signatures; if you can sign the message (or get it signed by an authorized MTA) you don't need to submit through a specific MTA, which may be blocked from where you are.
What about users who travel?
This is handled by doing the signing on your laptop. DK (and similar schemes like IIM) are designed not to require changes on user PCs for the vanilla use cases, but they permit the user to sign if they're so equipped. So you would just sign the messages yourself, and "drop them in the nearest mailbox" (ISP).