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)."
-
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.
Here is an example from NW's blog.
Opera Watch - An Opera browser blog.
DomainKeys survives forwarding.
-russ
Don't piss off The Angry Economist
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
It's not really free, as the yahoo license is for a very narrow field of use. If the DomainKeys is implemented as free software, it doesn't seem possible (by my reading) to use the software outside the narrow area defined by yahoo ("the sole purpose of a sender verification solution in connection with e-mail.") Hence the software isn't really free (and neither is DomainKeys).
SPF verifies that the IP address of the mail server sending you the email is authorized by the domain to do so. This causes problems when email is forwarded, such as via pobox.com. It requires all email to be sent through "authorized" servers, which can cause problems when people are working from home and want to send email, or when you are in a cyber cafe. It also causes problems when email is generated on greeting-card/news-story websites.
DomainKeys creates a hash of the email body and some of the headers and uses public key technology to sign it. This causes problems when email is sent to a mailing list and the mailing list mangles it or when it is sent through things like MS Exchange servers. There are also problems with being able to replay the message. Like SPF, there are problems people are working from home and want to send email, or when you are in a cyber cafe. Also like SPF, also causes problems when email is generated on greeting-card/news-story websites.
Using DomainKeys, a spammer can send an email from a throw-away gmail account to another email account, pick up a copy of the spam with the correct domainkeys signatures, and then blast it out to everyone. I can't see any way to prevent this with domainkeys.
Many mailing lists add stuff at the end, either unsubscribe/archive info, or outright ads. In order to make DomainKey signatures survive being sent through mailing lists, the email body is converted to a "canonical form", which allows this extra text to be ignored.
The problem is that a spammer can subscribe to a mailing list, watch for emails without much text, then add their own ads (spam) onto the end and send it out.
I think domainkeys is an interesting idea, but as of right now, I can't see how it is ever going to work or be useful.
SPF support for most open source mail servers can be found at libspf2.
Actually the idea is that you CAN identify the domain the mail came from. The example you mentioned, gmail: If an email comes from somewhere that claims to be @gmail.com and does not have the domain key header, then it's not from gmail, as all gmail mail has that header. If it tries to add a fake domain key header, it's checked and rejected as fake. As far as i can tell the key doesn't differ from person to person so you can't tell a john@gmail .com from a jeff@gmail.com, but i could be wrong on that point.
This is a joke. I am joking. Joke joke joke.
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.
DomainKeys creates a hash of the email body and some of the headers and uses public key technology to sign it. This causes problems when email is sent to a mailing list and the mailing list mangles it
The recipient should probably have their mailing list sources whitelisted. Or the mailing list could insert a Sender: header and resign the message.
or when it is sent through things like MS Exchange servers.
This is indeed a problem, but the -01 spec has c=nofws and h= which should go a long way towards fixing that.
There are also problems with being able to replay the message.
True, but you can't replay it with different recipients.
Like SPF, there are problems people are working from home and want to send email,
Your workplace can give you a selector and private key of your own so you can configure your MUA or MTA to sign email. (I realize that I'm creating software from whole cloth here, but we're talking about the capability of a standard, not the existance or capability of the implementations of it).
or when you are in a cyber cafe. Also like SPF, also causes problems when email is generated on greeting-card/news-story websites.
Typical email use in a cyber cafe (that I've observed anyway) is a webmail host. The greeting-card/news-story websites will have to stop forging email.
Using DomainKeys, a spammer can send an email from a throw-away gmail account to another email account, pick up a copy of the spam with the correct domainkeys signatures, and then blast it out to everyone. I can't see any way to prevent this with domainkeys.
gmail will start to get LOTS of queries for that selector. If they've given out one selector for each user, they'll be able to revoke the key for that user.
-russ
Don't piss off The Angry Economist
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.
Reply-To: takes precedence over From:. Any software that complies with the various and sundry RFCs will use the Reply-To: when asked to reply to the email.
The sender has to take explicit steps to cause this to break.
-russ
Don't piss off The Angry Economist
This is a good question; somebody mod it up (obviously *I* can't).
If your ISP supports domain-keys, they won't sign your outgoing mail, because they don't have a private key and selector/public-key combination for your from:. If they trust that you are you (e.g. because they used smtp-auth with reasonably secure passwords), then they might insert a Sender: header with your authentication information in it.
The alternative is for you to sign your outgoing email, or deal with people's reaction to the reception of unsigned email.
-russ
Don't piss off The Angry Economist
>According to the article, sendmail is working on an implementation of it, for which I rejoice. Its been available for several months http://sendmail.net/dk-milter/
Its thee .forward that survives, not the 'forward' button in your mail interface. If ebay sends a DomainKey signed mail to your pobox.com account, you can still prove that ebay sent it. With SPF, you can only say that pobox was that last to touch it.
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.
On a couple of your specific points:
.ZIP attachments. Hopefully you trust your employer's verification of the signature!
The SpamAssassin headers shouldn't interfere with the signature because the DK signature includes a list of the headers that are included, and the SpamAssassin headers won't be there.
Your employer could check the signature and annotate the message prior to removing the
Most authentication header solutions are server-to-server, not concerned with what person is sending the message, only what service. Given that domain spoofing is a server issue, not a client issue, that's reasonable.
In addition there are also issues with most email authentication systems involving relays.
(explanation for public benefit) In email situations you have:
Your Side -- Their Side
Where Your Side or Their Side consists of many or few email servers. It's very rare these days to have this situation:
Your Side -- External Relays -- Their Side
Where the external relays are not controlled by either you or the other side. These relays can do things such as the MIME re-encoding, ZIP removal, etc that was mentioned above. This is bad, as there really is no way to distinguish between a properly modified and an improperly modified email once it passes through those relays.
But they're rare. As long as the both Your Side and Their Side both have authenticators set up somewhere in the chain before things are mangled, everything is fine.
So, for instance, if you want to remove ZIP files, defang HTML or MIME, virus scan, and markup for spam purposes, you can do that. Just make sure that it's done *after* authentication.
It's like putting a letter in an envelope: envelope's only good if you check the seal before opening it.
No, read the specs - the whole point is that you CAN verify the domain name. If the from header says gmail.com but it isn't signed with gmai's key then it DIDNT come from gmail
And the people shall be oppressed, every one by another, and every one by his neighbour Isaiah 3:5
If my ISP supports domain-keys, they will sign my outgoing mail, but it will NOT match my totally-legitimate "from."''
I think DomainKeys takes this into account. If you provide a Sender: header, the domain in there will be used for signing the mail. So, the following mail:Your ISP would sign this mail, testifying that it indeed comes from the isp.com domain. The recepient sees the mail as verified, and sees the sender as anonymous@coward.org. His reply will also be directed there.
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
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.
.... are you just whining?
It's nowhere near as routine as you say. We struggled and struggled with this issue for months, and finally decided that we didn't have enough information about exactly what munging of messages actually happened "in the wild." Hence, the 00 draft had only tiny support for munging (allows for variable numbers of terminating CRLFs), and the 01 draft has only a little bit more.
Complexity is easy to add; simplicity is easy to lose. Simple specs get implemented; complex ones don't, or take longer to implement.
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.
The -01 draft? Did you miss the nofws canonicalization? Did you miss the h= tag which specifies the order of signing of headers?
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.
We have a committment from the SpamAssassin folks to support DK. That means checking the signature, and not munging.
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.
True. It's likely that complex corporate MTA configurations will need to check the signature at the border.
I could go on but you see the point.
Not really. Are you counselling inaction? Inaction is more likely to fail at stopping forgeries.
DK is a draft, and is far from ready yet.
Have you submitted your suggested improvements to Mark, or
I agree with you that some FUSSPs are not salvagable, but I believe that DomainKeys can succeed at stopping forgeries.
-russ
Don't piss off The Angry Economist