With the output of DKIM being the SDID, the identity associated with the
signature is of course that of the domain. But when my author-specific
domain signs a message for me, it's the domain that does that -- it
doesn't matter that it's an organization of one. Putting "author" here
just hints that authors might sign messages as well, and I don't think
that's intended. I suggest removing "author" to make that clear.
The author can be an organization. For mail from ESPs, I'd say that
the author is almost always an organization. Please leave the
language alone.
DKIM supports that mode of operation quite nicely and it is a
particularly powerful operational mode, so it is worth keeping that
"configuration" in mind explicitly. Given how persistent this
confusion seems to be it might even be worth more language, though I'm
not coming up with a suggestion, offhand.
This still seems to me to be too specialized a use case to list in the
specification, but would look to WG consensus on which way to go here.
I can easily see applications in universities, where the central IT
group often has only a tenuous hold over the departments who jealously
guard their autonomy, often well past any point of rationality. A
department wouldn't dream of sending their mail through the servers
run by those bureaucratic morons in central IT, but would be OK with
a remote signer where the mail stays on their computers.
The point is that the choice of i= had determined whether something
ought to be flagged to the recipient. Now it doesn't. That is a
behavioral change that is potentially incompatible with the RFC 4871
behavior.
"Flagged to the recipient" is UI design advice, which I think we've
agreed we're not doing.
"The Signer MAY choose to use the same namespace for its AUIDs as
its users' email addresses or MAY choose other means of representing
its users. However, the signer SHOULD use the same AUID for each
message intended to be evaluated as being within the same sphere of
responsibility, if it wishes to offer receivers the option of using
the AUID as a stable identifier that is finer grained than the SDID."
I suggest that the first sentence change MAY to "might" in order to
make it non-normative.
I really don't think changing MAY to "might" here is going to make
things any clearer for implementers. Much the opposite.
Agree. Let's leave it alone.
(radical idea alert)
The point is that if the AUID does not affect the result of the
verification at all, why even have it?
In my case, it's a comment that helps me figure out what happened when
someone sends back a message with a complaint. I would be quite happy
to change i= to be a private comment for the benefit of the signer and
remove any syntactic restrictions on it.
R's,
John
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html