> Original Text: > The tendency is to have the MUA highlight the address associated > with this signing identity in some way, in an attempt to show the user > the address from which the mail was sent. > Corrected Text: > The tendency is to have the MUA highlight the SDID, in an attempt > to show the user the identity that is claiming responsibility for the > message. > > > ### Limiting annotations to just the SDID can result in the source of > the message being ambiguous which will negatively impact security! > > Suggested correction: > > The intent is to have the MUA highlight the SDID, and AUID that match > with email-addresses within signed header fields. [...]
I agree with Doug's point here. The problem is that the more I think about it, the more I think it's a mistake for us to put MUA advice into the standards-track documents, and I'm inclined, rather, to want to remove what's there rather than to change it. I think the right approach, at this point, is to leave it as it is for now, and to 1. remove all the advice to client implementors when we do the 4871bis work, and 2. develop a separate, informational document, à la "deployment", for "considerations for email clients", which could discuss in more detail what clients might do with this information, perhaps as transmitted by the authentication-results header field. I'd stress that the "client considerations" document should aim to suggest *what* might be done, rather than *how* to do it, since we're not UI designers. Whether the working group should or would pick up such a document in its charter is an open question, but it can start as an individual draft. Doug, I encourage you, if you're interested, to pick up a co-author or two and work on something like that. If you do so, I suggest making sure that one of the co-authors actively works on client UI issues, to ensure that the advice has reasonable grounding in what clients might really do. Barry (chair) _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
