Subject: [dmarc-ietf] Advice to MUA

From: Franck Martin <[email-masked]>
Date: Sat, 7 Jun 2014 17:23:05 -0500 (CDT)

I think we need to give advice to MUAs, while letting MUA developers some liberty on how to interpret it. 

I'm proposing the following text to be added to the DMARC spec 

"MUAs SHOULD display to the end user, in UTF8 (and punycode), in a non ambiguous font, the domain used for the assertion of the DMARC policy, as well as the result of this assertion. A non ambiguous font is a font where the graphical representation of a chararcter is not identical to the graphical representation of another chararcter in the same font" 

If we know what a non ambiguous font is, then may be we could specifiy the font name.

---

From: "J. Gomez" <[email-masked]>
Date: Sun, 8 Jun 2014 01:52:33 +0200

Franck Martin wrote:

> "MUAs SHOULD display to the end user, in UTF8 (and punycode), in a
> non ambiguous font, the domain used for the assertion of the DMARC
> policy, as well as the result of this assertion. A non ambiguous font
> is a font where the graphical representation of a chararcter is not
> identical to the graphical representation of another chararcter in
> the same font"     
> 

I very much would like that to be included in the DMARC spec.

And what about an additional recommendation in the spec (less than SHOULD) for MUAs to "green bar" the Header-From when the DMARC check passed *and* the domain is found to be accesible at https://_dmarc.example.com *and* found to have an EV SSL certificate?

So that only MUAs complying with that could be branded "DMARC-compliant" or "DMARC-secured"... As long as Certification Authorities managed to keep EV SSL certificates trustworthy, that would go a long way securing email communications and averting phishing scams, I think.

At any rate, MUA involvement for a successful DMARC is definitely required.

Regards,
J.Gomez

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sun, 08 Jun 2014 09:22:22 +0900

Franck Martin writes:

 > I think we need to give advice to MUAs, while letting MUA
 > developers some liberty on how to interpret it.
 > 

Isn't the "domain used for assertion" normally called the Author
Domain?

 > policy, as well as the result of this assertion. A non ambiguous
 > font is a font where the graphical representation of a chararcter
 > is not identical to the graphical representation of another
 > chararcter in the same font"
 > 

Unfortunately, there is no such thing.  For example, the glyph that
represents "A" is very likely to be used for the corresponding
character in all of the Latin, Greek, and Cyrillic scripts.  Even if
the glyphs for such confusable characters are clearly distinct in each
script, it would require a very carefully designed font to ensure that
most users would be able to reliably decide which glyph represents the
character from which script.

