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

From: "Kurt Andersen (IETF)" <[email-masked]>
Date: Fri, 17 Jul 2020 11:30:39 -0700

Dave writes:

However, for all of the real and serious demonstration of users' being
tricked by deceptive or false content in a message, there is no
evidence that problematic content in a field providing information
about message's author directly contributes to differential and
problematic behavior by the end user.

I'd counter by personal anecdote that we have had to undertake security
remediations because of messages which were forwarded by our CEO to other
employees for responses which happened to contain malware and/or bad links.
Presumably, the cachet which was carried along with "important person says
look into this" overcame whatever native caution or skepticism might have
prevented them from falling prey otherwise.

--Kurt

---

From: Dave Crocker <[email-masked]>
Date: Fri, 17 Jul 2020 11:35:10 -0700

On 7/17/2020 11:30 AM, Kurt Andersen (IETF) wrote:
> Dave writes:
>
>     However, for all of the real and serious demonstration of users' being tricked by deceptive or false content in a message, there is no evidence that problematic content in a field providing information about message's author directly contributes to differential and problematic behavior by the end user.
>
> I'd counter by personal anecdote that we have had to undertake 
> security remediations because of messages which were forwarded by our 
> CEO to other employees for responses which happened to contain malware 
> and/or bad links. Presumably, the cachet which was carried along with 
> "important person says look into this" overcame whatever native 
> caution or skepticism might have prevented them from falling prey 
> otherwise.

Except that the problem isn't the email address, especially since almost 
no one sees those any more.  And the display name isn't protected.

I'm not quite motivated enough, or I'd have had this message contain:

    Kurt Anderson <dcrocker@gmail>

and it would have passed the necessary tests...

In other words, when we talk about threats and we talk about 
mitigations, we need to be careful that they align properly.

