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

From: "Douglas E. Foster" <[email-masked]>
Date: Sun, 21 Jun 2020 15:44:06 -0400

Dave Crocker writes:

The practical problem with From: field munging by MLMs that are
otherwise trying to relay a largely-unmodified messages, is that they
effective destroy author information, by putting in a different email
address.

This is helpful for identifying the three key stakeholder needs:

1) MLM's such as IETF want to alter the author's submission.

2) Authors like Hector want their submission left unmodified

3) Users like Dave want accurate author information in the MUA.

There is no legal corollary for "largely-unmodified".  If I use whiteout on a signed document, spill an ink bottle on hallf of the signature, or replace the special lawyer-only staples with standard staples, the document ceases to be trusted and is probably unenforcable.

The nature of the changes made by the IETF mailing list renders the reverse transformation impossible, so there is no way to validate the transformed document against the original unless the original is obtained, yet the purpose of the transformatiin is to hide the original.  A real solution has to eliminate this operation.  Hector is right.

MLMs could compare a submission against their screening criteria and reject submissions rather than transforming them.   IETF wants text-only subnissions.  Why not simply require text-only?   Because we have a MUA problem:  Some MUAs, including the one I am using, do not provide an option for sending text on ly.   Fix tbe submitter MUA and you eliminate the need for MLM reauthoring.

The recipient need is ironic.   We have established that the MUA's handling of From is unimportant as it has no effect on user behavior, and Dave has been forceful on this point.   But now Dave and others argue that From rewrite is a problem because it reduces the usability of the MUA.  The two positions need to be reconciled.

However, the upshot of this issue is that From rewrite creates a MUA problem and it can be solved with MUA changes. I have previously reported that my 3 MUAs present the IETF header information in 3 different ways.  This is ripe for standadization, and the header rewrite objection can be addressed during that process.

So we have two MUA problems.  Fixing the latter one provides a quick fix while header rewrite continues.   Fixing the former one and changing MLM behavior will take a little longer, but provides a high-integrity end result over time.

IETF also applies Subject tagging, which breaks DKIM signatures.  There are altetnatives for this as well, largely involving MUA tweaks.

DF

---

From: [email-masked]
Date: Mon, 22 Jun 2020 14:53:39 +0200

Hi,

Le 21/06/2020 à 21:44, Douglas E. Foster a écrit :
> 
> There is no legal corollary for "largely-unmodified".  [...]

Then what? An overwhelming majority of users need e-mail for day-to-day
communication, not for binding legal contracts. "Largely-unmodified" as
mailing-lists have been doing it for 40 years is good enough (we usually
don't hear authors complaining that they were impersonated).

People who need a high-integrity validation for each and every message
before reading it are the minority. The rest of us would rather keep our
communication possibilities unimpaired, even if it means dealing with a
bit of spam and use cryptography or out-of-band checks for important
business.

Not to say that DMARC's validation is not valuable per se. But asking
mailing-list (or other) users to jump through hoops to simply
communicate as they have for 40 years is incredibly arrogant.

Cheers,
Baptiste

P.S.: and no, "then don't use DMARC" cannot be the answer. Some time
down the road, it will be forced on us by the large mailhosts, who have
a business interest in curbing spam. So it'd better be done right.

---

From: Hector Santos <[email-masked]>
Date: Mon, 22 Jun 2020 14:49:48 -0400

> 2) Authors like Hector want their submission left unmodified

List Servers has historically modified submissions, the body and 
subject line. It is part of the "package" per se.  Burned in. While 
problematic for DKIM, I doubt that will ever change.

However, my only concern has been always with the RFC5322.From address 
rewriting kludge when done in a blind way.  If the MLM is aware of 
DMARC, then it is intentional ignorant of a security protocol. While 
it may have been done in certain legacy distributions, it was not a 
common practice for List Servers to rewrite the 822/2822/5322.From 
field. What was "rewritten" was the return address for errors & 
bouncing back to the MLM list agent.

A kludge is by definition (by Google) "an ill-assorted collection of 
parts assembled to fulfill a particular purpose."  We ideally view a 
kludge as a temporary solution until a real fix is obtained. But as we 
have learned by practice, a kludge, a temporary solution left 
unaddressed, has a tendency to become permanent. So if the IETF is 
going to sanction this kludge, then we should get it officially IETF 
reviewed, documented, and not via some highly subjective wiki 
primarily authored by one person who believed this was the right thing 
to do without foreseeing the consequences.

