On Dec 7, 2006, at 12:46 AM, John Glube wrote:
DKIM is not path based. It is a lightweight cryptographic method
for "validating an identity that is associated with a message,
during the time it is transferred over the Internet. That identity
then can be held accountable for the message."
DKIM does not encompass the envelope. While it might be possible to
hold signers accountable for content, this MUST exclude unsolicited
message status. This eliminates DKIM for white-listing or block-
listing, because either is easily abused. While DKIM is not path
based, white-listing MUST be protected from replay abuse. Before a
message obtains a "white-listed" status, a prerequisite should
include associating SMTP clients with the signing-domain. The same
strategy protects MailFrom, "third-party" signing, and establishes
policy for all other headers.
For illustrative examples see:
http://tools.ietf.org/wg/dkim/draft-otis-dkim-dosp-02.txt
I quote from the mission statement found at
http://www.dkim.org/
This means to me that the entity responsible for injecting the
email into the Internet can say, "Yes, I am an identity that is
associated with that email and can be held accountable."
It would be nice to think a DKIM signature is indicative of the
entity transmitting the message. If so, DKIM would then help in
resolving abuse issues. Alas, an expectation that providers use
their customer's private keys removes this feature. : (
For an e-mail application service provider, (ESP), one way to do
this is for that entity to sign the RFC 2822 sender header.
Fully agree. : )
By doing so, the ESP says "I, ESP am the entity sending this email
on behalf of my client, List (identified in the RFC 2822 from
header) and as such an identity that is associated with that email
and can be held accountable."
This approach is consistent with best practice and is specifically
allowed for in DK.
It could also be allowed in DKIM when protection is obtained by
annotation of email-addresses associated with the signing-domain.
With millions of new domains created at no cost for bad actors each
day, marking message "known" (through non-visual comparison) allows
DKIM to prevent spoofing. DKIM can not prevent abuse, although not
being on a "white-list" might limit the volume. Many of the larger
domains are often block-listed due to acts of a few. While these
domains are also easy targets of replay abuse, safe "white-listing"
of these domains remains possible only when the SMTP client can be
associated with the signing-domain.
Am I now to understand that no, you may only sign the RFC 2822 from
header and nothing else, if you want to: (i) publish a sender
signing policy; or (ii) take advantage of any reputation proposals
such as the Domain Assurance Council, which although out of scope,
is one of the perceived benefits of DKIM?
Without a means to associate a signing-domain with other email-
originating-identities, yes! Some suggest abuse can be blocked after
"everyone" publishes highly restrictive policies that "break" email,
AND after everyone searches the domain label tree for rare highly
restrictive policy statements. Of course this overlooks a sizable
problem of visual recognition and perhaps why UTF-8 remains ignored.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
