On Wednesday 28 November 2007 19:32, Jim Fenton wrote:
Jon Callas wrote:
The buck for the "administrative domain" of callas.org lies
ultimately with me. I run it. I have a number of users, who are all
members of my family. The way that I run the system, it's possible
for us to forge messages from each other. Now, the MTA will also put
in a header line that says who the authenticated sender is, but
that's in a "Received" line, and isn't going to be signed by DKIM.
My policy is that an authenticated user can "forge" senders. If that
policy turns out to be unwise, it's my problem. It is the intent of
DKIM that the administrative domain has the right to be stupid.
Nonetheless, a DKIM signature means that I accept responsibility for
a message I (meaning one of my authenticated users) put into the mail
stream.
I have avoided using the term "forge" because it is imprecise, and
here's an example of it. I don't think that authenticated users of
callas.org can forge each other's email, because Jon has authorized his
family to use any address in the domain. If it's authorized, it's not
forgery, is it?
If the definition of authorized includes not implemented technical measures to
prevent it, then sure. I expect that even within such a family domain there
is an expectation that this is not appropriate to do (that's certainly the
case here).
Nevertheless, there will be lots of domains, particularly bigger ones,
that don't authorize anyone in the domain to use any address in the
domain. Some of these will want to delegate keys to third parties, and
will need third parties with g= in their key records to use the
local-part on i=. It's entirely up to local domain policy whether they
want to use this feature, however.
Personally, I think this is a much lower risk case than shared servers that
serve multiple domains with disjoint user sets needing to worry about
cross-domain 'forgery'.
Scott K
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html