Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

From: Alessandro Vesely <[email-masked]>
Date: Sat, 2 Jan 2021 13:08:06 +0100

On Thu 31/Dec/2020 19:36:15 +0100 Michael Thomas wrote:
> On 12/31/20 10:22 AM, John R Levine wrote:
>>>> To what?  The Yahoo address is the only address the scout troop has?
>>>
>>> Copy that to Reply-To: and write a mangled From: that looks troopy but 
>>> passes DMARC.  Just like MLMs do.
>>
>> Lists at MLMs have names that the subscribers will recognize, but the scout 
>> troop only has the Yahoo address.
>>
>> There are certainly kludges that one can apply to circumvent DMARC 
>> rejections, but this is a clear failure, an existing legitimate mail use that 
>> DMARC breaks.
>>
>>
> The entire problem with catering to the long tail is that it is holding hostage 
> better email security. We should stop doing that. There is no right to stasis 
> forevermore. If the scouts email breaks, they can get somebody to fix it. They 
> will thank us in the long run when scammers can't phish using them as a prop.

I agree.  Setting p=none makes DMARC non-actionable.  I, for one, keep p=none 
because of mailing lists.

MLMs seem to be much better than ESPs, since their From: rewriting solves DMARC 
problems effectively, creating only an acceptable noise.

I added two new tickets:
https://trac.ietf.org/trac/dmarc/ticket/92
https://trac.ietf.org/trac/dmarc/ticket/93

Best
Ale
--

---

From: "John Levine" <[email-masked]>
Date: 2 Jan 2021 13:47:18 -0500

In article <[email-masked]>,
>> will thank us in the long run when scammers can't phish using them as a prop.

I agree too. I'm pretty sure there are more small organizations using
provider e-mail addresses than little private mail servers sending
less than 1000 messages a day, so let's declare both of those out of
scope. Or maybe not.

>because of mailing lists.

I keep it because none of my domains are particular phish targets and
I would prefer to get my mail delivered, even the part of it that
DMARC can't describe.

R's,
John

PS: This really is off in the weeds, isn't it?

---

From: Douglas Foster <[email-masked]>
Date: Sat, 2 Jan 2021 13:53:41 -0500

Regarding this section:

   Experience with DMARC has revealed some issues of interoperability
   with email in general that require due consideration before
   deployment, particularly with configurations that can cause mail to
   be rejected.  These are discussed in Section 9.

I suggest replacing it with a scope statement, such as this:

DMARC checks are applicable when a message is received directly from
the domain owner, or received indirectly from a mediator without
in-transit modification.  As discussed in Section 9, these two
criteria do not cover all legitimate email flows.   When a message is
received indirectly with modification, DMARC cannot produce a usable
result, and the message should be evaluated using alternate criteria.
 When messages may have been forwarded with modifications, the
algorithm for distinguishing between authorized and unauthorized
messages becomes difficult to define.

On Thu, Dec 31, 2020 at 12:51 PM John R Levine <[email-masked]> wrote:

> >> The main effect is that the mail they'd been sending from their ESP
> >> with their Yahoo address on the From: line used to work, and now falls
> >> on the floor or worse.
> >
> > Why can't the ESPs do From: rewriting?
>
> Regards,
> John Levine, [email-masked], Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly
>
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: Dave Crocker <[email-masked]>
Date: Sat, 2 Jan 2021 14:06:12 -0800

> The entire problem with catering to the long tail is that it is holding 
> hostage better email security. We should stop doing that.

The entire problem with statements like these is that they provide a 
cavalier dismissal of established practice, while lacking thoughtful 
cost/benefit detail, as well as failing to consider more general 
application of the 'logic'.

Email (and most other online) security has a sufficiently poor record so 
that claims about what is essential to do -- absent compellingly 
validated, reliable, and precise data -- has nothing at all with what is 
essential to do and everything to do with avoiding serious discussion.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 3 Jan 2021 11:49:36 +0100

> messages becomes difficult to define.

I disagree.  Limiting the applicability of DMARC is not going to boost its 
actionable usage.  The above wording boils down to suggesting a sequence of 
operations as follows:

1:  check SPF.  If not pass then the message is indirect.

2:  check DKIM.  If not pass then the message is with modification.  Hence 
DMARC results are not usable.

That would nullify the whole protocol.

Best
Ale
--

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 3 Jan 2021 12:36:42 +0100

On Sat 02/Jan/2021 19:47:18 +0100 John Levine wrote:
> [...]

I don't think so.  There is a very practical outcome.  We should expand Section 
9.5, "Interoperability Issues" and say something actually workable.  And its 
referring to Section 5.2 of RFC 6377, "DKIM Author Domain Signing Practices", 
has done its time and can be dropped.

I recall that MLMs were involved in a discussion about DMARC mitigation 
here[*], before From: rewriting started to take root.  Perhaps, things happened 
that way because, after all, IETF's own mailing lists were affected. 
Conversely, we never addressed the Girls Scout troops problem.

Now, MLMs work well even though From: rewriting isn't standardized yet, while 
ESPs apparently didn't get that hint.  Therefore we should describe From: 
rewriting (and possibly some other workarounds of those) in Section 9.5 of 
dmarcbis, so that everybody knows.  BTW, that's our chance to say /how/ to 
rewrite From:.

We should also encourage large free-mailbox providers to publish selectors with 
trusted ESPs' public keys.  Unlike MLM transformations, ESP messages cannot be 
authenticated by other means.

Best
Ale
-- 

[*] dmarc-ietf] IETF Mailing Lists and DMARC
Cullen Jennings, Wed, 02 November 2016 16:00 UTC
https://mailarchive.ietf.org/arch/msg/dmarc/2uVZ0BVpGoXSviXZxhU-G0sDSNc/

---

From: "John R Levine" <[email-masked]>
Date: 3 Jan 2021 11:09:22 -0500

On Sun, 3 Jan 2021, Alessandro Vesely wrote:
> I don't think so.  There is a very practical outcome.  We should expand 
> Section 9.5, "Interoperability Issues" and say something actually workable.

With some trepidation I ask, like what?

If it's anything like telling mailing lists how to rewrite From lines, 
the answer is no.  That's way out of scope.

Regards,

PS: 10.5

---

From: Douglas Foster <[email-masked]>
Date: Sun, 3 Jan 2021 14:56:59 -0500

You can disagree about whether this wording is appropriate, but there
should be no disagreement about the scope problem.   We do not have a
protocol which can handle all situations, and much of our discussion is
caused by those who apply DMARC to situations where it does not work.

Lets define "legitimate mail" as used in my proposed text to mean "delivery
is desired by the intended recipient and the message contains nothing that
threatens the interest of the user, the interest of the user's network, or
the policies of the user's organization."   Perhaps this is too
restrictive, because it  excludes advertising which is harmless in its
intent but unwanted by the recipient.

What is clear is that by this definition, mailing list messages are
legitimate, and yet are incompatible with DMARC.  Similarly, messages which
are tagged with informational content by a spam filter and then forwarded
at the request of the primary recipient are also legitimate.  In both
cases, specific messages may be unwanted or hostile, but the class of
messages is wanted.

My exception language is still incomplete, because we have another class of
senders who ignore DMARC but are too important to block.    My list in that
category includes a U.S. government agency and two vendors of cloud-based
products for secure web relay.

We need to set appropriate expectations for product developers, email
gateway operators, and domain owners.    Otherwise we end up with wrong
assumptions which lead to products which mindlessly apply a disposition
without providing adequate exception mechanisms.

Address rewriting is NOT the optimal answer to the problem, because it
hides the forwarding operation without addressing the complications that
forwarding creates for correctly evaluating email reputation.

Email evaluation products need to handle all possible scenarios.  This
includes
- forwarded and not forwarded
- with and without SMTP rewrite
- with and without modification.
- with and without From rewrite
- with and without ARC sets
- whether the email header chain is accurately documented or fraudulently
fabricated.

The only way to handle all of these scenarios is for the email filter to
examine the entire chain of Received headers and other headers.   There is
no simple algorithm for performing this analysis.   There is an opportunity
for IETF to provide ways for legitimate MTAs to facilitate this process,
and ARC is a step in the right direction, but only a first step.

