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

Good.

[AndGodSed]

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!

Useless....

[greichert]

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

Re:Useless....

[Intron]

You frequently get phish attempts from your friends and family?

Re:Useless....

[LiquidCoooled]

I get spam sent from myself offering around 75% off viagra products.
I cannot mark myself as spam so it continues.

Just this morning I found out I was offering an unprecidented 78% off!

Re:Useless....

[Anonymous Coward]

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

custom message id

[Fëanáro]

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.

Re:

[mstahl]

That's unprecedented! I'll take eight!

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:Useless....

[snl2587]

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.

Re:Useless.... In the mean time...

[davidsyes]

*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 e

Re:

[bpsbr_ernie]

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

Re:

[Epsillon]

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 point of DKIM is header signing, not encryption. Think the drunken love-child of SPF and DomainKeys on steroids. The public key of the key you sign the headers with appears in your domain as a TXT record. Your milter or whatever takes a hash of the headers, signs it with the private

Re:

[Aladrin]

Yeah, because I'm -so- worried that someone will pretend to be my father to try to get my password from me.

No, this is only useless if companies don't use it.

I'm glad to see Google is backing this so I can use it on my personal domain as well. I already use SPF and it -did- cut down on the spammers that were impersonating my domain.

Re:

[NormalVisual]

I already use SPF and it -did- cut down on the spammers that were impersonating my domain.

I wish I could say the same - I still get plenty of crap in my inbox from ISPs that don't check to see if the sender's domain has an SPF record before bouncing spam to me.

Re:

[psbrogna]

All my friends and family use google & yahoo email. So if google or yahoo support it, then my f&f are all set.

Re:

[hedwards]

One of my favorite things about gmail is that since google uses DKIM as well as SPF and a good filter, the vast majority of spam that comes in go immediately into the spam folder. Rarely do I see any spam in my inbox or solicited mail in my spam folder.

Re:

[Bombula]

until everybody starts using it

HOw long do you think it would take people to adopt this new standard once they find out they can no longer receive email from Yahoo or Hotmail addreses? About five seconds. This is a clear case of something these companies must just roll out by command decision instead of waiting for consensus.

Re:

[xaxa]

test:
    message from Google:
        with valid DKIM: not spam
        without DKIM or invalid DKIM: not spam
    message from Hotmail: not spam (or ordinary spam checking).

Google's DNS has information to tell mailservers they send mail with DKIM.

Re:

[SkyDude]

How long do you think it would take people to adopt this new standard once they find out they can no longer receive email from Yahoo or Hotmail addreses? About five seconds.

Apparently you don't have a mother-in-law, grandmother or other senior citizen in your family.

If my mother-in-law stopped getting email, she wouldn't mention it. She'd assume no one was sending her anything. Then a month later she'd call me for support.

Of course, I'd stop getting her insipid joke emails, with 200+ other forwards in it, so that might be a good thing.

Re:

[sempernoctis]

Won't this also make it harder to set up a mail server? I run a mail server at home, and I currently don't control the domain I am in, only my host. Most of the dynamic IP services out there provide support for this. When all the major players start using it, is this going to screw over people who run their own personal mail servers? Disposable addresses [wikipedia.org] are a system that works completely within the existing standard for e-mail. I use them on my server, with no other filtering mechanism whatsoever, and

Re:

[Lumpy]

My friends and family don't tell me my Ebay and Paypal accounts have been reset and click here to fix it.

If your friends do, I suggest getting new friends.

Oblig

[W3bbo]

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!

Re:Oblig

[AndGodSed]

You forgot to add "Your idea will be patented by someone else and you will be sued into oblivion" under reasons this won't work...

The risks of success for domain keying

[NetSettler]

(*) Microsoft will not put up with it
...
(*) Requires immediate total cooperation from everybody at once

Actually, I think they'll see this as a business opportunity. The risk here seems to me not that it will fail, but that it will succeed. That is, that people will start to only trust those big few who can afford to create such an identification mechanism. That will lead to the big ones reaffirming their "portal" role and making it harder for new entrants to achieve legitimacy. On a claim that new e

