Slashdot Mirror

Both office 365 and Google's gsuite support it and include DNS records you can add with a key identifer to verify the domain attached with the IP address is you. More information is here
http://www.dkim.org/

SPF also is pretty standard which helps but black hats have gotten work arounds.

If you own your exchange server you need to let your system administrator add the proper DNS records and turn it on in the Exchange Admin center

> Unlike PKI, DKIM has no revocation list mechanism natively. If one were to steal the keys, the best anyone could do is say "No, really, that email that appears to be sent from me and signed by me really wasn't!"

Two points:

* There is a way to revoke the keys, even if it doesn't involve CRLs or OCSP -

INFORMATIVE NOTE: A key may also be revoked as described below. The distinction between revoking and removing a key selector record is subtle. When phasing out keys as described above, a signing domain would probably simply remove the key record after the transition period. However, a signing domain could elect to revoke the key (but maintain the key record) for a further period. There is no defined semantic difference between a revoked key and a removed key.

INFORMATIVE RATIONALE: If a private key has been compromised or otherwise disabled (e.g., an outsourcing contract has been terminated), a signer might want to explicitly state that it knows about the selector, but all messages using that selector should fail verification. Verifiers should ignore any DKIM-Signature header fields with a selector referencing a revoked key.

* One of the keys in this example belongs to Google. So our hypothetical attacker in this case needs both GMail's key and hillaryclinton.com's. And both cover the body of the message. Here's the signature from this email just so everyone is clear on what we're talking about:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=hillaryclinton.com; s=google;
h=from:mime-version:references:in-reply-to:date:message-id:subject:to :cc;
bh=EHIyNFKU1g6KhzxpAJQtxaW82g5+cTT3qlzIbUpGoRY=;
b=JgW85tkuhlDcythkyCrUMjPIAjHbUVPtgyqu+KpUR/kqQjE8+W23zacIh0DtVTqUGD
mzaviTrNmI8Ds2aUlzEFjxhJHtgKT4zbRiqDZS7fgba8ifMKCyDgApGNfenmQz+81+hN
2OHb/pLmmop+lIeM8ELXHhhr0m/Sd4c/3BOy8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:from:mime-version:references:in-reply-to:date :message-id:subject:to:cc;
bh=EHIyNFKU1g6KhzxpAJQtxaW82g5+cTT3qlzIbUpGoRY=;
b=dEYKdN2vH085sl/02zUgJ1Lr66LV8lRV9Lrqx9SIpfiF1bOLLbIr1Au6AAY5vwg1vS
klK/TvacKT0j8aYADGNWP6BtG5XZ+IME6ydojlufQ3jqksqLkycSJ2ahYhxw4LmCii8n
kja2EKzRFcKGPnfhYnfwBCmIk/D5FWN6+yvpAYSmmZlxsR4b7mTJ8r/NmB7dKRIHeq8b

Hells yes. I use postifx and reject connections that fail SPF with a 500 error. For example..

"550 5.7.1 : Sender address rejected: Please see http://www.openspf.org/Why?id=dassergey%40tadka.com&ip=103.22.182.230&receiver=mail.server.com%20:%20Reason:%20mechanism"

I have found that most senders just forward the bounce message to their administrator who (you would hope) have the skills to rectify the problem.

I also use DKIM http://www.dkim.org/ and DMARC http://www.dmarc.org/. They're worth checking out too.

I've just recently seen email coming to me with a "DKIM-Signature"
"DomainKeys Identified Mail (DKIM) lets an organization take responsibility for a message that is in transit."
http://www.dkim.org/

While the e-mail came from across the pond, these go through Yahoo and seems to be a part of their system.
I haven't researched it any further than that.

I like these approaches though, it avoids using the Trusted Platform Module (TPM).
http://en.wikipedia.org/wiki/Trusted_Platform_Module

Only if it is implemented extremely poorly, which is unlikely. For instance, Domainkeys/DKIM has not been defeated yet (that I have noticed, anyway):

http://www.dkim.org/