We may be able to promote DMARC adoption by overselling its capabilities,
but I do not see that as a good thing.

DF

On Sun, Jan 3, 2021 at 7:48 AM Douglas Foster <
[email-masked]> wrote:

> But we do not have a comprehensive protocol, so we need to set appropriate
> expectations.
>
> I will define "legitimate mail" as used in my proposed text to mean
> "delivery is desired by the intended recipient and the message contains
> nothing that threatens the interest of the user, the interest of the user's
> network, or the policies of the user's organization."
>
> Either mailing list messages, as a class are legitimate, or not -- and we
> have concluded that they are.   (Indvidual messages could be in either
> category.)    Messages that are tagged by a spam filter and then forwarded
> to the recipients alternate mailbox are also legitimate.  We need to set
> appropriate expectations for product developers, email gateway operators,
> and domain owners. My exception language is actually still incomplete,
> because we have the category of senders who ignore DMARC but are too
> important to block.    My list in that category includes a U.S. government
> agency and two vendors of cloud-based email filtering software.
>
> DMARC FAIL can at best provide a data point for a filtering algorithm, as
> was stated in my interchange with Todd.   Claiming more than that will only
> result in misuse of DMARC concepts.
>
> There are real security issues to consider with forwarded mail.   Address
> rewriting hides some of them without solving the problems.   We need an
> in-depth assessment of how to evaluate forwarded mail.   Is this group the
> one to do it or is it assigned somewhere else?
>
> Doug Foster
>
> On Sun, Jan 3, 2021 at 5:50 AM Alessandro Vesely <[email-masked]> wrote:
>

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 4 Jan 2021 12:50:12 +0100

> caused by those who apply DMARC to situations where it does not work.

Let me object to the consistency of this point of view.  Unlike PGP, DMARC is 
not designed as an end-to-end protocol.  The only way that a user could decide 
on a per-message basis whether or not her message should be subject to which 
policy would be to have a variety of domains configured with each policy and 
then set her From: header field appropriately.  Clearly not a viable mode of 
operation.

A general purpose domain can have email users and some transactional mail as 
well.  DMARC has to be configured to suite all of them.  There are special 
domains, which are highly abused.  They had to direct their users to use 
subdomains for non-transactional mail.  The need to do so can be considered a 
DMARC defect, IMHO.

> intent but unwanted by the recipient.

Having advertisements come /From: advertiser/ is a goal.

> legitimate, and yet are incompatible with DMARC.

No, MLM messages with rewritten From: are fully compatible.

> Similarly, messages which are tagged with informational content by a spam
> filter and then forwarded at the request of the primary recipient are also
> legitimate.

Not sure.  Spam shouldn't be forwarded.

> In both cases, specific messages may be unwanted or hostile, but the class
> of messages is wanted. >

It is much simpler if the sender is DMARC-aware and sends messages that pass 
DMARC.  There is a plethora of legacy devices and servers that send plain old 
mail.  They are a problem and need to be identified and somehow gatewayed or 
delivered skipping DMARC processing.

> forwarding creates for correctly evaluating email reputation.

Hiding depends on how you rewrite and forward.  Receivers can examine ARC 
chains and/or undo MLM transformations so as to deliver a fully meaningful 
message header.

> - whether the email header chain is accurately documented or fraudulently fabricated.

Girl Scout troops will inevitably fall in the not forwarded category.  ESP 
messages, instead, should come /From: ESP/.

> and ARC is a step in the right direction, but only a first step.

I wish it ends up in something deterministic that can be used by small and 
large providers alike.

> but I do not see that as a good thing.

Some people push for domains to migrate toward a strict policy.  They assume 
that p=none is a transitory status.  I wouldn't call that "overselling", as, in 
fact, having p=none currently provides the best deliverability.  Yet, p=none 
makes DMARC non-actionable, which I think is a limitation.

Best
Ale
--

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 4 Jan 2021 13:15:43 +0100

> With some trepidation I ask, like what?

I'd add the whole "Sending side workarounds", mostly as-is, but edited as needed.

> If it's anything like telling mailing lists how to rewrite From lines, the 
> answer is no.  That's way out of scope.

Why?  I read:

     The working group will specify mechanisms for reducing or eliminating
     the DMARC's effects on indirect mail flows, including deployed
     behaviors of many different intermediaries, such as mailing list
     managers, automated mailbox forwarding services, and MTAs that
     perform enhanced message handling that results in message
     modification. Among the choices for addressing these issues are:

(which can hardly be considered fully completed with just ARC), and:

     The working group will document operational practices in terms of
     configuration, installation, monitoring, diagnosis and reporting. It
     will catalog currently prevailing guidelines as well as developing
     advice on practices that are not yet well-established but which are
     believed to be appropriate.

Isn't From: rewriting an operational practice?  It is not so important to tell 
MLMs how to do, since they already seem to do a good job, as it is to tell 
ESPs, which, as you say, don't.

> PS: 10.5

Eh?

10.5.  DMARC Report Format Registry?
Mac OS X 10.5 Leopard?
Magnitude 10.5?

What did you mean?

Best
Ale
--

---

From: Laura Atkins <[email-masked]>
Date: Mon, 4 Jan 2021 12:22:20 +0000

> On 4 Jan 2021, at 11:50, Alessandro Vesely <[email-masked]> wrote:
> 
> 
> 

Yes. 

[snip]

> Girl Scout troops will inevitably fall in the not forwarded category.  ESP messages, instead, should come /From: ESP/.

This incompatible with the above goal of having advertisements come from the advertiser. 

I find it highly problematic that we’re teaching recipients that they get official mail from companies that come from an address that is not connected to the company at all. It further devalues the 5322.from and means that recipients cannot trust the domains that the see there. This is even more true when the domain is one they’ve never heard of and passes all of the checks and comes in with a ‘verified by DMARC.’ 

There is absolutely nothing stopping a phisher from taking advantage of this. In fact, phishers currently do send DMARC verified email where the domain in the 5322.from is unrelated to the links in the message or to the domain being phished. 

This seems to me to be a step along the path of making DMARC irrelevant by teaching recipients that mail with a 5322.from address they don’t recognize is legitimate email. 
 
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: "John Levine" <[email-masked]>
Date: 4 Jan 2021 12:46:22 -0500

In article <[email-masked]> you write:
>There is absolutely nothing stopping a phisher from taking advantage of this. In fact, phishers currently do send DMARC verified email where the
>domain in the 5322.from is unrelated to the links in the message or to the domain being phished. 
>

We went through this same argument with DKIM 15 years ago, explaining
over and over to people who imagined that DKIM was a magic whitelist
bullet that a DKIM signature by itself tells you nothing. It's only
useful if you know something, good or bad, about the domain.

Similarly, DMARC alignment tells you nothing unless you also have a
reputation for the domain. I have trouble imagining why anyone would
think it's a good idea to get alignment by using third party domains
that recipients don't know.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Mon, 4 Jan 2021 09:49:51 -0800

> reputation for the domain.

Authentication creates a noise-free basis for developing an 
indentifier's reputation.

Any activity involving an authenticated identifier is, in fact, the 
responsibility of the agency responsible for that identifier.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
[email-masked]

---

From: Michael Thomas <[email-masked]>
Date: Mon, 4 Jan 2021 09:58:53 -0800

> that recipients don't know.
You don't need to know anything about the originating domain if they 
have a p=reject policy to do as they suggest. For many domains and 
especially commercial domains that is probably exactly the right thing 
to do.

Mike

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 4 Jan 2021 20:24:43 +0100

> This incompatible with the above goal of having advertisements come from the advertiser.

That depends on how you define "advertiser".  If you entrust your communication to an external agent, the advertiser becomes that.  Maybe, an agent they could differentiate by using subdomains, similar to the "onmicrosoft.com" suffix.

> I find it highly problematic that we’re teaching recipients that they get official mail from companies that come from an address that is not connected to the company at all. It further devalues the…

Agreed.

A recipient should somehow trust the ESP, or else discard their messages.

Then, there are several ways that an ESP (or a MLM) can try and convey some kind of transparency of intents.  One can use subdomains and display names.  IMHO, we should add some guidelines about this in the spec.

Of course, publishing the ESP's selectors would complete the entrust better.  The scalability looks similar to that of subscribed feedback loops.

