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)."
Maybe those C_a_n_a_d_i_a_n Pharmacies selling V1a-gra can start using this technology so that I can finally know the stuff is ligit!
Seven Days with Ubuntu Unity
... until everybody starts using it! It might help, but all your friends and family won't use it so you cannot rely fully on this alone.
TFA advocates a
(*) 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!
Gee. If you look at the links inside the emails, they always point you to some odd site. If I am going to sign into Paypal, I don't log into paypalphishing.chsslu.nl
You really don't need a lot of expensive authentication software. People will still click the links because they don't read before they click.
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.
So, where does that fancy new protocol standard thingy fit into this?
http://www.modernlifeisrubbish.co.uk/images/illustrations/how-viagra-spam-works-large.png
Another point: I read through the article. No mention of Microsoft?
How to Download YouTube Videos
...in the fight against spammers. I am all for it. Will this be the end-all-be-all tool? No, such a thing does not exist in the world of the inter-tubes, but if it can stop the majority of spoofing, then it is a good start.
Bearded Dragon
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 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.
"The most sensible request of government we make is not, "Do something!" But "Quit it!"
I can see that this might help to reduce false positives (i.e. legitimate mail misclassified as spam), but I don't see how it can reduce false negatives (i.e. spam misclassified as legitimate mail). Basically it's similar to SPF but with cryptographic protection.
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.
I used hushmail's free encrypted email storage and mailing for a while in early 2000 and was happy with it... but could never remember my password...
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 entrants are dangerous, it won't surprise me if (as with the network neutrality issue), the big ones jump in and say it's essential that they have special status. They like being special and competing among their (predictable) friends.
I like this technological proposal, btw. I just think it will, like all things, require some refinement before it's really working. But it sounds like a step forward. And at the same time something to be wary of ... in a calm way.
Kent M Pitman
Philosopher, Technologist, Writer
This article is fine news for non-nerds... but somehow that's not what I hope for around here.
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 the verification process involve checking for the latest information from the alleged signer in case a signature has been compromised?
In short, I'd like enough information to judge for myself whether a DKIM-signed message is trustworthy.
Speaking of deciding for myself -- I understand the rationale for ISP-level filtering of unsigned email, but I don't think it's a great idea. At most, I think this should be an end-user-configurable service (and sure, filter by default if you want). When I sign up for service, my base expectation is that messages will be delivered and I can decide what to do with them. Client-side support (conspicuous notification to the user of whether a message is signed and, if so, whether the signature validates and, if so, who signed it) are the way to handle this.
That way, the user can spot any attempt to impersonate eBay (not just instances where the filter decided that the message was trying to look like it came from eBay). Who sets those criteria, anyway? Do you just block messagse with an eBay return address? You'd miss a lot. Do you actually evaluate the content? That borders on giving each DKIM-using company the ability to censor for certain content. ("If it contains an MP3 attachment and we didn't sign it, filter it out!")
I believe the main intent here is to hurt phishing attacks (more of a con than a spam), where the sender appears to come from an authentic source (ebay, paypal, etc), but I doubt it could do much against actual spam where they are trying to get you to buy a product of generate page view ad revenue. Fortunately I have found that GMail manages to knock out a good 99.9% of all spam, so it looks like at least someone has it right.
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.
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
You are to late. The big players already use authentication. Gmail, Ebay, AOL, and HotMail all use SPF and DKIM.
Jeff Moss
TFA is about "phishing" which is slightly different from "spam" even though both use bulk email methods.
... while only increasing your legit email rejection count a slight bit. You are "winning" against spam. Or it appears that way.
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.
... be affected? I'm talking about Thunderbird in particular, which by default will assign the same SMTP to all your boxes.
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 tell my mail system "If the mail purports to be from the DKIM sites, make sure there's a signature and also that it's valid" just to cut down on spam load.
SPF is much lighter - it doesn't give me a strong guarantee that the mail's legitimate, but for sites that use it (such as Paypal/EBay), it lets me discard a lot of the spam based on IP addresses. That doesn't stop everything - mail from Paypal-Security-Team.com or similar bogus domains can still get through, but at least it's a good start.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Well, if it has a valid Yahoo DKIM, then you know it really did originate via a Yahoo account, as opposed to some random trojaned Windoze box just slapping something@yahoo.com in the headers. So if you report it to Yahoo, unless they are totally incompetent (which they are) or in bed with the spammers (which they are too), you could reasonably expect them to actually take some action against the originator (and even if they did, the spammer would just create a new account).
One possible suggestion would be to just 5xx all mail claiming an envelope of @yahoo.com, perhaps with a message to use another email account to send to you and/or a URL to a webform (if some legitimate person wanted to contact you about something you really did want to get (eg a job offer or something)
To enjoy the benefits of Public Key Encryption I must have a trusted means by which I obtain the Public Key of the sender
When I open an account at the bank, that would be the ideal time for me to get the key that I need for correspondence. And the ideal device to get that key would be the flash memory stick
But the procedures required for this kind of processing are a but much for the Average Joe. Or are they?
Public key encryption should have been included in all computers long since by now, and if it were,-- everyone would know they need to pick up a COMSEC key for anyplace they want to do online business with. They keys could easily be loaded into a local computer's PGP system automatically using the autorun file on a flash-stick. People would soon learn to do this. Joe could do it.
It ain't too late to do the job right but another hare-brain scheme that flops ain't gonna help further the cause of eCommerce
And this hare-brain scheme will flop because guess what: ya gotta get the RATS outta your computer before any kind of secuirty software such as HTTPS or PGP becomes meaningful.
and this means putting an end to un-authorized software. playing tiddly-winks with this hacking problem ain't gonna get the job done folks, it's just that simple.
NO SIGNATURE? NO EXECUTE.
This is a sore subject with me, as I jumped through all of the hoops to get DK and then DKIM going - only to find out almost no one uses it.
Curiously, this has the possibility of weeding out the legitimate Mail-server operators who don't implement DKIM. I.e. the big boys end up driving the email server market straight into their own hands, while not stopping spam.
In particular, take Yahoo. Now Yahoo originally started the ball rolling with Domain Keys. And the goal, to eliminate SPAM, is quite good. However the clowns who came up with it didn't think this all the way through.
The result is that spam operators can (and do) implement DK/DKIM. Consequently, Yahoo doesn't honor Domain Keys. Your DK, or DKIM, signed email goes straight into the Bulk folder where no one sees it. And there's almost nothing that you can do about it. Yahoo doesn't care.
Following Yahoo's procedures, filling out their forms, talking to support, are all useless. They don't simply don't care about reliable email delivery, and certainly not about DK/DKIM.
The same is true for HotMail, ATT, and Comcast, to name just a few.
Now, considering Yahoo started the ball rolling in the first place with DK, frankly this makes them look, at best, as technically incompetent. At worst, it looks like they are trying to drive out people who run their own Linux or BSD based mail servers. Microsoft Exchange servers, on the other hand, seem to work just fine without DK/DKIM.
The big problem of this approach is with the Domain Registrars who get money from spammers that register Domains, implement DK/DKIM if needed, and then throw away the Domain when people start blocking the email.
In short, what's needed is not DK/DKIM, but a Blacklist of Domain Registars who look the other way with their spammer customers. If we had an effective system here, it's questionable whether DK/DKIM would be needed.
From what I've seen, Google is the only reliable big private operator which actually works as advertised. Congrats, Google - yet again you illustrate that you folks really DO know what you are doing, and that your competition doesn't have a clue.
So for now, I'm recommending to all of my friends that they use gmail. Steer clear of Yahoo, Hotmail, ATT, etc. And I have no affiliation with Google other than as a satisfied customer.
Oh, and one last warning about DK/DKIM. People might want to do a security audit of that code. From what I've seen of the stuff up on sourceforge (IIRC), the code is not the best that I've seen. Has anyone done a security audit of thi s code? I have to wonder if there are buffer overflows waiting to happen.
This doesnt, by itself, eliminate or even reduce spam.
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 live in the same domain as legitimate nonspammers, primarily the free web email provides (such as yahoo)
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.
What kind of certs are being used, and are they relevant? I'm wondering if they're using business certificates which require verification of the business that owns a domain, instead of something akin to a domain cert, which only verifies that the recipient controls the domain.
I ask because I run my own mail server, and if DKIM is only for people with articles of organization, and who can afford a $700 cert, then I think it would be contradictory to the decentralized objective of the Internet.
Stop-Prism.org: Opt Out of Surveillance
What about mail from paypa1.com? or paypal.srv13.hk? or legitimate mail from paypalsucks.com? Now you're back to the same old game of black-list-filter-arms-race.
Support Right To Repair Legislation.
Technologies like SPF/SenderID and DKIM do address a number of senarios today, but unfortunatly they both suffer the same weakness in combating forgeries which pretty much dooms them to failure in the long run: They can't do anything to stop an infected client machine sending out perfectly valid and non-forged mails.
Consider...
Yes, of course there are many ways of dealing with the resultant spew. But, what have either of the anti-forgery technologies really accomplished other than escalating the tech war between hammers and spammers?
--
This is just a rehash of 2004 news.
Gmail, Yahoo!, and Yahoo!'s submission to the IETF.This Yahoo? Remind me why we are believing they can pull this off?
The best thing Yahoo can do to solve the spam issue is to cease trading. Fortunately, that is their certain future.
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.
All those phishing scams rely on violating the trademark of the corp they're posing as. If the owner of the mark doesn't defend their mark from dilution, possibly including use by phishers, they could even lose the mark. The banks and other trademark holders are obligated to stop phishers from posing as them. Even if they weren't, I'd expect that my bank at least defend itself, and me, from these phishers abusing its trademark to scam me. Which is also some lousy advertising for their brand.
--
make install -not war
Correct me if I am wrong, but how is this different than a pgp key signature?
Just curious, why was DKIM chosen as an IETF standard and not SPF? Apart from requiring faster machines to implement the crypto for each message, what does DKIM provide that SPF cannot provide?
I'd be very surprised if it was any less than 98% fake.
Je fume. Tu fumes. Nous fûmes!
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 - validates rfc2821 MAIL FROM using using connect ip. Optionally validates HELO using connect ip. Provides for sender requested policy for dealing with suspect messages. Very useful to email admins, allows rejecting forged emails rather than causing a bogus DSN to an innocent bystander. Forgeries are rejected before SMTP DATA, for high efficiency. Also enables reputation tracking (karma kounting) by domain. End user typically isn't aware of Return-Path or HELO, so SPF is of minimal value against phishing.
SenderID/PRA (M$) - validates one rfc2822 header field chosen by the sender using connect ip. Effectively validates Resent-Sender as that is the header field typically chosen by spammers. Requires email client to display which header field was validated to be effective, and requires minimal intelligence on the part of user to draw appropriate conclusions from that information (thereby dooming it to failure). Same policy mechanism as SPF, allowing senders to effectively protect the Resent-Sender header field.
DKIM - cryptographically validates multiple rfc2822 header fields (e.g. "From"). Still working on sender policy framework. Validates normal header fields that user sees, so can be helpful now against phishing if the email client displays validation status. When the sender policy portion is finished, DKIM will allow senders to request that recipient MTAs, for example, reject emails from example.com that lack a valid From header field signature. This will prevent end users from ever seeing a forged From (or other fields protected via the sender policy), provided the recipient MTA follows the recommended policy, thus not relying on end user intelligence.
Actually, this technique needs less corporate cooperation than you suggest.
1) The specification allows domain owners to report their signing policy in their domain DNS record. So Paypal can announce publicly that ALL mail from paypal.com must be signed. i.e., the senders can add themselves to the whitelist. If your e-mail client gets mail claiming to be from paypal.com, but without the proper certification, it knows with 100% certainty that it is junk.
2) It wouldn't take much for the big retail e-mail providers to start certifying all mail coming from their domains. Of course, they could only do this if they required their users to send outgoing e-mail using a secure connection to their own SMTP server. This would be annoying for people who like to send yahoo.com e-mail from their home SMTP server, but in the long run it's a better way to do it. This would move toward better symmetry between POP/IMAP and SMTP protocols (i.e., you use a secured logon to your e-mail provider for both, which is probably how it always should have been. It used to drive me crazy having to change my SMTP server for each network I used.)
3) It probably won't be long before every major e-mail interface shows a prominent icon indicating whether a message is certified or not. Then, banks can say, "Don't reply to any message from us, unless your client shows that it is certified to come from bankofamerica.com." Now that I think of it, the e-mail clients should not just say that the mail is certified -- they should also say from where, and preferably in plain text ("Bank of America Corporation"). There should also be a system to ensure that phishers cannot sign up for similar names to real companies. Maybe this could piggyback on the system for SSL certificates.
Cryptographic signing of mail. I'm sure it'll catch on this time. No, really. Duke Nukem Forever!
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
*I* have yet to have accessed my bank account via the Internets, tho a banker might have when I was *in* the bank. But even since then -- when they asked my why I don't (or why don't I) access my account from the computer, I tell them "until you can give me as secure a connection as yours from the terminal behind the counter. And, no, that one over at that desk for public use doesn't seem as secure as yours behind the counter. Or, is it?" They never give me a direct or straight answer, so I don't trust it either.
Previously: "Linux... Toward the Sunrise..." Now: "Linux... Toward the-- No, now, part of Every Sunrise"
As long as people will work for 1 cent per captcha cracked on Yahoo, DomainKeys will have no impact on phishing attempts. Actually, it won't even cost that much any more since Yahoo and Hotmail captchas can now be identified by software up to 5% of the time.
"Well you're not Fiona Apple, and if you're not Fionna Apple, I don't give a rat's ass."
I've wondered about this for years. Get a cert from Verisign or whoever. Sign your outgoing mail. Put the public key on your DNS server. Done.
All modern e-mail clients that I'm aware of have S/MIME signature checking built in.
Only problem I see is outfits like Yahoo that like to stick their own stuff onto the end of your mail. Domain spoofing is too difficult to use just for spam.
Welcome to the Turing Tarpit, where everything is possible but nothing interesting is easy.
Banks could simply *sign their e-mail* using S/MIME and the same certificate system used for SSL.
S/MIME is already supported by Microsoft, Apple Mail, Lotus Notes, Thunderbird, and so on.
Google really ought to get off their asses and support it in Gmail.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
The only way banks can send verifiable information to their clients is if they provide each client with a unique public key for signing and decryption. Until internet fraud becomes so expensive that this option looks affordable, it isn't going to happen.
Even then, some bonehead consumers will fall for unsigned emails from "their bank" saying that the encryption key needs to be updated, but I think of that as evolution in action. There are always going to be people falling for different types of fraud simply out of their own greed or stupidity. Kind of like the sub-prime loan crisis where the mortgage brokers and mortgage derivatives houses seem to have scammed the rest of the financial industry, as well as consumers of both mortgages and mortgage-backed financial instruments.
We are the 198 proof..
My company doesn't automatically let through any mail that comes from paypa1.com. It does, however, have several domains in whitelists, from which I do recieve a load of (forged header) spam. SPF or domainkeys filtering would allow them to keep the whitelist, while autojunking anything else purporting to be from the whitelisted domains.
Given that spammers can create thousands of Yahoo accounts automatically with a 35% success rate, it's become rather useless to rely upon Yahoo to shut them down on a complaint - there are probably more created each hour than Yahoo can disable per day. Of course, SPF has been a disappointment, too; too many companies who say they support its use also don't want to risk having anyone bounce their mail, so they put a "soft fail" parameter into their SPF strings - they list all the acceptable servers, but tell you to accept it from anywhere, in case they missed something. Haven't checked if eBay/Paypal has fixed this in the last couple of months, but Hotmail hasn't, and neither has AOL.
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...
While I'd love to support DKIM (one more tool...) on my email server, my family all use Blackberries and iPhones -- the blackberry internet service (BIS) doesn't appear to support supplying a private key, or DKIM signing in general, so if I implement DKIM then I'm basically marking all the messages sent from the Blackberries as spam :P I assume the iPhone is in the same camp, but haven't looked into it since the BIS limitation already knixes the deal...
include a custom string in the message id of mails that you send. Thunderbirds and most other mailers offer some way to do this.
Whitelist everything that contains this string, blacklist everything else from your address
In addition, most mails that are replies to one of your mails will contain your message id in its references header, so by whitelisting this string, you also prevent falsely classifying those as spam.
ISPs could offer 'x' number of bytes free per month with account, charge extra for any above that. This would make sure that ISPs keep track of who was sending how much. The problem comes from "evildoers" who send in bulk, so this would catch them, or at least make it unprofitable for them to flood the "tubes" with their stuff. If someone's computer was taken over and being used, they'd soon be made aware when their ISP sent a message saying "You used up your quota in the first 3 minutes of this billing period".
I see even classic Slashdot is now pretty much unusable on dial up anymore.
Seriously, though, it's a lot harder to send spam if you can't hide behind a forged or throwaway email address. Is there anybody here not totally sick of spam?
For years I've been ranting for an anti-spam solution that uses authentication, and ranting against blacklists, heuristic filters, and all the other evil, unreliable kluges we use now. I guess nobody was willing to invest in the infrastructure that would make authentication work. Thank God for phishers: thanks to their scams, banks are getting hurt, and they're willing to spend a little money to fix the system.
That's scary, and just reiterates that computer network planners or so-called security experts need to be 3x looked over... or overlooked for the job.
Previously: "Linux... Toward the Sunrise..." Now: "Linux... Toward the-- No, now, part of Every Sunrise"
But it was spam, from another account on the same isp.
I traced the IP, verified the headers, and got a canned reply.
Great technology, if only it would provide some benefit.
The main problem with DKIM is that it is policy-optional. The policy is the thing that tells you a domain's signing policy. Do they sign all of their mail? Where should you find the public key? Do they have a particular third party handle all their signing?
If I want to filter incoming email, I need to know if a particular site's policy. If they sign everything, then I can instantly filter all unsigned, or badly-signed email. But with DKIM, I don't know a site's policy when I get the email. According to DKIM, if I get an email, and it is signed, and it's headers say that it should be signed by foobar.com, then I can decide whether or not to accept it based on whether or not I trust foobar.com. It's soft spam filtering, just like what we have now. So if bigbank.com has their mail signed by prosign.com, a hacker can still create a perfectly legitimate DKIM message signed by evil.com, and the recipient won't know for sure who is supposed to sign the mail, and has to make a judgement call.
DKIM does have an optional policy. But it has to be referred to in the email headers. Spammers and phishers can easily craft messages that point to a different policy, or leave out the policy.
A better system, that's been consistently rejected by the DKIM developers, would be policy is required. You get a mail, you look up the domain's policy, and you can decide in a concrete way if this mail really came from that domain. If their policy says they sign their own mail, or prosign.com signs it, then you could instantly drop that evil.com-signed message on the floor. It would offer cheaper better spam filtering, and more concrete protection to domain owners that their domains couldn't be spoofed. Sites with no policy, or with a transitional policy, would still require some mail filtering, but eventually most people would get on board, and most email would be easily filterable. Some argue that this is already covered by SPF, but SPF is not an end-to-end solution, and therefore much easier to fool in several ways.
Some also argue that in this case the spammers would just use fake domains. But in a world where email was filertable based on signatures, you could develop a rapid blacklisting system for new spamming domains that would actually work. All centralized blacklisting systems today are hampered by the fact that spammers can forge real domains as easily as fake ones. DKIM doesn't fix that, but a policy-first system could. To put the argument another way, locks don't stop crime, but I still want a lock on my door. And I think there's a lot less crime because of locks.
DKIM makes sense only if there are very few email signers, e.g. like web certificate authorities. Then you could trust all mail signed by prosigner.com. It seems to me the primary goal of DKIM is to create a new email signing business that makes more money off of spam than the spammers do.
It's more likely though that DKIM is well-intentioned, but hasn't had the guts to confront the central problem: forging email is allowed by design. Under DKIM, it's still allowed. It's explicitly allowed so that DKIM doesn't break anything (god forbid). In my opinion, if we really want to have an impact on spam, we need to put an end to forgery. A policy-first system would allow domain owners to set their own forgery policy.
tom
Even better is for banks to abandon email altogether and deliver important messages via direct postings on their website, a message service in their online banking system or failing that via snail mail.
One of the strengths of DKIM is that it can work with existing infrastructure like DNS. DNS knows nothing about individual addresses. Many SMTP servers don't even know much about individual addresses since they are just relays.
That said, there can be more than one DKIM signature per domain. Hell, it's technically possible to create as many DKIM signatures as there are email addresses, it would just be a major PITA to maintain.
With DKIM you can at least hold domains accountable to their users' behavior and indemnify them against the behavior of nefarious individuals outside of their network. It truly is an elegant solution to the problem of authentication and reputation.
If you want security on just your own email address, use PGP/GPG to sign/encrypt the email. Problem solved. The point to DKIM is that an ISP can implement it without having to educate users or alter their workflow a single iota.
- I don't need to go outside, my CRT tan'll do me just fine.
DKIM allows the sender to specify which headers to include and also limits on the how much of the content to use for the cryptographic hash (so that automatically added footers don't spoil the party). DKIM was *designed* to work with relays without causing problems, extra work from administrators, single points of failure, etc.
DKIM isn't even intimately tied to DNS; it just uses DNS because that's what people have today. Any other domain lookup mechanism would work including LDAP or an HTTP request.
SPF is broken in that "tracking exists: mechanism" is still spoofable and requires constant maintenance. The cryptographic key of DKIM cannot be spoofed today.
Another huge win is that SPF requires that you make an audit of all of your sending servers or risk bouncing messages. This is why most companies still have a "~all" at the end of their SPF records. What good is "allow all when in doubt"? DKIM solves this by sidestepping the server IP enumeration issue altogether. The only requirement is that your MTA software (not email client!) supports DKIM.
- I don't need to go outside, my CRT tan'll do me just fine.
DKIM is email-based, not email user name-based. It *can* use the email address as part of the signature, but this is not necessary. Unlike SPF, you can also have multiple signatures per domain so that all of your eggs are not in one basket.
Basically the email server has the private key in a cryptographic key pair. The public key is placed in a special DNS domain entry (but this special entry does not violate standard DNS syntax). The SMTP server (or client) adds the header "DKIM-Signature" to each email, which contains the query mechanism, the cypher type, which other headers and bits of content were used to generate the signature, etc. When the recipient's email server gets the DKIM-signed email, the receiving server queries for the public key (usually from DNS, but that is not a requirement of the DKIM spec) and verifies from the signature that the email is valid.
It is a much better solution than SPF in that DKIM works through relays without any problems, is not dependent upon DNS should DNS ever get updated or replaced, and does not rely upon a fixed list of server IPs or host names to function correctly. DKIM could work from a laptop in a hotel room provided the email client understands DKIM and you have a valid private key. Once again, the public/private key pair for the laptop need not be the same key pair for the rest of the organization. In fact, DKIM even allows for expiring old keys and putting new ones in place without interrupting service.
In summary, SPF was marginal at best when it was the only game in town. DKIM does everything SPF does, it does it better, and does a lot more with fewer headaches.
Let SPF die and do not mourn its passing.
(And in case you were wondering, yes, I have maintained mail servers before and have worked in the past for two different companies that sell SMTP servers and software. I was the one who wrote the section about DomainKeys, DKIM, SPF, SenderID, GoodMail, etc. in the product manual.)
- I don't need to go outside, my CRT tan'll do me just fine.
The only way you could think that SPF was better was if you did not understand DKIM or hadn't read the DKIM spec.
Also, just because you add DKIM support doesn't mean you have to dump SPF; they are not conflicting technologies. DKIM is simply a better technology. I would even venture to say that generating a private key pair is easier than enumerating all of the IPs and host names in your domain in perpetuity like you do with SPF.
Check your SPF record. Does it end in "~all" like most domains? Are you really satisfied with a technology where the usual answer to a query is "maybe?"
- I don't need to go outside, my CRT tan'll do me just fine.
In a discussion where so many people have no idea what they're talking about, especially with regards to DKIM, it's refreshing to see such an accurate point.
DKIM + DNSbl = dead spam
- 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.
Here's your primary mistake: DKIM is not now nor has it ever been an anti-spam technology. It is an authentication technology. It makes sure you are who you say you are. Used in conjunction with deny lists and reputation services like Spamhaus, it can block spam. But more importantly, no one can send from "paypal.com" except PayPal. If spammers/phishers cannot spoof domains, you may still get Viagra ads, but you won't get eBay hacks. Once spammers are cornered to their own domains, those ISPs will be systematically blocked with nowhere to go. ISPs that tolerate or aid spamming/phishing will find that they are no longer able to communicate with the world anymore. A better system, that's been consistently rejected by the DKIM developers, would be policy is required. You get a mail, you look up the domain's policy, and you can decide in a concrete way if this mail really came from that domain. Man! Where do you get this stuff? When you receive a signed message, you don't have to look up a policy. All you have to do is look up the public key associated with the message category (the "c" attribute in the DKIM-Signature header). The message will either pass or fail. Done. No policy lookup necessary. If it should be signed in some other fashion, there wouldn't be a valid public key for it in the first place!. If there is no valid signature, then you look up the policy using the extremely well documented steps for doing so. DKIM makes sense only if there are very few email signers... Wrong! DKIM was *designed* so that third-party authorities were not necessary. All you need at the minimum is to generate a public key pair and deploy them. Your private key is stolen? No problem! Generate a new pair, sign all new mail with the new private key and publish the new public key on your DNS server. DKIM makes absolute sense even with ZERO third-party authorities. The only ones who push that line are the third-party authorities because they want your two bits.
Please stop discussing DKIM. You obviously do not know enough about it to give reasoned advice on the topic.
- I don't need to go outside, my CRT tan'll do me just fine.
You are right these days most of the complaints and spam mail that is getting by the filters and being sent to our Abuse Department is coming from Yahoo. Yes we've sent over 100 of these through their little form with the header information and still the next week more 419 spam with the same! FROM: address.
I called Yahoo and after an hour of being dropped and calling back I could not talk with anyone connected with the mail system. The ONLY thing I got was "Fill out the form." They actually told me that their was no phone in the office where the Postmaster was at. They really expected me to believe that too.
So here we have a site promoting and using Domain Keys (yes they're in the headers of these email so they must be vaild!) Yet they are enabling the abusers of the network. Domian Keys aren't going keeping this shit out it has a vaild key!
The only thing that will help is that companies like Yahoo and Hotmail clean up their own back yard and for them to somehow allow Engineers from one network talk and work out issues with THEIR! network. If they don't stop accounts that are doing this they are accessories to this crime and this IS a crime. You can only stop something at its source and the source is the orginating email account. These email accounts are being hosted by Yahoo.
There was a day when you had a problem and you did a whois lookup and called the Techinal Zone Contact and got things worked out. Sadly these days when dealing with the Big Boys like Yahoo and Hotmail are gone.
There is a method to deal with this and I am working on getting it approved here. Block all mail from Yahoo and explain to our customers that this is where their spam is coming from and to tell who ever is trying to send them mail to get a real email account somewhere.
Sure we're a little company and if we do this it will only cause a small issue with them but if more networks just started refusing Yahoo Mail soon it would make an effect on their user base.
indeed, most banks use X25 circuits for inter-site links, and these carrying credit card and other payment data in plain text
X25 is quite an old simple protocol and usually over slow-ish circuits (9600bps) so you could probably tap into it with something as basic as an original palm pilot!