Re:

[JaredOfEuropa]

Read the article again. I don't think any of the items you've ticked on this list really apply to the proposed solution, which in this article is targeting phishing attempts, but can work against spam as well.

Besides, I think this form by now deserves an automatic -5 Stale and patently unfunny.

Re:

[mkettler]

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

Re:

[Sandbags]

I still want to know why challenge response e-mail never caught on. It's a simple process really, would have been easy to implement (for end users), would have allowed any who complied with it to e-mail anyone else with ease, and would have incurred major costs only for companies who send more than ten thousand or more e-mails a day (mostly advertisers and other really big firms).

It's simple. Your e-mail client gets a message. First, it quarantines the message. Next, it opens a retun connection to the s

Re:Oblig

[Ioldanach]

Except that spoofed mail isn't necessarily bad. I have a gmail account which I use to aggregate a couple of other email addresses that I commonly send messages from and receive mail to. Gmail allows me to send messages out with these addresses after an email exchange with the address to verify that I have access and permission to perform that activity. Preventing spoofing will mean I have to use the actual accounts themselves, which is at best inconvenient.

Re:

[ahodgson]

I still want to know why challenge response e-mail never caught on. It's a simple process really, would have been easy to implement (for end users), would have allowed any who complied with it to e-mail anyone else with ease, and would have incurred major costs only for companies who send more than ten thousand or more e-mails a day (mostly advertisers and other really big firms).

Because spammers have access to more computing resources than anyone else. Any it would require a "flag day", or a time when ever

Re:

[Sandbags]

It doesn't require a simultaneous change. As people adopt a new browser, they find there are certain sites they can't go to. eventually, its us on the old browser that find we can't go certain places.

Those who adopt chalenge response clients will still get mail from everyone, just abunch of it will end up in a filtered folder until those sending it comply. Sure, for a while early adopters will find they basically have to manage 2 inboxes. It's easy enough to use a mail recipient rule to help that. The

Re:

[chromatic]

I still want to know why challenge response e-mail never caught on.

Because it's a monumentally stupid idea.

Re:

[oglueck]

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?

Nope.

[khasim]

TFA is about "phishing" which is slightly different from "spam" even though both use bulk email methods.

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 ... while only increasing your legit email rejection count a slight bit. You are "winning" against spam. Or it appears that way.

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.

DKIM doesn't help with the domain is compromised

[WoodstockJeff]

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.

Re:DKIM doesn't help with the domain is compromise

[TheRaven64]

The problem with DKIM is that it still relies on domain names. You can't spoof [e-mail], but you can by phisher.com, and have a valid DKIM signature for [e-mail], including links to https://mybank.com.phisher.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.

Re:

[metamatic]

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.

Universal encryption

[bwcbwc]

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

Re:DKIM doesn't help with the domain is compromise

[The Cisco Kid]

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 [e-mail] 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 t

Re:

[owlnation]

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

Quite correct. Yahoo -- the company who has repeatedly allowed its advertisers to install spyware on your computer. The company whose accounts are responsible for a significant amount of spam on the net -- they are one of th

Yahoo spam accounts

[WoodstockJeff]

Given that spammers can create thousands of Yahoo accounts automatically with a 35% success rate [slashdot.org], 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

How Viagra Spam Works!

[webword]

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 [modernlife...bish.co.uk]

Another point: I read through the article. No mention of Microsoft?

Another tool...

[Ngarrang]

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

Introduction to DKIM

[dotancohen]

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 [what-is-what.com]

(disclaimer: I am affiliated with that site)

