Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

From: "Douglas E. Foster" <[email-masked]>
Date: Fri, 19 Jun 2020 09:06:20 -0400

DMARC helps establish a verified identity.  Delivery is based on 
reputation.  The two are very different. 

Unwanted mail with DMARC validation will be blocked on the same basis is 
unwanted mail without it.

But a verified identity is helpful for ensuring that wanted mail is not 
blocked.

There is no vulnerability created by DMARC.

On Jun 19, 2020 1:17 AM, Jim Fenton <[email-masked]> wrote:On 
6/18/20 7:35 PM, Dave Crocker wrote:
> On 6/18/2020 4:01 PM, Jim Fenton wrote:
>> It would be remarkable for IETF to achieve rough consensus on a
>> specification with a known vulnerability while we "wait for the bad
>> actors to catch on." Particularly when that vulnerability relates to an
>> aspect of the specification that has caused widespread deployment
>> problems.
>
> vulnerability?

Yes. When bad actors (your choice of words) can work around an aspect of
the specification that is depended upon to enable differential handling
by a receiving filtering engine (again your choice of words), that is a
vulnerability.

_______________________________________________
dmarc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dmarc

---

From: Todd Herr <[email-masked]>
Date: Fri, 19 Jun 2020 11:18:36 -0400

Laura Atkins wrote:

> DMARC alignment alone is not sufficient for reaching the inbox. Ask all of
> my non spamming clients who manage to screw up their delivery.

I cannot agree more with both of these statements.

There are countless entities in the email ecosystem, both legit senders and
bad actors, who believe that authentication alone is enough to earn the
privilege of delivery to the inbox, and they continue to be misinformed on
that point.

Authentication allows the receiving entity to reliably apply to the message
in question any reputation information that the receiving entity has
accumulated for the verified identity.

A published DMARC policy allows the domain owner to request treatment by
the receiving entity for mail that does not pass authentication checks; the
receiving entity can honor this request or not based on their own local
policies.

-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* [email-masked]
*p:*

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.

---

From: Jim Fenton <[email-masked]>
Date: Fri, 19 Jun 2020 10:08:52 -0700

On 6/19/20 6:06 AM, Douglas E. Foster wrote:
> Unwanted mail with DMARC validation will be blocked on the same basis
> is unwanted mail without it.
>
> But a verified identity is helpful for ensuring that wanted mail is
> not blocked.

A verified identity is established by DKIM and/or SPF. What is DMARC
adding in this respect?

---

From: Dotzero <[email-masked]>
Date: Fri, 19 Jun 2020 13:23:01 -0400

On Fri, Jun 19, 2020 at 1:09 PM Jim Fenton <[email-masked]> wrote:

> Policy expressed by the  domain owner/administrator based on some
combination of DKIM and/or SPF and the feedback loop.

Michael Hammer

---

From: Todd Herr <[email-masked]>
Date: Fri, 19 Jun 2020 13:41:24 -0400

> combination of DKIM and/or SPF and the feedback loop.
Not only that, but DMARC is the only one of the three that is necessarily
tied to the domain in the (usually) visible in the MUA From header.

--

---

From: Laura Atkins <[email-masked]>
Date: Fri, 19 Jun 2020 18:44:33 +0100

> On 19 Jun 2020, at 18:08, Jim Fenton <[email-masked]> wrote:
> 

It’s pushing the verified identity out to bits of the email that the end user (sometimes) sees. 

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: Jim Fenton <[email-masked]>
Date: Fri, 19 Jun 2020 11:22:13 -0700

On 6/19/20 10:41 AM, Todd Herr wrote:
> On Fri, Jun 19, 2020 at 1:23 PM Dotzero <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>
>     On Fri, Jun 19, 2020 at 1:09 PM Jim Fenton <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
Both policy and the feedback loop are actions taken on the basis of
verification of the identity (or lack thereof). They do not establish
the identity themselves.
>
> Not only that, but DMARC is the only one of the three that is
> necessarily tied to the domain in the (usually) visible in the MUA
> From header.
>
That comes back to the question of whether the domain in the From header
is visible in the MUA, and if visible, does it alter user behavior
(e.g., discourage users from clicking phish links). Different people
have different opinions on that. A couple of messages back on this
thread, the blocking of email was discussed and that does not relate to
visibility of the domain in the MUA.

-Jim

---

From: Dave Crocker <[email-masked]>
Date: Fri, 19 Jun 2020 11:40:07 -0700

> necessarily tied to the domain in the (usually) visible in the MUA 

Todd,

There is no evidence that end-users are relevant to 
manipulated/fraudulent From: fields or that DMARC's "certifying" the 
domain name of the From: field is relevant to reducing end-user 
vulnerability.

There is quite a bit of evidence that improving trust signals to end 
users has no significant effect.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Dave Crocker <[email-masked]>
Date: Fri, 19 Jun 2020 11:43:01 -0700

On 6/19/2020 11:22 AM, Jim Fenton wrote:
> That comes back to the question of whether the domain in the From 
> header is visible in the MUA, and if visible, does it alter user 
> behavior (e.g., discourage users from clicking phish links). Different 
> people have different opinions on that. 

A small point that keeps being ignored is that there is quite a bit of 
objective information showing that it does NOT have an effect.  As far 
as I'm aware, there is no objective data that it DOES have an effect.

So, no, this is not just a matter of differing 'opinions'.

d/

---