(I suspect there's some irony in my choosing 'align' but it was not 
intentional, though I'll take the extra point for noting it.)

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "Dave Crocker on behalf of Kurt Andersen" <[email-masked]>
Date: 17 Jul 2020 17:00:53 -0400

In article <[email-masked]> you write:
>> and/or bad links. ...

>no one sees those any more.  And the display name isn't protected.

Do we have any recent numbers on how many users see the From address rather
than or in addition to the display name?

Signed,
uh, someone

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 18 Jul 2020 10:45:12 +0200

> than or in addition to the display name?

Similar problems are typosquatting and homograph attacks.  I heard the latter 
is being addressed also in email clients —which implies they target users who 
look beyond the display name.  We used to hold that DMARC does not cover those 
topics.  Why should we worry about display names?

DMARC filtering is designed to operate at the (edge) MX, not MUA.  If applied 
consistently, it grants a well defined kind of protection.  That is just a 
building block, not a silver bullet.  Our problem is that DMARC filtering 
cannot be applied consistently, because of MLMs.  Lowering DMARC's contractual 
obligations is not a proper solution.

Best
Ale
--

---

From: Jim Fenton <[email-masked]>
Date: Sat, 18 Jul 2020 10:24:10 -0700

On 7/18/20 1:45 AM, Alessandro Vesely wrote:

> DMARC filtering is designed to operate at the (edge) MX, not MUA.  If
> applied consistently, it grants a well defined kind of protection. 
> That is just a building block, not a silver bullet.  Our problem is
> that DMARC filtering cannot be applied consistently, because of MLMs. 
> Lowering DMARC's contractual obligations is not a proper solution.
>
>
You lost me there. What do you mean by "DMARC's contractual obligations"?

-Jim

---

From: Dave Crocker <[email-masked]>
Date: Sat, 18 Jul 2020 13:11:51 -0700

> than or in addition to the display name?

Thereby making clear that this is a spoofed message, since I wouldn't 
ask a question like that, potentially distracting from the substance of 
the topic.  Beyond, none vs. some vs. all, the numbers shouldn't matter.

There is ample evidence that trust markers presented to end users do not 
produce adequately differential (and useful) decision-making about 
whether a message is trustworthy.

d/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 18 Jul 2020 17:16:50 -0700

Brandon Long, if you're watching:

> than or in addition to the display name?

At some point in the past, Gmail decided to show the email address only
unless that address was in the recipient's contact list, or if the
recipient had replied to that address previously, or something like that.
In those cases, the RFC5322.From address was trusted, and so the display
name was shown.  Is there logic like that still in place?

Any other UI developers got a policy here?

-MSK, sans chapeau

---

From: Dave Crocker <[email-masked]>
Date: Sat, 18 Jul 2020 18:32:18 -0700

On 7/18/2020 5:16 PM, Murray S. Kucherawy wrote:
> At some point in the past, Gmail decided to show the email address 
> only unless that address was in the recipient's contact list, or if 
> the recipient had replied to that address previously, or something 
> like that.  In those cases, the RFC5322.From address was trusted, and 
> so the display name was shown.  Is there logic like that still in place?

If end users do not reliably make trust decisions based on /any/ of the 
information in the rfc5322.From field, then how is this question 
important.  It seems to be seeking precise data about something that 
isn't even secondary.

The persistence of thinking that end users are influenced by trust 
indicators is pernicious.

d/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 18 Jul 2020 21:23:36 -0700

> important.  It seems to be seeking precise data about something that

Google strikes me as the kind of place that would make a decision about
what to show users based on data, so I was wondering if they have any,
because I seem to remember them talking about this back when DMARC was in
development.

While I'm intrigued by the discussion about the domain name isn't visible
and thus may not be as important to protect as we originally thought, 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.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 19 Jul 2020 11:39:56 +0200

> You lost me there. What do you mean by "DMARC's contractual obligations"?

One is filtering on From:

    o  Allow Domain Owners to assert the preferred handling of
       authentication failures, for messages purporting to have
       authorship within the domain.
                https://tools.ietf.org/html/rfc7489#section-2.1

Here, authorship should be meant to be something rather akin to a formal 
copyright holder, whereas the Author: field addresses moral attributions.  In 
that sense, authorization to rewrite From: is granted by BCP 78.[*]

OTOH, filtering on Sender: doesn't comply with the quoted purpose.

Best
Ale
-- 

[*] IANAL.

---

From: Dave Crocker <[email-masked]>
Date: Sun, 19 Jul 2020 05:40:19 -0700

On 7/18/2020 5:16 PM, Murray S. Kucherawy wrote:
> only unless that address was in the recipient's contact list, 

btw, I just logged in to gmail's web interface -- I normally access via 
imap -- and it is only showing display-name text.  No email address for 
any of the messages.  As far as I can tell, I have no address book at gmail.

d/

---

From: Dave Crocker <[email-masked]>
Date: Sun, 19 Jul 2020 08:04:14 -0700

On 7/18/2020 9:23 PM, Murray S. Kucherawy wrote:
> On Sat, Jul 18, 2020 at 6:32 PM Dave Crocker <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> Google strikes me as the kind of place that would make a decision 
> about what to show users based on

Perhaps, but since we don't have their data and we don't have their 
decision-criteria -- which might be quite different from what is needed 
here -- then it's probably a good idea not to make assumptions about the 
utility, nor to put all of the human factors marbles in the google camp.

>    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

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.

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.

d/

---

From: "John Levine" <[email-masked]>
Date: 19 Jul 2020 15:08:15 -0000

In article <[email-masked]>,
>any of the messages.  As far as I can tell, I have no address book at gmail.

I just sent my Gmail account a test message from an address that never existed before,
and it only showed the display name in the web site and the iOS and Android apps.

This tells us that at least at one big gorilla, the header address
isn't something that users see.  This leads to two questions, one being
why the From address is a better authentication handle than, say, DKIM d=.

The other is that if the users don't see the address, why do we care
if mailing lists change it? I think I have some reasonable answers,
starting with the way it screws up replies. something we know from
experience that Reply-To can't fix.

R's,
John
-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Dave Crocker <[email-masked]>
Date: Sun, 19 Jul 2020 08:13:18 -0700

> why the From address is a better authentication handle than, say, DKIM d=.

I think the possibility of d= hasn't been considered seriously. I'm not 
going advocate, but it's worth thinking about this a bit, just to make 
sure we understand it's implications.

I've thought (assumed, recall) that From: was chosen because it is the 
only address value in email that is required to be present.  So it gives 
you a domain name to start from and then look up for a DMARC record.

There is always that domain name, even when there is no authentication 
information.

It's only possible to use the d= if there is a signature.  So a 
downgrade attack would succeed by merely removing the DKIM information.

d/

---

From: "John Levine" <[email-masked]>
Date: 19 Jul 2020 11:20:07 -0400

>and it only showed the display name in the web site and the iOS and Android apps.

Took a look at the mail programs that come with my iPad and Samsung
phone, neither of which show the From address either. You can
eventually see the address but it's not easy, tap on the message to
open it (thereby enabling the phish in the message of course), then
tap on the name to see the address.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 19 Jul 2020 11:08:05 -0700

On Sun, Jul 19, 2020 at 8:04 AM Dave Crocker <[email-masked]> wrote:

> what to show users based on
>
Certainly it's only one data point, and as I recall it's the one that got
the most discussion during the early DMARC work.  That's what made me think
of it.  Data from multiple sources would of course be better, and I'd
happily solicit other possible sources.  My employer isn't in the inbox
game anymore, so I don't have any of my own data to offer.

I agree they might be quite different, but they also might not be.  Don't
know unless we ask.

> 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.
>
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?

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

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

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 19 Jul 2020 11:09:41 -0700

> any of the messages.  As far as I can tell, I have no address book at

Same.  That's why I attempted to invoke Brandon.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Sun, 19 Jul 2020 11:33:46 -0700

On 7/19/2020 11:08 AM, Murray S. Kucherawy wrote:
>
>     gain: 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.
>
> indicators, but rather whether the RFC5322.From domain is visible.  I 
> don't have any reason yet to think trust indicators are effective.
>
The view that the From: address, or domain, or Display-Name is used, by 
end-users, for assessing the trustworthiness of a message means it/they 
are used as trust indicators.

The track record is that people are unreliable at this.

There is quite a bit of distance between 'unreliable' and 'blindly open 
and read absolutely everything'.

In any event...

The essential point that needs to be made is that standards like this 
MUST NOT be cast in terms of what end users will do.  In practical 
terms, this work has nothing to do with end users. Really.  Nothing.

To the extent that anyone wants to make an affirmative claim that 
end-users /are/ relevant to this work, they need to lay that case out 
clearly, carefully, and with material that provides objective support.(*)

By contrast, say that this work provides input to a receiving filtering 
engine made the work easy to explain and understand and defend.

d/

(*) I've seen one posting here or somewhere else that noted that letting 
bad mail through can lead to end-users being deceived. I'll claim that 
while true, it is not relevant, since the behavior happens after DMARC, 
and the like, are relevant.  That is, DMARC, etc., do not inform the 
end-user behavior.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 19 Jul 2020 17:04:46 -0700

On Sun, Jul 19, 2020 at 11:33 AM Dave Crocker <[email-masked]> wrote:

> gain: There is quite a bit of experience demonstrating that providing
> end-users, for assessing the trustworthiness of a message means it/they are
> used as trust indicators.
>
Is there?

If there's no part of the From field that can be considered reliable, then
by opening even this email am I not exhibiting nearly-blind faith that the
indicators I can see (in this case the string "Dave Crocker (gmail.com)")
have not been falsely generated?  How is this message, in terms of its
trustworthiness, different from any other?

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Sun, 19 Jul 2020 17:52:44 -0700

On 7/19/2020 5:04 PM, Murray S. Kucherawy wrote:
> On Sun, Jul 19, 2020 at 11:33 AM Dave Crocker <[email-masked] 
>     There is quite a bit of distance between 'unreliable' and 'blindly
>     open and read absolutely everything'.
>
> Is there?

Yes.

> If there's no part of the From field that can be considered reliable, 
> then by opening even this email am I not exhibiting nearly-blind faith 
> that the indicators I can see (in this case the string "Dave Crocker 
> (gmail.com <http://gmail.com>)") have not been falsely generated?  How 
> is this message, in terms of its trustworthiness, different from any 
> other?

It's an act of curiosity, not faith.  You know that mail can be 
spoofed.  You might even suspect that I'm capable of lying. (Silly, I 
know, but...) Or that I might be wrong. (Truly a foolish thought.)  So 
the process of deciding on the validity and worth of my message is 
incremental and heuristic.

Human evaluation processes vary, but mostly are pretty complex. Except 
when they aren't, though then it's often problematic.

Mostly, your line of comments is trying to apply logical reasoning, 
which is rarely helpful in assessing human behavior.

All of which is why this is a really terrible forum for making 
assertions or, worse, decisions, about end-user behavior.

Whereas talking in terms of receiving filtering engines is both simpler 
and more useful.

d/

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 20 Jul 2020 10:44:27 +0200

On Sun 19/Jul/2020 20:33:46 +0200 Dave Crocker wrote:
> 
> The essential point that needs to be made is that standards like this MUST NOT 
> be cast in terms of what end users will do.  In practical terms, this work has 
> nothing to do with end users. Really.  Nothing.
> 
> [...]
> 
> 
> (*) I've seen one posting here or somewhere else that noted that letting bad 
> mail through can lead to end-users being deceived. I'll claim that while true, 
> it is not relevant, since the behavior happens after DMARC, and the like, are 
> relevant.  That is, DMARC, etc., do not inform the end-user behavior.

Aren't those two paragraphs self-contradictory?

If DMARC were dependable, maybe users would learn to trust From:.  Or maybe 
not.  Avoiding end user considerations cuts both ways.  Yet, we can trust that 
if we do a well-defined, clear job, then the whole system will work better.

Best
Ale
--

---

From: Laura Atkins <[email-masked]>
Date: Mon, 20 Jul 2020 09:59:38 +0100

> On 19 Jul 2020, at 19:08, Murray S. Kucherawy <[email-masked]> 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.
> 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. 

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 

Laura Atkins
Word to the Wise
[email-masked]
(650) 437-0741		

Email Delivery Blog: https://wordtothewise.com/blog

---

From: Jesse Thompson <[email-masked]>
Date: Mon, 20 Jul 2020 17:05:24 -0500

On 7/19/20 1:33 PM, [email-masked] wrote:
> The essential point that needs to be made is that standards like this MUST NOT be cast in terms of what end users will do.  In practical terms, this work has nothing to do with end users.  Really.  Nothing.
> 
> To the extent that anyone wants to make an affirmative claim that end-users /are/ relevant to this work, they need to lay that case out clearly, carefully, and with material that provides objective support.(*)

I'll take a shot (admittedly, I'm having trouble keeping up with all of the points that have been made):

We're migrating 30,000 lists, of various types/use cases, from a MLM provider that is DMARC-ignorant to one that munges the From.  It rewrites the friendly-From in addition to the From address (this touches on Laura's point that even though some/most MUAs hide the domain, recipients still *see* something different)

