ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Re: Role of Sender header as signing domain

2006-12-07 01:55:38
Since my name has been referenced I am compelled to
resond.

I am confused.

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."

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."

For an e-mail application service provider, (ESP), one way
to do this is for that entity to sign the RFC 2822 sender
header.

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.

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?

If so, then in it seems we are moving in the wrong
direction. The approach is not backward compatible. It will
prejudice the ability of certain entities to follow best
practice. It appears to undermine the mission statement
quoted above.

On this basis only, I add my vote in favor of this petition.

That being said, if my understanding is wrong, such that
under DKIM base an entity associated with an email during
its transit across the Internet can properly sign the RFC
2822 sender header and so publish a sender signing policy
under DKIM SSP (whether based on any proposed standard or
draft proposal which comes out of this working group), I
will pass and go back to lurking.

John

P.S. DKIM allows for tying of reputation to the accountable
party that is an associated identity. In the case of ESPs,
receiving networks look to the sending network.  When the
ESP signs for the domain in the RFC 2822 sender header,
this allows for reputation assignment to the accountable
party. This is appropriate. It deprecates the practice of
the ESP attempting to "slip" responsibility down to
clients. It promotes what is understood as the best
approach to control abuse. However, a client with a strong
brand may insist that it is allowed to hold itself out as
the identity associated with that email and so
accountable, especially where the phishing threat is
overarching. DKIM is sufficiently flexible to allow for
these situations while supporting best ESP practice in
that the receiving network looks to the
sending network and the ESP does not hide behind
the client.

Please accept my apologies if none of this is relevant to
the present discussion.

John Glube
BigHip - Abuse / Compliance
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html