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

From: Doug Otis <[email-masked]>
Date: Tue, 7 Apr 2009 09:17:07 -0700

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.  The annotation  
should help clarify for the user the SDID claiming responsibility for  
the message, as well as possibly specific intra-SDID sources.  AUIDs  
that match with signed email-addresses can disambiguate messages  
emanated by a mailing-list from those emanated directly by individual  
users, for example.

-Doug

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Barry Leiba <[email-masked]>
Date: Tue, 7 Apr 2009 17:24:32 -0400

> 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)

---

From: John Levine <[email-masked]>
Date: 7 Apr 2009 21:57:18 -0000

>to remove what's there rather than to change it.

I couldn't agree more.

Honestly, it's hard to think of a group worse qualified to offer MUA
advice than we are.  As far as I know, none of us has any particular
expertise or experience UI design, and I suspect that we use a totally
arcane and atypical set of MUAs.  How many of us use an MUA that shows
the From: comment in preference to the address, after all?  Probably
the majority of e-mail users do.

I don't know much about UI design, but I do know that there's a lot of
superficially plausible ideas that turn out to be really bad, with the
most obvious being to pop up a warning every time there's a suspicious
message.  All that'll do is repeat Microsoft's mistake and train users
to hit OK every time since most of them would be false alarms.

We have plenty to do within our range of expertise, so please let's
avoid wasting time outside it.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Tue, 7 Apr 2009 15:09:29 -0700

> avoid wasting time outside it.

Agreed. Drop the MUA section then.

-Doug

---

From: Jeff Macdonald <[email-masked]>
Date: Wed, 8 Apr 2009 09:46:45 -0400

>to remove what's there rather than to change it.

+1

-- 
Jeff Macdonald
[email-masked]

---

From: "Siegel, Ellen" <[email-masked]>
Date: Wed, 8 Apr 2009 10:42:19 -0400

+1

---

From: <[email-masked]>
Date: Wed, 8 Apr 2009 08:58:27 -0400

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

Barry (chair)

---

From: Hector <[email-masked]>
Date: Thu, 09 Apr 2009 08:24:12 -0400

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

---

From: "J.D. Falk" <[email-masked]>
Date: Thu, 09 Apr 2009 11:16:17 -0600

+1

I don't completely agree with John, though -- I think this group /could/ 
come up with a fairly sane set of recommendations for MUA developers who 
want to display information based on DKIM results, so long as we're careful 
to confine it to what the results mean to end recipients and not get into 
whether the buttons should be painted periwinkle or mauve -- but if we do, 
it has to be a separate informational document.

-- 
J.D. Falk
Return Path Inc
http://www.returnpath.net/
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Hector Santos <[email-masked]>
Date: Thu, 09 Apr 2009 14:23:32 -0400

> it has to be a separate informational document.

We have 4-5 MUAs under our belt from console, native gui, web gui, 
pop, imap, etc.  All in all, you generally have three types:

    - Online MUAs
    - Offline MUAs
    - Hybrid MUAs

If the backend does not support DKIM, you can have two considerations:

     - Passthru of RFC formats
     - Gateways, transformations.

If the backend does support DKIM, for us, this can/will change or add 
new considerations.

     - Passthru of RFC formats + status DKIM header
     - Gateways with DKIM status headers NO DKIM SIGNATURES

What the MUA will need #1 is to determine if DKIM was or was not 
evaluated.

If its hasn't been evaluated, then the MUA is open do to whatever it 
wants, the HOST is ignorant about DKIM.

If its been evaluated by the HOST, it depends on the type of MUA.

With online and possibly hybrids, the server can control the display 
presentation.

For Offline, like the RFC based mail readers, need a header that is 
associated with the mail pickup host only - the DKIM status header. 
Can the Authorization-Result header make due?

-- 
Sincerely

Hector Santos
http://www.santronics.com

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 9 Apr 2009 10:58:50 -0700 (PDT)

> it has to be a separate informational document.

+1 to JD's view (remove it from ADSP, but don't rule that we're not 
competent to make informational recommendations).
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 09 Apr 2009 14:33:00 -0400

> it has to be a separate informational document.

1. There is a difference between explaining what results "mean" in terms of 
information, versus what they mean to end users.  The latter would have to do 
with human perception, psychology, blah blah blah.  We can do the former -- and 
I think that could be useful.  As a group, the latter is what we should avoid.

2. Unless folks strongly object, I propose *not* changing the Errata/Update text 
about MUA, since the goal of the Update is to focus on other issues.  Rather, I 
suggest we defer this more substantive issue with the MUA-related text to the 
RFC4871bis effort.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: [email-masked] (Wietse Venema)
Date: Thu, 9 Apr 2009 14:45:00 -0400 (EDT)

+1