Why DKIM (dick'em?) and not SPF?

[jerryasher]

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?

Re:

[QuantumRiff]

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

Re:

[wayne]

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.

Both SPF and DKIM have problems with this kind of thing. With SPF, you need to include these third parties in your SPF record (possibly using the SPF "include:" mechanism). As you mentioned, with DKIM, you have to send them a key.

I've also heard about relaying problems in large companies, with decentralized email, ie, each divison or site has its own mail server.

Ye

Re:

[dotancohen]

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?

For one thing, as one who travels with his laptop, I cannot use SPF because I'm not always in the same set of mailservers that I've configured. But that is my own problem, not necessarily the reason for the decision. If you ask the IETF and get a response let me know. You might want to review this relevant /. article:
http://ask.slashdot.org/article.pl?sid=07/06/22/1547225 [slashdot.org]

Note, there is nothing preventing one from using both DKIM and SPF.

Re:

[wayne]

Just curious, why was DKIM chosen as an IETF standard and not SPF?

The IETF standard process runs by rough consensus [wikipedia.org]. The IETF working group (MARID) that tried to standardize some of this stuff had everyone from Richard Stallman to Bill Gates trying to influence the outcome, along with a dozen proposals from "competing" technologies that would preferred no standard to theirs being excluded (this group included many folks who supported Domainkeys). SPF grabbed an early lead in deployment and mindshare by w

Re:

[ahodgson]

Because Microsoft hijacked the SPF approval process and patented the bastardized (and useless) hybrid that resulted, a combination of which resulted in the approval process dying a horrible death.

Re:

[notnAP]

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 [what-is-what.com]
(disclaimer: I am affiliated with that site)

What a coincidence!
A site I also administer has a great introduction to DKIM for those interested:
http://what-is-what.com/what_is/domainkeys_identified_mail.html [what-is-what.com]
(disclaimer: I am not affiliated with that site, but I did pwn it and use it as a spam bot)

Re:

[techno-vampire]

Thank you. It answered one question for me that TFA didn't: what happens if a phisher copies the DKIM from a legitimate email? It wasn't clear from TFA that the DKIM is unique for each message and that it won't verify if the message's been altered.

Revisionist history

[Degrees]

From TFA:

PayPal is deploying DKIM after already rolling out Sender Policy Framework (SPF), a complementary Microsoft-backed standard that is an extension to the Simple Mail Transfer Protocol (SMTP). SPF allows software to reject e-mail coming out of forged "from" addresses.

Except that Microsoft shat on SPF because it was Not Invented Here. They tried to get the world to implement their Sender ID protocol instead.

The IETF refused to ratify SPF as an official standard because it didn't have Microsoft support.

Today, RFC 4408 is still an "experimental" protocol - due to Microsoft's hurt. Someone at Network World isn't familiar with the material they are reporting.

I think SPF addresses a real problem, and does it well; but, my MTA vendor doesn't want to spend the programmer cycles on something non-standard (they've been accused of being non-standard in the past, and don't want to risk the accusation again). I am annoyed that something so simple and easy as SPF isn't ubiquitous yet.

DKIM vs. SPF for Spam and Phishing

[billstewart]

I've got two main problems with mail from Paypal/EBay/etc. One is that sometimes they actually send me legitimate mail, so if I get mail that looks legit I may need to check that it's really from them. The other is that lots of spammers send me junk purporting to be from them that I don't want cluttering up my mailbox.

DKIM is a heavy cryptographic protocol for positive identification - it's occasionally worth checking, but I'd rather not have to use it on every phishing spam, and I'd rather not have to

Re:

[Degrees]

Agreed. If I'm going to throw junk away, first I'll use RBLs, then SURBLs, and then I would like to cull the next layer of spam out with SPF. I only want to try the CPU heavy stuff on the items that make it past all the lightweight barriers.

Re:

[MightyMartian]

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.

SPF is no panacea either. For forwarded mail you have to header rewrites, and it may help to some extent with zombies, but when you have something like a distributed dictionary attack, it'

Re:

[rolfc]

SPF is very useful, if everyone use it. That way it will be difficult to send mail from other domains than your own, which make it easier to block spammers.

So if you dont use it, you are part of the problem.

Re:

[MightyMartian]

Oh come on. Everyone legit, and many spammers, have SPF records. It suffers the same fatal flaw that Domain Keys and Sender ID do, that unless you have a large proportion of mail servers co-operating, it doesn't work very well at all, and worse, adds overhead to processing SMTP transactions. The best one can use it for in the generic mail situation is as part of a suite of tests that weight for or against a message. Anyone who fails a message solely because of a lack of SPF record or because of a failur

Re:

[Degrees]

SPF isn't supposed to be the anti-dictionary-attack solution. It's a lightweight way of checking whether the incoming connection is coming from the IP address range that the message header claims to represent. That's all.

It does help me, even though my MTA doesn't support it. After I put in the "hard fail" SPF record for our domain, we got far fewer bounce-backs from other people getting bogus messages passing themselves off as us. Less bounce-backs means less work for me, explaining to my users why some m

Re:

[Doctor O]

I think SPF addresses a real problem, and does it well

So do I. We enabled SPF for all our mail one year ago and it really made an amazong difference. Sure, you've got the occasional mail that won't get through because of shitty forwarding somewhere in the recipient's mail chain, but those can usually be resolved by resending to the *real* address which comes with the error message.

Re:

[Degrees]

I only get the benefit of one half of SPF - if you receive a connect from a zombie PC purporting to be one of my users, you can instantly hang up on the box, knowing it wasn't from us. But even that helped me a lot, as the number of bounce-backs I got dropped tremendously.

Heck, my SPF record is of the "hard fail" type - so if you do get a bogus connect for my domain, feel free to update the RBL of your choice. ;-)