We have a DMARC policy published for our 500ish domains, and an increasing number of the domains of our external list members are publishing DMARC.  DMARC enforcement (outside of our control) is also increasing - which motivates us to accelerate our transition to the DMARC-friendly MLM platform (one that rewrites the From)
 
** We have had many complaints from users about the From munging **

I could try to quantify, if that's the only way to prove the point that end-users matter and are relevant to this conversation.

It calls into question whether we (or any domain) should publish DMARC policies.  Gmail.com doesn't publish a DMARC policy, after all, and many people (such as some on this list) are using gmail.com to subscribe to lists, and they don't have to suffer the consequences of DMARC.  

Why should the rest of end-users suffer?  (some might say)

Granted, we are a university.  Maybe these are just faculty being hyper-sensitive to how their messages are appearing to their peers/students.  But isn't that enough evidence that end-users *are* relevant?  With time, maybe we can change these end-user expectations, and From rewriting will be the new reality that people will accept.

The To-rewrite strategy seems interesting, in a "From-rewriting is here to stay" assumed world, to force MUA behavior and to help mitigate the auto-collecting address problem.

I think that draft-kucherawy-dkim-transform-02 is getting at what I was originally thinking.  In my opinion, MLMs will *always* need to munge, because they will never know if an arbitrary receiver will trust their non-munged mail.  Giving the receivers a way to un-munge (if they can and/or want and/or trust) would be a productive path forward out of this situation.

I think that we just have to agree that From-munging by MLMs is a permanent reality.  It needs to be documented more prominently (and promoted as part of the DMARC marketing) so that implementations are more consistent, so that un-munging tactics and/or MUA behavior can be consistently implemented.

Jesse

---

From: Brandon Long <[email-masked]>
Date: Mon, 20 Jul 2020 16:20:04 -0700

On Mon, Jul 20, 2020 at 2:00 AM Laura Atkins <[email-masked]>
wrote:

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

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.
>
> indicators, but rather whether the RFC5322.From domain is visible..  I
> 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
> [email-masked]
> (650) 437-0741
>
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: Brandon Long <[email-masked]>
Date: Mon, 20 Jul 2020 16:20:56 -0700

> on this, but don't think I ever saw the data.

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

Brandon

>>> it, and this isn't just my second thought on the challenge, but quite a bit
>> 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.
>>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 20 Jul 2020 18:18:19 -0700

> Tech that looked at this as well.

I remember something about the former.  I'll see if I can find a public
reference to it.