> There is no legal corollary for "largely-unmodified".  If I use whiteout on a
> signed document, spill an ink bottle on hallf of the signature, or replace the
> special lawyer-only staples with standard staples, the document ceases to be
> trusted and is probably unenforcable.
>
> The nature of the changes made by the IETF mailing list renders the reverse
> transformation impossible, so there is no way to validate the transformed
> document against the original unless the original is obtained, yet the purpose
> of the transformatiin is to hide the original.  A real solution has to eliminate
> this operation.  Hector is right.

Imo, the resigner performing the rewriting, SHOULD resign using a 
secured resigner domain with the same level protection sought by the 
original author domain.

This would be consistent with the ietf.org only rewriting for domains 
with a p=reject|quarantine DMARC policy. It uses _dmarc.ietf.org for 
the rewriting domain.  Since this _dmarc.ietf.org domain only exist 
for rewriting a p=reject|quarantine domain, it would be technically 
logical for _dmarc.ietf.org to also have a p=reject|quarantine policy 
as well.   This includes using _dmarc.ietf.org for the return address 
to kept with the expected DMARC alignment. That will maintain the 
DMARC aligned protection for the original submission and resigner 
distribution.

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

---

From: Brandon Long <[email-masked]>
Date: Mon, 22 Jun 2020 12:44:31 -0700

> bit of spam and use cryptography or out-of-band checks for important

It's not a minority, it's a majority.  It's the majority which are
routinely subjected
to phishing and spam messages... or at least a large enough minority (100s
of millions?)
that to say it's not important is suspect.

There's no easy way to say "just this mail is important".

If you want a minority, that's people using mailing lists... or even people
using email instead of other messaging protocols, unfortunately.

> communicate as they have for 40 years is incredibly arrogant.

There have been a large number of changes in how email works in the last 40
years,
many things that used to work no longer do.  Open relays, anyone?

> a business interest in curbing spam. So it'd better be done right.

As opposed to the small mailhosts who love letting spam and phishing
messages
rip off their customers?

Brandon

---

From: "Douglas E. Foster" <[email-masked]>
Date: Tue, 23 Jun 2020 01:58:00 GMT

To the chairs:
It has become clear that we do not have consensus on the issue of content-altering mailing lists.

Despite the diversity of viewpoints the number of persons involve in the discussion is fairly small.
Have you identified the stakeholder groups that should be represented in the DMARCbis process for it to be considered sufficiently representative?
Have you made any assessment of whether all such groups are in some way represented in this discussion?
Do we need to do some outreach to ensure that all stakeholder groups are involved

Of course, adding additional voices may make the consensus problem more difficult.  What is your mechanism for resolving consensus problems?

Doug Foster

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 22 Jun 2020 22:29:33 -0700

On Mon, Jun 22, 2020 at 6:58 PM Douglas E. Foster
<[email-masked]> wrote:
> [...]

Are you familiar with RFC 7282?

-MSK

---

From: [email-masked]
Date: Wed, 24 Jun 2020 10:24:59 +0200

Hi,

just answering this one bit, which I believe is at the heart of the 
disagreement:

Le 22/06/2020 à 21:44, Brandon Long a écrit :
> 
> [...]  It's the majority which are 
> routinely subjected
> to phishing and spam messages... 

IMHO "phishing and spam messages" is way too broad a concept to permit 
useful discussion. DMARC nowadays addresses a whole range of problems of 
varying severity to the end user.

When protecting security-sensitive domains like banks, where phishing is 
a major threat to the end user, a fail-closed policy is a necessity, and 
incompatibility with some uses is acceptable.

However, mailboxes with no special security needs call for a different 
tradeoff. From the end user's point of view, spam or addressbook-based 
phishing attempts are small annoyances that they somehow deal with 
(otherwise, they couldn't be using e-mail today). The goal here is an 
incremental win over an acceptable statu quo, not a revolution. No 
legitimate communication should thus be made to ressort to tedious 
workarounds to send mail (mailing-list users having to send every 
message twice, really?) or to find out who said what.

Cheers,
Baptiste

---

From: Dotzero <[email-masked]>
Date: Wed, 24 Jun 2020 11:25:08 -0400

On Wed, Jun 24, 2020 at 9:43 AM <[email-masked]> wrote:

> <SNIP>

I'm curious, could you please provide us with the " whole range of
problems" which you believe DMARC addresses? As far as I know, it only
addresses the problem of direct domain abuse, nothing more and nothing less.

Michael Hammer