(Managing communication internally is even better.)

> There is absolutely nothing stopping a phisher from taking advantage of this. In fact, phishers currently do send DMARC verified email where the domain in the 5322.from is unrelated to the links in…

We cannot prevent phishers from doing so anyway.  Yet, if we insist on using DMARC nevertheless, authentication will create "a noise-free basis for developing an indentifier's reputation", in Dave's words.

> This seems to me to be a step along the path of making DMARC irrelevant by teaching recipients that mail with a 5322.from address they don’t recognize is legitimate email.

It is as legitimate as the identifier's reputation.

Best
Ale
--

---

From: Douglas Foster <[email-masked]>
Date: Mon, 4 Jan 2021 15:17:46 -0500

I have not seen an identity problem with ESPs, bevause messages are
received directly.  They consistently use their own domain for MailFrom to
ensure SPF pass, and the client domain for From.    Domains that use DMARC
enforcement have signatures.

Additionally, the From domain correctly presents the client identity, so I
do not fear spoofing, even from ESPs that happily provide their services to
criminal domains.  Those that serve criminals have all of their
unclassified clients sent to administrative quarantine.  A small portion
that is found to be wanted traffic will be released and exempted from
quarantine on future messages.

If the same messages were received indirectly, it would be a problem
because the SMTP rewrite hides the ESP identity, so the quarantine would
not happen.  Hence, I must start scanning the entire Received chain and
related headers.

Since everyone deals with the same ESPs, I think everyone needs to do full
scans also.

DF

On Mon, Jan 4, 2021, 2:24 PM Alessandro Vesely <[email-masked]> wrote:

> >> Girl Scout troops will inevitably fall in the not forwarded category.
> ESP messages, instead, should come /From: ESP/.
> >
> That depends on how you define "advertiser".  If you entrust your
> communication to an external agent, the advertiser becomes that.  Maybe, an
> agent they could differentiate by using subdomains, similar to the "
> onmicrosoft.com" suffix.
>
>
> > I find it highly problematic that we’re teaching recipients that they
> get official mail from companies that come from an address that is not
> connected to the company at all. It further devalues the 5322.from and
> means that recipients cannot trust the domains that the see there. This is
> even more true when the domain is one they’ve never heard of and passes all
> of the checks and comes in with a ‘verified by DMARC.’
>
>
> Agreed.
>
> Then, there are several ways that an ESP (or a MLM) can try and convey
> some kind of transparency of intents.  One can use subdomains and display
> names.  IMHO, we should add some guidelines about this in the spec.
>
> Of course, publishing the ESP's selectors would complete the entrust
> better.  The scalability looks similar to that of subscribed feedback loops.
>
> > There is absolutely nothing stopping a phisher from taking advantage of
> this. In fact, phishers currently do send DMARC verified email where the
> We cannot prevent phishers from doing so anyway.  Yet, if we insist on
> using DMARC nevertheless, authentication will create "a noise-free basis
> for developing an indentifier's reputation", in Dave's words.
>
>
> > This seems to me to be a step along the path of making DMARC irrelevant
> by teaching recipients that mail with a 5322.from address they don’t
> recognize is legitimate email.
>
>

---

From: "Jim Fenton" <[email-masked]>
Date: Tue, 05 Jan 2021 10:01:07 -0800

> that recipients don't know.

Because recipients often can’t see (or don’t pay attention to) the 
domain name and the reputation system you postulate doesn’t exist. 
OTOH, getting alignment avoids a restrictive policy that might be 
associated with the original domain.

-Jim

---

From: "Paypal security confirm your password now" <[email-masked]>
Date: 5 Jan 2021 13:17:55 -0500

> Because recipients often can’t see (or don’t pay attention to) the domain 
> name and the reputation system you postulate doesn’t exist. OTOH, getting 
> alignment avoids a restrictive policy that might be associated with the 
> original domain.

I think you're saying that I can always evade DMARC problems by putting an 
address I control on the From line and nobody will notice.  That would 
mean that DMARC is useless.

If that's not what you're saying, could you clarify?

Regards,

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Tue, 5 Jan 2021 10:28:13 -0800

On Tue, Jan 5, 2021 at 10:18 AM Paypal security confirm your password now <
[email-masked]> wrote:

> domain

That is indeed the assertion - as long as you consider 97+% to be "always"
and interpret "nobody" in terms of real human actors (excluding the
automatons on this list) and discount the influence of receiver-level
reputation/filtering mechanisms. Personally, I think those levels of
rounding errors should not be ignored either for good or evil. The
formation of this working group and our initial deliverables provides some
level of concurrence with my personal perspective.

--Kurt

---

From: "Jim Fenton" <[email-masked]>
Date: Tue, 05 Jan 2021 10:50:38 -0800

On 5 Jan 2021, at 10:17, Paypal security confirm your password now 
wrote:

>> Because recipients often can’t see (or don’t pay attention to) 
>> the domain name and the reputation system you postulate doesn’t 
>> exist. OTOH, getting alignment avoids a restrictive policy that might 
>> be associated with the original domain.
>
> I think you're saying that I can always evade DMARC problems by 
> putting an address I control on the From line and nobody will notice.  
> That would mean that DMARC is useless.
>

I used the word “often” and indeed some people will notice as I did. 
But I recall we beat this issue to death a few months ago, although 
I’m not sure what WG consensus on that was, if any.

It looks like we’ve strayed pretty far from the subject line (failure 
reports) though.

-Jim

---

From: Dave Crocker <[email-masked]>
Date: Tue, 5 Jan 2021 11:22:25 -0800

On 1/5/2021 10:28 AM, Kurt Andersen (b) wrote:
>     the domain
>     putting an
> That is indeed the assertion - as long as you consider 97+% to be 
> "always" and interpret "nobody" in terms of real human actors 
> (excluding the automatons on this list) and discount the influence of 
> receiver-level reputation/filtering mechanisms. Personally, I think 
> those levels of rounding errors should not be ignored either for good 
> or evil. The formation of this working group and our initial 
> deliverables provides some level of concurrence with my personal 
> perspective.

From: header field rewriting demonstrates that DMARC is, indeed, trivial 
to defeat (or rather, to route around.)  Also, receiver filtering 
engines are all that matter.  Real-time actions by recipients are 
demonstrably irrelevant to DMARC (and all other anti-abuse) utility.

DMARC has utility because a great deal of spam includes unauthorized use 
of domain names that happen to support DMARC.

Some anti-abuse methods have inherent utility.  They are useful even if 
abusers seek to defeat the methods.  Other methods have utility by 
virtue of correlations with current behavior.  They are useful now, but 
merely require some effort by abusers to defeat (or route around.)

DMARC has the appearance of the former but is actually the latter.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Michael Thomas <[email-masked]>
Date: Tue, 5 Jan 2021 11:34:41 -0800

On 1/5/21 11:22 AM, Dave Crocker wrote:
>
> From: header field rewriting demonstrates that DMARC is, indeed, 
> trivial to defeat (or rather, to route around.)  Also, receiver 
> filtering engines are all that matter.  Real-time actions by 
> recipients are demonstrably irrelevant to DMARC (and all other 
> anti-abuse) utility.
>
That's not the conclusion of the paper that Doug Foster linked to the 
other day. It showed that visual indicators statistically helped. The 
biggest problem was the low deployment rate of DMARC from what I can 
tell from the paper. Everybody here should read that paper IMO.

When I first came back and saw the From rewriting I was very confused by 
what it was until I figured out what was going on. If it were directly 
sent to me I would definitely be suspicious. But Thunderbird shows the 
entire email address when you view it, unlike some of the crappy MUA's 
out there. What we should be agitating for is better MUA's in general 
that care about security. Not IETF, obviously, but the email community 
at large.

Mike

---

From: Dave Crocker <[email-masked]>
Date: Tue, 5 Jan 2021 12:04:59 -0800

On 1/5/2021 11:34 AM, Michael Thomas wrote:
> other day.

1. I've looked back over his postings to this mailing list and am not 
finding the link you refer to.  Please post it (again).

2. A single study is unlikely to be definitive about much of anything.

3. Especially when it counters years of experience, including the Web EV 
experiment:

https://en.wikipedia.org/wiki/Extended_Validation_Certificate

