You say $345 with an exclamation mark as if that's a lot of money for a portable entertainment device. How much do you think an iPod costs? Or a Rio? -russ
I think DK is relevant in cases where the originator and receiver are not directly in contact. But for that purpose, it's too brittle for now.
Yes and no. Some MTAs munge. We know this, and have from the start. We don't know how many there are in actual use, and we don't know exactly what controls are needed to survive munging. So... we start with requiring no munging at all, then we add controls as experience dictates.
However, in the short term, anybody whose MTA is well written will find that it doesn't munge messages, and the DK sig will survive being forwarded. -russ p.s. I'm not going to tell you which ones are known not to munge, but if appropriately tortured, Google will quickly confess to my preferred choice of MTA.
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.
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.... are you just whining?
I agree with you that some FUSSPs are not salvagable, but I believe that DomainKeys can succeed at stopping forgeries. -russ
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
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
Yes, quite true, however you can mark unsigned emails as unsigned. DomainKeys is just one of many possible introducers for an email. SPF is another, whitelisting is another, having the email not come from a host on a DNSBL is another, having the email come from Paypal as a payment notification is another.
Yes, you're right that ebay.com will have to tell people that ONLY email from ebay.com is actually FROM ebay.com and ONLY if it's signed. -russ
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
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
Pretty lame post.... I'd be surprised if moderators failed to mark it Redundant. I'll take the risk of getting the same treatment by saying that DomainKeys survives forwarding. -russ
If you hand out one selector per user, then if the signature matches, the user is accurate as well. Trouble is that right now the DomainKeys document has no way to express that policy. -russ
Because if you forward email, the SPF authentication breaks. DomainKeys doesn't. Also, DomainKeys has the potential of authenticating on a user level, which SPF cannot ever do. -russ
Slashdot Mirror
Oh.
Yeah, really, is adjusting for inflation THAT subtle that two people had to get it wrong in their reply to me??
-russ
If that was his point, then why did he put an exclamation mark as if that's a lot of money?
... why am I repeating myself? Didn't you read what I wrote the first time?
But
-russ
meme. Hey, you're right, I sound deep!
-russ
You say $345 with an exclamation mark as if that's a lot of money for a portable entertainment device. How much do you think an iPod costs? Or a Rio?
-russ
Don't think of it as a 7 hour movie. Think of it as a 7 minute movie .... downloaded at 110bps.
-russ
Hmph. In *my* day, we didn't have laptops. We had to CARRY the teletype back and forth between school and home.
-russ
I can't imagine using less than four monitors. Or, rather, when I'm forced to, I find it horrible.
-russ
Moooo! Great to see Sketchcow doing this before all of us old farts who cut our teeth on 300bps BBSes die off.
-russ
I think DK is relevant in cases where the originator and receiver are not directly in contact. But for that purpose, it's too brittle for now.
... we start with requiring no munging at all, then we add controls as experience dictates.
Yes and no. Some MTAs munge. We know this, and have from the start. We don't know how many there are in actual use, and we don't know exactly what controls are needed to survive munging. So
However, in the short term, anybody whose MTA is well written will find that it doesn't munge messages, and the DK sig will survive being forwarded.
-russ
p.s. I'm not going to tell you which ones are known not to munge, but if appropriately tortured, Google will quickly confess to my preferred choice of MTA.
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
http://russnelson.com/cec.html
-russ
Ha! Yes, that's probably sub-optimal behavior on the part of an MUA. So if it's wrong, then point that out to MUA authors.
-russ
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
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
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
It will force spammers to stop lying about their domain name, or else use domain names belonging to people who don't care. That's a good thing.
-russ
Yes, quite true, however you can mark unsigned emails as unsigned. DomainKeys is just one of many possible introducers for an email. SPF is another, whitelisting is another, having the email not come from a host on a DNSBL is another, having the email come from Paypal as a payment notification is another.
Yes, you're right that ebay.com will have to tell people that ONLY email from ebay.com is actually FROM ebay.com and ONLY if it's signed.
-russ
X- is dead. Has been for at least eight years.
-russ
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
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
This is true. Gmail could give you a selector and corresponding private key to let you sign your own emails.
You could always use Reply-To:.
-russ
Pretty lame post .... I'd be surprised if moderators failed to mark it Redundant. I'll take the risk of getting the same treatment by saying that DomainKeys survives forwarding.
-russ
If you hand out one selector per user, then if the signature matches, the user is accurate as well. Trouble is that right now the DomainKeys document has no way to express that policy.
-russ
Because if you forward email, the SPF authentication breaks. DomainKeys doesn't. Also, DomainKeys has the potential of authenticating on a user level, which SPF cannot ever do.
-russ