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(_dot_)Oxley(_at_)cox(_dot_)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" <barryleiba(_at_)computer(_dot_)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