>
>       Effectiveness against phishing attacks with IE7 security UI
>
> In 2006, researchers at Stanford University 
> <https://en.wikipedia.org/wiki/Stanford_University> and Microsoft 
> Research <https://en.wikipedia.org/wiki/Microsoft_Research> conducted 
> a usability study^[21] 
> <https://en.wikipedia.org/wiki/Extended_Validation_Certificate#cite_note-21> 
> of the EV display in Internet Explorer 7 
> <https://en.wikipedia.org/wiki/Internet_Explorer_7>. Their paper 
> concluded that "participants who received no training in browser 
> security features did not notice the extended validation indicator and 
> did not outperform the control group", whereas "participants who were 
> asked to read the Internet Explorer help file were more likely to 
> classify both real and fake sites as legitimate". 

> When I first came back and saw the From rewriting I was very confused 
> by what it was until I figured out what was going on. 

You think you are representative of end users?  Try again.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Michael Thomas <[email-masked]>
Date: Tue, 5 Jan 2021 12:11:53 -0800

> 2. A single study is unlikely to be definitive about much of anything.
https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-hu.pdf

Actual data, actual experiments. Finally. And it's a lot better than all 
of the conjecture here which is the currency of the realm.

> You think you are representative of end users?  Try again.
I use my inner Luddite to use all of the time. It's one of my skills. 
But an MUA designed with security in mind with its UI would go a long 
way too. From re-writing is exactly the wrong thing to do from a 
security standpoint though.

Mike

---

From: Dave Crocker <[email-masked]>
Date: Tue, 5 Jan 2021 12:48:52 -0800

> https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-hu.pdf
thanks.

How carefully did you read the details?  While I suppose the study is a 
bit interesting, it's a very long way from serving as definitive 'proof' 
of much of anything.

> Actual data, actual experiments. Finally. And it's a lot better than 
> all of the conjecture here which is the currency of the realm.
>
You might want to review the actual semantics of the statistical methods 
used for actual experiments.  They don't mean what you seem to think 
they mean. In particular note that the focus of such semantics is on 
negatives, rather than positives.  It's the reason that conclusions 
about affirmative statements require a constellation of studies.

> security standpoint though.

That's been a regular refrain, for decades. Odd that we do not yet see 
actual efficacy, after all that... conjecture.

By now, there should be that constellation of compelling evidence for 
the efficacy of visual indicators with average recipients.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Michael Thomas <[email-masked]>
Date: Tue, 5 Jan 2021 12:55:22 -0800

On 1/5/21 12:48 PM, Dave Crocker wrote:
>>> 1. I've looked back over his postings to this mailing list and am 
>>> not finding the link you refer to.  Please post it (again).
>>>
> How carefully did you read the details?  While I suppose the study is 
> a bit interesting, it's a very long way from serving as definitive 
> 'proof' of much of anything.
>
Who said it was proof? It's data. Very useful data, IMO. Did you read it 
carefully? It took me about a day to digest it. It also says with actual 
data that your assertion that users can't be trusted for anything is not 
correct. Categorical statements without data are always dubious.

Mike

---

From: Dave Crocker <[email-masked]>
Date: Tue, 5 Jan 2021 13:18:07 -0800

On 1/5/2021 12:55 PM, Michael Thomas wrote:
> It also says with actual data that your assertion that users can't be 
> trusted for anything is not correct.

I didn't say that.  And it didn't say that.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Michael Thomas <[email-masked]>
Date: Tue, 5 Jan 2021 13:20:39 -0800

> I didn't say that.  And it didn't say that.
"Also, receiver filtering engines are all that matter." The word all 
includes human beings. That's the nature of "all".

And you are wildly off topic.

Mike

---

From: Dave Crocker <[email-masked]>
Date: Tue, 5 Jan 2021 13:49:01 -0800

On 1/5/2021 1:20 PM, Michael Thomas wrote:
>>> It also says with actual data that your assertion that users can't 
>>> be trusted for anything is not correct.

1. In terms of average use for typical email, it is.

2. The quoted statement has no semantic relationship to what you claimed 
I asserted (above).

> And you are wildly off topic.

'we' might be. but note that I'm merely responding to your own content.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Michael Thomas <[email-masked]>
Date: Tue, 5 Jan 2021 13:58:08 -0800

> 1. In terms of average use for typical email, it is.
What study asserts that for email? You wouldn't take my word for it if I 
said that. But of course I wouldn't make a categorical statement without 
empirical evidence.

You really should read the paper. It's quite clever what they did, and 
provides a lot of interesting information to consider. It was very 
interesting to see what was happening in the wild instead of the 
conjecture that informs most of what goes on. They apparently have a 
follow on study they're working on.

Mike

---

From: Dave Crocker <[email-masked]>
Date: Tue, 5 Jan 2021 14:07:01 -0800

On 1/5/2021 1:58 PM, Michael Thomas wrote:
> What study asserts that for email? You wouldn't take my word for it if 
> I said that. But of course I wouldn't make a categorical statement 
> without empirical evidence.

You seem to be seeing a requirement to prove the negative, while the 
actual requirement is to prove the positive.  A claim that there is 
meaningful efficacy, for average recipients, by having visual trust 
indicators, requires affirmative demonstration that there is.  There is 
no requirement to prove there isn't.  My point is that we have decades 
of belief that it's useful but no demonstration that it actually is.  
And we have history such as the EV effort, showing that it isn't.

Your focus on email, as somehow distinctive, would need some basis for 
ignoring the web experience.  Feel free to provide it.

> You really should read the paper.

Your implication that I haven't is both odd and troublesome.

d/

-- 

Dave Crocker
[email-masked]
408.329.0791

---

From: Michael Thomas <[email-masked]>
Date: Tue, 5 Jan 2021 14:19:40 -0800

On 1/5/21 2:07 PM, Dave Crocker wrote:
>>>>>> It also says with actual data that your assertion that users 
>>>>>> can't be trusted for anything is not correct.
>>>> "Also, receiver filtering engines are all that matter." The word 
>>>> all includes human beings. That's the nature of "all".
>> What study asserts that for email? You wouldn't take my word for it 
>> if I said that. But of course I wouldn't make a categorical statement 
> indicators, requires affirmative demonstration that there is.  There 
> is no requirement to prove there isn't.  My point is that we have 
> decades of belief that it's useful but no demonstration that it 
> actually is.  And we have history such as the EV effort, showing that 
> it isn't.
>

Your example of web is fraught because web stuff has had visual 
indicators for decades now, and trying to compare EV certs isn't 
especially a good example because the situations are not the same. At 
least this study is directly relevant and it doesn't support your 
categorical statement. This is actually a Good Thing.

I did provide it with that paper. You seem to be dismissing it out of 
hand in favor of something that isn't even email based. We are here 
because of email, so I think that's pretty relevant.

> Your implication that I haven't is both odd and troublesome.
In 15 minutes? It's like 30 pages long and very technical. And you're 
asking me whether I read it closely? If you have read it before, just 
say that. If you haven't you can skip to the part that doesn't support 
your categorical statement.

Mike

---

From: Dave Crocker <[email-masked]>
Date: Tue, 5 Jan 2021 14:43:32 -0800

>> Your focus on email, as somehow distinctive, would need some basis 
>> for ignoring the web experience.  Feel free to provide it.

Oh?  A trust indicator to a user, flagging a domain name, isn't pretty 
much the same?  Please explain.

> At least this study is directly relevant and it doesn't support your 

It is largely unrelated to my observation about efficacy of trust 
indicators for average users..

> because of email, so I think that's pretty relevant.

Except that I didn't 'dismiss' it, out of hand or otherwise.

> your categorical statement.

sigh.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Michael Thomas <[email-masked]>
Date: Tue, 5 Jan 2021 14:57:14 -0800

> much the same?  Please explain.
Pretty much != same. The study was directly about email. If you read it, 
the authors were also skeptical about the efficacy. It sounds like you 
have an issue with the study, not me. Maybe you should take it up with 
them and we can be done. In the mean time, I'll take hard data over your 
speculation.

Mike

---

From: Dave Crocker <[email-masked]>
Date: Tue, 5 Jan 2021 15:44:12 -0800

