I would suggest its not the lack of instructions, but whose. The analogy is probably closer to when you (users) have multiple cars (MUAs), each with the own set of near similar but different instructions. Just consider the natural ergonomics of American vs Japanese cars, the electronic window button is different directions for opening/closing a window.
We can't control MUA designs. All we know is one thing - all mail systems, networks or just any electronic telecommunications use: From: To: Date: Subject: as the common defacto fields in storage and displays. Everything else is network related (Network Control Lines as we use to call them in Fidonet). In all cases, the From: is the recognized author of the message. Whether he actually wrote the message or not, he is the one "speaking" to you when you read the message. Not a 3rd party signer. So if the 3rd party signer wants to take responsibility for a message, well, it better be ready for everything that comes with it - including claims of fraud. -- HLS bill.ox...@cox.com wrote: > DKIM and ADSP are of benefit to edge email processing to assist in limiting > hopefully to legitimate messages to the message stores and client processing > systems. If a MUA was designed to highlight any processing of the legitimacy > of the email stream I would hope that the MUA would be checking to see that > these highlighted bits were the result of an actual process as opposed to an > injected piece of text. A DKIM aware MUA should be doing the same due > diligence of an edge device if we are going to advertise that this check has > been done. > > Maybe a poor analogy is a car that advertises that all passengers are > protected by seatbelts without instructions on how to fasten them > Thanks, > Bill > > > On 4/7/09 5:24 PM, "Barry Leiba" <barryle...@computer.org> wrote: > > >> 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 > > > _______________________________________________ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html > _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