I agree with Doug/Ellen, and with JD except that our explanations
should target MUA developers, not recipients.

	Wietse

---

From: Doug Otis <[email-masked]>
Date: Thu, 9 Apr 2009 16:55:10 -0700

On Apr 9, 2009, at 11:33 AM, Dave CROCKER wrote:

> 2. Unless folks strongly object, I propose *not* changing the Errata/ 
> Update text about MUA, since the goal of the Update is to focus on  
> other issues.  Rather, I suggest we defer this more substantive  
> issue with the MUA-related text to the RFC4871bis effort.

This MUA consideration changes the role intended for the i= value.   
Either include a statement about the i= value's possible role, or  
remove the MUA considerations for later.  As currently stated, this  
information is incorrect.  This might expose recipients to intra- 
domain exploits when adopted as suggested.  A simple example of  
possible confusion would be when the same domain hosts a mailing-list.

-Doug

---

From: Barry Leiba <[email-masked]>
Date: Fri, 10 Apr 2009 08:58:55 -0400

> suggest we defer this more substantive issue with the MUA-related text to the

As chair, I note that any attempt to use the "errata" format of the
update document to *remove* text will be fraught.  The text will still
exist (and will, in fact, be repeated in this document).

As a participant, my inclination would be to have the update replace
the whole Appendix D like this:

 Original text:
   [Appendix D, in its entirety.]

 Corrected text:
   When a DKIM signature is verified, the processing system sometimes
   makes the result available to the recipient user's MUA.  How to
   present this information to the user in a way that helps them is a
   matter of continuing human factors usability research.  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 confirmed
   address from which the mail was sent.

   Specific advice on how to accomplish that is beyond the scope of
   this document.

But I could also accept leaving Appendix D as it is for now, and
dealing with it in the 4871bis effort.

Barry Two-Hat

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 10 Apr 2009 09:34:44 -0400

Folks,

> the whole Appendix D like this:
...
> dealing with it in the 4871bis effort.

I'd like to strongly encourage the working group to defer this change until the 
-bis work.

First, there isn't any urgency, since we do not know of any immediate -- 
nevermind serious -- problems being caused by the current text.

Second, we are about to enter a -bis phase and so we have an opportunity to 
review this issue with more deliberation.

On the average, I believe a working group should take time to reflect on 
conceptual changes.  And even simply removing -- nevermind modifying -- all text 
related to a concept such as MUA handling tends to benefit from the time that 
can be taken to iterate on the text and reflect on versions.  Precipitous 
changes -- anything done quickly and in one pass -- invites poor understanding.

I say this in spite of being vigorously in favor of a basic change to this part 
of the spec.  I just think that this phase isn't the right way to get it done.

And gosh, we have such a convenient way coming up immediately...

d/

ps.  this shouldn't need saying, but sensitivities get high:  obviously whatever 
the chairs rule as wg consensus is what goes into the doc.
-- 

   Dave Crocker

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 10 Apr 2009 15:14:21 +0100

> I'd like to strongly encourage the working group to defer this change until the 

Yep. With my chair hat on, I think such a change would be very
like starting in on the bis work (which we've yet to scope) and
we didn't include it in the consensus call. So I believe this is
one for later.

Stephen.

---

From: Doug Otis <[email-masked]>
Date: Fri, 10 Apr 2009 10:53:51 -0700

On Apr 10, 2009, at 6:34 AM, Dave CROCKER wrote:

>> update document to *remove* text will be fraught.  The text will  
>> still exist (and will, in fact, be repeated in this document).
>>
>> As a participant, my inclination would be to have the update  
>> replace the whole Appendix D like this:
> ...
> I'd like to strongly encourage the working group to defer this  
> change until the -bis work.

Agreed.

It appears the definition in RFC 4871 Section 1.1 for the term Signing  
Identity will remain, although this term's use has mostly been  
replaced by AUID with changes made elsewhere.

The MUA consideration section uses the term Signing Identity (AUID)  
which is similar to and perhaps might be mistaken for the term Signing  
Domain Identifier (SDID).

Replacing AUID in the MUA consideration section with SDID, as was  
proposed, represents a significant change to the base draft.  For  
clarity sake, replacing the term Signing Identity with AUID would not  
be a change to the base draft.

> First, there isn't any urgency, since we do not know of any  
> immediate -- nevermind serious -- problems being caused by the  
> current text.

Agreed.

-Doug

---

From: Byung-Hee HWANG <[email-masked]>
Date: Mon, 20 Apr 2009 05:35:39 +0900

>> change until the -bis work.

Agreed, too. 
We should settle DKIM-Base in stable as soon as possible.

-- 
Byung-Hee HWANG, KNU 
∑ WWW: http://izb.knu.ac.kr/~bh/