On 1/5/2021 2:57 PM, Michael Thomas wrote:
>>
>> Oh?  A trust indicator to a user, flagging a domain name, isn't 
>> pretty much the same?  Please explain.
>>
> Pretty much != same.
>
A trust indicator, to a user, flagging a domain name. Essentially the 
same user-oriented mechanism. Web vs. email.  Why and how does that make 
a difference?

The extensive experience with the web EV experiment has been that it 
does NOT make a difference.  Since you seem to dismiss this web 
experience, please explain why it is not relevant to the current topic.

> The study was directly about email. If you read it, the authors were 
> also skeptical about the efficacy.
>
Exactly.  Thank you for noting that.  But, then, it raises the question 
of why you cited it as demonstrating meaningful efficacy for signalling 
DMARC results to end users?

d/

-- 

Dave Crocker
[email-masked]
408.329.0791

---

From: Michael Thomas <[email-masked]>
Date: Tue, 5 Jan 2021 15:50:44 -0800

On 1/5/21 3:44 PM, Dave Crocker wrote:
> same user-oriented mechanism. Web vs. email.  Why and how does that 
> make a difference?
>

I'm dismissing nothing. That is a strawman. I already said why its 
problematic to compare the two which apparently you did dismissing and 
why it's preferable to have an apples-apples comparison.

> Exactly.  Thank you for noting that.  But, then, it raises the 
> question of why you cited it as demonstrating meaningful efficacy for 
> signalling DMARC results to end users?
>
Quit cutting out needed context to make your points. The study directly 
contradicts your categorical statement. Your issue is with the study's 
authors not me. Quit shooting the messenger.

Mike, this is just silly. and typical. I'm done.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 5 Jan 2021 15:55:41 -0800

On 1/5/2021 3:50 PM, Michael Thomas wrote:
>>
> Quit cutting out needed context to make your points. The study 
> directly contradicts your categorical statement.

Except that it doesn't.

  Feel free to provide an serious explanation of why you think 
otherwise, but please put some effort into accurately representing what 
I said or what the study shows.  Attention to detail will help.  
Conclusions are less important than showing your work.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Douglas Foster <[email-masked]>
Date: Tue, 5 Jan 2021 20:11:14 -0500

Sorry that my name was dragged into this.   The study in question was one
provided by Laura Atkins several months ago.   I forwarded it to Michael to
bring him up to speed.   To date, it is the only study submitted to this
group.  I was not trying to introduce new information or re-ignite this
fight.  The chairs and our charter call for us to proceed with DMARC as a
tool to control misuse of the From address, which is also what I want.

To that end, we want to make sender, intermediary, and forwarder interests
converge as much as possible.    Our strategy is for intermediaries to
provide sufficient information for an evaluator to fairly judge whether a
particular message is in his interests or contrary to them.   By my
analysis, we are not there yet.

The particular information that I seek to achieve this result is the
following:
(a) know whether forwarding action(s) have occurred during transit
(b) reconstruct the message identity state prior to the forward(s), so I
can evaluate the message based on both the intermediate and final message
states.

I cannot reconstruct prior state using most ARC sets, because ARC only
provides an identifier if that identifier was evaluated.  Even then, some
of the identifiers are provided in comments or not at all.   Evaluating the
message based on its prior state requires a complete set of identifiers.

DF

---

From: Michael Thomas <[email-masked]>
Date: Tue, 5 Jan 2021 17:19:34 -0800

On 1/5/21 5:11 PM, Douglas Foster wrote:
> Sorry that my name was dragged into this.   The study in question was 
> one  provided by Laura Atkins several months ago.   I forwarded it to 
> Michael to bring him up to speed.   To date, it is the only study 
> submitted to this group. I was not trying to introduce new information 
> or re-ignite this fight.  The chairs and our charter call for us to 
> proceed with DMARC as a tool to control misuse of the From address, 
> which is also what I want.

No it was an unalloyed good that you brought that up. We can use a much 
more data-driven approach rather than opinion and conjecture. It would 
be good for it to be required reading for everybody on this working 
group, and not snarled at as a heresy. DKIM itself was a leap of faith. 
16 years later it is gratifying that we have data.

Mike

---

From: Dave Crocker <[email-masked]>
Date: Tue, 5 Jan 2021 17:22:39 -0800

On 1/5/2021 5:19 PM, Michael Thomas wrote:
> and not snarled at as a heresy. 

Michael,

That was yet another ad hominem from you.  As well as being grossly 
inaccurate.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Michael Thomas <[email-masked]>
Date: Tue, 5 Jan 2021 17:23:45 -0800

> That was yet another ad hominem from you.  As well as being grossly 
Your issue is with the authors of the study. Leave me out of this.

Mike

---

From: Dotzero <[email-masked]>
Date: Wed, 6 Jan 2021 01:02:17 -0500

> 16 years later it is gratifying that we have data.

DKIM was NOT a leap of faith. At the time there was plenty of data from DK
(Domain Keys) and IIM to inform those involved. Please stop making
assertions of "fact" which are simply not true.

Michael Hammer

---

From: Laura Atkins <[email-masked]>
Date: Wed, 6 Jan 2021 10:10:35 +0000

Changed the subject line because this has nothing to do with failure reports. 

> On 5 Jan 2021, at 20:04, Dave Crocker <[email-masked]> wrote:
> 
>>> From: header field rewriting demonstrates that DMARC is, indeed, trivial to defeat (or rather, to route around.)  Also, receiver filtering engines are all that matter.  Real-time actions by recipients are demonstrably irrelevant to DMARC (and all other anti-abuse) utility. 
>>> 
>> That's not the conclusion of the paper that Doug Foster linked to the other day.
> 1. I've looked back over his postings to this mailing list and am not finding the link you refer to.  Please post it (again).
> 
Someone mentioned it was the article I shared a few months ago. If so it’s this one: https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-hu.pdf <https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-hu.pdf>

Note: a single study does not make any conclusion accurate. 
> 2. A single study is unlikely to be definitive about much of anything.
Absolutely true. 

Anyone relying on a single piece of evidence to prove their point is wrong. I am absolutely sure there is a bigger body of research out there and more data. In fact, I was at a conference in SF many years ago reporting a study done between a mailbox provider and a large sender of email. Their study showed quite definitively that visual indicators in email do not affect user behavior in any statistically meaningful way. 

> 3. Especially when it counters years of experience, including the Web EV experiment
> 
>      https://en.wikipedia.org/wiki/Extended_Validation_Certificate <https://en.wikipedia.org/wiki/Extended_Validation_Certificate>Effectiveness against phishing attacks with IE7 security UI
>> 
>> In 2006, researchers at Stanford University <https://en.wikipedia.org/wiki/Stanford_University> and Microsoft Research <https://en.wikipedia.org/wiki/Microsoft_Research> conducted a usability study[21] <https://en.wikipedia.org/wiki/Extended_Validation_Certificate#cite_note-21> of the EV display in Internet Explorer 7 <https://en.wikipedia.org/wiki/Internet_Explorer_7>. Their paper concluded that "participants who received no training in browser security features did not notice the extended validation indicator and did not outperform the control group", whereas "participants who were asked to read the Internet Explorer help file were more likely to classify both real and fake sites as legitimate".

And that’s with the Extended Validation Certificate which required extensive checks by the certification authority. In email anyone can ‘certify’ their mail with DMARC. Bad actors can trivially get a DMARC pass if they control the mail. If we start saying ‘bypass DMARC by rewriting the From: address’ to legitimate mailers then every bad actor on the planet is going to do the same thing. 

Header rewriting is a poor solution to the problem of indirect mail flows. 

>> When I first came back and saw the From rewriting I was very confused by what it was until I figured out what was going on.
I think he’s representative of one kind of enduser. He’s getting a trust indicator in email (DMARC fails) and doesn’t understand what that indicator means or implies. When I shared the relevant piece of the DMARC spec causing the DMARC failure he told me that was ‘all gobbledygook’ and that alignment wasn’t even part of DMARC. 

I think this is exactly one of the types of responses we can expect from end users. 

laura 

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

---

From: Douglas Foster <[email-masked]>
Date: Wed, 6 Jan 2021 07:29:44 -0500

I am no fan of header rewrite, but...