"Data, data, data; we cannot make bricks without clay."

> candidate mail) they also hid the 5322.From address.

I could be wrong but I seem to recall that at the time DMARC was published,
this wasn't the case.  (See my previous remarks about Gmail.)  But I agree
that it does seem to be the case now.

I'm not sure we've ever fully faced the idea that what MUAs choose to
display needs to be factored into the evolution of these protocols.  For as
long as I've been working on this, it's been the opposite.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Mon, 20 Jul 2020 18:33:58 -0700

On 7/20/2020 6:18 PM, Murray S. Kucherawy wrote:
> display needs to be factored into the evolution of these protocols.  
> For as long as I've been working on this, it's been the opposite.

Although various people keep citing affecting display based on dmarc, 
that's never been the essence of its motivation.  Which is good, because 
users are not affected by trust indicators. Really.  Not.

It's entirely reasonable to start with the idea that it might (or 
should) help end-user evaluation, but human factors don't serve the 
master of that kind of logic. To date, online experience is that users 
are essentially impervious to trust indicators.(*)

Rather, DMARC serves to provide some clean data to the receiving 
filtering engine, which is the only venue that matters for email 
safety.  (Well, and originating filtering engines, of course.) Not the MUA.

d/

(*) Obviously, if you have some data to the contrary...

---

From: "John Levine" <[email-masked]>
Date: 20 Jul 2020 22:27:15 -0400

In article <[email-masked]> you write:
>Granted, we are a university.  Maybe these are just faculty being hyper-sensitive to how
>their messages are appearing to their peers/students.  But isn't that enough evidence that
>end-users *are* relevant?  With time, maybe we can change these end-user expectations, and
>From rewriting will be the new reality that people will accept.

I don't think the claim is that users don't see anything, it's that
they're no good at using what they see to make security decisions,
something that has more to do with mental models and metaphors between
what's on the screen and reality.

>I think that draft-kucherawy-dkim-transform-02 is getting at what I was originally thinking. 
>In my opinion, MLMs will *always* need to munge, because they will never know if an arbitrary
>receiver will trust their non-munged mail.  Giving the receivers a way to un-munge (if they
>can and/or want and/or trust) would be a productive path forward out of this situation.

We already have a couple of ways to do reversible message munging,
starting with MIME message wrapping. In principle it works fine, in
practice it's awful because MUAs don't show wrapped messages
consistently and often in ways that are painful, e.g., you can see the
original author address but there's no button you can push to respond
to it.

Unwrapping a MIME attachment is a lot easier than the proposed DKIM
unmunging but I doubt either is going to show up in MTAs any time
soon.  Perhaps you could do it in the mail gateway.

R's,
John

---

From: Laura Atkins <[email-masked]>
Date: Tue, 21 Jul 2020 08:59:46 +0100

> On 21 Jul 2020, at 00:20, Brandon Long <blong=[email-masked]> wrote:
> 
> 
> 
> On Mon, Jul 20, 2020 at 2:00 AM Laura Atkins <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> On 19 Jul 2020, at 19:08, Murray S. Kucherawy <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 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.