Re:

[Antique Geekmeister]

Microsoft didn't just shit on SPF. They embraced and extended it, broke the labeling for version 1 by stuffing their domain keys into it inappropriately, poisoned it with patented and un-extendable patented technologies no major SMTP server except Microsoft Exchange dared to be burdened with, and tried to cook the ISO proceedings in ways similar to what they're doing with OOXML. The result is that they claim all the SPF enabled sites as Domain Keys, when over 90% of them actually refuse to use Domain Keys.

M

Re:

[Degrees]

Yep.

It was a pretty disgraceful set of moves.

I expect that from Microsoft, but then, I'm an old guy and have plenty of experience on which to draw....

Right tool for the job

[CustomDesigned]

Good history correction. Let me explain what each of the anti-forgery methods offers:

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

Re:

[Degrees]

Thank you - nice summary.

DKIM looks to be a little on the CPU heavy side, but if a message has to clear all the other hurdles first, then that shouldn't be too bad.

Re:

[Znork]

I am annoyed that something so simple and easy as SPF isn't ubiquitous yet.

No shit. Last year I can recall a bank here had problems with loads of phishing mails purporting to be from them. When I checked, they didn't even have an SPF record, which would have, at least, instakilled the messages in some spamfilters.

Checking today, they've actually fixed that problem. So at least it's getting better.

Re:

[Degrees]

Yes - even though my MTA doesn't hang up on connections that fail the SPF check, at least by publishing my hard fail SPF record, I'm helping other mail systems to hang up on spam that tried to claim it was from us.

And a soon as any of my vendors support it, I'll start adding the SPF score to my ham/spam weighting.

Re:

[ttfkam]

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" subdoma

Comment removed

[account_deleted]

Comment removed based on user account deletion

Might help a little but could be dangerous as well

[Aaron Isotton]

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.

Re:Might help a little but could be dangerous as w

[PrescriptionWarning]

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.

Re:Might help a little but could be dangerous as w

[The Cisco Kid]

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 l

Re:Might help a little but could be dangerous as w

[Comboman]

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

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.

Re:

[Znork]

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.

Probably more useful than you think

[superposed]

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 provi

Technical details?

[mea37]

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

Counter-measure

[The MAZZTer]

From: [e-mail]
To: [e-mail]
Reply-To: [e-mail]

Hello, we at InterBankCorp have been having a problem with other people accessing your account, and transferring funds out of it. We are working to rectify this problem, and all we need from you is your username, password, and pin number to confirm that you are the legitimate holder of the account.

