[dkim-ops] DKIM seems complicated

[Arvel Hathcock]

Hi Jerry!

> First of all, I'm not clear on the timing between the time
> the DNS server is updated and the time the message
> signing begins.

I'm not a DNS expert but I do know that it takes a while here at Alt-N for 
our DNS changes to propogate.  The length of time is usually on the order of 
an hour or two (this is what I'm told by my IT guys but in practice the time 
taken has been much less).

> If I first update the DNS records, will enabled receiving
> servers immediately begin expecting my messages to be
> signed?

If you assert a policy of "I sign all mail" then DKIM enabled receivers will 
expect all mail to be signed once that policy has propogated to DNS (which 
isn't instant I'm told).

> Or, if I begin by signing messages, will enabled receiving
> servers fail the messages if it doesn't find the matching
> DNS entry?

If the DKIM verifier can't acquire your DNS records then the message is 
treated essentially as if it wasn't signed to begin with.  It is possible 
however that the inability to acquire DNS data might result in a temporary 
refusal of your message by DKIM-enabled SMTP servers (this is the way 
MDaemon is supposed to work but I introduced a bug recently that I have to 
fix).

I would create the DNS records first using the "I sign some mail" policy. 
Once you do, write me back and I'll test and see if your records are 
accessible.  After that, you can start signing.

I would setup one MDaemon 8.11 server as the Internet facing inbound mail 
handler.  This MDaemon will be configured to verify all SPF, DK, and DKIM 
data.  My GUI there isn't the best but you can do just about anything you 
want with the results of these tests (except feed back into a reputation 
system but this will be the next thing).  Then, setup another MDaemon 8.11 
on the Internet facing outbound mail handler.  This one will do all the 
signing.  The GUI here isn't the best either but you can create RSA keys and 
a dns_readme.txt file will tell you what to put in DNS for both DK and DKIM. 
Messages need to be sent to MDaemon using SMTP AUTH to be considered 
eligible for signing.  Also, you can specify what must be present in a 
messages FROM or TO header to be considered eligible for signing.  So, for 
example, here at altn.com I have:  "from *@altn.com" as eligibility 
requirements for signing.  If you run multiple domains you will need to put 
multiple "from *@<domain.com>" entries into MDaemon's configuration to get 
those messages signed.  You can specify a different selector (RSA Key) for 
each entry allowing you to use different keys for any criteria (the most 
obvious being a different key per signing domain).

> If, later, the key is changed, DNS propagation can take
> several days. How do I avoid having conflicts with message
> signatures and DNS records?

Don't revoke existing selectors for at least 7 days.  That's the 
recommendation currently.  So, if you change a key, leave the old key in DNS 
and make a totally new selector.  Start signing with the new selector but 
leave the old one in DNS for 7 days.

> What might be the best method for me to go about keeping DNS current?

This is the current topic of much debate.  There's no easy way to do it.  I 
have to do it by hand and most of my customers are in the same boat as 
yourself - DNS is managed by an ISP or third-party.  You have to ask them to 
do it if they don't provide you with any tools to manage it yourself.

> Should I use the same key for both mail1 and mail2,
> or doesn't it matter?

The same key will work but I recommend to our customers to use a separate 
key per domain.  This just seems safer to me.

> I can't even be sure that the other domain admins will
> even be interested in DKIM. If I start signing messages,
> will the other domains be effected?

WIth Mdaemon you can specify the criteria for which messages will be signed 
and what selector will be used.  If other domains don't want to sign, then 
just don't include them in the configuration for signing.

> Can anyone point me to some documents that might help
> make this all more  clear?

We have some stuff which is MDaemon specific at 
http://www.altn.com/support/white_papers.asp/product_id/MDaemon but I'm not 
sure how helpful it will be.

-- 
Arvel