If you are going to talk about "Trust Indicators", we need to define terms,
which has not been done.   Here are my definitions:
- The From header is an Identity Assertion.
- DMARC is an Identity Verification technique.
- A text message saying, "This message verified by DMARC", is a Trust
Indicator.
My definitions are consistent with the way that that one study used a trust
indicator.   Using these definitions, From rewrite has nothing to do with
Trust Indicator research.  If anyone wants to assert different definitions,
please get them on the table.

The fact that users complain about From rewrite is proof that they look at
the information.    This is because it is an Identity Assertion, not a
Trust Indicator.

I accept that actual Trust Indicators have a small effect, but rounding
down  to zero seems like an overstatement.   When fighting malware, I will
take all the help that I can get, even small help.

Lots of organizations use trust indicators and lots of organizations use
DMARC for validating the From address.  Message annotation has gone up
exactly because many MUAs are making the From address visible only on
request.   Common tag lines are now of the form:  "This message is from an
external source, so be careful."   I don't see that it is our job to tell
domain owners that they are wrong,

Domain administrators are within their rights to block any incoming message
for any reason.   Users routinely work with their domain administrators to
ensure that the messages that they want get accepted and messages that they
do not want get blocked.    If users and domain administrators cannot solve
their differences, the user can communicate using a different domain.  If
DMARC produces false positives that cannot be resolved by this process, we
would do well to ask why.

I see no relevance between the EV experience and DMARC.   EV is an identity
verification technique, but it lacked a policy mechanism.   As a website
user, I have no way of knowing whether a particular website MUST have an EV
certificate or not.   If such a policy mechanism existed, it would have
been automated and the site would be blocked.   DMARC has a policy
mechanism, and it has been automated, so messages are blocked.

Forwarding hides information that the email filter needs to make a correct
decision.   Header rewrite hides the problem, but does not solve it.   When
we get the automation right, predicting user behavior will not be necessary.

Doug Foster

---

From: Laura Atkins <[email-masked]>
Date: Wed, 6 Jan 2021 12:52:33 +0000

> On 6 Jan 2021, at 12:29, Douglas Foster <[email-masked]> wrote:
> 
> If you are going to talk about "Trust Indicators", we need to define terms, which has not been done.   Here are my definitions:
> - A text message saying, "This message verified by DMARC", is a Trust Indicator.
> My definitions are consistent with the way that that one study used a trust indicator.   Using these definitions, From rewrite has nothing to do with Trust Indicator research.  If anyone wants to assert different definitions, please get them on the table.
> 
> The fact that users complain about From rewrite is proof that they look at the information.    This is because it is an Identity Assertion, not a Trust Indicator.

The header rewriting being proposed - that is header rewriting by the ESP so that the messages that go through their system are rewritten to point to the ESP and not the author of the message - means that the identity assertion is disconnected from the context of a message.

Want to know what mail goes through ESPs? Bank mail, social media mail, marketing mail. Billions of emails a day go through ESPs that you have and have not heard of. 

The proposal at issue is that these ESPs be allowed to rewrite the From  address any message they handle to point to an email address they control. This disconnects the identity in the 5322.from address from the actual sender of the message. 

Most users may know who constantcontact are or mailchimp because they advertise widely. Some might have heard of GoDaddy but do you know what the company name of the GoDaddy ESP is? I don’t off the top of my head. 

> I accept that actual Trust Indicators have a small effect, but rounding down  to zero seems like an overstatement.   When fighting malware, I will take all the help that I can get, even small help.

And now we have a malware company that rewrites headers to point to a domain they own and it passes DMARC and is given a Trust Indicator. Recipients are used to seeing domains they don’t know or understand send trusted mail from their bank, or their girl scout troop, or their social media company. They have no reason to distrust the unfamiliar identity assertion in the from address. 

> Lots of organizations use trust indicators and lots of organizations use DMARC for validating the From address.  Message annotation has gone up exactly because many MUAs are making the From address visible only on request.   Common tag lines are now of the form:  "This message is from an external source, so be careful."   I don't see that it is our job to tell domain owners that they are wrong,

This has nothing to do with header rewriting at all, which is the topic at hand. 

> Domain administrators are within their rights to block any incoming message for any reason.   Users routinely work with their domain administrators to ensure that the messages that they want get accepted and messages that they do not want get blocked.    If users and domain administrators cannot solve their differences, the user can communicate using a different domain.  If DMARC produces false positives that cannot be resolved by this process, we would do well to ask why.

Header rewriting doesn’t solve false positives, it increases the chances of them. Header rewriting for commercial messages by ESPs means that folks attempting to masquerade as a legitimate company have a RFC recommended way to evade DMARC and pretend to be the company they’re attacking. 

This isn’t random speculation, this is what is going to happen. We've spent the last 20 years watching spammers and phishers do everything they can to get mail out. If the DMARC RFC says ‘ESPs should rewrite headers to avoid DMARC policies on mail going through the ESP’ then we’ve just made DMARC utterly worthless. We’ve also set up every company that is currently using DMARC p=reject to be attacked in ways they cannot tract. 

> I see no relevance between the EV experience and DMARC.   EV is an identity verification technique, but it lacked a policy mechanism.   As a website user, I have no way of knowing whether a particular website MUST have an EV certificate or not.   If such a policy mechanism existed, it would have been automated and the site would be blocked.   DMARC has a policy mechanism, and it has been automated, so messages are blocked.

The whole point here is that header rewriting evades the policy mechanism of DMARC so that messages aren’t blocked.

> Forwarding hides information that the email filter needs to make a correct decision.   Header rewrite hides the problem, but does not solve it.   When we get the automation right, predicting user behavior will not be necessary.

You’re going to need to provide evidence this is the case.

laura

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

---

From: Dave Crocker <[email-masked]>
Date: Wed, 6 Jan 2021 06:12:02 -0800

On 1/6/2021 2:10 AM, Laura Atkins wrote:
>>> When I first came back and saw the From rewriting I was very 
>>> confused by what it was until I figured out what was going on. 
>>
> I think he’s representative of one kind of enduser. 

Each of us is, of course.  But that was not the point in my 
comment/question.

The issue is whether he/you/me are sufficiently representative of an 
'average' user, where average is drawn from a population of millions (or 
these days, possibly billions.)  Because we aren't.

If there were benefit in talking about a highly specialized (and 
extremely tiny) market segment of geek users, then fine.  But we weren't.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Michael Thomas <[email-masked]>
Date: Wed, 6 Jan 2021 06:41:06 -0800

On 1/5/21 10:02 PM, Dotzero wrote:
>
>
> On Tue, Jan 5, 2021 at 8:19 PM Michael Thomas <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> DKIM was NOT a leap of faith. At the time there was plenty of data 
> from DK (Domain Keys) and IIM to inform those involved. Please stop 
> making assertions of "fact" which are simply not true.
>
Um, dude, I was one of the authors of IIM. You're literally claiming to 
know more than me about what was in my head.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Wed, 6 Jan 2021 06:56:29 -0800

On 1/6/21 2:10 AM, Laura Atkins wrote:
> Anyone relying on a single piece of evidence to prove their point is 
> wrong. I am absolutely sure there is a bigger body of research out 
> there and more data. In fact, I was at a conference in SF many years 
> ago reporting a study done between a mailbox provider and a large 
> sender of email. Their study showed quite definitively that visual 
> indicators in email do not affect user behavior in any statistically 
> meaningful way.

Dave made a categorical statement that the only thing that can have an 
effect on phishing is filters. I provided that study as a counterpoint 
which does not support his categorical assertion. He then tried to 
assert that something completely irrelevant to email is pertinent to 
prove his point: another one off study which is irrelevant to email. At 
the very least categorical statements in the face of little data are 
ridiculous, and should be ignored.

> I think he’s representative of one kind of enduser. He’s getting a 
> trust indicator in email (DMARC fails) and doesn’t understand what 
> that indicator means or implies. When I shared the relevant piece of 
> the DMARC spec causing the DMARC failure he told me that was ‘all 
> gobbledygook’ and that alignment wasn’t even part of DMARC.
>
I beg your pardon. I designed and implemented SSP. If you don't know 
what this is, you are unqualified to tell me what I do or don't 
understand. Take your ad hominems elsewhere.

Mike, newbies

---

