[ietf-dkim] Re: Role of Sender header as signing domain
hsantos at santronics.com
Thu Dec 7 01:29:34 PST 2006
John Glube wrote:
> For an e-mail application service provider, (ESP), one way
> to do this is for that entity to sign the RFC 2822 sender
> 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,
No. Sender SHOULD be signed if that is what makes the authentication of
the message stronger. But I think the "confusion" is......
> 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 the ESP here is a THIRD PARTY SIGNER!
The critical issue, debate, 'dividing line' whatever you want to call it
is the "AUTHORIZATION" of the signing.
In other words, I own the domain, just because you may be hosting my
mail, doesn't really mean you have the authority to sign on my behalf.
Remember, the specs does say the signer is now accountable. So you have
to consider the idea that the ESP/ISP may not want to get involved and
in the TRADITIONAL is to not get involved in the passthru nature of
mail. Thats been the best practice and what most systems work with on
But probably in the name of "business", allowing unauthorize and
unrestricted 3rd party signing, then this basically says ANYONE can sign
my mail and effectively make my mail appear to end-users that my mail is
"OK" just because it has some confusing "GOOD DKIM MAIL" SEAL on it.
It opens the door to exploitation to allow just anyone to sign on your
behalf, and that may include a domain that doesn't even use the domain
for sending mail! Something today, we have little control of unless you
are using something like SPF or some other technical to determine its a
valid EMAIL domain in play.
IMV, the "technology" that has not been completely worked out is how
does a DOMAIN authorized 3rd party signers. Thats the missing piece in
all this and its the heart of most of the pros and cons debates.
IMV, there are 4 general types of DKIM messages:
By far, the strongest protection, and in my view, the highest benefit
DKIM/SSP has to offer to the world is the exclusive signing policies.
This is where the high value domains will see the greatest benefit.
OPTIONAL gives domains to integrate DKIM/SSP into different email
routes. 3rd PARTY can play a role in original signing or as second
hand signings in order to maintain the "DKIM integrity" of possibly
altered mail, and then you have NONE where NO DKIM is expected at all
which will include the legacy market.
The missing piece, in my view, is how the 3rd party is involved in an
authorized and expected manner. Once that part is worked out, IMV, we
are pretty much done. Exclusive is easy and required for DKIM to have
basic VALUE to offer the world. Unfortunately, IMV, the SSP cons are
not making it easy to allow that to happen.
More information about the ietf-dkim