i.e. is it ever reasonable for the From address to be a "role"
address and the actual signature be by an individual? and if it is,
is the signature meaningful? would it be meaningful if you had an
established relationship with that person and knew that was his email
address? what if you didn't?
would it make more sense to say that the "role" address should sign
the message? what about when different people are authorized to fill
a role? wouldn't you want to know specifically who signed it?
would it make sense to forbid "role" addresses in From fields? OTOH,
they're useful.
I dunno, here I guess I'm willing to believe that carbon based units can
sort this sort of thing out. Going too far into local part semantics seems
if nothing else to pull us way away from the goal of having something
easily deployable.
Well, personally I don't see why we should stop the key/authority
delegation at the @ sign. If the owner of a domain wants to specify a
pointer to a service that looks up keys for individual addresses I
don't see how this is less trustworthy than higher level domains' NS
records pointing to keys (or other NS records) for their subdomains.
More to the point, however, is that at a certain point we do expect
"carbon based units" to be able to sort these things out. In
particular we expect carbon based units to know about the bindings
between certain names and the entities they represent, and the
relationships between those entities. And that's part of the calculus
in helping a recipient decide what is valid. There's a limit to how
much we can trust an upstream verifier to delete messages on
recipients' behalf, especially without instructions from the recipient.
Keith
_______________________________________________
ietf-dkim mailing list
http://dkim.org