On Mar 27, 2006, at 5:37 PM, Jim Fenton wrote:
Mike Wolf wrote:
While on the topic of "o=", how about allowing a list of approved
third party signers to be included, rather than just declaring
that either no third party signing is allowed or everyone and
their mother can sign on your behalf?
This seems like an obvious improvement that could be backwards-
compatible with the current draft and would allow senders to
explicitly enumerate those third parties that are allowed to sign
on their behalf.
If I am missing some other way to do this or there is some reason
why this makes no sense, just explain it to me.
One concern is that this doesn't scale. I have heard one large
financial institution say that they have over 100 external senders
of email.
The email-address domain would be listing signing-domains. A large
institution should be able to delegate keys that extend to any number
of external services. For the average domain owner, the scale of a
domain list will easily meet their needs. Such a list already
exceeds the capabilities of other types of email-registrations.
Another concern is privacy; does a large corporation really want to
enumerate a list of its mailing partners? It also makes the
messages sent by the external party less "seamless" (it looks more
like an external sender) and muddies the question of who is really
responsible for the message, the originating domain or the party
sending messages on their behalf.
There is key delegation to hide who is doing the sending. The
signing-domain is _always_ accountable. An association with a From
email-address may change handling, as there would be less likelihood
of the message being replayed.
The preferred way to do this is to publish a key record (selector)
for the external sender of email. The external sender signs
messages just as if they were their client, and the client retains
control of the relationship by being able to revoke a key record at
any time.
This type of intimate relationship is expensive for the average
user. The goal should be to ensure proper message handling does not
require owning servers or needing special services.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html