You may note that this e-mail is not signed digitally, as we assured you all our communications with you would be. We are having problems with our e-mail servers, rest assured this message is legitimate as it contains our official logo. Our e-mail problems will be resolved shortly and we will go back to using digital signing to verify our authenticity with you.

Thank you again for helping us resolve this problem with your account.

Re:

[aug24]

I think the hope is that your ISP will already have thrown the email away on your behalf, so you'll not even get to read it.

J.

Re:

[Erwos]

Preface: nothing I say is the official word of my employer, nor do I represent their views. This is all my personal opinion.

Speaking as someone who's actually privy to the details of DKIM implementation at a major ISP, the bank is going to want us to discard that email, or at the very least, toss it in the junk folder. You won't even see that email, most likely, and if you do, it's going to be in a place to make you _very_ suspicious of it. Most likely, the bank will also be telling you to disregard all non

Powerful?

[owlnation]

Some of the Internet's most powerful companies -- including Yahoo, Google, PayPal and AOL.

Ok, I'll give them Google.

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.

Re:

[Erwos]

AOL is a major player in the sender community - if you had ever gone to MAAWG's conferences, you'd know that. The fact that they're not terribly popular on Slashdot is meaningless. In fact, I'd argue that Google's relatively closed-mouth approach to working with the sending community makes them _less_ relevant than AOL, Yahoo, and the other players.

Cert Cost? Cert Relevance?

[Bob9113]

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.

Re:Cert Cost? Cert Relevance?

[khendron]

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.

Re:

[NormalVisual]

And unlike SPF, it will survive forwarding without the need to alter the sending address.

Re:

[Bob9113]

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.

Nice - thanks for the info!

Re:

[swb]

The other guy that replied says you can basically use self-signed (ie, no hierarchy of trust) but I agree 100% that we have to watch out for "security" initiatives that suddenly require formal organization verification and/or high dollar SSL certs. I'm sure the corporate entities would love this to force small-time email server users into the arms of the corporations.

In General

[flakier]

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

