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

[Hector Santos]

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
> 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, 

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 
that basis.

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:

     EXCLUSIVE
     OPTIONAL
     3RD PARTY
     NONE

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.

---
HLS