I would suggest

    MUAs SHOULD indicate the domain used for the assertion of the DMARC
    policy, and SHOULD also display internationalized domain names
    [IDNA = RFC 3490] as Punycode [PUNYCODE = RFC 3492].  MUAs MAY
    highlight a confusable character [UTS #39] if its script differs
    from the surrounding characters, or otherwise indicate different
    scripts in the domain name.

I'm not wedded to that language, and the part about highlighting
confusables needs refinement.

I wonder if it might not be a better idea to say that in the case of
identity alignment *failure*, the MUA should clearly indicate this
fact, as well as the Author Domain?

---

From: Hector Santos <[email-masked]>
Date: Sat, 7 Jun 2014 21:02:38 -0400

> On Jun 7, 2014, at 7:52 PM, "J. Gomez" <[email-masked]> wrote:
> 

All security considerations tell you otherwise.  You need control of the MUA and that's only possible with online-based MUAs or hybrid MUAs. You have no control over offline RFC-based store and forward MUAs. The only control you have is what the backend provides via the 5322 format.

--
Hector Santos
http ://www.santronics.com

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 7 Jun 2014 21:33:28 -0700

> I very much would like that to be included in the DMARC spec.

I would very much include such advice in documents if I thought there was
any hope they would be followed.  MUA developers rarely if ever participate
at the level of IETF work and often do things we don't expect, which has
led us to our current pattern of punting on using any kind of normative
language describing user interface stuff.  That is, they are consumers of
things like IMAP and SMTP, but they're completely free to decide how to
render the user side of those things.

Moreover, at the levels the IETF deals with, we as a community would be
kidding ourselves to think we understand what user interface choices work
or don't, so it would be silly for us to write things into RFCs that
purport otherwise.

Still, I've asked this before in other contexts, and I'll ask again: Does
anyone have contacts in MUA space that we might reach out to, and what
chances are there of them actually engaging?  I may have one with
Thunderbird that I'll try to reach out to in the coming week.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Sun, 08 Jun 2014 06:52:59 +0200

> I'm proposing the following text to be added to the DMARC spec

Directives encased in standards that concern UI/UX design are
appropriate when there are empirical data to support them.

On the average, efforts in IETF-related discussions at making UI/UX
design assertions lack that empirical basis and often even run counter
to existing empirical data.

Often they represent using the speaker as the user exemplar or cognitive
models along the lines of "more information presented to the user is
better".  The former is bad methodology and the latter is known to be
wrong.  Think bell curve...

UI/UX design is a specialty.  Few of us have the necessary training or
experience.

A hallmark of those who do have that training and experience is knowing
that world-class expertise only produces a useful /starting/ point in
design, but that the /finishing/ point is rarely the same.  What is
required to reach that finishing point is testing of the design.

I've been making that above, two-sentence summary for many years, but
finally tested with a group of real UI/YX experts at the SOUPs
conference last year and they nodded yes. (It's the per-eminent 'usable
security' conference. Last year was England; this year is Menlo Park, CA.)

> "MUAs SHOULD display to the end user, in UTF8 (and punycode), in a non
> ambiguous font, the domain used for the assertion of the DMARC policy,
> as well as the result of this assertion. A non ambiguous font is a font
> where the graphical representation of a character is not identical to
> the graphical representation of another character in the same font"

This is an example of a directive for a design choice that has
demonstrated very poor utility.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Terry Zink <[email-masked]>
Date: Sun, 8 Jun 2014 05:46:37 +0000

> Does anyone have contacts in MUA space that we might

> reach out to, and what chances are there of them actually

> engaging?

I'm currently working with the Outlook Web Access (OWA) team to do some UX work for email we (Exchange Online) detect as phishing, and am similarly working with the Outlook team. Eventually Hotmail/outlook.com will move to have a similar interface as OWA.

Getting UX teams to pick up the work is not easy, though. In terms of engaging, it depends on how much uniformity there is across the industry. There has to be a concrete proposal in place that has either wide adoption or wide support.

-- Terry

________________________________
From: dmarc <[email-masked]> on behalf of Murray S. Kucherawy <[email-masked]>
Sent: Saturday, June 07, 2014 9:33 PM
To: J. Gomez
Cc: [email-masked]; Franck Martin
Subject: Re: [dmarc-ietf] Advice to MUA

I would very much include such advice in documents if I thought there was any hope they would be followed.  MUA developers rarely if ever participate at the level of IETF work and often do things we don't expect, which has led us to our current pattern of punting on using any kind of normative language describing user interface stuff.  That is, they are consumers of things like IMAP and SMTP, but they're completely free to decide how to render the user side of those things.

Moreover, at the levels the IETF deals with, we as a community would be kidding ourselves to think we understand what user interface choices work or don't, so it would be silly for us to write things into RFCs that purport otherwise.

Still, I've asked this before in other contexts, and I'll ask again: Does anyone have contacts in MUA space that we might reach out to, and what chances are there of them actually engaging?  I may have one with Thunderbird that I'll try to reach out to in the coming week.

-MSK

---

From: "J. Gomez" <[email-masked]>
Date: Mon, 9 Jun 2014 20:33:00 +0200

> appropriate when there are empirical data to support them.

Ok.

Empirical data #1: web browsers[*] seem to be standardizing on displaying the address bar in green when the user goes to a web site with an Extended Validation SSL certificate.

Empirical data #2: there seems to be industry-wide[*] consensus that #1 is a good step forward.

Empirical data #3: users[*] seem to be accepting #1 in good terms.

Question: Could something akin to that be achieved in MUAs, leveraging both DMARC *and* EV SSL certificates, for example coloring in green the From: field which is displayed to the user (in MUA which happen to do that[*]).

[*]Exceptions may be found, caveat emptor.

Regards,
J.Gomez

---

From: Dave Crocker <[email-masked]>
Date: Mon, 09 Jun 2014 21:03:39 +0200

> Empirical data #1: web browsers[*] seem to be standardizing on displaying the address bar in green when the user goes to a web site with an Extended Validation SSL certificate.

Please forgive my having been unclear in what I meant.  I mean empirical
data about users, not about developers.  That is, there needs to be
evidence that what is being proposed has actual efficacy in user
behavior, not merely popularity amongst software developers (or their
managers.)

> Empirical data #3: users[*] seem to be accepting #1 in good terms.

"accepting" is an interesting word, since it refers to attitude, rather
than actual utility.

And then, of course, then there's the whole matter of needing external
references that objectively support the assertions you are making...

d/

---

From: "J. Gomez" <[email-masked]>
Date: Mon, 9 Jun 2014 21:25:36 +0200

> references that objectively support the assertions you are making...

Yeah, well, we are having a mailing list exchange, not presenting a doctoral thesis here.
 
Do you have references that objectively support the contrary to those assertions, perhaps?
 
Do you know of any references/literature which posits contrary to those assertions? Are those references/literature significant and/or peacefully undisputed? Do you think those assertions are, as of today, an undecided issue?

Regards,
J.Gomez

---

From: Dave Crocker <[email-masked]>
Date: Mon, 09 Jun 2014 21:40:40 +0200

> Do you have references that objectively support the contrary to those assertions, perhaps?

You want me to prove the negative?  What an exciting (if impossible)
challenge.

Besides being an inherently problematic requirement, the usual policy is
that someone taking the affirmative position to do something is expected
to justify it.  We don't usually start with a default assumption that
taking an action should be approved and it's everyone else's obligation
to prove why the action should not be done.

> Do you know of any references/literature which posits contrary to those assertions? Are those references/literature significant and/or peacefully undisputed? Do you think those assertions are, as o…

Well, my masters in the topic certainly doesn't suffice, so take a quick
scan of the last 10-15 years of SOUPS papers.

And just to offer a quick example of how basic my point is about this
topic, I did a google on "user interface design computer system
efficacy" and the second result was:

     Efficacy of User Interface Design
     www.usernomics.com/user-interface-design.html

which includes:

     "Optimized User Interface Design requires a systematic approach to
     the design process. But, to ensure optimum performance, Usability
     Testing is required."

To repeat, UI/UX design is a specialty requiring extensive training in
cognitive, memory and attention psychology, testing methodology and, oh
yes, computer science.

Users mostly don't notice the kinds of signals being proposed and when
they do notice, they do it only erratically, and their interpretation of
the signals is poor.

d/

---

From: Derek Diget <[email-masked]>
Date: Mon, 09 Jun 2014 16:00:04 -0400 (EDT)

On Jun 9, 2014 at 21:25 +0200, J. Gomez wrote:
=>On Monday, June 09, 2014 9:03 PM [GMT+1=CET], Dave Crocker wrote:
=>
=>> And then, of course, then there's the whole matter of needing external
=>> references that objectively support the assertions you are making...
=>
=>Yeah, well, we are having a mailing list exchange, not presenting a 
=>doctoral thesis here.
=> 
=>Do you have references that objectively support the contrary to those 
=>assertions, perhaps?
=> 
=>Do you know of any references/literature which posits contrary to 
=>those assertions? Are those references/literature significant and/or 
=>peacefully undisputed? Do you think those assertions are, as of today, 
=>an undecided issue?

Not directly related to email, but see "The Emperor's New Security 
Indicators" that was presented at the 2007 IEEE Symposium on Security 
and Privacy. 

My googling came up with the PDF at IEEE Xplore : 
<http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4223213>  If you 
can't get it there, there are many other sites that have the PDF.

-- 
***********************************************************************
Derek Diget                            Office of Information Technology
Western Michigan University - Kalamazoo  Michigan  USA - www.wmich.edu/
***********************************************************************

---

From: "J. Gomez" <[email-masked]>
Date: Mon, 9 Jun 2014 22:02:16 +0200

On Monday, June 09, 2014 9:40 PM [GMT+1=CET], Dave Crocker wrote:

> cognitive, memory and attention psychology, testing methodology and,
> oh yes, computer science.

So I guess we will wait until Apples just does it, and then go and copy it, whichever side it falls.

Because, well, talking about it outside of a cathedral chorus full of emminentiae is a no-no...

Regards,
J.Gomez

---

From: Terry Zink <[email-masked]>
Date: Mon, 9 Jun 2014 21:12:37 +0000

> So I guess we will wait until Apples just does it, and then go and copy it, whichever side it falls.

Your response is tongue-in-cheek but I think represents a harsh reality; only large companies have the resources to test UX'es and the associated user behavior. For example, Amazon tests everything on its webpage when it comes to pixel placement, and I believe that Netflix does the same.

Alternatively, some universities who have researchers or grad students or professors study this sort of thing may similarly come up with recommendations.

-- Terry

---

From: "J. Gomez" <[email-masked]>
Date: Mon, 9 Jun 2014 23:30:21 +0200

On Monday, June 09, 2014 11:12 PM [GMT+1=CET], Terry Zink wrote:

> > > To repeat, UI/UX design is a specialty requiring extensive
> > > training in cognitive, memory and attention psychology, testing
> > > methodology and, oh yes, computer science.
> 
> Your response is tongue-in-cheek but I think represents a harsh
> reality; only large companies have the resources to test UX'es and
> the associated user behavior. For example, Amazon tests everything on
> its webpage when it comes to pixel placement, and I believe that
> Netflix does the same.

True, but at the same time UX is something that every user can talk about, as per se every user has experience with it.
 
Every time I hear that UI is a black art to be refined only by ultra specialists, I shiver in fear, because not only I have seen no improvement in that area since the Windows 95 days (except perhaps the Windows 2000 cosmetic improvements), but on the contrary what I have seen and *experienced* is plain user disgust. However, they call it the product of deep field tests helped by teams of psychologists and what not, so that "evolution" must be great and I be just wrong about it.

Regards,
J.Gomez

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 9 Jun 2014 14:44:28 -0700

On Mon, Jun 9, 2014 at 2:30 PM, J. Gomez <[email-masked]> wrote:

> True, but at the same time UX is something that every user can talk about,
> as per se every user has experience with it.
>
> Every time I hear that UI is a black art to be refined only by ultra
> specialists, I shiver in fear, because not only I have seen no improvement
> in that area since the Windows 95 days (except perhaps the Windows 2000
> cosmetic improvements), but on the contrary what I have seen and
> *experienced* is plain user disgust. However, they call it the product of
> deep field tests helped by teams of psychologists and what not, so that
> "evolution" must be great and I be just wrong about it.
>

True, but who's to say our proposed improvements would make things any
better than the ones that would (or would not) happen without our
guidance?  This group might come to consensus on what we think users would
understand and [try to] push that into user space, but in the end that's
merely what we imagine would work based on our own experiences or
extrapolations, and might actually make things worse.

I'm not saying we shouldn't talk about it or even that we shouldn't try,
but I am saying we'd better be pretty darned sure about the end result, and
I'm not really sure how to go about doing that.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Mon, 09 Jun 2014 19:38:32 -0400

> Every time I hear that UI is a black art to be refined only by ultra specialists, I shiver in fear, because not only I have seen no improvement in that area since the Windows 95 days (except perhap…

Good points.

Its a very complex subject.

How many different mail portals do you use/need as a user?  How many 
different mail portals does the service host offer, they need to 
design for?

Vendors that have strategic control of the many integrated mail parts 
have a better means of doing the things that you would to see. Make a 
change here, comes with a change there.  But sometimes these things 
are split by product department, team, etc, so change doesn't always 
come easy or fast.

The more you can single source your mail infrastructure, the better it 
is and this has been happening more with long time established 
systems. Centralization and a renewed direction towards online, with 
full duplex interactive I/O is on the move, and it offer more 
intelligent information to the end users.

I have at least 4-5 different MUA designs and thats hard to get right 
with new stuff. Its also hard to change too.  For example, Microsoft 
recently (a few years now) abandoned their 20+ years of Newsgroups 
NNTP servers and move their support operation to online forums. They 
were already exploring with various UI look and feels for a few years 
so now you have different competing support operations.   When the MS 
NNTP servers were turned off, to help support legacy NNTP news reader 
users, like me, I wrote a NNTP proxy (Wildcat! Live Exchange, 
http://opensite.winserver.com/wclex) with authenticated Live ID access 
to the backend mail host using their SOAP protocol API wire.   I did 
it knowing it wasn't going to be a big thing as more and more people 
went directly to the online forums.  I can also control what the news 
reader will display in the fields and also body by transforming the 
extra data bits from the backend user and mail records; how many 
brownie points the reader has, MVP, etc.

You are still using OE, thats old dude!! :)  But sure, it works. I 
have it on various machines.   How do we change it to show the info 
would like?  Will you adapt to a new reader?

In the mean time, we have only the IETF protocols as a means to 
communicate with each other, ideally, in a cooperative competitive 
manner using global common methods, format and standards.   It is 
possible to put data bits in the 5322 headers. But its only good if 
the MUA can use it.

It is still a good idea to extract general MUA ideas and offer them as 
guidelines for the general MUA.

-- 
HLS

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Tue, 10 Jun 2014 12:33:43 +0900

Terry Zink writes:

 > the associated user behavior.

Open source projects can simply do it, and let the real users of their
software test directly.  They often do so graciously, too.  It still
has to be tested, though, and until there is data, I have to agree
that at best we're talking about "Best Unimplemented Practices", and
that doesn't belong in a standards-track RFC (yes, I know, but this
*should* be a standards-track RFC given its content).

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Tue, 10 Jun 2014 12:38:10 +0900

Murray S. Kucherawy writes:

 > guidance?

I don't think we should propose improvements, at least not expecting
them to be taken at all seriously, and possibly not at all unless
asked for examples by the MUA developers.

IMO, what we should do is lay out the security model that we're trying
to implement, and explain why we need the users' help to complete it.
Then ask the MUA developers to help the users help us keep the users
(more) secure.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 9 Jun 2014 21:36:08 -0700

> *should* be a standards-track RFC given its content).

Even with those caveats, I see open source implementations as a huge
resource to vetting good solutions to these problems.  There were extremely
useful in the development of SPF, DKIM, and DMARC, for example, and you've
done so with Mailman as well.  I'd be happy make some of these recent
proposals available as experiments in my open source packages if there end
up being one or two front runners.

-MSK