Wasn’t Google (which doesn’t mean Google hasn’t done similar work. Following up offlist. 

laura 

Laura Atkins
Word to the Wise
[email-masked]
(650) 437-0741

---

From: Laura Atkins <[email-masked]>
Date: Tue, 21 Jul 2020 09:08:50 +0100

> On 21 Jul 2020, at 02:18, Murray S. Kucherawy <[email-masked]> wrote:
> 
> On Mon, Jul 20, 2020 at 1:59 AM Laura Atkins <[email-masked] <mailto:[email-masked]>> wrote:
> I remember something about the former.  I'll see if I can find a public reference to it.
> 

https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-hu.pdf <https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-hu.pdf> is the conference talk I was mentioning. 

I’ll be honest, I do think both phishing and UX has evolved significantly since DMARC was initially announced. The protocol has not kept up with the evolution and it’s benefits are much less obvious than when it was initially launched. We’re forcing a lot of damage on normal email usage, for non-obvious benefits. 

> I could be wrong but I seem to recall that at the time DMARC was published, this wasn't the case.  (See my previous remarks about Gmail.)  But I agree that it does seem to be the case now.

I don’t remember, either. I think clients were going down that route, though. I know, for instance, that the iOS mail client has never shown the email address, always the friendly from. 

> I'm not sure we've ever fully faced the idea that what MUAs choose to display needs to be factored into the evolution of these protocols.  For as long as I've been working on this, it's been the opposite.

When we’re basing a protocol on “what the user sees” and “what the user can trust” then I think we have to. DMARC says “users can trust that mail from @domain.example is really from @domain.example” but if the user never sees that, how do they know? 

laura 

Laura Atkins
Word to the Wise
[email-masked]
(650) 437-0741

---

From: Laura Atkins <[email-masked]>
Date: Tue, 21 Jul 2020 09:17:04 +0100

> On 21 Jul 2020, at 02:33, Dave Crocker <[email-masked]> wrote:
> 
> Although various people keep citing affecting display based on dmarc, that's never been the essence of its motivation.  Which is good, because users are not affected by trust indicators. Really.  Not.

I agree users are not affected by trust indicators (although see the .pdf that I linked to in an earlier email that says they are). But I would argue that much of the marketing and justification around DMARC has been around end users and improving their trust in brands and protecting them from phishing. 

> 
> It's entirely reasonable to start with the idea that it might (or should) help end-user evaluation, but human factors don't serve the master of that kind of logic. To date, online experience is that users are essentially impervious to trust indicators.(*)
> 
> Rather, DMARC serves to provide some clean data to the receiving filtering engine, which is the only venue that matters for email safety.  (Well, and originating filtering engines, of course.) Not the MUA.

That is not how I’ve seen DMARC being sold. Most of the marketing I’ve seen about DMARC is all about user experience and the user being able to trust mail is “from who it claims to be from.” And now people are explicitly layering on another protocol that is all about what the user sees in the MUA. 

laura

Laura Atkins
Word to the Wise
[email-masked]
(650) 437-0741

---

From: "Douglas E. Foster" <[email-masked]>
Date: Tue, 21 Jul 2020 11:05:55 GMT

I would like a better understanding of why MUAs are hiding or removing the FROM address.

I have one mail store that formerly used hover-to-view, but recently changed to always-show.   This was done in response to a client request on their support forum.  I have never seen a user ask for the From address to be hidden or removed.  I wonder if this trend is driven only by attempts to optimize display space.   It would be a shame to weaken our protocols in response to this trend, if the trend lacks a theoretical foundation.

I also wonder if the trust indicator research is being over-applied when it is applied to the From Address.    From Address is a unique identifier, while Friendly Name is not.   A trust indicator is like putting a green check mark next to the From Address as a trust indicator.   They have different levels of relevance.   

One attack method steals a contact list, then emails people in that contact list using friendly names of others in that list.   Hiding the From Address plays into that attack.

This trust-indicator research also promotes despair.  The conclusion is that users process information poorly.   This result then becomes an excuse to withhold information from those users, or to allow misleading information to be presented to them.    I am not convinced that those are appropriate responses.   "Never" is a hard thing to prove.  So it is risky to say users "Never" use available information correctly, and "cannot be taught" to do better.

Attack filtering is designed on a layered defense and a sequence of probabilities:
What is the probability that this attack will get through my spam filter?What is the probability that the user will read the message?What is the probability that the user will click on the hostile link?What is the probability that my web filter will allow access to the hostile website?What is the probability that the web filter will allow the attack to be downloaded?What is the probability that my antivirus program will allow the attack to proceed?
The goal is to decrease the probability of a wrong decision at each point in the process.   All I need is for some people to act smarter on some occasions in response to some available clue.   But this cannot happen if the clue is not provided..

Doug Foster

---

From: Brandon Long <[email-masked]>
Date: Tue, 21 Jul 2020 10:28:12 -0700

Do sms/mms programs show the phone number any more?  I think there's been a
deliberate strategy to make email clients more like
other messaging clients, and the technical parts like the actual address
are details that most of the time aren't useful to the user... when
they're not being spoofed, of course, or otherwise need to differentiate
between multiple addresses for the same person.

Brandon

On Tue, Jul 21, 2020 at 4:06 AM Douglas E. Foster <
[email-masked]> wrote:

> I have one mail store that formerly used hover-to-view, but recently
> changed to always-show.   This was done in response to a client request on
> their support forum.  I have never seen a user ask for the From address to
> be hidden or removed.  I wonder if this trend is driven only by attempts to
> optimize display space.   It would be a shame to weaken our protocols in
> response to this trend, if the trend lacks a theoretical foundation.
>
> I also wonder if the trust indicator research is being over-applied when
> it is applied to the From Address.    From Address is a unique identifier,
> while Friendly Name is not.   A trust indicator is like putting a green
> check mark next to the From Address as a trust indicator.   They have
> different levels of relevance.
>
> One attack method steals a contact list, then emails people in that
> contact list using friendly names of others in that list.   Hiding the From
> Address plays into that attack.
>
> This trust-indicator research also promotes despair.  The conclusion is
> that users process information poorly.   This result then becomes an excuse
> to withhold information from those users, or to allow misleading
> information to be presented to them.    I am not convinced that those are
> appropriate responses.   "Never" is a hard thing to prove.  So it is risky
> to say users "Never" use available information correctly, and "cannot be
> taught" to do better.
>
>    - What is the probability that this attack will get through my spam
>    filter?
>    - What is the probability that the user will read the message?
>    - What is the probability that the user will click on the hostile link?
>    - What is the probability that my web filter will allow access to the
>    hostile website?
>    - What is the probability that the web filter will allow the attack to
>    be downloaded?
>    - What is the probability that my antivirus program will allow the
>    attack to proceed?
>
> The goal is to decrease the probability of a wrong decision at each point
> in the process.   All I need is for some people to act smarter on some
> occasions in response to some available clue.   But this cannot happen if
> the clue is not provided..
>
> Doug Foster
>

---

From: Joseph Brennan <[email-masked]>
Date: Tue, 21 Jul 2020 15:08:48 -0400

On Tue, Jul 21, 2020 at 1:28 PM Brandon Long
<blong=[email-masked]> wrote:
>
> Do sms/mms programs show the phone number any more?  I think there's been a deliberate strategy to make email clients more like
> other messaging clients, and the technical parts like the actual address are details that most of the time aren't useful to the user... when
> they're not being spoofed, of course, or otherwise need to differentiate between multiple addresses for the same person.
>
-

I think you're right about how non-email messaging clients have
influenced email.

But even in email, Microsoft's Outlook, with its roots as an
intraoffice memo client, has shown only display name as far back as I
know, except when Internet mail comes in with a From header that has
no display name to show. For all its quirks, Outlook is the only
client I can think of that shows the content of the RFC5322 Sender
header, even if it is in the peculiar "x on behalf of y" notation,
which shows display name when there is one and address otherwise.

But we are digressing into a proposal for an Internet Email Client standard.

Joseph Brennan
Lead, Email and Systems Applications

---

From: Jesse Thompson <[email-masked]>
Date: Tue, 21 Jul 2020 16:45:04 -0500

On 7/21/20 6:05 AM, Douglas E. Foster wrote:
>   * What is the probability that this attack will get through my spam filter?
>   * What is the probability that the user will read the message?
>   * What is the probability that the user will click on the hostile link?
>   * What is the probability that my web filter will allow access to the hostile website?
>   * What is the probability that the web filter will allow the attack to be downloaded?
>   * What is the probability that my antivirus program will allow the attack to proceed?
> 

I like this way of thinking, and it seems like a good time to mention the following anecdote for the sake of the "end-users can't make security decisions" argument...

Specifically to address BEC we strip the friendly from (at our MTA gateways prior to ingestion to O365) conditionally (one example: from domains of free email providers) to force the MUA (Outlook and everything else) to show the From address.  

It works because now the victims just see "[email-masked]" instead of "Office of the Provost" and are more likely to consider the message hostile, less likely to click on the weird link, less likely to buy gift cards, and so on.  

I can count on one finger how many people have noticed that we're doing it (it wasn't an end-user, but it was our CRM team who uses friendly from to soft match on contacts) for a population of 150,000 mailboxes.  Meanwhile, we get very few people claiming that we aren't somewhat mitigating BEC scams.

