On Wed, 30 Aug 2006, Wietse Venema wrote:
william(at)elan.net:
On Wed, 30 Aug 2006, Dave Crocker wrote:
John Levine wrote:
If I understand your position, you are positing that someone will pay
between $20 and $50/mo for Internet access, probably some extra amount
per month for a DKIM-capable mail service, but they use a crummy DNS
service where they don't know how to put in NS records,
And... Even if this scenario is correct, it does not warrant adding an
entire layer of security mechanism into DKIM.
Not "into" - on-top of or as supplement. And for specific type of
email identity security protection.
This would be a required component for all DKIM signature verifiers,
because there is no point building verifiers that can't verify all
valid signatures.
A policy described in separate record and use of which is described
in separate document RFC is a required component for those who only
want to do base verifier? Who said that?
Chairs - please step up! Please clarify for everyone what the
relation between documents and requirement for implementers would be.
Let's not re-invent the wheel. DNS already provides delegation of
leaf nodes (CNAME) and interior nodes (NS). It already works. People
who are unhappy with their DNS service can vote with their wallet.
People who want to do CNAME and NS delegation to allow somebody to
sign with their domain in 'd' are all still be free to do so.
But let me repeat what I said before - not everyone can or would
want do that noth only because of how their dns is hosted but simply
because it requires coordination between them and signing system.
Added to that not everyone wants outside signing system (i.e. 3rd
party) putting signature without taking some responsibility for email
that is more like it is really coming from them (i.e. mail lists).
So you loose nothing but gain number of additional uses and making
it easier for more domains to claim they have all their emails signed.
---
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html