Subject: [dmarc-ietf] Agenda requests for Madrid IETF

From: Seth Blank <[email-masked]>
Date: Mon, 20 Jul 2020 11:36:21 -0700

We have a session on the books for IETF108, and would like suggestions from
the group for the agenda, otherwise the chairs will choose relevant topics.
Items in tickets or from the past month are all fair game.

Thanks,

Seth, Tim, and Alexey

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 21 Jul 2020 12:51:04 +0200

On Mon 20/Jul/2020 20:36:21 +0200 Seth Blank wrote:
> We have a session on the books for IETF108, and would like suggestions from the 
> group for the agenda, otherwise the chairs will choose relevant topics. Items 
> in tickets or from the past month are all fair game.

I think *The fate of From:* can be a fair title for summarizing the WG feelings 
about relaxing rules in favor of Sender: (#73), as well as other issues about 
this field, such as multi-address (#74) and the companion Author:.  It'd be 
appropriate to air this topic also in next day's emailcore session.

Best
Ale
--

---

From: Jim Fenton <[email-masked]>
Date: Thu, 23 Jul 2020 20:50:59 -0700

On 7/20/20 11:36 AM, Seth Blank wrote:
> We have a session on the books for IETF108, and would like suggestions
> from the group for the agenda, otherwise the chairs will choose
> relevant topics. Items in tickets or from the past month are all fair
> game.
>
> Thanks,
>
> Seth, Tim, and Alexey
>
I am hoping for a resolution on whether/how to split DMARC into 2 or 3
separate specifications (e.g., aggregated reports, failure reports,
policy). I understand the chairs were discussing this.

-Jim

---

From: Hector Santos <[email-masked]>
Date: Fri, 24 Jul 2020 00:08:43 -0400

> policy). I understand the chairs were discussing this.

+1.

(I believe it will provide necessary focus on a DMARC-BASE spec. Its 
variables and outputs can be defined, registered for the DKIM-REPORTS 
specs.)

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

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Fri, 24 Jul 2020 11:22:43 -0700

On Mon, Jul 20, 2020 at 11:36 AM Seth Blank <seth=
[email-masked]> wrote:

> from the group for the agenda, otherwise the chairs will choose relevant
> topics. Items in tickets or from the past month are all fair game.
>

Based on the recent discussions that have been happening, I think that
there are two key topics that should be hashed out in the F2F:

   1. Jim Fenton's ask to develop a threat model; along with this I think
   we need to more tightly defined the problem statement
   2. Is the goal of this WG to "get DMARC onto the standard track" or is
   it to "solve the spam problem"?

--Kurt

---

From: "John Levine" <[email-masked]>
Date: 24 Jul 2020 14:45:51 -0400

In article <[email-masked]> you write:
>-=-=-=-=-=-

I would hope that we'd all agree that the answer to the second question is obvious.

R's,
John

---

From: Dotzero <[email-masked]>
Date: Fri, 24 Jul 2020 15:04:29 -0400

Apologies, I intended on sending this to the group rather than just Seth.
---------- Forwarded message ---------
From: Dotzero <[email-masked]>
Date: Fri, Jul 24, 2020 at 3:03 PM
Subject: Re: [dmarc-ietf] Agenda requests for Madrid IETF
To: Seth Blank <seth=[email-masked]>

> topics. Items in tickets or from the past month are all fair game.

I would like to see an agenda item as to whether work around "Display Name"
changes are in scope or out of scope for this effort and this working
group. It would seem to me that any such efforts are more appropriate for
the emailcore working group.

I also concur with Kurt Anderson's agenda suggestions. It seems like the
discussions are all over the place and it would be useful to have a clearer
focus on what we are trying to fix/achieve in our discussions.

It would also be nice to get some updates on the status of ARC, which is
supposed to address the concerns regarding intermediaries vis a vis DMARC.
If it is working as intended is it a deployment issue? If it is working as
intended do we need duplicative efforts? I am asking questions, not
suggesting answers.

Michael Hammer

---

From: Dave Crocker <[email-masked]>
Date: Fri, 24 Jul 2020 12:24:00 -0700

On 7/24/2020 12:04 PM, Dotzero wrote:
> It would also be nice to get some updates on the status of ARC

Getting status updates is, of course, useful.

However I will strongly suggest that that be done on the mailing list.  
Real-time sessions are rare and short, so we should try to budget their 
time only for things that require real-time interaction.

Asking for status updates to be posted before the session leaves open 
the possibility of raising questions or comments, as follow-on, without 
taking time for the basic 'presentation'.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 25 Jul 2020 06:48:22 -0700

On Fri, Jul 24, 2020 at 12:05 PM Dotzero <[email-masked]> wrote:

> I would like to see an agenda item as to whether work around "Display
> Name" changes are in scope or out of scope for this effort and this working

A quick read of the current charters suggests to me that it's in scope for
neither.  That seems to be especially true for emailcore.

Do you have such a change to propose?

-MSK

---

From: "Douglas E. Foster" <[email-masked]>
Date: Sat, 25 Jul 2020 14:29:13 GMT

I support an initiative to validate other parts of the mail message, to inhibit the ability of criminal actors to spoof recipients.   The topics that I think need attention include:
Control untrusted content in the Friendly Name.   As suggested, a mechanism is needed to hide or remove untrusted Friendly Names.  This seems to require a way to sign the message with and without the Friendly Name included, as well as methods to configure policy defintions for Friendly Name trust.

Obstruct hijacking of corporate logos.   Existing work with Digital Rights Identifiers seems to be the starting point for this effort.

Validate routing paths and detect suspicious routes.    ARC seems to provide this opportunity.    Currently, any Received header, prior to the first one, cannot be fully trusted, because it might be spoofed.   This is a source of concern even if criminals are not yet spoofing this content.    ARC provides the opportunity to distinguish verified Received headers from unverified ones.   The potential benefits of this information for spam filtering are not yet clear, but I believe those opportunities will become evident in the future.

Embrace multiple authorship.   We need to provide spam filters, mailing lists, and other intermediaries with the ability to add signed content without destroying existing signatures,.  This will require MUAs that understand the multiple authors and can use that knowledge to display the content of different authors with appropriate identifying information.  It will also require supporting protocols to allow incoming gateways and individual users with the ability to control whether an addition is trusted and visible or untrusted and hidden.
These initiatives will add complexity to the email evaluation process.   We know that anything which adds complexity will also create risk that email gateways will become confused and therefore vulnerable.    These initiatives must be carefully vetted to avoid creating new attack methods.   The criminals seem to have more imagination than the rest of us, so attack methods can be difficult to predict.

Doug Foster

----------------------------------------
From: "Murray S. Kucherawy" <[email-masked]>
Sent: 7/25/20 9:49 AM
To: Dotzero <[email-masked]>
Cc: IETF DMARC WG <[email-masked]>
Subject: Re: [dmarc-ietf] Fwd: Agenda requests for Madrid IETF
On Fri, Jul 24, 2020 at 12:05 PM Dotzero <[email-masked]> wrote:
I would like to see an agenda item as to whether work around "Display Name" changes are in scope or out of scope for this effort and this working group. It would seem to me that any such efforts are more appropriate for the emailcore working group.

A quick read of the current charters suggests to me that it's in scope for neither.  That seems to be especially true for emailcore.

-MSK

---

From: "Not Douglas Foster" <[email-masked]>
Date: 25 Jul 2020 12:33:16 -0400

In article <[email-masked]> you write:
>-=-=-=-=-=-
>
>I support an initiative to validate other parts of the mail message, to inhibit the ability of criminal actors to
>spoof recipients. 

I'm reasonbly sure there's no way we can tell in a software protocol
whether someone who is sending a message is a criminal, and it is
quite clear from recent discussion that there is no agreement about
what "spoof" means when applied to e-mail.

Neither of these seem like fruitful directions.

I can also say that attempting to validate the unstructured name
comments is a hopeless swamp if you limit yourself to ASCII and
bottomless pit of despair once you remember that for 30 years
MIME has let you use any text in any character set.

R's,
John

---

From: Dotzero <[email-masked]>
Date: Sat, 25 Jul 2020 22:00:40 -0400

> Do you have such a change to propose?
I was hoping for a ruling that such an effort be ruled out of scope for the
DMARC effort/working group and further discussions be limited by the
Chairs. As "Not Douglas E. Foster" (John Levine)  noted, it is a free form
field. DMARC has been intended from the start to mitigate direct domain
abuse by 3rd parties. I'm hoping that the working group will make better
progress by focusing on issues specific to DMARC and not try boiling the
ocean by trying to "fix" all forms of abuse through this effort. Display
Name abuse is a broader problem that DMARC simply is not in a position to
address. This is especially true as most current implementations are at the
MTA and MUA providers are not visible among the participants in this
working group. My opinion is that trying to address this problem space in
this working group is somewhat like trying to push on a rope.

If the Chairs are willing to make this call then there is no need to have
it as an agenda item for the session given the limited amount of time and
the number of other issues that might be better addressed using that
limited time.

Michael Hammer

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 26 Jul 2020 11:45:48 +0200

On Sun 26/Jul/2020 04:00:40 +0200 Dotzero wrote:
> On Sat, Jul 25, 2020 at 9:48 AM Murray S. Kucherawy wrote:
>> On Fri, Jul 24, 2020 at 12:05 PM Dotzero wrote:
>>
> DMARC effort/working group and further discussions be limited by the Chairs.
> As "Not Douglas E. Foster" (John Levine)  noted, it is a free form field.

Although out of scope, I'd still propose that display name abuse be explicitly 
mentioned in one of the specs as an out-of-scope problem that has to be solved 
at a different level.

> DMARC has been intended from the start to mitigate direct domain

Let me add that, for the sake of Murray's dkim-transform, unlike subject tag 
and footer additions which only need a couple of bits to be undone, display 
name removal would require the full original header field, as in a (partial) z= 
tag.

BTW, dkim-transform, along with From: rewriting, using To:, using Author:, and 
giving up any modifications make for an effective solution of the MLM problem. 
  None of them belongs specifically to DMARC, albeit the spec could mention them.

Dkim-transform, in particular, looks like an update to RFC 6376.  Yet, it might 
be practical for this WG to adopt it.  Shall we discuss that F2F?

Best
Ale
--