1. Company/ISP Exchange Server/Notes/Sendmail/FooMTA is setup for authenticated relay via public key, username/password, or whatever (or for that matter Non-auth via authorized IP range

DKIM is useless and unused anyway

[vsync64]

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.

Re:

[NecroPuppy]

I don't know that I agree with "Yahoo does not support DKIM."

See, I get DKIM verified e-mail, DKIM-less e-mail, and e-mail with DKIM fucked up. (The headers say domainkeys=fail (bad syntax).)

The DKIM verified e-mail comes through very quickly. Nothing is delayed (beyond normal e-mail delays); nothing is lost.

Same with the DKIM-less e-mail. It comes through fine.

However, the DKIM failing e-mail sometimes shows up quickly, but more often is delayed by 3-5 days.

Since 90-95% of that comes from one server tha

Not even wrong

[ttfkam]

You are so far from correct, you're not even wrong [wikipedia.org].

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 [e-mail] actually wrote the email to [e-mail] and that only [e-mail] co

Trademark vs Phishing

[Doc Ruby]

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.

Re:

[Antique Geekmeister]

They're committing "wire fraud". Forget the bank prosecuting, this makes them the responsibility of the US Treasury, specifically the Secret Service, at least for fraud against US citizens. If anyone was going to bother to prosecute them, it would be for criminal activity, but the Secret Service can't be bothered. It regularly discards any complaints less than a quite large threshold as not worth the manpower to investigate and convict.

If the banks would bother to report, and to support prosecutions, the Se

Re:

[Doc Ruby]

If the banks weren't making $BILLIONS in guaranteed profits every month, they might pay more attention to these little frauds that add up to $millions each month. With the way the economy is going, and with the change in the White House and FBI coming, maybe they will indeed find a lot more time on their hands to to their jobs of keeping us and our money safe.

Only 80%?

[ajs318]

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

You really think it's as little as that?

I'd be very surprised if it was any less than 98% fake.

DKIM is not about phishing

[SSpade]

The article has this so wrong that it's not even funny.

DKIM has pretty much nothing to do with phishing, and will do absolutely nothing to make phishing more difficult (though you could build some sorts of phish defenses based on DKIM I wouldn't bet on them being very effective, and they're certainly not what DKIM was really designed for).

DKIM is designed to allow the sender of a piece of email to cheaply embed a cryptographic signature in the mail to prove that they sent the mail. It's not usually used at the end-user level, rather a consumer ISP might sign all the mail coming from their smarthost or a company sending a newsletter may sign that email using their domain, even though they're sending it out via their ISP or via an ESP.

That signature doesn't mean anything other than I take responsibility for this email.

That has two uses that are (mildly) related to spam or phishing. The first is that it means that when you get a piece of email and hit the "this is spam" button it's easy for your ISP to work out who to send the feedback report to.

The second is a bit more subtle. It allows a sender of email to attach a persistent identity to the mail they send, in a way that can't be spoofed by others and which is independent of the IP address the mail comes from. That allows receiving ISPs to accurately track the reputation of senders of email, tied to that DKIM identity. If, say, Cisco signs all their newsletters with DKIM, and I as an ISP haven't seen customers complain about that DKIM signed mail from Cisco then when this new email arrives Cisco I can be pretty sure that my customers won't complain about that, either. I can avoid some expensive content based spam filtering, deliver the mail directly to the inbox and avoid false positives.

Note that I don't give that mail that red carpet treatment because it is DKIM signed - I do so because the DKIM signature proves that it comes from a sender that I've decided to trust because of their good behaviour in the past. You can think of it as kind of like a cryptographically signed "From" address, if you like, or as an identity that receivers can use to track reputation that's more convenient to receivers and senders than peer IP address.

Why not S/MIME or PGP? Well, DKIM can be cheaper to sign and check than either, but the real reason is that DKIM doesn't change the body of the email at all - just adds a few headers - so it doesn't require any special changes to the recipients mail client to be readable, and doesn't leave ugly detritus in non-DKIM aware clients. (The tradeoff of that is that DKIM is slightly fragile - some forms of body modification in transit will break the signature - but that's OK, as DKIM isn't designed to work 100% of the time, and if the signature breaks the mail will just be treated on it's merits, without the benefit of additional history).

DKIM will be (and is) used by spammers, of course, but it won't buy them anything other than making it easier for ISPs to track their reputations. And, in the case of spammers, that's a bad reputation (so they'll likely cycle through lots of identities in DKIM, just as they do everywhere else, to leave that bad reputation behind them). But it only provides advantages to the sender of the mail if they use a consistent DKIM identity over the long term, and consistently send mail recipients don't object to.

dkim.org [dkim.org] has all the technical info and suchlike on DKIM.

SIgning mail?

[pclminion]

Cryptographic signing of mail. I'm sure it'll catch on this time. No, really. Duke Nukem Forever!

DKIM is a tool, not a solution

[EdIII]

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

Re:

[Red Flayer]

I see a lot of confused posts about phishing and spam. Phishing is a subset of spam.

I'd say more that phishing intersects spam.

There are phishing attempts from spoofed websites, etc, and these cannot be classed as spam. It's less common now than it used to be, mostly due to awareness by users and vigilance by "real" domainholders, but IIRC the original phishing attempts were by spoofing domains & taking advantage of common typos and url entry errors (eg, secondcommunitybank.com vs secondcommunity.com

Re:

[EdIII]

Actually... your SPOT FUCKING ON, pardon my french. At least IMO.

I am a power user. I have a static IP with a Sonicwall router at home. If my connection was doing something funny, and I don't mean P2P or IP protection/copyright filter/bullshit, I would would feel perfectly fine with an http redirect informing me of the problem, offering a download of the logs, and suggestions on how to fix it. I call that a sign of a responsible ISP. They don't even need to shutdown the whole service, just redirect the

So Why Not Just Sign It?

[StormyMonday]

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.

Problem solved

[kellyb9]

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.

They invented smarter users?