On Dec 7, 2006, at 12:56 PM, Damon wrote:
In this case, wouldn't it be better to say:
DKIM separates the question of the identity of the signer of the
message from the purported author of the message. In particular, a
signature includes the identity of the signer which can be traced
to a specific author or first party signer. Verifiers can use the
signing information to decide how they want to process the message
based on the reputation of the author. The signing identity is
included as part of the signature header field.
Some wish to view protections afford by DKIM are prohibitions of
specific uses of an email-address. Some view DNS delegation, sharing
private-keys, or CNAMEs a means to establish simple mandates-
The From MUST be signed by a "parent" domain. (Often worded as "All
signed.")
While seeming like a simple mandate, it fails to handle replayed
messages as the recipients of the message is not constrained. In
addition, the "author" can not be held accountable for the sending
unsolicited messages. Few will assess reputation based upon content,
which brings in issues of censorship and privacy. White-listing can
be abused. So just how can the reputation of the "author" be
applied, even assuming it can be established?
Millions of new domains are created every day. This affords bad
actors (who might not be charged for this service) greater freedom
than a good actors who must wait 48 hours for their NS record
updates. It is hard to imagine there is much value tracking negative
domain reputations of such a disposable commodity.
The positive reputations of DAC appears to represent a reasonable
approach for staying ahead of the registration mayhem.
Unfortunately, the signing-domain not be related to the SMTP client,
so there is no means to safely use the DKIM signature as a basis for
acceptance. The term "trace" is misleading. The term associate
would be better.
What needs to be associated to protect white-listing the signing-
domain are all the identities of the email-originating-elements.
These include the:
1) From
2) Sender
3) Resent-From
4) Resent-Sender
5) MailFrom
6) SMTP Client
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
