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.
What if you send mail through domain you own, A, but they only provide redirects for that account. Ie... user@A. Your ISP, the one you pay money to have access to an smtp server, is domain B. This technology now requires either i) I set up my own SMTP server to send mail for said domain, or ii) start handing out my redirect account, which DEFEATS the purpose of a redirect account. Or, I'd have to contact the ISP and get them to set up an smtp server just for my domain, so that it could sign keys. Or maybe I've misinterpreted the technology, but that's how it appears to me at the moment.
Here is an example from NW's blog.
Opera Watch - An Opera browser blog.
How DomainKeys Works
How it Works - Sending Servers
There are two steps to signing an email with DomainKeys:
1. Set up: The domain owner (typically the team running the email systems within a company or service provider) generates a public/private key pair to use for signing all outgoing messages (multiple key pairs are allowed). The public key is published in DNS, and the private key is made available to their DomainKey-enabled outbound email servers. This is step "A" in the diagram to the right.
2. Signing: When each email is sent by an authorized end-user within the domain, the DomainKey-enabled email system automatically uses the stored private key to generate a digital signature of the message. This signature is then pre-pended as a header to the email, and the email is sent on to the target recipient's mail server. This is step "B" in the diagram to the right.
How it Works - Receiving Servers
There are three steps to verifying a signed email:
1. Preparing: The DomainKeys-enabled receiving email system extracts the signature and claimed From: domain from the email headers and fetches the public key from DNS for the claimed From: domain. This is step "C" in the diagram to the right.
2. Verifying: The public key from DNS is then used by the receiving mail system to verify that the signature was generated by the matching private key. This proves that the email was truly sent by, and with the permission of, the claimed sending From: domain and that its headers and content weren't altered during transfer.
3. Delivering: The receiving email system applies local policies based on the results of the signature test. If the domain is verified and other anti-spam tests don't catch it, the email can be delivered to the user's inbox. If the signature fails to verify, or there isn't one, the email can be dropped, flagged, or quarantined. This is step "D" in the diagram on the right.
In general, Yahoo! expects that DomainKeys will be verified by the receiving email servers. However, end-user mail clients could also be modified to verify signatures and take action on the results.
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 quite as clear cut as that.
Yes, if the spam originated from gmail, then the weird address is verifiably correct. However, there is no safeguard in place to prevent spoofing of gmail addresses from other domains.
I like Google a lot. I also think this kind of authentication system is absolutely necessary in the long run. I do not think that it needs to be plastered all over the news every time some obscure anti-spam safeguard goes up.
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
The message has to be unmunged. That is, it has to be your exact words and headers. If you don't stand by your words, don't send them.
-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
The zombies won't be able to correctly sign their messages.
>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
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?
They would need either the private key or access to the dns to alter the public key if they want to send it out as coming from the zombie's domain.
BUT - if they were using the zombie to send mail that is signed by the spammer's domain then adding the login to sign the spams is trivial and since they are already using SPF txt records in their DNS, I don't see why they wouldn't use "Domain Keys-compatible" spamming software.
I think he means that whenever you publish your main acount somewhere, you publish the fake ones too. That way, the people that do neet to get ahold of you, do. You could also publish just the fake ones in various places, but that would be useless, as they wouldn't help in cleaning out the main account.
Sig
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.
As far as I can tell from the specification you are correct, the provider of the e-mail service will sign the address as legit since it did come from one of their accounts.
The benefit would be that the provider could exactly trace the user account that was comprised. When complaints came in they would know which accounts were causing the problem and take appropriate action.
As it is now I get e-mails from people saying I'm sending them messages with viruses in them when I have never sent them anything. If they received a message signed by DomainKeys coming from my account I would know that someone has comprised either my computer or the account itself.
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
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
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).