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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html