Note that other institutions are tagging Subjects and bodies with EXTERNAL warnings, either to all external sourced email or based on some conditional rules, but they are not directly addressing the display name spoofing itself.  I suspect that people learn to ignore those warnings over time and still fall victim to some well crafted scams from a spoofed VIP in their organization.  

I can't say with certainty which tactic works better (DKIM signature breakage is a wash), but I think forcing the MUA to reveal the sender's identity is more effective, less disruptive, and dovetails nicely with DMARC and the security marketing of the DMARC vendors.

Jesse

---

From: Dave Crocker <[email-masked]>
Date: Wed, 22 Jul 2020 06:23:32 -0700

On 7/21/2020 1:08 AM, Laura Atkins wrote:
> When we’re basing a protocol on “what the user sees” and “what the 
> user can trust” then I think we have to. DMARC says “users can trust 
> that mail from @domain.example is really from @domain.example” but if 
> the user never sees that, how do they know? 

I think this can be connected to the query about threats that DMARC is 
intended to respond to, by virtue of suggesting clarity about /where/ 
the responding takes place.

My contention is that it takes place in a receiving filtering engine and 
does not take place at the user level.

Further, it's one more data point in that engine's analysis process, 
rather than being in any simple way definitive.

In any event, work here really should make a point of creating text that 
is clear about threats DMARC is intended to respond to, and clear about 
where such responding takes place.

To the extent any of that text makes assertions about the performance of 
end users, it needs to cite the basis for the assertions.

d/

---

From: "Doug Foster" <[email-masked]>
Date: Wed, 22 Jul 2020 09:39:38 -0400

Since the conflict between DMARC and Mailing Lists is related to the changes that Mailing List apply to a received message, it may be useful to review the purposes that each of those changes serve, with a goal of eliminating unnecessary changes.

Specifically, this list adds a footer to every message.   Is the footer a "trust indicator" which serves an imaginary purpose, or a necessary addition for other reasons?   If it is added as a trust indicator, perhaps it could be dropped.

I would be willing to format my submissions to IETF specifications, if it would protect the integrity of my signature.   But IETF has not disclosed a way for that to be done.   What I can determine is that the footer addition is currently unconditional, as evidenced by reply messages with multiple copies of the footer, and therefore I cannot prevent my signature from being invalidated.

DF

-----Original Message-----
From: dmarc [mailto:[email-masked]] On Behalf Of Dave Crocker
Sent: Wednesday, July 22, 2020 9:24 AM
To: IETF DMARC WG
Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations

d/

---

From: "John Levine" <[email-masked]>
Date: 22 Jul 2020 13:05:14 -0400

In article <[email-masked]> you write:
>Since the conflict between DMARC and Mailing Lists is related to the changes that Mailing List apply
>to a received message, it may be useful to review the purposes that each of those changes serve, with
>a goal of eliminating unnecessary changes.

I don't believe we have a charter to tell mailing list operators what
to do, even if we believed, against all experience, that they would
take our advice.

As may have been pointed out a few times, mailing lists had been
serving their users perfectly well for decades before AOL and Yahoo made them
DMARC roadkill.

R's,
John

---

From: Jesse Thompson <[email-masked]>
Date: Wed, 22 Jul 2020 17:38:25 -0500

> to do, even if we believed, against all experience, that they would

https://cyber.dhs.gov/bod/18-01/ references https://dmarc.org/wiki/FAQ#I_operate_a_mailing_list_and_I_want_to_interoperate_with_DMARC.2C_what_should_I_do.3F

Who should be giving them advice?

> serving their users perfectly well for decades before AOL and Yahoo made them

Given that the email security industry's marketing now shames domain owners for not adopting DMARC, I think that the statute of limitations for AOL and Yahoo has passed.

Jesse

---

From: Dotzero <[email-masked]>
Date: Wed, 22 Jul 2020 18:53:22 -0400

On Wed, Jul 22, 2020 at 6:38 PM Jesse Thompson <jesse.thompson=
[email-masked]> wrote:

> https://cyber.dhs.gov/bod/18-01/ references
> https://dmarc.org/wiki/FAQ#I_operate_a_mailing_list_and_I_want_to_interoperate_with_DMARC.2C_what_should_I_do.3F
>

Probably not a technical standards group.

> Given that the email security industry's marketing now shames domain
> owners for not adopting DMARC, I think that the statute of limitations for
> AOL and Yahoo has passed.
>

Despite my personal opinions regarding mailing lists, DMARC and anti-abuse,
this working group is not the running dog for the email security industry's
marketing efforts to shame domain owners. Perhaps you would like to submit
an Internet Draft on how to resist feeling shamed. I have a feeling it
would be informational at best.

I would also suggest that this group, lacking significant representation of
MUA providers, should also refrain from thinking it reasonable that this
group should tell MUA providers how they should go about their business.

Michael Hammer

---

From: Joseph Brennan <[email-masked]>
Date: Thu, 23 Jul 2020 09:07:27 -0400

> It calls into question whether we (or any domain) should publish DMARC policies.  Gmail.com doesn't publish a DMARC policy, after all, and many people (such as some on this list) are using gmail.co…

