ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Update of RFC4871 Appendix D. MUA Considerations (resent)

2009-04-08 13:03:32
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