Slashdot Mirror
Domain Key Identified Mail vs Phishing
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)."
Do spammers use the exact names of my friends and family in phishing attempts? No, they use the names of banks and such.
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.
The majority of phishing and pharmacy mail coming to two accounts on my system are coming in with legitimate DKIM signatures... from Yahoo itself. With their CAPTCHA being broken several months ago (even if they only discovered it last month), the amount of "legitimate" Yahoo-domain mail with has been running at least 30 messages per day to one of those accounts.
A site that I administer has a great introduction to DKIM for those interested:
http://what-is-what.com/what_is/domainkeys_identified_mail.html
(disclaimer: I am affiliated with that site)
It is dangerous to be right when the government is wrong.
The problem with DKIM is that it still relies on domain names. You can't spoof info@mybank.com, but you can by phisher.com, and have a valid DKIM signature for info@mybank.com.phisher.com, including links to https://mybank.com.phisher.com/ with no SSL certificate problems. You still need some other mechanism to verify that an email from your bank is from a domain that your bank owns, and this could be done easily by pre-sharing your bank's PGP key (for example). If banks want to stop their customers being caught by phishing attempts, they should include their PGP keys on CDs when they post out statements (or even just include the fingerprint on the paper statement and tell people how to check it the first time they get email), and tell people to disregard anything that's not sent by them.
I am TheRaven on Soylent News
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.
TO BUY A NEW CAR WOULD MAKE YOU SEXUALLY ATTRACTIVE.
DKIM is designed to not require a root of trust for its certificates. Most DKIM installations simply use a free RSA private/public key pair generated using openssl. The private key goes on the SMTP server, and signs all the outgoing messages. The public key is placed on the DNS server servicing the domain. When a DKIM signed message is received, the receiving MTA retrieves the public key via DNS and verifies the signature.
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.
Life is like a web application. Sometime you need cookies just to get by.
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 has all the technical info and suchlike on DKIM.
SPF has some issues with Relaying. If your an org that sends out emails from a 3rd party from time to time, (IE, surveys, or other crap), then you will have issues with SPF. If I have site B send out email for me, claiming to be from my site, (site A) then it will fail SPF. (unless I add them to my DNS as a legitimate sender, which is a pain, and takes ahwile to propagate). If I use DKIM, I just need to pass them the key to use to sign the email. The emails will be signed, and will validate against my public keys. I've also heard about relaying problems in large companies, with decentralized email, ie, each divison or site has its own mail server.. this solves that.
What are we going to do tonight Brain?
I agree in the context of spam in general. Well somewhat. I don't think DKIM will stop spam for 3 seconds, much less 2 weeks.
However, TFA isn't about spam in general, it's about spoofing and phishing. While this is spam related, it doesn't take a solution that works for spam in general to be useful against spoofing and phishing.
Domainkeys, spf, etc, are horrid anti-spam technologies. Good thing they aren't intended for such use. Although many confuse them as being anti-spam technologies, they are decidedly not. They are anti-spoofing technologies. Period. They may have some limited application in spam control (ie: that which is spoofed is probably spam), they aren't general-purpose spam solutions.
Do yourself a favor, stop thinking of these measures as spam control. No matter what any idiot tells you, they aren't. They're only practical as spoofing control.
Just remember.. figuring out a message passes DKIM isn't useful information. Failure is useful. Lack of signature for a domain that declares it signs all email is useful. Passing tells you nothing unless you choose to trust the sending domain, which in general, you can't.
Nonspam domains won't lie, and won't declare valid email to be forged, so you can trust them when they say a message is forged. Spam domains will lie, but they won't declare anything to be forged. As a result, you can't believe anyone telling you a message isn't forged. You can only believe someone telling you it IS forged. This is why DKIM isn't useful as a general anti-spam solution. However, it is useful for anti-forgery. It requires no special trust to believe a domain when it tells you a message is forged.
-Matt
I see a lot of confused posts about phishing and spam. Phishing is a subset of spam. I also find it funny how many skeptical/doom-and-gloom posts there are about Spam is impossible to stop. That is false. 100% false. It just requires a level of cooperation that is unlikely. It's not actually that bad right now, at least from the perspective of a mail server administrator. Or maybe I am just very lucky. Who knows?
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
The IETF standard process runs by rough consensus. 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 working outside the IETF, causing no great love with the IETF insiders.
It shouldn't be a big surprise that the MARID working group fail to reach consensus and was shut down without publishing any standards.
The folks involved with SPF (including me), and Microsoft both put forward their systems as "independent RFC submissions". These RFC submissions usually do not get put on the standard track and it could easily be argued that even being labeled "experimental" rather than "information" is a positive sign that the IETF sees at least some value in them.
By the time the DKIM working group was started, most of the hype had died away and a much smaller group of people were able to find consensus. DKIM was also backed by IETF insiders and most of the people from the SPF project that participated in the DKIM working group saw it as a complementary technology, rather than a competing one.
For email sent directly from one party to another, SPF, Sender ID, DomainKeys and DKIM all work very well.
In general, SPF (and Microsoft's Sender ID) has many more problems with email forwarders. There are ways around the problem using things like SRS or what gmail does and munges through the Received: headers to see which ones can be trusted and are forwarders. DKIM (and DomainKeys), on the other hand, rarely fail on forwarders, although it does happen when the forwarder adds trailers, do mime-rewriting, virus/worm scanning, etc.
In general, SPF has few problems with things like mailing lists. DKIM (and DomainKeys and Sender ID), on the otherhand frequently have problems with mailing lists.
Those of use that see SPF and DKIM/Domainkeys as complementary see domainkeys as very useful in identifying trustworthy forwarders which can then be used to make SPF more reliable, and SPF as a way of identifying trustworthy mailing lists, which can then be used to mail DKIM/DomainKeys more reliable.
SPF support for most open source mail servers can be found at libspf2.
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.
Change is certain; progress is not obligatory.
Because it's a monumentally stupid idea.
how to invest, a novice's guide
>I cannot mark myself as spam
If you signed *all* your outgoing mail, then you could mark as spam any signature-less mail which purported to come from you.
You think the terminal behind the counter has a secure connection? One very large nameless bank that I can think of, uses plaintext over IP from behind the counter...
And a soon as any of my vendors support it, I'll start adding the SPF score to my ham/spam weighting.
"The most sensible request of government we make is not, "Do something!" But "Quit it!"
I still want to know why challenge response e-mail never caught on.
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?
I don't blame them. SPF doesn't cut it. In theory, making an audit of all SMTP hosts allowed to send email for your domain and listing them in an SPF record makes sense. In practice, when you have a large, multinational organization with many subnets and even more SMTP senders, it simply doesn't make economic sense -- especially when it's a technology intimately tied to something as flakey as DNS. Check to see if that bank has a DKIM record instead.
The DKIM records show up as a complete "_domainkey" subdomain, not a single TXT record like SPF.
- I don't need to go outside, my CRT tan'll do me just fine.
You are so far from correct, you're not even wrong.
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 could have written it.
BUT...
This requires that every single user on the internet gets a copy of PGP and shares their public key with everyone they know. Most businesses (even the legitimate ones) don't know all of the people that contact them. Could you imagine telling a sales department that they can only converse with people with people they have previously talked to? I'm sure they'd all quit long before you went bankrupt.
DKIM can work (and usually does work) at the organizational and domain levels. This is a huge win for adoptability since most folks haven't even heard of PGP let alone public key encryption let alone how to use them.
Your comment about SPF is almost correct, but the failure to widely commit to SPF is not because of apathy. After years of growing their IT infrastructure out, to list all possible SMTP launch points is not only prohibitively expensive, but hard to manage for very large organizations that span multiple subnets and multiple continents.
DKIM signs header fields, it's true, but organizations decide which fields are used for the signature. It's not like DKIM uses all fields. In fact, it can use the content of the email or a subset of the content as part of the signature as well.
Matching on the envelope is a *bad* idea. It was a bad idea for other technologies, and it'll be a bad idea for the next crop of technologies that use it. As soon as you have an email redirection from one relay to the other, the headers will usually remain intact but the envelope will most certainly change.
DKIM breaks on relay more than SPF? You are obviously high. DKIM was *designed* to be more relay friendly than SPF. If DKIM is causing you problems when going through relays, the problem lies with your DKIM setup, not with DKIM.
- I don't need to go outside, my CRT tan'll do me just fine.