From: Todd Herr <[email-masked]>
Date: Fri, 19 Jun 2020 16:05:00 -0400

On Fri, Jun 19, 2020 at 2:22 PM Jim Fenton <[email-masked]> wrote:

> verification of the identity (or lack thereof). They do not establish the
> identity themselves.
>
>
> is visible in the MUA, and if visible, does it alter user behavior (e.g.,
> discourage users from clicking phish links). Different people have
> different opinions on that. A couple of messages back on this thread, the
> blocking of email was discussed and that does not relate to visibility of
> the domain in the MUA.
>
>
>

> users has no significant effect.

Nowhere have I made any claim regarding the alteration of user behavior; I
am speaking solely to the idea of DMARC being used to verify an identity,
specifically the domain in the From header. It's my assumption that this
verification is likely to be done by someone other than the user,
specifically their mailbox provider, whom I further assume will make
acceptance and folder placement decisions for a message based on a
combination of factors, including, but definitely not limited to, the
results of all applicable authentication checks. We don't ask users to
perform SPF or DKIM validation checks, so I don't believe that my
assumptions are inconsistent here.

While it's true to say a verified identity is established by DKIM and/or
SPF, which identity is established by these protocols? I've got mail in my
inbox right now that has:

   - in.constantcontact.com as the Return-Path domain; SPF verdict was
   pass, so in.constantcontact.com was verified as being authorized to send
   from the host that originated the message; if we want to call this the
   verification of an identity, so be it.
   - auth.ccsend.com as the DKIM signing domain; DKIM verdict was pass, so
   auth.ccsend.com was verified as the signer, but definitely not the
   purported author, per RFC 6376, section 1.2
   - $MYGOLFCLUB.com as the From domain; no DMARC policy published, so the
   identity was not verified, but I can tell from the content of the message
   that it's legitimate

Now, this mail was wanted mail, so I'm thankful in this case that the
domain doesn't publish a DMARC policy, or else I might not have gotten the
message. Maybe if they did, Constant Contact would enforce a policy of DKIM
signing with $MYGOLFCLUB.com; I don't know how things work at CC. However,
such a tuple of three unaligned domains isn't unheard of, and it is to me a
textbook case of the need for some mechanism for receiving domains to use
to verify the identity associated with the From header. Without such a
mechanism, then there is nothing, save the Acceptable Usage Policy enforced
by my connectivity provider, to prevent me from sending an unlimited amount
of mail using $MYGOLFCLUB.com in the From domain, along with those
disposable domains mentioned upthread for SPF and DKIM. (Whether or not
such messages reach their destination is an open question, based on the
filtering policies in place at the target domains.)

--

---

From: Hector Santos <[email-masked]>
Date: Sat, 20 Jun 2020 10:54:54 -0400

> visibility of the domain in the MUA.

As an "MUA" author/developer, this is a matter on how aggressive the 
end-user client software wishes is to be.  We have seen this evolved 
and increasingly employed over the years.  I can them "Scare Tactics 
Ponzi Schemes."

o Code Signing: Today, developers are being forced to fork up money to 
order to stop scaring users that they are to install "uncertified" 
software.  While I believe this has good reason for FIRST TIME 
installations, I considered it unethical, unfair for established 
developers when the software is already installed and user is merely 
upgrading.

o Self-signed SSL certs:  Today, the browsers, especially Chrome, are 
scaring the "manure" of the laymen users with FALSE complex page 
display indications that they domain just intended to reach is not 
secured. That is false.  The target and common name match and it is 
not expired. What remains is, once again, the lack of an authorized 
3rd party signature requirement.  The domain simply did not wish to 
pay extortion fees to a CA that has a mechanism for an SSL trusted 
chain.  Thanks to Let's Encrypt, this is less of an issue today.

So do we consider advising MUA to add or don't add "Scare Tactics?"

I believe the MUA must begin to become proactive with assisting users 
with the mails DKIM Policy and Trust-based indicators.  I know some 
cites have explored this that was before DKIM POLICY took how. How 
will it play to today with DMARC.  Overall, as a MUA developer, who 
does have new MUA projects in the works, the perpetual mantra that "we 
did that and it didn't work" and the idea that one size (one protocol) 
must fit all and that is must scale, otherwise its useless, doesn't 
really apply anymore.

We need to allow systems who are capable of giving the user more 
confidence with what their eyeballs are seeing explore the considerations.

My take with all this since the beginning was since we don't know all 
the answers on how people will use protocols, we should at least 
provide the considered possible options for them to explore using 
DMARC Tag Extensions.   Here are few that can apply:

Proposed Tag Extensions:

-Rewrite=0|1  if 1, authorize any list system to rewrite 5322.From, 
using the a "standardized" approach that helps keep the domains 
original security.

-atps=0|1  if 1, the domain supports RFC6541 "DomainKeys Identified 
Mail (DKIM) Authorized Third-Party Signatures"

and this one I just came up with to address this MUA display question, 
just winging it now:

-MUA.From={logic to offer MUA on what to display}

The MUA can do its own lookup to see domain's desire to what to 
display. Maybe the options can be:

-MUA.From=0 No advice (default)
-MUA.From=1 Display the Address with User Name
-MUA.From=2 Display just the address
-MUA.From=3 Only Display address when signer domain differs

Of course, with change comes new opportunity.  If the MUA was updated 
to support this tag, then we may not need the tag and just advise the 
MUA to prominently display the address and/or when we have a 3rd party 
resigner involved.

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