>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