I interpret Gmail's approach as a fine marketing decision. It means
mail from gmail.com is more deliverable than mail from yahoo and aol.
They must be smiling every time some domain rejects end-user mail for
DMARC violations.

> I think that we just have to agree that From-munging by MLMs is a permanent reality.  It needs to be documented more prominently (and promoted as part of the DMARC marketing) so that implementation…

I'd be happier for the proposed standard to say that DMARC policy
"SHOULD NOT" be compromised by rewriting From lines-- and see how that
goes over. My reasoning is that blessing the practice makes it easier
for bad actors to craft spoofed mail and get it accepted. The opposite
of the purpose of DMARC, isn't it?

---

From: Joseph Brennan <[email-masked]>
Date: Thu, 23 Jul 2020 09:15:01 -0400

On Tue, Jul 21, 2020 at 5:45 PM Jesse Thompson
<jesse.thompson=[email-masked]> wrote:

> It works because now the victims just see "[email-masked]" instead of "Office of the Provost" and are more likely to consider the message hostile, less likely to click on the weird link, less likel…

Briliant!  I wish we were still using Mimedefang. This wouldn't be
hard to code, and the results would be effective.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 23 Jul 2020 06:15:42 -0700

> of the purpose of DMARC, isn't it?

Technical specifications are not policy advisories or expressions of 
opinion.  They definebehavior to be used by actors that are trying to 
follow the specification.  A specification defines a sandbox.  Normative 
statements apply to actors that have chosen to be inside the sandbox.

So, normative language in specifications is meaningful only when it will 
be followed.  Giving directives to actors not participating in the topic 
of the specification is wasteful and likely misleading.

d/

---

From: Benny Pedersen <[email-masked]>
Date: Thu, 23 Jul 2020 15:20:29 +0200

> hard to code, and the results would be effective.

show the source on how to make this work in mimedefang, or will it 
completely fail with spampd ?

---

From: Joseph Brennan <[email-masked]>
Date: Thu, 23 Jul 2020 11:05:59 -0400

> completely fail with spampd ?

Since it is off topic, I will give a short answer. If the Header From
matches /From: anything <string@domain>, check whether domain is one
that needs the rewrite, gmail.com for example, and change the field to
be simply /From: string@domain/.

In Mimedefang, we created a per-message global hash %Header, and
parsed each field (split on :). So for example $Header{from} was the
value of the From header field. The hash was used in various rules. MD
has a built-in function to replace the content of header fields, which
I think is a milter function.

---

From: Benny Pedersen <[email-masked]>
Date: Thu, 23 Jul 2020 17:18:24 +0200

> be simply /From: string@domain/.

ok

> I think is a milter function.

but it fails to not break dkim then

