Russ: What do you, who will need to approve the charter, think about
this pass? Do you think it's reasonably solid, and takes into account
the major comments that've been made? Would you be comfortable with
a working group with this charter?
Everyone: Pretty much the same questions. Does this reflect what
most of us think? Does it adequately explain what we're trying to do,
and not trying to do? And do the milestones seem feasible?
I think this is an improvement and it is now in pretty good shape. Some
specific (and very minor) comments follow.
...
The Internet mail protocols and infrastructure allow mail sent from one
domain to purport to be from another. While there are sometimes legitimate
reasons for doing this, it has become a source of general confusion, as
well as a mechanism for fraud and for distribution of spam (and is, in this
context, called "spoofing").
The DKIM working group will produce standards-track specifications that
allow a domain to take responsibility for having a part in the transmission
Perhaps "taken part" would be better than "having a part"
of an email message, using digital signatures, and to publish "policy"
information about how it uses those signatures. Taken together, these will
allow receiving domains to detect (or rule out) spoofing in many
circumstances. The specifications will also contain summaries of the
threats, requirements and limitations that are associated with the specified
mechanism.
The specifications won't contain this material, will they? It will be in
a separate document. Perhaps change "specifications" to "documents produced".
While the techniques specified by this working group will not prevent fraud
or spam, they will provide a valuable tool for defense against them by
allowing receiving domains to detect spoofing of known domains. What to do
with that information is still left to the receiving domain, and this group
makes no attempt to define that, or to establish trust relationships, or
reputation of accreditation systems.
The signatures will use public-key cryptography and will be based on domain
Canonicalization and hashes are also important mechanisms we depend on.
Might want to mention them.
name identifiers. Keys will be stored in the responsible identity's DNS
hierarchy. The specifications will be based on the following Internet
Drafts:
One point Stephen felt needed to be mentioned in regard to mechanism was that
this will be a header-based mechanism. I don't insist on it personally, but
this is where it goes if we want to put it in.
The rest looks fine to me.
Ned
_______________________________________________
ietf-dkim mailing list
http://dkim.org