(DKIM is a scheme for message signing, if a message contains an organization's signature, it is quite likely that the organization did handle the message)

hi

how do you tell the difference between messages that Facebook send out and messages that spammers send out ?

you can

They implemented DKIM http://www.dkim.org You Can !

paypal and ebay both do this and now facebook...

Please simply ask your admin to implement DKIM !

regards

John Jones

  http://www.johnjones.me.uk

A couple of smallish corrections:

The SSP specification is under active development in the IETF DKIM Working Group. There is a much newer version of the spec here, but the spec is still evolving.

The public key is looked up using the "s" (selector) and "d" (domain) attributes of the signature. "c" specifies the canonicalization algorithm (used to deal with trivial modifications such as spacing to the body).

But generally, very good points...

Here are the technical details on DKIM that you're looking for.

As for the scenario of a company wanting to censor MP3 attachments, they can do so already just by looking for the MIME attachments. They've been able to do that since day one. It has nothing to do with DKIM.

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.

Rather than track everyone in the world, you could just have a reputation system based on email addresses. Anyone can make up a brand-new email address at any time, but then it won't have an impressive reputation. The main barrier to this is that currently, the From: on an email is easily forged, so the notion of reputation does not work. Domain Keys and SPF attack exactly this problem -- enabling a durable notion of reputation for a domain. If we could get a few more people to implement those, it's going to make a huge difference. We're so close ... yet the default attitude seems to be to exclaim how hopeless it all is. Domain Keys Now! http://dkim.org/

Any spam solution that uses Comic Sans on its web site is no spam solution.

Maybe that should be added to the spam solutions form?

This has happened to me not once but twice, and I really was at a loss at what to do. Well, and angry and annoyed. The second time I decided enough was enough and set up DomainKeys and DKIM (both because DKIM hasn't quite caught on enough yet). Both of them are ways to sign your e-mail so the receiving server can be sure that it actually came from your domain. It's not yet a real solution because not enough people/sites use it or validate against it, but encouraging adoption is always a good thing.

Of course, signing mail isn't really enough to stop it, so you may have to turn off the "catch-all" feature of your mail just to avoid mail bounced to "xycjdfedf@mydomain.com"

>Unfortunately, SPF and DomainKeys (DKIM) are not the answer to verifying mail.

I see, so you think Domainkey and DKIM are the same thing... they are not...... DKIM has just been approved by the IETF, and will be an RFC. It is far superior to DK (domainkey), in that it gives domain assurance via 256 bit (default) encryption that authenticates the sending domain. Its features are far superior, even covering a mail timebomb which will only confirm assurance for a specific time frame. I have been running over 30 domains with DKIM for a long time now.

>Those few who have adopted these tools are in the minority, and as a result, it is impossible to rely upon these tools as definitive proof that a message is legitimate.

Of course it is in the minority, DKIM has just been passed... you will soon see Ebay, Earthlink, Google uses it now, and many major ISPS. They were all at the meeting in CA recently.

>Compounding this problem is the fact that there is NOTHING in place to stop spammers from setting up a SPF record or perhaps a DKIM record for their domain.

So what, there is nothing to stop you from setting up your DKIM policies to not lower the spam score, or to just ignore those domains you do not trust, treat them as spam, unless you say otherwise, you have that flexability... The policy statements are as you want them to be.....

I suggest you really find out what DKIM is...... it is not domainkey

http://www.dkim.org/index.html

and http://dkim.org/specs/draft-ietf-dkim-base-10.html

>Unfortunately, SPF and DomainKeys (DKIM) are not the answer to verifying mail.

I see, so you think Domainkey and DKIM are the same thing... they are not...... DKIM has just been approved by the IETF, and will be an RFC. It is far superior to DK (domainkey), in that it gives domain assurance via 256 bit (default) encryption that authenticates the sending domain. Its features are far superior, even covering a mail timebomb which will only confirm assurance for a specific time frame. I have been running over 30 domains with DKIM for a long time now.

>Those few who have adopted these tools are in the minority, and as a result, it is impossible to rely upon these tools as definitive proof that a message is legitimate.

Of course it is in the minority, DKIM has just been passed... you will soon see Ebay, Earthlink, Google uses it now, and many major ISPS. They were all at the meeting in CA recently.

>Compounding this problem is the fact that there is NOTHING in place to stop spammers from setting up a SPF record or perhaps a DKIM record for their domain.

So what, there is nothing to stop you from setting up your DKIM policies to not lower the spam score, or to just ignore those domains you do not trust, treat them as spam, unless you say otherwise, you have that flexability... The policy statements are as you want them to be.....

I suggest you really find out what DKIM is...... it is not domainkey

http://www.dkim.org/index.html

and http://dkim.org/specs/draft-ietf-dkim-base-10.html

It is time to rebuild the email protocol.

We may have to settle for working on a fix. The industry isn't going to replace such an entrenched protocol easily, even if that may be the best solution.

A large part of the problem is lack of a good, entrenched E-mail Authenication standard. The IETF's Domain Keys Identified Mail is working on fixing this, but that will take a while. DKIM is pretty much the standardization of Yahoo's DomainKeys protocol.

My guess, is that we will have to wait at least a year before DKIM comes out with any type of RFC document. At least some of the big players including Yahoo and Google will support this protocol right off the bat. Hence it should have a good chance at solving the current lack of any email authentication.

Of course we know the spammers will adapt as well...

There are certainly problems with DomainKey and DKIM but I cannot glean from what you wrote that you and I agree on what those problems are. If you do NOT modify the body or one of the protected headers, DKIM will pass validation no problem (I say this as someone who has his mail validated this way every day).

I will speak to DKIM since that is what the IETF is standardizing on, and that is the code you can get for free on SourceForge. DKIM's biggest advantage is that it does not care about how the mail gets to your mailbox, that there might be intervening MX forwarders or other mechanisms, that convolute the path, and that these may or may not participate in whatever path-based games SPF and Sender-ID presume. DKIM's biggest disadvantage is not for everyday mail, but primarily relating to mailing lists, where validation of the content becomes a problem, when it is altered. A DKIM header contains a header signature and a body hash. The body hash becomes invalid when you add stuff like mailing list info, or if you normalize the output in any way, which some systems do.

The answer to all of this is for those systems to take responsibility for the message and apply appropriate policies before forwarding. This means that a mailing list should, yes, check whatever reputation service and then make a decision as to whether or not the sender is to be trusted (assuming a valid and acceptable signature).

It also means that corporate mail servers should perform validation PRIOR to any monkeying of the headers or the body. Whatever fragility can thus be mitigated.

what a great idea! try http://www.dkim.org/ for more information
on the best bet for getting a deployable protocol out there for
authenticating email. It's currently going through IETF standarization,
but the -allman-01 draft is stable and has multiple interoperable implementations
including a sourceforge sendmail milter.

SSL is helpful for some protocols, but not others. PKI via X.509 is also hard to deploy, and more complicated, and requires distribution of root certs in clients. And the user interface issues
with SSL in todays browsers is a whole 'nother topic....

DNSSEC helps secure all DNS-based protocols, even those that couldn't adopt SSL/TLS.
DKIM (DomainKeys Identified Mail) is the lastest case in point, and if adopted will help drive DNSSEC deployment since it relies on DNS to help stop spam etc.

  http://dkim.org/