Slashdot Log In
Domain Key Identified Mail vs Phishing
Posted by
CmdrTaco
on Mon Feb 11, 2008 10:00 AM
from the fifty-six-thousand-spam-in-the-last-thirty-days dept.
from the fifty-six-thousand-spam-in-the-last-thirty-days dept.
alphadogg writes "Some of the Internet's most powerful companies — including Yahoo, Google, PayPal and AOL — are brandishing a new weapon in the ongoing battle against e-mail fraud. DKIM is an emerging e-mail authentication standard developed by the IETF. DKIM, which stands for DomainKeys Identified Mail, allows an organization to cryptographically sign outgoing e-mail to verify that it sent the message. DKIM addresses one of the Internet's biggest threats: e-mail fraud. As much as 80% of e-mail that purports to be from leading brands, banks and ISPs is spoofed, according to a report released in late January by the Authentication and Online Trust Alliance (AOTA)."
Related Stories
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Good. (Score:5, Funny)
Useless.... (Score:3, Insightful)
Re:Useless.... (Score:5, Funny)
Parent
Re:Useless.... (Score:5, Funny)
I cannot mark myself as spam so it continues.
Just this morning I found out I was offering an unprecidented 78% off!
Parent
Re:Useless.... (Score:4, Informative)
If you signed *all* your outgoing mail, then you could mark as spam any signature-less mail which purported to come from you.
Parent
Re: (Score:3, Funny)
That's unprecedented! I'll take eight!
Re:Useless.... (Score:4, Informative)
Parent
Re:Useless.... (Score:5, Informative)
Are you referring to using DKIM for personal email? If you really want secure personal email, either buy, get for free (Comodo offers one, for instance), or make a certificate for public key encryption and have whoever you want to communicate with do the same. As long as they keep the certificate secure you'll always know who you're talking to, and it will be encrypted. You can even just digitally sign the message if you so choose.
It is my understanding that DKIM is for use in mass mailing where individually encrypting the messages or attaching a relatively large digital signature would not be feasible. Thus, there are better options for personal use.
Parent
Re: (Score:3, Informative)
Re: (Score:2)
No, this is only useless if companies don't use it.
I'm glad to see Google is backing this so I can use it on my personal domain as well. I already use SPF and it -did- cut down on the spammers that were impersonating my domain.
Re: (Score:3, Insightful)
Re: (Score:2)
HOw long do you think it would take people to adopt this new standard once they find out they can no longer receive email from Yahoo or Hotmail addreses? About five seconds. This is a clear case of something these companies must just roll out by command decision instead of waiting for consensus.
Re: (Score:2)
message from Google:
with valid DKIM: not spam
without DKIM or invalid DKIM: not spam
message from Hotmail: not spam (or ordinary spam checking).
Google's DNS has information to tell mailservers they send mail with DKIM.
Re: (Score:2, Interesting)
Oblig (Score:4, Funny)
(*) technical ( ) legislative ( ) market-based ( ) vigilante
approach to fighting spam. Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular idea, and it may have other flaws which used to vary from state to state before a bad federal law was passed.)
( ) Spammers can easily use it to harvest email addresses
( ) Mailing lists and other legitimate email uses would be affected
( ) No one will be able to find the guy or collect the money
( ) It is defenseless against brute force attacks
(*) It will stop spam for two weeks and then we'll be stuck with it
( ) Users of email will not put up with it
(*) Microsoft will not put up with it
( ) The police will not put up with it
( ) Requires too much cooperation from spammers
(*) Requires immediate total cooperation from everybody at once
( ) Many email users cannot afford to lose business or alienate potential employers
( ) Spammers don't care about invalid addresses in their lists
( ) Anyone could anonymously destroy anyone else's career or business
Specifically, your plan fails to account for
( ) Laws expressly prohibiting it
( ) Lack of centrally controlling authority for email
( ) Open relays in foreign countries
( ) Ease of searching tiny alphanumeric address space of all email addresses
( ) Asshats
( ) Jurisdictional problems
( ) Unpopularity of weird new taxes
( ) Public reluctance to accept weird new forms of money
( ) Huge existing software investment in SMTP
( ) Susceptibility of protocols other than SMTP to attack
( ) Willingness of users to install OS patches received by email
( ) Armies of worm riddled broadband-connected Windows boxes
(*) Eternal arms race involved in all filtering approaches
(*) Extreme profitability of spam
(*) Joe jobs and/or identity theft
(*) Technically illiterate users
(*) Extreme stupidity on the part of people who do business with spammers
( ) Dishonesty on the part of spammers themselves
( ) Bandwidth costs that are unaffected by client filtering
(*) CPU costs that are involved with cryptography
(*) Outlook
and the following philosophical objections may also apply:
( ) Ideas similar to yours are easy to come up with, yet none have ever been shown practical
( ) Any scheme based on opt-out is unacceptable
( ) SMTP headers should not be the subject of legislation
( ) Blacklists suck
( ) Whitelists suck
( ) We should be able to talk about Viagra without being censored
( ) Countermeasures should not involve wire fraud or credit card fraud
( ) Countermeasures should not involve sabotage of public networks
(*) Countermeasures must work if phased in gradually
( ) Sending email should be free
(*) Why should we have to trust you and your servers?
( ) Incompatiblity with open source or open source licenses
( ) Feel-good measures do nothing to solve the problem
( ) Temporary/one-time email addresses are cumbersome
( ) I don't want the government reading my email
( ) Killing them that way is not slow and painful enough
Furthermore, this is what I think about you:
(*) Sorry dude, but I don't think it would work.
( ) This is a stupid idea, and you're a stupid person for suggesting it.
( ) Nice try, assh0le! I'm going to find out where you live and burn your house down!
Re:Oblig (Score:5, Insightful)
Parent
The risks of success for domain keying (Score:3, Insightful)
Actually, I think they'll see this as a business opportunity. The risk here seems to me not that it will fail, but that it will succeed. That is, that people will start to only trust those big few who can afford to create such an identification mechanism. That will lead to the big ones reaffirming their "portal" role and making it harder for new entrants to achieve legitimacy. On a claim that new e
Re: (Score:2, Interesting)
Besides, I think this form by now deserves an automatic -5 Stale and patently unfunny.
Nope. (Score:5, Insightful)
The first problem with blocking "spam" is that there is so much of it (80%+ of all email is spam) that just about any stupid idea will result in a decrease in total spam received. Suppose you refuse to accept any email on odd-numbered dates. Since 80%+ of the email coming in was spam anyway, you've reduced your total spam message count
The second problem is that an approach that works for ONE sub-category will NOT work on a different sub-category.
Example, spam from Gmail is not stopped by greylisting even though greylisting is fairly effective at blocking spam zombies.
Will Domain Keys block spam? No.
Domain Keys will only help against a specific sub-category and only when configured correctly and verified correctly.
Parent
Re:Oblig (Score:4, Insightful)
Parent
Re: (Score:3, Informative)
Because it causes backscatter. And backscatter is a Bad Thing (tm). Spammers use valid email addresses as their sender address. So that poor guy is swamped by challenge emails. This has happened to me. As a result my MTA no longer accepts ANY email from that c-r service. See where that leeds to?
DKIM doesn't help with the domain is compromised (Score:4, Informative)
Re:DKIM doesn't help with the domain is compromise (Score:4, Informative)
Parent
Re:DKIM doesn't help with the domain is compromise (Score:2)
One possible suggestion would be t
How Viagra Spam Works! (Score:3, Interesting)
http://www.modernlifeisrubbish.co.uk/images/illustrations/how-viagra-spam-works-large.png [modernlife...bish.co.uk]
Another point: I read through the article. No mention of Microsoft?
Another tool... (Score:3, Insightful)
Introduction to DKIM (Score:4, Informative)
http://what-is-what.com/what_is/domainkeys_identified_mail.html [what-is-what.com]
(disclaimer: I am affiliated with that site)
Re: (Score:3, Funny)
What a coincidence!
A site I also administer has a great introduction to DKIM for those interested:
http://what-is-what.com/what_is/domainkeys_identified_mail.html [what-is-what.com]
(disclaimer: I am not affiliated with that site, but I did pwn it and use it as a spam bot)
Re: (Score:3, Informative)
Re: (Score:3, Informative)
The IETF standard process runs by rough consensus [wikipedia.org]. The IETF working group (MARID) that tried to standardize some of this stuff had everyone from Richard Stallman to Bill Gates trying to influence the outcome, along with a dozen proposals from "competing" technologies that would preferred no standard to theirs being excluded (this group included many folks who supported Domainkeys). SPF grabbed an early lead in deployment and mindshare by w
Revisionist history (Score:4, Interesting)
The IETF refused to ratify SPF as an official standard because it didn't have Microsoft support.
Today, RFC 4408 is still an "experimental" protocol - due to Microsoft's hurt. Someone at Network World isn't familiar with the material they are reporting.
I think SPF addresses a real problem, and does it well; but, my MTA vendor doesn't want to spend the programmer cycles on something non-standard (they've been accused of being non-standard in the past, and don't want to risk the accusation again). I am annoyed that something so simple and easy as SPF isn't ubiquitous yet.
DKIM vs. SPF for Spam and Phishing (Score:2)
DKIM is a heavy cryptographic protocol for positive identification - it's occasionally worth checking, but I'd rather not have to use it on every phishing spam, and I'd rather not have to
Re: (Score:2)
SPF is no panacea either. For forwarded mail you have to header rewrites, and it may help to some extent with zombies, but when you have something like a distributed dictionary attack, it'
Re:Revisionist history (Score:4, Informative)
Let's see. I turn off SPF. I get forgies from paypal, gmail, hotmail and various banks. The alternatives mentioned do not stop the forgies of the above mentioned list. Therefore, the alternatives do not work for me. Period.
The from address used in the protocol should be from the mail forwarding agent, not the e-mail address it is forwarding for. You can keep that information in the headers of the e-mail just fine.
This seems uncommon from what I have seen - But alas I have no real verifiable statistics on me and you haven't provided any to enforce your point.
Actually, the past two decades used "<>" as the from address. Then when such unreturnable addresses started getting blocked, mail providers started using things like mailer-daemon@attheirdomain.com or a spoofed e-mail address. There is a problem identified with the latter.
Most mail servers will reject e-mails at the SMTP connection with a error code actually. Very few mail servers will return bounces as actual e-mails to addresses due to the fact that this was done away with, with how spammers used to bounce spam on other servers through such messages.
Such as using the methods the person in mentioned article is discussing rather than using what is done in most real installations.
This has never happened with me and will never happen. This is a lie. 100% of my e-mails were never denied due to SPF reasons on my domain.
If SPF is not supported by the mail server, the e-mail will go through as normal.
On the other hand, the servers that are forging from addresses from domains that they truely do not operate may get the e-mails either flagged or rejected -- I consider this a good thing.
There is of course the issue where a provider may require that all e-mails that go to them, publish DNS records for SPF. But I don't know of any in existence.
It is actually. It's meant to stop spoofing of domains by reating a whitelist of permitted outgoing servers.
If I get a e-mail from say @gmail.com. I can be sure that the e-mail which sits in my inbox with a @gmail address came from gmail's servers (any e-mail that does not match the headers in the e-mails gets flagged as junk - mailing list items get filtered into the appropriate folder obviously).
I don't see how duping is working here.
Parent
Re: (Score:3, Informative)
And a soon as any of my vendors support it, I'll start adding the SPF score to my ham/spam weighting.
Re: (Score:3, Informative)
The DKIM records show up as a complete "_domainkey" subdoma
Might help a little but could be dangerous as well (Score:5, Insightful)
If the "big" spam targets (Paypal, Ebay and Amazon spring to mind) and the big mail providers (GMail, Hotmail, AOL etc) work together, it might reduce the amount of spam as well; for example, Paypal could state that *all* of their Mail will be signed with DomainKeys; Gmail could then immediately put all non-signed mail from Paypal into the spam folder (or reject it).
Since more and more people are using the big providers for their personal E-Mail, it might help with false positives there too.
It will not help with E-Mail from Domains not using DomainKeys, for domains set up by spammers (they can DomainKeys as everybody else) and for "small" domains, i.e. not deemed important enough by the big players to be listed as "non-spamming".
If the big players really work together on this, it might reduce spam a little but it will also damage the small players; since they're not whitelisted, their E-Mail is more likely to be classified as spam. Which makes the big players more attractive, so more people will use them and so on. It leads to a centralization of E-Mail.
I'm not sure whether this is good or bad.
Re:Might help a little but could be dangerous as w (Score:2)
Re:Might help a little but could be dangerous as w (Score:2)
All it does is provide some degree of certainty that a given email, if it passes the dkim check, did in fact originate from a server/account/system under the control of the registrant of the domain name it validates to.
Now, if it were to ever catch on to where 99% of email senders (spammers or otherwise) were using this, it would help to identify the spammer domains from the nonspammer domains. It doesnt, unfortunately, help very much when the spammers l
Technical details? (Score:2)
So there's a standard (or collection of standards) coming together to combat phishing. Good, good. How does it work? TFA mentions documents describing how a company signs its messages and how a recipient checks the signature, but no link?
Is it a technically sound signature, with a secret key that can be reasonably protected and no reasonable means to modify a signed message without breaking the signature? Does
Counter-measure (Score:5, Interesting)
From: fraud-dept@interbankcorp.com
To: joe.smith@someplace.somewhere
Reply-To: fraud-dept.interbankcorp.com@freewebmailplace.bleh
Hello, we at InterBankCorp have been having a problem with other people accessing your account, and transferring funds out of it. We are working to rectify this problem, and all we need from you is your username, password, and pin number to confirm that you are the legitimate holder of the account.
You may note that this e-mail is not signed digitally, as we assured you all our communications with you would be. We are having problems with our e-mail servers, rest assured this message is legitimate as it contains our official logo. Our e-mail problems will be resolved shortly and we will go back to using digital signing to verify our authenticity with you.
Thank you again for helping us resolve this problem with your account.
Re: (Score:3, Insightful)
J.
Powerful? (Score:2)
AOL is essentially deceased. PayPal isn't a big deal outside of the eBay community (which itself is slowly contracting). And as we all know Yahoo has been less and less relevant over the past couple of years, and is set to die any moment.
1999 called and wanted its powerbrokers back.
DKIM is useless and unused anyway (Score:5, Informative)
DKIM is a cheesy hack. If you want crypto use PGP or I guess S/MIME. You can not only sign but encrypt and do other proper things as well.
For eliminating phishing and other forged mail, I've found it far more useful to implement SPF on my MX host. Surely forged mail (where the policy says -all) is summarily bounced. Mail which passes an SPF check is let right through. Finally the rest is greylisted for 15min.
The big problem is that no one seems ready to commit to SPF. Most "big names" seem to say "?all" (neutral) or occasionally "~all" (soft-fail), making it impossible to definitively reject forgeries. More importantly, if they refuse to commit to what mail server they will use, they certainly won't commit to whether all mail will be signed.
DKIM fails because it signs the headers and not just the SMTP envelope. This breaks forwarding more than SPF does. Mailing list implementations and others seem to ignore the semantics of multiple signatures despite info in RFCs. And no one is going to re-open mail relays so it's extra complication over SPF which merely codifies existing behavior.
Lastly, this important point: Yahoo does not support DKIM. Despite sitting on the standard committee, they refuse to send DKIM headers or even parse DKIM headers on mail they receive. Rather they stick to DomainKeys which is broken in numerous ways (example: it doesn't specify which headers are signed so any headers added by intermediate relays cause signature failure). Yahoo doesn't play nice with others and hold up standards. Guess it's obvious why Microsoft is buying them, but they've sold out long ago. Yahoo's HTML used to be clean and nice; now it's garbage.
All of Yahoo's fascism and rudeness does nothing to help them. I get far more spam to my (unused) Yahoo mail account than I do to my (unused) GMail account. Yet Yahoo greylists mail for long times even when the sender is SPF, DKIM, and DomainKey signed. They don't share the greylisting among servers in their farm. That means even after the greylisting should be over it bounces yet again. Even when they "accept" mail it takes forever to show up. Somehow GMail which supports higher volumes, more usable interface, larger files, and I'm guessing more overall traffic blocks almost all spam, lets real mail through instantly.
Yahoo's time is over. Let's let them die quietly.
Not even wrong (Score:3, Informative)
S/MIME requires a certificate signed by a third-party certificate authority to be even remotely useful. DKIM does not. A self signed cert wouldn't work for S/MIME because any spammer could then just generate their own key pair and send.
PGP is an end-to-end signature and encryption solution. This is a completely different problem domain. PGP/GPG can guarantee that userA@placeA.com actually wrote the email to userB@placeB.com and that only userB@placeB.com co
Only 80%? (Score:3, Insightful)
I'd be very surprised if it was any less than 98% fake.
DKIM is not about phishing (Score:5, Informative)
The article has this so wrong that it's not even funny.
DKIM has pretty much nothing to do with phishing, and will do absolutely nothing to make phishing more difficult (though you could build some sorts of phish defenses based on DKIM I wouldn't bet on them being very effective, and they're certainly not what DKIM was really designed for).
DKIM is designed to allow the sender of a piece of email to cheaply embed a cryptographic signature in the mail to prove that they sent the mail. It's not usually used at the end-user level, rather a consumer ISP might sign all the mail coming from their smarthost or a company sending a newsletter may sign that email using their domain, even though they're sending it out via their ISP or via an ESP.
That signature doesn't mean anything other than I take responsibility for this email.
That has two uses that are (mildly) related to spam or phishing. The first is that it means that when you get a piece of email and hit the "this is spam" button it's easy for your ISP to work out who to send the feedback report to.
The second is a bit more subtle. It allows a sender of email to attach a persistent identity to the mail they send, in a way that can't be spoofed by others and which is independent of the IP address the mail comes from. That allows receiving ISPs to accurately track the reputation of senders of email, tied to that DKIM identity. If, say, Cisco signs all their newsletters with DKIM, and I as an ISP haven't seen customers complain about that DKIM signed mail from Cisco then when this new email arrives Cisco I can be pretty sure that my customers won't complain about that, either. I can avoid some expensive content based spam filtering, deliver the mail directly to the inbox and avoid false positives.
Note that I don't give that mail that red carpet treatment because it is DKIM signed - I do so because the DKIM signature proves that it comes from a sender that I've decided to trust because of their good behaviour in the past. You can think of it as kind of like a cryptographically signed "From" address, if you like, or as an identity that receivers can use to track reputation that's more convenient to receivers and senders than peer IP address.
Why not S/MIME or PGP? Well, DKIM can be cheaper to sign and check than either, but the real reason is that DKIM doesn't change the body of the email at all - just adds a few headers - so it doesn't require any special changes to the recipients mail client to be readable, and doesn't leave ugly detritus in non-DKIM aware clients. (The tradeoff of that is that DKIM is slightly fragile - some forms of body modification in transit will break the signature - but that's OK, as DKIM isn't designed to work 100% of the time, and if the signature breaks the mail will just be treated on it's merits, without the benefit of additional history).
DKIM will be (and is) used by spammers, of course, but it won't buy them anything other than making it easier for ISPs to track their reputations. And, in the case of spammers, that's a bad reputation (so they'll likely cycle through lots of identities in DKIM, just as they do everywhere else, to leave that bad reputation behind them). But it only provides advantages to the sender of the mail if they use a consistent DKIM identity over the long term, and consistently send mail recipients don't object to.
dkim.org [dkim.org] has all the technical info and suchlike on DKIM.
DKIM is a tool, not a solution (Score:5, Informative)
DKIM is not a total solution against SPAM, so the snippy comments about the futility of filtering/fighting/etc aside, DKIM is only useful for signing the headers of an email BETWEEN mail servers. It was never intended as a solution to be run on the clients machine. As a mail administrator I fight Spam with several tools, DKIM only being one of them. I also don't give a damn what the client is running to stop spam either. That's not my business, but I think THAT is futility.
DKIM attempts to authenticate the content of an email. Failure means that the message was not sent by the certificate holder. That's it. So if DKIM is actually used, failures can be stopped before they are even delivered to the client. I am not an super genius when it comes to this stuff, but false negatives would have to be pretty low. It could only occur if the message was signed incorrectly, or there was corruption in the headers. False positives would involve breaking the encryption, taking over the domain, etc. Not an easy task to do, and if accomplished the domain owner has more to worry about it.
I sign the messages leaving my mail servers with DKIM. I also process them on the incoming. I don't outright reject any email based solely on DKIM. It just gets weighed in an overall decision about the message.
The other methods used:
SPF - DNS entries on the domains indicate the IP addresses that are authorized to send mail on the domains behalf. When implemented, this is quite powerful. VERY powerful in fact. The problem is that is not widely enough used at the moment and most domains will not enable policies that guarantee a failure if the IP address does not match. So once again, whatever I learn from SPF is weighted. Now if a message comes from a domain that ONLY allows email messages from specific IPs and the email message is not coming from that IP, the session gets terminated immediately. The email client does not receive the message at all.
No Relays - This one is really old and quite obvious at this point. I only accept mail for my users and nobody else's users.
Reverse DNS/PTR Lookup - I check the incoming connection and compare it's IP address against the one claimed in the headers. I perform Reverse DNS lookups and compare those values to the headers as well. This is where you get the domain to check with SPF in the first place.
Greylisting - I actually use this, but it can possibly cause problems. Once a mail server has sent a message the 2nd time, it gets added to the list and there is generally no problems from that point on. However, if a user is constantly clicking the Send/Receive button after registering on a new website, there could be some frustration.
SpamCop/Blacklisting - This is actually very effective. I lookup the IP address of every email and check it against these databases. A failure has its session terminated immediately. The vast majority of the entries in these databases are from infected computers sending spam. So if the owner of an infected computer sent an email message through via his mail server, it would not get rejected. If it was from his computer directly, it would. This represents over 90% of the spam my servers receive.
Whitelisting - This helps eliminate a whole lot of false positives. I don't have any global entries, but if the FROM address matches an address entry in the user's contacts found with the TO address, it will be let through.
Spam Traps - I have created some virtual machines were I get stupid for a good reason. I actually do my best to make sure that a bunch of email add
Re: (Score:3, Insightful)
I am a power user. I have a static IP with a Sonicwall router at home. If my connection was doing something funny, and I don't mean P2P or IP protection/copyright filter/bullshit, I would would feel perfectly fine with an http redirect informing me of the problem, offering a download of the logs, and suggestions on how to fix it. I call that a sign of a responsible ISP. They don't even need to shutdown the whole service, just redirect the
Re:Cert Cost? Cert Relevance? (Score:5, Informative)
If the signature verifies successfully, all you have proved is that the messages originated from the domain it claims to be from. This does not eliminate spam, since it is possible for iamaspammer.com to DKIM sign emails (DKIM is dead easy to implement), but it does go a long way to preventing a phisher from faking an email from ebay.com or whatever.
Parent