ietf.org have more ips to spare to make not breaking dkim, sadly so many 
experts doing the wrong things :(

---

From: Dave Crocker <[email-masked]>
Date: Sun, 26 Jul 2020 04:32:59 -0700

On 7/20/2020 1:44 AM, Alessandro Vesely wrote:
>> (*) I've seen one posting here or somewhere else that noted that 
>> letting bad mail through can lead to end-users being deceived. I'll 
>> claim that while true, it is not relevant, since the behavior happens 
>> after DMARC, and the like, are relevant.  That is, DMARC, etc., do 
>> not inform the end-user behavior.
>

No.

A specification defines a field of activity.  (A sandbox.) Things 
outside that field are not relevant to the specification, even though 
they might be highly relevant from a larger perspective. There is a 
constant desire to have a specification that involves security-related 
decision-making include the (human) recipient be an actor within the 
scope of the specification. The first paragraph, quoted above, is a 
reminder that we need to resist that desire.

The second paragraph, quoted above, is a reminder about a specific 
example of this, namely about the DMARC specification. It acknowledges 
that, in general, recipients can be deceived, for the specific From: 
field protection that DMARC provides, the recipient is not a relevant actor.

> If DMARC were dependable, maybe users would learn to trust From:. Or 
> maybe not.  Avoiding end user considerations cuts both ways. Yet, we 
> can trust that if we do a well-defined, clear job, then the whole 
> system will work better.

It is expensive and highly risky to create an international standard 
that relies on such a tenuous hope about future behavior, especially in 
the face of consistent empirical evidence that it won't happen.

d/

---

From: Dave Crocker <[email-masked]>
Date: Sun, 26 Jul 2020 04:40:20 -0700

On 7/20/2020 3:05 PM, Jesse Thompson wrote:
> On 7/19/20 1:33 PM,[email-masked]  wrote:
>> To the extent that anyone wants to make an affirmative claim that end-users/are/  relevant to this work, they need to lay that case out clearly, carefully, and with material that provides objective support.(*)
> We're migrating 30,000 lists, of various types/use cases, from a MLM provider that is DMARC-
...
> ** We have had many complaints from users about the From munging **

My wording was not careful enough.  What I /meant/ was: end-users are 
not relevant to the /trust-related decision making/ that is the goal of 
these protection mechanisms.

They certainly /are/ relevant to the sorting/searching/presentation 
issues that are disrupted by having mail authored by the same person 
contain different From: field data.

d/

---

From: Hector Santos <[email-masked]>
Date: Sun, 26 Jul 2020 11:16:57 -0400

On 7/26/2020 7:40 AM, Dave Crocker wrote:

> not relevant to the /trust-related decision making/ that is the goal
> of these protection mechanisms.

This may be a philosophical theory, but in reality, in lieu of having 
deterministic mechanisms, we do have mail systems who do allow the 
user to make these type of trust decisions.  If a trust-related 
question is answered wrong by the user, the true victim is the honest 
sender.

-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos

---

From: Dave Crocker <[email-masked]>
Date: Sun, 26 Jul 2020 09:12:39 -0700

> question is answered wrong by the user, the true victim is the honest 

My comment was about observable behavior, not philosophical anything.

The issue isn't about was is available to users, but what they actually 
do.  Behavior.

d/

---

From: Hector Santos <[email-masked]>
Date: Sun, 26 Jul 2020 14:29:15 -0400

On 7/26/2020 12:12 PM, Dave Crocker wrote:>
> The issue isn't about was is available to users, but what they
> actually do.  Behavior.

Dave, for a number of years of practice, depending in the system or 
service, users have been provided with trust-related decisions . Do 
you need real examples?

Gmail moves spam into Spam box.

If you user do not look into their spam box, their inaction is used to 
give spam weight to false positives.   If the user is looking for 
something, finds it in the spam box, it will see something like this:

    "What is this message in spam? (specific or vague reason)"
    "REPORT NOT SPAM"

Clicking "REPORT NOT SPAM" it doesn't guarantee it will be moved to an 
area you can see it.  It's been reported as lost, you just can't find 
it.  So it is sent again.  The next time another message of the same 
type is received, it will also be placed in the spam box but this time 
it says:

    "What is this message in spam? it is similar to messages 
identified as spam in past"
    "REPORT NOT SPAM"

Clicking "REPORT NOT SPAM" it doesn't guarantee the next transaction 
will not be moved into the spam box the next time.   There are 
properly other behaviors the user must make before the message source 
is "white listed."

I am not sure if we can model this behavior based on the different 
ways it may be done, but let me outline what I have observed with users:

- May never check spam box
- May check if expecting a message unexpectedly delayed.
- Ignore it, it gets weighted as spam.
- Click Report not Spam. Cross finger you can see it in-box.
- Next similar messages are still moved to spam box

It is the last behavior that is concerning because when you are 
dealing with layman users who may see an message in a spam box but 
leave it there, it appears GMAIL will keep adding weight to it as a 
spam, negatively impacting the source identities of the mail.

In the end, the positive of SPAM box are lost because now you are 
forcing the user to scrutinize the Spam Box opening the door to 
reading and accidental clicks. if REPORT NOT SPAM does not clear it 
up, there is even more confusion for the purpose of that button or any 
similar AI learning logic that may be employed.

-- Hector Santos,

---

From: Dave Crocker <[email-masked]>
Date: Sun, 26 Jul 2020 11:34:44 -0700

> service, users have been provided with trust-related decisions . Do 

There is a difference between providing a signal, versus its getting 
received and use.

Please provide objective data that these signals are being perceived and 
used effectively by end users.

d/

---

From: Hector Santos <[email-masked]>
Date: Sun, 26 Jul 2020 15:07:16 -0400

On 7/26/2020 2:34 PM, Dave Crocker wrote:
> Please provide objective data that these signals are being perceived
> and used effectively by end users.

Dave, I made a mistake to preempt the remaining comment by saying  "Do 
you need real examples?"  I thought I had removed it.  It was rude. Sorry.

Please read the remaining part in my previous message with my input 
explaining how GMAIL provides Trust-Related decision options to the 
layman user mail reader.

There is a lot more to this and I need to go.   I think you are 
correct in suggesting the user has no input in the protocols are are 
looking for.   Its the deterministic vs subjective/learning/heuristics 
protocols issue again.  In reality, we don't have the latter (IETF 
public domain standard for a non-deterministic filtering engine). 
Unless we want to include SpamAssasin as the Default EmailCore AVS 
Engine, it has been a long time missing, desirable part of the total 
picture.  With that engine, users would be a natural part of the 
equation. Unfortunately, we are not there.  But with the former, I 
always thought these deterministic protocols were targeted for 
unsolicited, anonymous transactions where only the AUTHOR DOMAIN, the 
self-signing domain, is the only trusted source.  Not the user or even 
the sender unless IFF there is an Author::Sender association established.

Have a good day, off to relax at the safe-distancing pool.

---

From: Jesse Thompson <[email-masked]>
Date: Fri, 31 Jul 2020 17:00:37 -0500

> of the purpose of DMARC, isn't it?

(sorry, I forgot to reply earlier)

I realize that your worry is valid if anyone attempted to un-munge the messages and then use the un-munged state somehow to validate authenticity.  I assume that un-munging would only be attempted locally if the message passes DMARC and is trusted by local policy.  (Similarly, as I've suggested in other contexts, it would be nice if the Receiver could preemptively communicate this trust to the Intermediary so that the munging didn't need to occur in the first place and ARC could come to fuition, but I digress.)

As others have said, munged messages sent via a MLM aren't much different than someone posting to a web form and it then distributing the post to a set of email recipients.  That web form isn't expecting to be able to use the author's domain, and the pattern it uses in the Friendly From is somewhat arbitrary and could be co-opted by spammers.  

I don't think that bad actors crafting is a huge worry since I think that in both scenarios it would just fall back on the reputation of the domain (and other factors). 

(just spit balling... it's getting late on a Friday...) Perhaps an interesting local policy enforcement (to get at your concern) would be to require that messages with certain Friendly From patterns to be DMARC aligned (regardless of policy) since I could assume that any MLM (that I care about) that's DMARC aware enough to munge would also have aligned SPF and/or DKIM results.

Jesse

---

From: Dave Crocker <[email-masked]>
Date: Fri, 31 Jul 2020 15:41:42 -0700

On 7/23/2020 6:07 AM, Joseph Brennan wrote:
> goes over.

Consider coming along, in the middle of a 45-year practice and suddenly 
declaring the an independent entity, with whom you have no business 
relationship and who has been doing legal things for those 45 years, 
should now stop their legal practices because you've decide to impose a 
new policy on them.

Forget technology.  Consider the inter-organization implications here.

MLMs are independent.  They take delivery of a message.  Delivery, not 
simple relaying.  The post a new message.

You've suddenly made their existing practice fail and so, as is common 
and famous for the Internet, they start routing around the breakage 
you've created.

Please explain how this "should not" you want is reasonable.  Then 
please explain how it is likely to be effective.

d/