On 4/27/11 3:56 AM, Hector Santos wrote:
What is surreal about this brush back to make a SIMPLE change is that
it touches base with the often stated concern about DKIM DNS
management complexities as one of the barriers for adoption.
In a perfect DKIM spec world, this section should cover the expected
markets of DKIM operators to decrease the barriers:
o Creating Public/Private Keys
If your DKIM software does not offer public/private key
management, there are tools available to help:
- using OpenSSL
- using CAPI
o Publishing Public Key for brisbane._domainkey
- Using ISP managed DNS zones
- Using your *nix wienies DNS server zones
- Using your Windozes DNS Server zones
Instead, its only:
o Creating Public/Private Keys using OpenSSL
o Publishing Public Key for brisbane for *nix wienies
But the issue posting is not asking to get crazy with idealism. Only a
simple clarification is all that is needed.
-1. I suggest to add clarifications etc. to a future update of RFC5863
(deployment and operations document).
/rolf
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html