On Aug 24, 2006, at 5:39 PM, Jim Fenton wrote:
In addition to other objections I have, if it is not significantly
simpler I question the need for an additional mechanism, especially
in a security context such as this.
For any 2822.From address signed with DKIM to be trusted, the
2822.From address MUST be restricted to accounts where the 2822.From
being signed is known valid and marked as such using the i= syntax.
This mechanism MUST exist whether or not any 2822.From policy is
asserted about this domain.
Assume that a large ISP finds that validating _all_ 2822.From
addresses for a specific d= signing domain generates revenue as a
premium service, AND this also reduces support costs related to abuse
issues. In addition, this domain can be certified as only signing
validated addresses. This certification increases the acceptance
rate of messages signed by this domain and increases the value of
their service. None of these benefits are dependent upon anyone
designating this domain in their policy. Such designation will add
to their stature however and can be monitored. : )
A customer of this service can then independently designate this
domain in their email-address domain. This designation process does
not require the exchange of any keys, key locations, or any special
handling of their messages. Just a simple domain name is entered in
the DNS they control. Recipients can then identify which trusted
2822.From address are valid when signed by this domain and are
designated, without the need of the i= syntax.
The extra effort required would be validating that the holder of the
account is also the recipient of the address being used. That effort
is not much more than what is needed to assure the 2822.From address
in the first place. The prerequisite for DKIM security is knowing
who and what to trust. Being able to convey with DKIM what should be
trusted is vital for retaining trust and security.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
