Mike said
*************
For larger business and maybe ISP's even, our anecdotal experience at
Cisco is that our messaging and DNS folks don't have mich to do with one
another (changing mx records is not a ordinary event). Thus to achieve
key rollover, you'd need to create linkages between the groups and their
software that didn't exist before.
***********
Which is our situation, so I sidle over to the DNS folks to get a swag
and right after
"WHY THE H*** ARE YOU DOING THIS IN DNS? DO IT AT THE MTA FER XXXXXSAKE"
The answer was quarterly is the minimum time they would be willing to
change keys
.
Thanks,
Bill Oxley
Messaging Engineer
Cox Communications, Inc.
Alpharetta GA
404-847-6397
bill(_dot_)oxley(_at_)cox(_dot_)com
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Michael Thomas
Sent: Friday, April 14, 2006 2:22 PM
To: dcrocker(_at_)bbiw(_dot_)net
Cc: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] x= lets senders expire responsibility
Dave Crocker wrote:
Bill(_dot_)Oxley(_at_)cox(_dot_)com wrote:
I suspect in the real sysadmin world changing keys every week
probably
isn't going to happen :-)
Given the intended use of DKIM and given the current state of DNS
administrative tools, what do folks think *is* a realistic expectation
(and recommendation) for the lifespan of a key, for a typical email
operation?
In other words, given the pragmatics, how often is reasonable an
appropriate for changing keys?
I don't want to put words into Arvel's mouth, but my read of his users
experience
is that you struggle to get the keys into the DNS once and hope that you
never have
to struggle with it again. I think his base is mostly small/medium
business.
For larger business and maybe ISP's even, our anecdotal experience at
Cisco is
that our messaging and DNS folks don't have mich to do with one another
(changing
mx records is not a ordinary event). Thus to achieve key rollover, you'd
need
to create linkages between the groups and their software that didn't
exist before.
Which is to say, a very slow process for the motivated, and a
non-process for
the unmotivated. Maybe SPF has helped here, but I doubt it.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html