Introduction:

wcDKIM is a new Internet standard Message Signature system called DKIM (Domain Keys Identified Message) to help secure the authenticity and integrity of the mail sent by your system.

DKIM is simple in concept, but not very simple to the beginner to understand all its details. It can be complex and wcDKIM puts it all together to make it work out of the box to get you started in adding DKIM message signing support for your Wildcat! Mail System.

The wcWeb-based WCDKIM GUI Manager is used to setup wcDKIM for the first time and to manage your DKIM operation. Use the URL link /services/wcdkim to start the wcDKIM Manager.

The following offers a QUICK SUMMARY and a short explanation of DKIM-Signature parts:

Quick Summary:

In DKIM, there are two basic parts; Signing the mail by adding a special header DKIM-Signature: to it and Verifying the mail to see if anyone or anything has tampered or changed with your message before it arrived in the user's in-box.

The domain that signs the message before it leaves your system is called the SIGNER. When the signed message reaches the destination mail receiver, if it supports DKIM, it will attempt to verify and validate your signed messasge. This is called the VERIFIER.

The idea of DKIM Signer Trust:

The signer domain can be your own domain (1st party, self-signed) or a 3rd party signer domain (i.e. a Trusted vendor) signing your mail on your behalf.

What distinquishes between 1st party vs 3rd party is whether the DKIM signature signer domain and the From: author domain are the same or not. When they are the same, this is called a 1st party self-signed signature. When they are not the same, in the eyes of the verifiers, it a 3rd party signature.

In DKIM, the 1st or 3rd party signer is the domain everyone else (verifiers or users) needs to trust. If they don't trust the signer or simply the domain is unknown to them, then the valid DKIM signature has little worth to anyone. Since any one can send signed to you, include spammers, even if the DKIM signature is valid, if you don't trust the signer or know them, the message value is not known to you.

The idea of DKIM Author Policies:

wcDKIM supports advanced DKIM methods called ADSP (Author Domain Signing Practices) which allows domains to tell the world what to expect about the signed mail and when it fails, do something about it.

ADSP allows a 1st party domain to declare to the world

"Only my domain signs my mail and no one else! I don't allow any 3rd party signer so if you see a 3rd party signer, its not my mail. I authorize you to delete and discard this message. Passing it on to the recipient is your call, but we are not responsible for this invalid message you received."

All that is said in an one word ADSP public policy statement: DISCARDABLE

ADSP offers another one word policy called ALL, which is more relaxed and offers a way to allow other 3rd party signers, but it is basically a "My mail is always sign" idea. So if the signature is missing or broken, this can also allow verifiers to take some action as well.

ADSP is still new and expected to get more support in the future as DKIM grow.

Keep in mind, even domains with valid ADSP policies can't be trusted unless the receivers trust the signer domain. But the true value of using ADSP is not when signatures are valid but when a declared public ADSP policy is voilated and its not what you expected, i.e. missing signature, broken signature, not the 1st party or not an authorized 3rd party signer. This can help protect spoofers and unauthorized signers.

About the DKIM-Signature:

A DKIM signature is a special Message header named "DKIM-Signature:" and when a message contains this special header, we called this a DKIM signed Message which basically means the message contains one or more of this "DKIM-Signature:" header. It looks like this within a typical DKIM signed message with the basic internet headers but we show only From: since it is an important concept in understanding how wcDKIM works:

DKIM-Signature: v=1; d=winserver.com; s=tms1; a=rsa-sha1;
	c=simple/relaxed; t=1313035034; h=Message-ID:Date:From:To:Subject;
	bh=wALN7eIg0IjuKpmaUTXpp5XKBNM=; b=Or42Iv01umAzCYzkemvb
	1kW1Fbw6MEFs6WGOPtC7XZxUiU5oB2zFlBBflz//lUziQBmqOCECM3Boir1kUzLl
	9q5mdaLOh3ClIvbpANLc8dyZLv4wxCG9zRWltVX9zHrPq/fFv90TozdGeT0GpNhn
	Rhi5/AYAroO29K+64llGVXU=
From: Bill Smith 

When we display the DKIM-Signature header more cleanly line by line by tag= value, it will help to begin the process of understanding it:

DKIM-Signature:
   v=1;                                      <-- VERSION
   d=winserver.com;                          <-- SIGNER DOMAIN
   s=tms1;                                   <-- SELECTOR
   a=rsa-sha1;                               <-- HASH METHOD
   c=simple/relaxed;                         <-- C14N METHOD
   t=1313035034;                             <-- TIMESTAMP
   h=Message-ID:Date:From:To:Subject;        <-- SIGNED HEADERS
   bh=wALN7eIg0IjuKpmaUTXpp5XKBNM=;          <-- BODY HASH
   b=Or42Iv01......9K+64llGVXU=              <-- SIGNATURE
From: Bill Smith 

The most important tags are; d=, s=, h=, bh= and b=.

It is important to understand that DKIM-Signature or any parts of it, including any header like From: and the headers listed in the h= tag can not be altered without invalidating the signature.

The basic idea is that DKIM hashes the Message Body and all or some of the Messages Headers the using the hash method defined by the a= tag to creates those ulgy looking body hash (bh=) and signature hash (b=) tags.

These are the hashes that must be reproducible by the remote DKIM verifier. If the verifier can not reproduce it, then something is different about the message and the DKIM verification fails. The signature is broken and invalid.

The v= tag defines the DKIM standard version. It is currently 1 today. It may not be present and its assumed to be 1.

The a= tag describes the hash method used to create the bh= and b= tags. rsa-sha1 and rsa-sha256 are available with sha256 being the higher strength.

The c= tag describes the canonicalization (C14N) methods used to first clean up the body and header before it is hashed. Simple means to do nothing, Relaxed means to remove any extra spaces, tabs and end of line characters.

The t= tag describes the time stamp (secs sincs 1970) when the message was signed.

The h= tag describes which of the message headers will be hashed. These headers are the ones that protected by the signature and can not be changed. DKIM does not check header that are not listed in the h= tag. The From: is required to be always protected and hashed. If the from: is missing in h=, the DKIM signature is bad and invalid.

The bh= tag is the hash of the actual message body and its generally the first thing checked because of the body has been altered, the body hash is invalid and the entire signature is bad. The body hash must first be valid before the signature itself can be valid.

The b= is the Digital Signature encryption haash of the entire DKIM-Signature header (before b= is added) encrypted with the private key belonging to the signer of the message.

The private key is secured and stored locally on your system and its paired with a PUBLIC KEY that is used by verifiers to check the signature.

So the verifier needs to retrieve this public key by doing a DNS QUERY using the d= tag called the signer domain and the s= tag called the selector sub-domain.