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 *(_at_)altn(_dot_)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
_______________________________________________
dkim-ops mailing list
dkim-ops(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/dkim-ops