From: Dotzero <[email-masked]>
Date: Wed, 6 Jan 2021 09:59:39 -0500

> know more than me about what was in my head.

So all the data was in your head? I wasn't using IIM but was publishing DK
and getting feedback from Yahoo! and a few other receivers through private
channels. There were other senders in a similar situation as myself. And
yes, people were discussing things privately (Web of Trust groups). Your
claim that there was no data available at the time is quite simply false.

Michael Hammer

---

From: Michael Thomas <[email-masked]>
Date: Wed, 6 Jan 2021 07:07:38 -0800

On 1/6/21 6:59 AM, Dotzero wrote:
>
>
> On Wed, Jan 6, 2021 at 9:41 AM Michael Thomas <[email-masked] 
>>     DKIM was NOT a leap of faith. At the time there was plenty of
>>     data from DK (Domain Keys) and IIM to inform those involved.
>>     Please stop making assertions of "fact" which are simply not true.
>>
>     Um, dude, I was one of the authors of IIM. You're literally
>     claiming to know more than me about what was in my head.
>
>     Mike
>
>
> So all the data was in your head? I wasn't using IIM but was 
> publishing DK and getting feedback from Yahoo! and a few other 
> receivers through private channels. There were other senders in a 
> similar situation as myself. And yes, people were discussing things 
> privately (Web of Trust groups). Your claim that there was no data 
> available at the time is quite simply false.
>
You are literally telling me what I knew at the time. It was a lot of 
the reason that we got push back to form the DKIM working group. It 
wasn't until I read that paper that I got some concrete feel for how it 
affected things, and that was 16 years later. The biggest change for the 
better was senders closing open relays. It's still not clear that DKIM 
had any affect on that.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Wed, 6 Jan 2021 07:14:04 -0800

On 1/6/21 4:52 AM, Laura Atkins wrote:
>
> Most users may know who constantcontact are or mailchimp because they 
> advertise widely. Some might have heard of GoDaddy but do you know 
> what the company name of the GoDaddy ESP is? I don’t off the top of my 
> head.

An extremely dubious assertion. Source? I barely know who they are and 
could not name them unless I saw their names first.

Mike

---

From: Dotzero <[email-masked]>
Date: Wed, 6 Jan 2021 10:17:54 -0500

On Wed, Jan 6, 2021 at 10:07 AM Michael Thomas <[email-masked]> wrote:

>> DKIM was NOT a leap of faith. At the time there was plenty of data from
>> DK (Domain Keys) and IIM to inform those involved. Please stop making
> You are literally telling me what I knew at the time. It was a lot of the
> reason that we got push back to form the DKIM working group. It wasn't
> until I read that paper that I got some concrete feel for how it affected
> things, and that was 16 years later. The biggest change for the better was
> senders closing open relays. It's still not clear that DKIM had any affect
> on that.
>
> Mike
>

No, you are literally telling everyone else how things were. In fact, there
was a lot of data. You are the one who claimed that everything was in your
head and the rest of us have no clue. - "DKIM itself was a leap of faith"
and that we were doing things based on opinion and conjecture. It did not
take 16 years for there to be data. There was data before DK and IIM were
merged to form DKIM.

Michael Hammer

---

From: Laura Atkins <[email-masked]>
Date: Wed, 6 Jan 2021 15:20:08 +0000

> On 6 Jan 2021, at 15:14, Michael Thomas <[email-masked]> wrote:
> 
> 
> An extremely dubious assertion. Source? I barely know who they are and could not name them unless I saw their names first.

That was actually my point. One you decided to clipp out of the email you’re replying to. Having these companies rewrite the 5322.from address to domains they control does not increase security. It is an end run around the small amount of protection DMARC offers and is a bad idea. 

laura 

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

---

From: Michael Thomas <[email-masked]>
Date: Wed, 6 Jan 2021 07:23:17 -0800

On 1/6/21 7:20 AM, Laura Atkins wrote:
>
>
>> On 6 Jan 2021, at 15:14, Michael Thomas <[email-masked] 
>>> Most users may know who constantcontact are or mailchimp because 
>>> they advertise widely. Some might have heard of GoDaddy but do you 
>>> know what the company name of the GoDaddy ESP is? I don’t off the 
>>> top of my head.
>>
>> An extremely dubious assertion. Source? I barely know who they are 
>> and could not name them unless I saw their names first.
>
> That was actually my point. One you decided to clipp out of the email 
> you’re replying to. Having these companies rewrite the 5322.from 
> address to domains they control does not increase security. It is an 
> end run around the small amount of protection DMARC offers and is a 
> bad idea.
>
I agree about From rewriting. But your assertion here is extremely 
dubious. But mailing lists should just die, IMO.

https://rip-van-webble.blogspot.com/2020/12/are-mailing-lists-toast.html

Mike

---

From: Michael Thomas <[email-masked]>
Date: Wed, 6 Jan 2021 07:26:23 -0800

On 1/6/21 7:17 AM, Dotzero wrote:You are literally telling me what I 
knew at the time. It was a lot of the reason that we got push back to 
form the DKIM working group. It wasn't until I read that paper that I 
got some concrete feel for how it affected things, and that was 16 years 
later. The biggest change for the better was senders closing open 
relays. It's still not clear that DKIM had any affect on that.
>
>     Mike
>
>
> No, you are literally telling everyone else how things were. In fact, 
> there was a lot of data. You are the one who claimed that everything 
> was in your head and the rest of us have no clue. - "DKIM itself was a 
> leap of faith" and that we were doing things based on opinion and 
> conjecture. It did not take 16 years for there to be data. There was 
> data before DK and IIM were merged to form DKIM.
>
What data? Data that showed what? That's completely news to me. You 
weren't even part of the informal group who caused DKIM to be created, iirc.

Mike

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 6 Jan 2021 07:58:16 -0800

On Wed, Jan 6, 2021 at 7:26 AM Michael Thomas <[email-masked]> wrote:

> there was a lot of data. You are the one who claimed that everything was in
> your head and the rest of us have no clue. - "DKIM itself was a leap of
> faith" and that we were doing things based on opinion and conjecture. It
> did not take 16 years for there to be data. There was data before DK and
> IIM were merged to form DKIM.
>
Everyone,

A working group charter is in some sense a contract between the IESG and
the working group regarding what work it will do, how it will do it, and
what its deliverables are.

I hope it's clear that the discussion taking place here does nothing in
service of that contract.

Please get yourselves back on track without undue delay.

-MSK, your increasingly irritable Area Director

---

From: Dave Crocker <[email-masked]>
Date: Wed, 6 Jan 2021 10:02:45 -0800

On 1/6/2021 6:41 AM, Michael Thomas wrote:
> Um, dude, I was one of the authors of IIM. You're literally claiming 
> to know more than me about what was in my head.

Um, dude, she was claiming there was operational experience, upon which 
DKIM was based.  I don't recall IIM having operational experience, but 
DomainKeys had gone through two rounds of field deployment.  So, 
arguably, she was being kind about IIM.

The issue isn't what was in your head but what was in the field 
experience of the industry.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Dave Crocker <[email-masked]>
Date: Wed, 6 Jan 2021 10:04:31 -0800

On 1/6/2021 7:07 AM, Michael Thomas wrote:
>
> You are literally telling me what I knew at the time.
>

They are literally doing nothing of the kind.  Since you think 
otherwise, please provide sufficient analysis of what they actually 
wrote to explain your rather divergent interpretation of it.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Michael Thomas <[email-masked]>
Date: Wed, 6 Jan 2021 10:06:29 -0800

The AD said to stop an hour ago. So stop.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 6 Jan 2021 10:08:11 -0800

> The AD said to stop an hour ago. So stop. 

And yet, you didn't.

I only just, finally, read his directive.  what's your excuse?

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: "John Levine" <[email-masked]>
Date: 6 Jan 2021 14:11:26 -0500

In article <[email-masked]> you write:
>The header rewriting being proposed - that is header rewriting by the ESP so that the messages that
>go through their system are rewritten to point to the ESP and not the author of the message - means
>that the identity assertion is disconnected from the context of a message.
>
>Want to know what mail goes through ESPs? Bank mail, social media mail, marketing mail. Billions of
>emails a day go through ESPs that you have and have not heard of. 

