[ietf-dkim] Re: Role of Sender header as signing domain
dotis at mail-abuse.org
Thu Dec 7 10:28:37 PST 2006
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:
> I quote from the mission statement found at
> 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.
More information about the ietf-dkim