Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations

[Brandon Long <[e-mail]>]

On Mon, Jul 20, 2020 at 4:20 PM Brandon Long <[e-mail]> wrote:

>
>
> On Mon, Jul 20, 2020 at 2:00 AM Laura Atkins <[e-mail]>
> wrote:
>
>>
>> On 19 Jul 2020, at 19:08, Murray S. Kucherawy <[e-mail]>
>> wrote:
>>
>>
>>    I'm less convinced by the notion that all of the RFC5322.From is
>>> disregarded by the preponderance of users when deciding what level of trust
>>> to put in the message's content. That suggests we blindly open and read
>>> absolutely everything, and I suspect that isn't the case.
>>>
>>> 1. That's not what it suggests, at all
>>>
>> Then I don't know what else you might mean by "end users do not reliably
>> make trust decisions based on /any/ of the information in the rfc5322.From
>> field".  What other data exist upon which to make trust decisions in the
>> display of a mailbox?
>>
>>
>> There was a research project done by an inbox provider and a major
>> supporter of DMARC presented at a MAAWG meeting a few years ago. They tried
>> adding trust indicators to the message list but found no statistically
>> significant behavioral changes by users. Given the conference policies, I
>> hesitate to mention it here, but there is research. There’s also a
>> conference paper I found, done by a computer science research team at VA
>> Tech that looked at this as well.
>>
>
> Was it us?  If so, I can push on folks to find and make it releasable, but
> I don't recall that we had such a presentation but I've also been out of
> the loop for a while and wasn't there are
> the beginning of DMARC either.  Ie, I know the ecert goldkey stuff failed
> on this, but don't think I ever saw the data.
>

Hah, and of course that was supposed to be private.

Brandon



>
> Brandon
>
>
>
>>
>> This question is actively being studied and there is research out there.
>> We don’t need to speculate or bring in individual opinions, we can look at
>> the different studies folks have done.
>>
>> 2. No doubt there is a better way to put this, but I'm not thinking of
>>> it, and this isn't just my second thought on the challenge, but quite a bit
>>> more than that:  This demonstrates why the IETF is a very poor venue for
>>> conducting human factors discussions.
>>>
>> No argument here.
>>
>>> Again: There is quite a bit of experience demonstrating that providing
>>> trust indicators to end users does not produce reliable -- ie, useful --
>>> decision-making by end users.
>>>
>> We appear to be talking past each other.  I wasn't talking about trust
>> indicators, but rather whether the RFC5322.From domain is visible..  I
>> don't have any reason yet to think trust indicators are effective.
>>
>>
>> Most clients these days seem to be hiding the RFC5322.From domain from
>> the individual end users. Mail.app on OSX does unless you change that
>> setting specifically (and it seems every few upgrades they reset the
>> setting and then hide the checkbox again). The iOS mail app doesn’t even
>> have a setting to change that I’ve been able to find. I seem to remember
>> the last time I set up a mailbox on Thunderbird (pre-2016 election as I was
>> tracking some candidate mail) they also hid the 5322.From address.
>>
>> There was another comment elsewhere about why not change the 5322.from
>> address if it’s not visible to the enduser, and there are 2 reasons I have
>> for that: The ability to search for mail from a particular author and the
>> ability to block mail from a particular author. Rewriting the From: address
>> always breaks the first. Some mailing lists point the Reply-To: to the
>> original author which means some kinds of filtering can trigger off that.
>> Other mailing lists point Reply-To: to the list address, which breaks the
>> second. Both things are important to mailing list usability.
>>
>> laura
>>
>> --
>> Having an Email Crisis?  We can help! 800 823-9674 <(800)%20823-9674>
>>
>> Laura Atkins
>> Word to the Wise
>> [e-mail]
>> [phone]
>>
>> Email Delivery Blog: https://wordtothewise.com/blog
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> dmarc mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dmarc
>>
>