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.
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
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.
>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...