It's even worse than that. Some ESPs are not very good at managing
their customers. Sendgrid, one of the larger ESPs, sends me a stream
of bank phishes, fake vaccine offers and (for symmetry I suppose)
antivax kookery mixed in with the legit bulk mail and some receipts
for real transactions. They do not have a good reputation and a great
deal of the mail they send goes straight to the junk folder where it
belongs.

Header rewriting is not any sort of solution to the problems that DMARC creates.

R's,
John

---

From: Douglas Foster <[email-masked]>
Date: Wed, 6 Jan 2021 17:57:13 -0500

I don't know how ESPs and From Rewrite ended up in the same sentence.  ESPs
do not need From rewrite because they can do DKIM signing.    The
incentives are all against them using or allowing From rewrite.

Taking business from criminal clients does not include allowing one client
to impersonate another client or a non-client.   Such behavior would hurt
the revenue of the ESP.

---

From: Douglas Foster <[email-masked]>
Date: Wed, 6 Jan 2021 17:58:44 -0500

On this topic:

---

From: Douglas Foster <[email-masked]>
Date: Wed, 6 Jan 2021 18:32:55 -0500

A previous attempt at this reply was sent prematurely.  Sorry about that.

I said:

Laura replied:

Happy to explain, but I have been saying as much for some time.

My source filtering uses five parameters:   Source IP, Reverse DNS of the
Source, Helo name, SMTP address, and From Address.

Assuming that a forwarder adds no threat content, the need to evaluate the
actual source remains.    But this is difficult to do:

-- Forwarding hides the three elements of server identity behind the
forwarding server.
-- SMTP rewrite hides the source domain identity, such as the ESP which
sent the message.
-- From rewrite hides the asserted author identity.

We have hidden everything.   If the forwarder could be trusted to block all
spam, this might not be a concern.   But everybody assesses spam
differently and everybody misses some of it.   As a group, forwarding
services have an incentive to minimize false positives, so the likelihood
of spam getting through is high.   Mailing lists have different incentives,
and should be able to block spam reliably.   Whether they do so or not is
outside my experience.

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 7 Jan 2021 11:14:24 +0100

On Wed 06/Jan/2021 00:55:41 +0100 Dave Crocker wrote:
>> contradicts your categorical statement.
> 
> Except that it doesn't.
> 
> Feel free to provide an serious explanation of why you think otherwise, but 
> please put some effort into accurately representing what I said or what the 
> study shows.  Attention to detail will help.  Conclusions are less important 
> than showing your work.

The report says:
     This returns the email-opening rate of 53.4% and 48.9%. Among these users,
     the corresponding click-through rates are 48.9% (without security
     indicator) and 37.2% (with security indicator) respectively. The
     results indicate that security indicators have a positive impact to reduce
     risky user actions.
https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-hu.pdf

You said:
     My point is that we have decades of belief that it's useful but no
     demonstration that it actually is.  And we have history such as the EV
     effort, showing that it isn't.
https://mailarchive.ietf.org/arch/msg/dmarc/r7unHaCXKKFeotbjU1pL-Jx4f_o

Best
Ale
--

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 7 Jan 2021 13:10:12 +0100

> Most users may know who constantcontact are or mailchimp because they advertise widely. Some might have heard of GoDaddy but do you know what the company name of the GoDaddy ESP is? I don’t off the…

The options we have depend on both identities, the ESP customer, be it a bank 
or a girl scout trooper, and the ESP itself.  If the customer avails itself of 
a free-mailbox provider, the options depend, in turn, on what ancillary 
services does the latter provide.

Ancillary services may include publishing external selectors on behalf of the 
ESP, and authorizing an ESP to use submission on behalf of its customer.  They 
both result in better authentication than From: rewriting.  To cope with girl 
scout troop at a free-mailbox provider, an ESP could also get itself an account 
at that provider and gain DMARC authentication that way.

For cases where the above options don't apply, From: rewriting is an 
established workaround.  We ourselves are using it on this list.  Its 
effectiveness depends on the reputation of the ESP domain.  It might be better 
known than the customer domain, in which case the customer itself may prefer it 
for increased deliverability.

> And now we have a malware company that rewrites headers to point to a domain they own and it passes DMARC and is given a Trust Indicator. Recipients are used to seeing domains they don’t know or un…

Phishing happens irrespective of our recommending From: rewriting or not.

If we do specify it, we could say something like:

DON'T:
From: "Someone <[email-masked]>" <[email-masked]>

DO:
From: "Someone via devil" <[email-masked]>
Reply-To: Someone <[email-masked]>

It seems Mailman is careful enough when it rewrites entries like:
From: "[email-masked]" <[email-masked]>

The latter is an example of bad display names.  It can be accepted, as it's 
sadly so common, as long as the addresses match.  Mismatched addresses like in 
the first example should be interpreted as a sign of phishing, and hence 
trigger filtering or distrust indicators as needed.

Can we say that?

Would such kind of normative help to improve filters and trust indicators?

> Header rewriting doesn’t solve false positives, it increases the chances of them. Header rewriting for commercial messages by ESPs means that folks attempting to masquerade as a legitimate company…

People cannot pretend /to be/ another company, they can only pretend to /be on 
behalf of/ it.  Shouldn't we train users to look at the name after the strudel?

Web browsers came to the conclusion of highlighting the organizational domain 
part of URLs.  (It is one of PSL's uses.)  Do we have data on the effects of 
doing so?

> This isn’t random speculation, this is what is going to happen. We've spent the last 20 years watching spammers and phishers do everything they can to get mail out. If the DMARC RFC says ‘ESPs shou…

Keeping in mind that that attack path is here to stay anyway, we can choose to 
either content ourselves with mentioning it in the Security Considerations, or 
also suggest to use it as a legitimate workaround.

CON:
DMARC may seem to be utterly worthless, since it can be circumvented so easily.

PRO:
The workaround increases deliverability of mail flows from domains with strict 
policies.

IMHO, there is value in certifying DMARC's main identifier.  Increasing the 
deliverability of strict policies will invite more domains to get beyond 
p=none, especially if, eventually, mail from domains with p=none or without 
DMARC record at all is going to be treated with some suspicion.

Mailing lists are going to stick on From: rewriting for the foreseeable future, 
and not standardizing that workaround while we're using it is somewhat 
schizophrenic of our stance.  Undoubtedly, mailing lists are doomed to 
disappear, in the long run.  Meanwhile, they have full citizenship in the email 
panorama.

Best
Ale
--

---

From: "John Levine" <[email-masked]>
Date: 7 Jan 2021 08:21:15 -0500

>Would such kind of normative help to improve filters and trust indicators?

No. As Dave has repeatedly reminded us, when we guess about user
interface features, we invariably guess wrong.

Please can we stop this unproductive thread?

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Thu, 7 Jan 2021 07:25:05 -0800

On 1/7/2021 2:14 AM, Alessandro Vesely wrote:
>> otherwise, but please put some effort into accurately representing 
>> what I said or what the study shows.  Attention to detail will help.  

We've got roughly 25 years of anti-abuse effort.  This includes some 
that have attempted to use end-user trust indicators.  All have proved 
useless.  The entire anti-abuse industry relies on filtering engines, 
not end-user behavior. (End user 'education' is minor and generic.  
There is little or no evidence it has much effect.)

A single, small-sample study under somewhat-controlled conditions does 
not provide 'proof' of efficacy.  At very best, it suggest a line for 
further inquiry.

At the very least, note the Study Limitations section.  Then note that 
studies like these have very, very low correlation factors. A result of 
0.4 is about as good as it ever gets, and that's quite rare.  But it 
means that, at best, the study accounts of only 16% of the behavior, 
leaving 84% due to other factors.  This is not much of a foundation for 
the time and opportunity cost of a standards effort.

 From the cited paper:

> Visual Security Indicators. Security Indicators are
> commonly used in web or mobile browsers to warn users
> of unencrypted web sessions [25, 39, 61, 49], phishing
> web pages [21, 24, 69, 70], and malware sites [7]. Existing work shows 
> that users often ignore the security indicators due to a lack of 
> understanding of the attack [69] or
> the frequent exposure to false alarms [43]

It's significant that their text misses a variety of cognitive 
limitations that are also likely to account for the lack of efficacy.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791