Subject: [dmarc-ietf] DMARC-Compliant Mailing Lists

From: Douglas Foster <[email-masked]>
Date: Sun, 3 Oct 2021 20:17:01 -0400

As I hinted in a recent message, I believe that DMARC-compliant mailing
lists are possible.   I have posted a draft which explicates how this can
be done.

Doug Foster

---------- Forwarded message ---------
From: <[email-masked]>
Date: Sun, Oct 3, 2021 at 8:14 PM
Subject: New Version Notification for
draft-fosterd-dmarc-compliant-mailing-lists-00.txt
To: Douglas Foster <[email-masked]>

A new version of I-D, draft-fosterd-dmarc-compliant-mailing-lists-00.txt
has been successfully submitted by Douglas Foster and posted to the
IETF repository.

Name:           draft-fosterd-dmarc-compliant-mailing-lists
Revision:       00
Title:          DMARC Compliant Mailing Lists
Document date:  2021-10-03
Group:          Individual Submission
Pages:          10
URL:
https://www.ietf.org/archive/id/draft-fosterd-dmarc-compliant-mailing-lists-00.txt
Status:
https://datatracker.ietf.org/doc/draft-fosterd-dmarc-compliant-mailing-lists/
Html:
https://www.ietf.org/archive/id/draft-fosterd-dmarc-compliant-mailing-lists-00.html
Htmlized:
https://datatracker.ietf.org/doc/html/draft-fosterd-dmarc-compliant-mailing-lists

Abstract:
   Mailing Lists often make changes to a message before it is
   retransmitted.  This invalidates DKIM signatures, causing a DMARC
   test on the RFC5322.From addres to fail.  A DMARC-compliant mailing
   list is one which uses member alias addresses to identify the
   document as sent by a specific author via the mechanism of the list.
   An appropriate aliasing mechanism will not only prevent DMARC FAIL,
   but will also allow messages between members, will look natural to
   senders and recipients, and will allow list organization domains to
   advance to p=reject.  This document describes an aliasing approach
   which meets these goals.

The IETF Secretariat

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 4 Oct 2021 09:58:40 +0200

On Mon 04/Oct/2021 02:17:01 +0200 Douglas Foster wrote:
> As I hinted in a recent message, I believe that DMARC-compliant mailing lists 
> are possible.   I have posted a draft which explicates how this can be done.

Explaining From: rewriting is a good task by itself.  Perhaps the draft would 
be easier to read it it introduced that workaround first, noting the problems 
it rises afterwards, and finally introducing alias retransmission.

I think John implemented something similar, but doing member to member only for 
recent messages rather than keeping a permanent alias table.  See:
http://lists.dmarc.org/pipermail/dmarc-discuss/2018-October/004201.html

Best
Ale
--

---

From: "John Levine" <[email-masked]>
Date: 4 Oct 2021 22:25:34 -0400

>> are possible.   I have posted a draft which explicates how this can be done.

I took a look, and this appears to be essentially the same sender rewriting hack that I
set up several years ago on my own lists and that the IETF adapted to lists including this one.

It's still a hack, since it forces people to use aliases they do not want and do not
control.

>recent messages rather than keeping a permanent alias table.  See:

I delete the aliases after a few days so they aren't useful for scraping and spamming.

R's,
John

---

From: Baptiste Carvello <[email-masked]>
Date: Tue, 5 Oct 2021 16:17:28 +0200

Hi,

another season, another "From rewriting" proposal. Once again, it more
or less amounts to wishing mailing lists away. So let me try to
articulate precisely what is wrong with all those approaches:

A) The From field
=================

0) Unless I missed something, changing the semantics of RFC5322.From,
even just for mailing lists, is way off charter for this group.

1) The From field semantics are important not just for interoperability
with software systems, but also for "interoperability" with us *humans*,
which makes them especially hard to change :-) This human meaning is
twofold:

a) the "friendly From" conveys *authorship*, that is the (possibly
pseudonymal) identity of an *natural person* who claims credit and
accepts responsibility for the content.

A corporate entity such as a domain is *not* an author. And whatever the
"moderation" mechanism, a censor is just that, and will never be an
author either.

b) the address part provides a *contact point* for the above-defined
author, that must be as much as possible *stable* and under the control
of an entity *trusted by the author*.

2) All proposed "From rewriting" mechanisms fail at least one of the
above requirements. The traditional mechanism blurs the authorship, by
introducing a false sense of *affiliation*. This message is authored by
"Baptiste Carvello", not "IETF" or even "Baptiste Carvello by IETF". I
demand full credit, and I'm sure IETF happily lets me bear full
responsibility.

Any mechanism that rewrites the address alone gives a wrong idea of the
contact point and thus possibly "hijacks" communication attempts. The
present proposal is especially egregious in that is does so without any
hint to the reader. If this happened to me, I would feel like I'm
subject to identity theft, sorry to say.

In fact, I lied, the "unwrapping" mechanism could meet both
requirements. Except that it is vaporware that no MUA has expressed
interest in implementing. And that for all practical purposes, it would
be equivalent to disabling DMARC for mailing-list traffic. Quite a
loophole, right?

B) Mailing lists
================

1) Again, I question the process of redefining the operating principles
of mailing lists in a forum where neither mailing-list operators, nor
developers of mailing-list systems or even MUAs are represented. This
seems like a recipe for "solving" the wrong problem.

Fragmenting the ecosystem by creating a new incompatible "blessed by
DMARC" kind of mailing list is of course worse than everything.

2) Specifically, the present proposal fails to take into account that
mailing lists are fundamentally different from "closed-group
communication systems", not by deficiency, but by *design*.
Interoperability with direct e-mail, including the possibility to
privately reply to the author (or to temporarily invite non-members by
just CC-ing them), is a necessary feature, not a "security hazard" to be
fixed.

3) Many (most?) mailing lists are not "intended to be a closed group"
living only in the "environment" of their hosting domain. They are
communication channels for open communities that have an autonomous
existence, and as such should be resilient even to the loss of their
mailing-list provider (if it closes shop, or "turns evil"). The
community can then only be rescued if users know each-other's real
addresses. Aliases would fail you precisely when you need them most!

C) Now what
===========

So what's my solution? Well I recognize it's not easy, but a first step
could be to mandate that, in the case of DMARC FAIL and p=reject, a
message coming in from a mailing list (with a List-Id header) must not
be bounced, but *ignored*. The rationale is twofold:

1) Bounces produce no useful result whatsoever, as they never reach back
to the originating domain. All they can do is have the recipient users
delisted.

2) DMARC incorporates its own reporting mechanism, which goes to the
right place.

Once DMARC-compliant receivers do this, mailing list operators can
remove their workarounds and happily get out of the way. Messages would
be lost at first, but DMARC-compliant senders and receivers would
collectively bear responsibility for solving *their* problem.

Field-testing new solutions would be easier with only two partners, both
involved in the DMARC community, than with three. I expect those
solutions to be ARC + something…

Cheers,
Baptiste

Le 04/10/2021 à 02:17, Douglas Foster a écrit :
> lists are possible.   I have posted a draft which explicates how this
> can be done.
> 
> Doug Foster
> 
> 
> From: <[email-masked] <mailto:[email-masked]>>
> To: Douglas Foster <[email-masked]
> <mailto:[email-masked]>>
> 
> 
>

---

From: Douglas Foster <[email-masked]>
Date: Tue, 5 Oct 2021 18:30:12 -0400

This is a great analysis, and I am happy to highlight the points of
agreement and disagreement.

Author Identifiers help me associate all the disparate elements of a
communication stream, and they serve as a recall clue to help me integrate
a new message with prior messages.   This is why they need to be permanent
and memorable.   I believe much of the emotion around From Munging comes
from the fact that Author=AuthorDomain@ListDomain is NOT memorable, so it
fails to serve as a recall clue.   Any transition to an alias-based system
will encounter significant resistance because it will break that
permanence.

We clearly disagree about whether mailing list SHOULD be a closed group.
I don't give away my email address lightly.   We use multiple email
addresses for personal purposes, to separate retail mass mailings from
friends.   Facebook is successful for the very reason that it does not give
away email addresses to other participants, even though it probably
compromise our privacy in a thousand other ways.   Closed groups allow me
to disconnect from a mail stream when it becomes problematic.    Once my
email address is published to a list, I lose all control over where it
lands and how it is used.  My defense has been to use an email address
dedicated to this list.

We also disagree about authorship.   I argue that a message received
directly from you is very different from a message received via the list.
 The message from the list is either more trustworthy, if I understand the
list reputation, or less trustworthy, if the list is unrecognized.

You propose special handling of messages from lists, but you gloss over the
difficulties of identifying a list message.    List headers appear in lots
of mass mailings, and any header that cannot be authenticated cannot be
trusted.   IETF list messages are pretty easy to identify because they come
from a single server and I already have a reputation assigned to IETF.   So
I trust the server, not the list identifier.   These features are not
present in the general case.

There is a widespread perception that mailing lists are not currently
subject to address harvesting or list spoofing.   This perception leads to
an assumption that this state will persist forever.    I don't build my
security strategies around assumptions that good luck will last forever.
We need to think about options.   If a change is not necessary now, it is
still useful to plan for what changes will be needed when the situation
changes.

Currently, lists have an outsized impact on network security.   Education
organizations participate in lists.  Lists make participant organizations
unwilling to enforce  DMARC.   As a result, spammers know that universities
are widely respected and easily spoofed, so those domains become weapons.
 Those attacks affect organizations who do participate in DMARC and do not
participate in lists.  So there are ethical issues around the status quo.

In the end, it is a power issue.   As long as participants are willing to
compromise security for list participation, the status quo can continue.
 I can accept the assertion that lists are not politically required to
change right now.  But I do want to break the assumption that their is no
alternative other than to kill lists off.

Doug Foster

On Tue, Oct 5, 2021 at 10:17 AM Baptiste Carvello <
[email-masked]> wrote:

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

---

From: Baptiste Carvello <[email-masked]>
Date: Wed, 6 Oct 2021 11:19:31 +0200

Hi,

I'll just make a few quick points here, as my message from yesterday was
long enough :-)

> We clearly disagree about whether mailing list SHOULD be a closed

Indeed we do, but ultimately it doesn't matter that much.

The relevant question is not what mailing lists *should be*, but what
they *are*.

It just so happens that some people (me included) would rather *not* be
protected from «any risk associated with interacting with strangers» by
some entity out of their control. Which can also mean taking one's own
precautions, as you describe. Still, if I wanted Facebook, I know where
to find them (OK, maybe not yesterday :-)

> directly from you is very different from a message received via the

We indeed disagree. I can understand your point *in theory*. But in
practice, mailing lists do not *substantially* modify the contents of
the messages. This practice is not ensured through any *technical*
means, but through *social* means: reputation, threat of legal action in
the worst case… Communication is not just technology.

FWIW, I would never post to a mailing list that altered the substance of
the messages, *even if* it would also alter the "From" field.

> You propose special handling of messages from lists, but you gloss over
> the difficulties of identifying a list message.    List headers appear
> in lots of mass mailings, and any header that cannot be authenticated
> cannot be trusted.

To clarify my view: I don't believe messages from mailing list should
get a free PASS, except maybe as a temporary measure while a solution is
devised.

What I believe is that DMARC implementers should take their own
responsibilities. If a receiving domain decides to enforce p=reject on
mailing-list messages, they should *silently discard* the messages and
face any related user complaints, not dump the problem onto the mailing
lists operators by bouncing.

> Currently, lists have an outsized impact on network security. 
> […] As a result, spammers know that universities are widely respected
> that universities are widely respected and easily spoofed, so those
> and easily spoofed, so those domains become weapons.

You seem to view mailing lists as the only roadblock towards *universal*
DMARC adoption and subsequent end of all spoofing. I'm afraid this is
way unrealistic…

Anyway, asking mailing lists to sacrifice themselves in the name of the
greater good (or your view thereof) does not seem like a constructive
strategy, nor an efficient one.

Any constructive solution should take mailing lists as they are and work
with those requirements. Otherwise, the situation will stay as stuck as
it has been for several years already.

Cheers,
Baptiste

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 6 Oct 2021 20:22:43 +0200

On Tue 05/Oct/2021 16:17:28 +0200 Baptiste Carvello wrote:
> 
> another season, another "From rewriting" proposal.

Doug's emphasis on aliases tends to give that impression.  Otherwise it can 
finally be a much needed attempt at formalizing the old, known From: rewriting.

> A) The From field

A list claims some responsibility for the message as well.

> "moderation" mechanism, a censor is just that, and will never be an

Right.  They are publishers.

> of an entity *trusted by the author*.

Right.  Yet, posters do trust the MLM operator somewhat.

> demand full credit, and I'm sure IETF happily lets me bear full

The usual rewriting is "Baptiste Carvello *via* IETF".  It is shorter than MS's 
"on behalf of", and hence better.  The draft should cover this detail, IMHO.

> subject to identity theft, sorry to say.

The "via IETF" or similar wording /is/ a hint.  It is both a hint to the user 
and a disambiguator for automated address books.  This too should be mentioned 
in the draft.

> be equivalent to disabling DMARC for mailing-list traffic. Quite a

Which unwrapping are you talking about?  I developed an unwrapping mechanism[*] 
to be used by the server, not the MUA.  It works for posters who sign the 
fields recommended by RFC 6376; that is, for example, not signing Content-Type: 
and MIME-Version:.  The receiving server replaces the munged From: with 
Munged-From: and restores the original value of From:.

[*]
https://datatracker.ietf.org/doc/html/draft-vesely-dmarc-mlm-transform
http://www.tana.it/sw/zdkimfilter/zdkimfilter.html#mlmtrans

> B) Mailing lists

There used to be MLM developers on this list.  Perhaps they unsubscribed due to 
lots of traffic which does not concern mailing lists.  Maybe it is a good idea 
to send them a note.  I sent one to Mailman-Developer.

> DMARC" kind of mailing list is of course worse than everything.

Why is that incompatible?

> just CC-ing them), is a necessary feature, not a "security hazard" to be

Doug's note on authors' privacy addresses a kind of mailing lists.  IETF's 
lists are public and publicly archived.  Other lists preserve anonymity.

In all cases, rewriting From: betters a list's deliverability.

> C) Now what

I agree with Doug on lists not being automatically recognizable as such.

An alternative would be that MLM don't delist when the rejection message text 
contains "DMARC".  I know this is horrible, but there will never be a dedicated 
5xx code for that.  Of course, enabling From: rewriting is easier and cleaner.

> 2) DMARC incorporates its own reporting mechanism, which goes to the

The right place is the list, and it is reached if From: is rewritten.

That's the same logic that has always been in place for bounce addresses, 
except that From: is visible to recipients.  OTOH, DMARC chose that field 
exactly for its visibility.

> remove their workarounds and happily get out of the way.

Requiring all SMTP servers to comply is as weak as the paradigmatic FUSSP[†]. 
ARC suffers a similar syndrome.  In comparison, From: rewriting works 
out-of-the-box.

[†]
https://www.rhyolite.com/anti-spam/you-might-be.html#senior-IETF-member-5

Best
Ale
--

---

From: Douglas Foster <[email-masked]>
Date: Wed, 6 Oct 2021 18:32:30 -0400

We are laying out options, not specifying a MUST,   So there is room for
multiple approaches.   The situation has been stuck because there is no
good way to identify an innocuous edit from a harmless one.

Your proposal stimulated my thinking, so let me try to build on yours and
come back to mine later.   Assume that lists and most of the participating
organizations want to cooperate, and that these evaluators will make
accommodations if the list can be reliably identified.   I can define three
ways that a list can be reliably identified.
The list bounce address is known to the evaluator, and:
- The list bounce address is known to the evaluator and the message is
DKIM-signed by the list bounce address.
- The list bounce address is known to the evaluator, is the message's
MailFrom address, and the message produces SPF PASS.
- The list's server identities are known to the evaluator, and can be
verified by IP address and/or Forward-confirmed DNS.
The signature mechanism is preferred
As a supplement, the LIST-ID could also be known to the evaluator.

How is the "known" information conveyed?   By a disclosure statement
provided during list enrollment.   It says something like this:

This list validates author identity during enrollment and upon message
submission, so messages from this list are not subject to identity-spoofing
attacks.   However, the list also applies standard edits to the message as
it is being relayed, and these changes prevent normal authentication based
on DKIM signatures from being used to validate the author address.
Consequently, participating organizations are requested to bypass author
(From Address) filtering for messages received from this list.    List
messages can be identified by <see above>.   Please ask your email support
organization to implement one of these exception mechanisms so that you can
receive all posts to this list.    If an exception is not granted, From
addresses will be rewritten to work around this constraint, but many
subscribers find that the rewritten address hinders usability."

But many proposals die on the feedback problem.   Even if an evaluator has
made accommodations for the list, the list also needs to know that the
accommodations are in place.    So the rest of the enrollment process needs
to look like this:

"Please indicate the results of your exception request:"
"___ Success. My organization has implemented the accomodation to bypass
sender verification for messages coming from the list."

"If you were unsuccessful, please indicate all of the situations which will
require workarounds:"
"___ A. My organization enforces sender DMARC policies.  Please rewrite any
affected messages."
"___B. My organization will block list messages that use my domain in the
>From address.   Please rewrite these messages."
"___C. My organization applies unconditional blocking of some domains based
on domain suffix.   As the effect of these filters may be unpredictable,
please rewrite all messages coming to me."

A savvy list operator should be able to construct some test messages to
validate the subscriber's submission.  If the subscriber responds to the
test message, then the list operator knows that the test message was
allowed.

The subscriber should have a way to update his assessment at any time.

Something along these lines would allow the list to rewrite messages going
to AOL, rather than rewriting messages coming from AOL and going to
organizations that have accommodated the lists in which they participate.

Because the research is requested before the first message is sent, we
escape the pattern of watching things break and then doing damage control.

Doug Foster

---

From: "John Levine" <[email-masked]>
Date: 6 Oct 2021 19:37:26 -0400

>finally be a much needed attempt at formalizing the old, known From: rewriting.

To point out what I would think is obvious, formalizing a bad idea doesn't make
it any less bad an idea.

R's,
John

---

From: Douglas Foster <[email-masked]>
Date: Wed, 6 Oct 2021 20:04:32 -0400

"Bad idea" is a subjective term, and irrelevant.

The purpose of technical standards is not to get somebody elected, it is to
define solutions to problems.  The critical question is whether a proposal
provides the best available solution to a problem.

I wonder if the mailing list community is actually content with the status
quo, and there is no problem to be solved.   Is From-munging only a minor
nuisance, one that is useful for abusing with friends, but not otherwise
important?

The chairs told us, over a year ago, that DMARCbis would only get approved
if we "solved" the mailing list problem.   I see no reason to conclude that
anything approaching a solution has been put on the table until now.   So I
have been motivated to find a viable solution.  Is change needed or not?
 You tell me.

There simply is no technical solution to the requirement "lists must be
allowed to do things that others cannot, and this must be allowed without
lists having to pre-register themselves with all of their recipient
organizations."   If you want change, you need to relax the constraints
because this constraint is unsolvable.

I defined a complete solution as one that:

   - Produces allow-by-default, even when an unknown list sends a message
   from an unknown author to a new subscriber organization.
   - Allows list messages to be reliably whitelisted from content filters
   that have caused false positives.
   - Protects the list from spoofing.
   - Permits both user-to-list and user-to-user communication

The rest of my proposal flowed from those requirements, and I concluded
that the net benefits are substantial.

If you want weaker requirements, we might be able to produce a weaker
solution.   But do we even have a weaker solution defined?   If so, what
results does it produce, and with what reliability?

Doug

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 07 Oct 2021 00:08:07 +0000

>To point out what I would think is obvious, formalizing a bad idea doesn't make

Agreed.

To give a specific example:

The mobile mail client I use (K-9 Mail) will either display friendly name or email address.  Due to the compact user interface, both isn't an option.

There's one Google Group I'm a member of with a number of users with DMARC p=reject domains, so their addresses are rewritten to the list address.  As a result, when people don't bother to say who they are in a message, I end up digging through the message header to find out who wrote it.

This is not a good user experience.  It's not salvageable.

Scott K

---

From: Laura Atkins <[email-masked]>
Date: Thu, 7 Oct 2021 08:48:12 +0100

> On 7 Oct 2021, at 01:08, Scott Kitterman <[email-masked]> wrote:
> 
> 
> 

Agreed. The other day I was trying to refer work to a colleague I’ve only really interacted with on a professional mailing list. Due to header re-writing and no email address in any other place in the email, I didn’t actually have a direct email address for her. 

It’s also become almost impossible to search for messages from some people in some clients because you can’t search on from: address any longer. 

These are usability and UX problems induced by DMARC. 

laura 

-- 
Having an Email Crisis?  800 823-9674 

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

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

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 7 Oct 2021 11:06:30 +0200

On Thu 07/Oct/2021 00:32:30 +0200 Douglas Foster wrote:
> I can define three ways that a list can be reliably identified.
> - The list bounce address is known to the evaluator and the message is DKIM-signed by the list bounce address.
> - The list bounce address is known to the evaluator, is the message's MailFrom address, and the message produces SPF PASS.
> - The list's server identities are known to the evaluator, and can be verified by IP address and/or Forward-confirmed DNS.

How come a list is known to the evaluator?  I don't want to go hunting each and 
every mailing list I ever subscribed to, let alone pester my users for doing so 
in turn.

For wet dreams, I did outline a three-way opt-in whereby servers become aware 
when their users subscribe to mailing lists...  Let's talk real.

Best
Ale
--

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 7 Oct 2021 11:37:43 +0200

> These are usability and UX problems induced by DMARC.

What do we want to do, then?

Let's exclude, for the sake of reality, both dropping DMARC altogether and 
stopping to use mailing lists.  What realistic possibilities are there?

ARC, when 60% of receivers will have (reliably) implemented it?  This is not 
more realistic than the Vernon's kook I cited upstream.

After careful consideration, header re-writing doesn't have to imply no email 
address in any other place.  Savvy lists save the original From: in Reply-To: 
or Cc:.  If some lists don't do that, perhaps specifying how to re-write From: 
can improve that condition, no?  When everything is done well, it is possible 
to unmunge From: and fully recover pre-DMARC functionality while still enjoying 
DMARC checks.

Do you see other possibilities?

Best
Ale
--

---

From: Laura Atkins <[email-masked]>
Date: Thu, 7 Oct 2021 10:56:19 +0100

> On 7 Oct 2021, at 10:37, Alessandro Vesely <[email-masked]> wrote:
> 
>>>>> Doug's emphasis on aliases tends to give that impression.  Otherwise it can finally be a much needed attempt at formalizing the old, known From: rewriting.

I don’t know, honestly. Convince people to actually sign their emails and put .sig files in? There are multiple lists I’m on that has people who post and I have no idea who it is because they neither sign their messages nor include a .sig file and the list sets the reply-to: as back to the list. Implement a ‘original author / submittor’ header for mailing lists? 

It might be easier to update mailing list software to include a new header than trying to change every SMTP server out there. 

> Let's exclude, for the sake of reality, both dropping DMARC altogether and stopping to use mailing lists.  What realistic possibilities are there?

If I had a realistic solution I’d have proposed it years ago. But just because I don’t have a solution doesn’t mean that any other solution is better than nothing. Sometimes proposed solutions compound the problem, not fix it. 

> ARC, when 60% of receivers will have (reliably) implemented it?  This is not more realistic than the Vernon's kook I cited upstream.
> 
> After careful consideration, header re-writing doesn't have to imply no email address in any other place.  Savvy lists save the original From: in Reply-To: or Cc:.  If some lists don't do that, perhaps specifying how to re-write From: can improve that condition, no?  When everything is done well, it is possible to unmunge From: and fully recover pre-DMARC functionality while still enjoying DMARC checks.

The avalanche has started, it’s too late for the pebbles to vote. 

> Do you see other possibilities?

There are fewer legitimate intermediaries (although there is the inevitable long tail of older installations) than there are legitimate SMTP services. Fixing the mailing list problem by adding a new header to identify the original posters email address may be a better solution than codifying the horrible hack that is From munging / rewriting. 

laura 

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

---

From: Douglas Foster <[email-masked]>
Date: Thu, 7 Oct 2021 06:40:10 -0400

My proposal provides a unique, permanent, user-selected alias which can be
used as a valid email address as long as both sender and receiver are still
subscribed to the same list.   When they want to switch over to actual
email addresses, they use the member-to-member alias communication to
disclose that information to other person.   This design is not
revolutionary; it is used successfully in many other contexts.

   - Scott's problem is that an individual address was rewritten to a
   generic list address.
   - Laura's problem was that the rewritten address was not usable.
   - John complained about users not having control over their rewritten
   list identity.

None of these problems are applicable to my proposal.   Please read the
whole thing.

 Doug Foster

On Wed, Oct 6, 2021 at 8:08 PM Scott Kitterman <[email-masked]> wrote:

> The mobile mail client I use (K-9 Mail) will either display friendly name
> or email address.  Due to the compact user interface, both isn't an option.
>
> There's one Google Group I'm a member of with a number of users with DMARC
> p=reject domains, so their addresses are rewritten to the list address.  As
> a result, when people don't bother to say who they are in a message, I end
> up digging through the message header to find out who wrote it.
>

---

From: Douglas Foster <[email-masked]>
Date: Thu, 7 Oct 2021 06:51:59 -0400

OK, I will talk real.

Message rewriting is a privileged function, because it can be misused.
Privileges require trust and trust requires a trusted identity.

In this context, the privilege has to be granted by the evaluator, and the
list has to know that the evaluator has granted that privilege.

You have two options:
- use only the list organization identity, so that the evaluation is based
on the list identity, OR
- register with the evaluator, so that you are granted privileged status to
use other organization identities, and know that you have been granted
privileged status.

ARC fails on exactly this point.   ARC only works if the evaluator examines
ARC and the List knows that the evaluator will use ARC to allow list
messages.   Without that knowledge, the list has to assume an absence of
trust and use a fallback method of sender rewrite.  When 60% of the world
implements ARC, we will still need 100% From-munging, unless there is
out-of-band communication between the evaluator and the list.

Doug

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 7 Oct 2021 13:37:27 +0200

On Thu 07/Oct/2021 11:56:19 +0200 Laura Atkins wrote:
>>>>>> Doug's [...] can finally be a much needed attempt at formalizing the old, known From: rewriting.
>>>>>
>>>>> formalizing a bad idea doesn't make it any less bad an idea.
>>>>
>>>> Agreed.
>>>

There's Dave's Author: RFC 9057.  It assumes From: rewriting, but doesn't specify it.  It complains that using Reply-To: distorts its meaning, in case the MLM wanted to set it to the list itself, so adds the new field.

RFC 9057 came out as independent submission.  I'd support adopting Doug's I/D, but all this stuff, specifications of DMARC improvements to support indirect mail flows, is part of phase II of the charter, which is considered complete.

> It might be easier to update mailing list software to include a new header than trying to change every SMTP server out there.

Sure!  Maybe it is because the IETF is so slow in reacting.  Maybe the IETF is so slow because there are no beautiful solutions.  The result is that we are confined to techniques which can be applied unilaterally.

> There are fewer legitimate intermediaries (although there is the inevitable long tail of older installations) than there are legitimate SMTP services. Fixing the mailing list problem by adding a ne…

Uh?!?  What's the new field worth for if we don't codify the horrible hack?

My unmunging filter looks at each candidate field, Reply-To:, Cc:, Original-From:, and Author:, and compares the display names with that of From:.  An unvarying way of rewriting would make that easier.

Best
Ale
--

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 07 Oct 2021 09:38:12 -0400

On Thursday, October 7, 2021 5:37:43 AM EDT Alessandro Vesely wrote:
> >>>> finally be a much needed attempt at formalizing the old, known From:
> >>>> rewriting.>>> 
> >>> To point out what I would think is obvious, formalizing a bad idea
> >>> doesn't make it any less bad an idea.
> >> 
> >> Agreed.
> >> 
> >> There's one Google Group I'm a member of with a number of users with
> >> DMARC p=reject domains, so their addresses are rewritten to the list
> >> address.  As a result, when people don't bother to say who they are in a
> >> message, I end up digging through the message header to find out who
> >> wrote it.
> >> 
> > Agreed. The other day I was trying to refer work to a colleague I’ve only
> > really interacted with on a professional mailing list. Due to header
> > re-writing and no email address in any other place in the email, I didn’t
> > actually have a direct email address for her.
> > 
> > It’s also become almost impossible to search for messages from some people
> > in some clients because you can’t search on from: address any longer.
> > 
> After careful consideration, header re-writing doesn't have to imply no
> email address in any other place.  Savvy lists save the original From: in
> Reply-To: or Cc:.  If some lists don't do that, perhaps specifying how to
> re-write From: can improve that condition, no?  When everything is done
> well, it is possible to unmunge From: and fully recover pre-DMARC
> functionality while still enjoying DMARC checks.
> 
> 

I don't think there is a single "solution".  If there was, we would have 
achieved some kind of consensus around it.  There is a mix of different things 
which can be done to mitigate the impact of DMARC on mailing lists.

Personally, I think mailing lists changing From has horrible UX and I don't 
really think anyone disagrees.  It's only advantages are that it's relatively 
easy to implement in a Mailing List Manager (MLM) and it solves the entire 
DMARC problem for a specific mailing list without needing anyone else to change 
anything.  I understand the appeal.

The From field and its related semantics are nearing a half-century in age.  
It's out of our charter's scope to try and change them and even if we could, I 
don't think we should try.  I doubt anyone can anticipate the unintended 
consequences of doing so.

I'm also extremely skeptical of solutions that require user interface changes.  
If reading email "correctly" requires training a non-technical end user, we've 
lost.

Some of you will recall what we did to address the SPF "forwarding problem" in 
Appendix D of RFC 7208.  I suspect that a compendium of solutions like this is 
the best way forward, although I doubt that's the right way to structure it.  
Note that this appendix didn't standardize anything.  For problems that don't 
have a single, or even small, solution set this is essential.

Here's a start on some ideas (none new):

Things a MLM can do on their own:

1.  Don't modify messages in ways that break DKIM signatures
2.  Don't accept messages for delivery by the list from p=reject domains
3.  Rewrite From to avoid negative DMARC assessments (I seriously dislike 
this, but let's not pretend it's going to go away)

Things a MLM can do to support receivers:

1.  Add and DKIM sign List-* header fields
2.  Exclude mail originally from p=reject domains from bounce counts related 
to unsubscribing bouncing list participants
3.  ARC

Things receivers can do
1.  Don't reject based on DMARC fail
2.  ....

I'm out of time, but something like that which defines the solution space 
rather then trying to specify THE solution is probably the only path forward.

Scott K

---

From: Barry Leiba <[email-masked]>
Date: Thu, 7 Oct 2021 09:57:47 -0400

> anything.  I understand the appeal.

I think Scott is right that we all agree that rewriting From mitigates
problems that mailing lists have with DMARC, but at a significant cost
in usability.

I think it would be bad to publish From-rewriting as a standard.

But here:  I think it is reasonable, perhaps advisable, to
informationally document From-rewriting as a mechanism that is in use,
and to include in that documentation a clear exposition of the
problems that it causes.  Why not get those horrible UX issues down on
paper so that when someone decides to deploy it they are better
informed?  Perhaps we can lead people to take steps to reduce the UX
challenges (for example, rewriting the way the IETF is doing it at
least addresses the issue of knowing who sent the message, and how to
reply to the actual sender, as compared to a rewrite directly to the
mailing list address).

Doesn't that make sense?

Barry

---

From: Baptiste Carvello <[email-masked]>
Date: Thu, 7 Oct 2021 15:58:55 +0200

Hi,

(I'm trimming my own message severely to avoid overwhelming the list)

Le 06/10/2021 à 20:22, Alessandro Vesely a écrit :
>> 1) 
>> a)

[…]
>> b)

Traditionally, these have been a very weak "some", and a weak "somewhat".

Mailing list stem from a time where not everything had to be moderated
and sanitized. This old Internet with weak "editors" has served us well,
and though some people want it dead, not everybody has to agree.
Standards should stay neutral on this political matter.

>> 2)
> 
> The usual rewriting is "Baptiste Carvello *via* IETF".  It is shorter
> than MS's "on behalf of", and hence better.  The draft should cover this
> detail, IMHO.

"via" is better than anything else. Still, that's too much emphasis on
what I consider a technical intermediary.

>> hint to the reader. […]
> The "via IETF" or similar wording /is/ a hint.  It is both a hint to the
> user and a disambiguator for automated address books.  This too should
> be mentioned in the draft.

The draft should be much clarified: I had understood it would use the
name alone by default, with some configuration possible for subscribed
users (N.B.: not every list is subscriber-only).

Still, you're only answering the *easy half* of my paragraph: the hard
part is the author's real contact address no more being accessible (with
"traditional" munging, you can at least try and guess it; with this
draft, you can't even).

The alias is only useful if you are a subscriber (I suppose mailing
lists won't resend alien mail) and if it is still operating (any free
service expires eventually…)

In the use case I know best (Open Source development mailing lists),
there are good reasons to contact posters, even years after the fact
(say you have inquiries about an old design decision). An yes,
mailing-list archives often outlive bug/patch trackers.

In the worst case, aliases can lead to communication hijacking. That's
my point B3), which you didn't answer either. Typically the provider of
an Open Source mailing list goes "evil", either with aggressive
monetizing a la sourceforge, or by trying to turn the product proprietary.

> Which unwrapping are you talking about?  I developed an unwrapping
> mechanism[*] to be used by the server, not the MUA. […]

Yes, that's it, thanks for the pointers. I didn't remember it only kicks
in when modifications can be undone. Then, it doesn't create a loophole
in DMARC checks, but is only useful for part of the problem (how big a
part, your draft doesn't say).

>> 1)

It's incompatible with the existing usage patterns of mailing lists and
expectations of the end users, as informed by 40 years of "tradition".
Communication is people talking to people, not domains talking to
domains, so you have to take a broad view of backward compatibility when
a change leaks up to the UI.

>> 2)
>> Doug's note on authors' privacy addresses a kind of mailing lists. 
> IETF's lists are public and publicly archived.  Other lists preserve
> anonymity.

That's not my point. My point is, in the lists I know, preserving
anonymity is a bug, not a feature. Hiding the author's real address
prevents some useful communication patterns. Granted, addresses in
messages bring SPAM, but users already know how to protect themselves.

I'm not denying this is a judgment call which you may well disagree
with. Standards work however should only consider facts: accessibility
of the author's real address is by design, and it has valid use cases.

> In all cases, rewriting From: betters a list's deliverability.

In other words, it solves the problem DMARC introduced, at the expense
of forcing list users to learn new usage patterns. We should not expect
them to be grateful :-)

>> 1)

It depends for what. A message with a "List-Id" header purports to be a
mailing list message. If all you have to decide is whether to bounce a
rejected message or just trash it, why not take this affirmation at face
value?

> An alternative would be that MLM don't delist when the rejection message
> text contains "DMARC".  I know this is horrible, but there will never be
> a dedicated 5xx code for that. […]

That would be a possible variant, but what's the point of producing a
bounce, if it's going to be ignored anyway?

I understand the a priori reluctance to trash a message with no
feedback, but here, the case is well known by now, and bounces only
cause harm (not just delisting, but also DOSing the list operators).

> The right place is the list, and it is reached if From: is rewritten.

The list is only the right place to report breakage if there is
something to fix on its side.

So let's rewind history: mailing lists worked for years and minded their
own business. Then some mail senders and some mail receivers both
implemented this new thing called DMARC, and list operators suddenly get
overwhelmed with bounces.

I'd say the DMARC-implementing senders and receivers collectively
triggered the breakage, and should get the reports and act on them. The
receiver is obviously aware of the messages they trash, the sender is
notified through DMARC Aggregate reports. The list operator doesn't need
to be bothered.

> Requiring all SMTP servers to comply is as weak as the paradigmatic
> FUSSP[†]. ARC suffers a similar syndrome.  In comparison, From:
> rewriting works out-of-the-box.

From: rewriting only "works" if you ignore the requirements of mailing
list users.

Also, requiring all mailing lists to comply with it suffers from your
FUSSP syndrome just as well. The only reason it currently seems easier
is because they alone have incentives to fix the situation, and DMARC
senders and receivers have none.

If a sufficient proportion of DMARC senders and receivers implement an
ARC-based solution, mailing lists can remove the workarounds and the
remaining DMARC implementers will have a strong incentive to follow. Or,
alternatively, mailing list users will have an incentive to switch
providers.

Cheers,
Baptiste

---

From: Dave Crocker <[email-masked]>
Date: Thu, 7 Oct 2021 07:57:23 -0700

> reply to the actual sender, as compared to a rewrite directly to the

Sorry, but I've lost track of which document would informationally 
document this issue.

The re-writing hack is an operational one that might or might not prove 
the be transient. Having a spec note the effect of what it does, in 
terms of rendering mailing use problematic, is reasonable.

Having a spec go into details about the hack of the moment isn't.  On 
the other hand, it's reasonable to put such discussion into a companion 
'usage' doc, IMO.

d/

ps.  As soon as there is text talking about From rewriting, there should 
be associated text discussing related mechansisms.  The Author spec has 
already been mentioned, but the discussion should try to be exhaustive.  
ARC and whatever else makes sense, too.

-- 
Dave Crocker
[email-masked]
408.329.0791

Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
[email-masked]

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 7 Oct 2021 08:11:34 -0700

> the other hand, it's reasonable to put such discussion into a companion

He didn't specify, but I took the suggestion to mean a new document, not
any of the current ones.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Thu, 7 Oct 2021 08:21:10 -0700

On 10/7/2021 8:11 AM, Murray S. Kucherawy wrote:
> He didn't specify, but I took the suggestion to mean a new document, 
> not any of the current ones.

The use of DMARC, and its collateral effects, are atypically complex.  
So a separate discussion piece would certainly make sense.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Barry Leiba <[email-masked]>
Date: Thu, 7 Oct 2021 11:21:59 -0400

> He didn't specify, but I took the suggestion to mean a new document, not any of the current ones.

Indeed; it would be bizarre to put it into an existing document, and I
don't think I've exhibited symptoms of bizarritude (though I suppose
if I had I might not know...).

Barry

---

From: "John Levine" <[email-masked]>
Date: 7 Oct 2021 14:33:42 -0400

>He didn't specify, but I took the suggestion to mean a new document, not

You're welcome to start with the stuff in the ASRG wiki:

https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail

It's a real wiki, if you think there's stuff missing ask me for a password if
you don't already have one and add it.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Thu, 7 Oct 2021 11:39:26 -0700

On 10/7/2021 8:21 AM, Barry Leiba wrote:
> and I

no more than usual, no.

but to be fair -- or, perhaps bizarrely fair -- my comment wasn't just a 
concern about your own preferences...

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Benny Pedersen <[email-masked]>
Date: Thu, 07 Oct 2021 21:19:26 +0200

> rather then trying to specify THE solution is probably the only path 

maillists can dmarc reject posters that use dmarc reject policy or 
quarantine, problem solved downstream

for postfix there is a nice smtpd_milter_maps so maillists ips is not 
dkim/arc/dmarc rejected at all

i pick my games, but if maillists stops dkim sign non orginating mails 
50% of the main problem is solve there

maillist should only ARC seal / and ARC sign, nothing more, if that is 
done BEFORE dkim is breaked, then it wont break dmarc from github trunk 
of opendmarc, time to stablelize

---

From: Douglas Foster <[email-masked]>
Date: Thu, 7 Oct 2021 20:47:38 -0400

Assume the following:

List "L" has implemented ARC and has subscribers from 10 domains,
Domain through DomainJ.

A user from DomainA, which publishes p=reject, submits a post to the list.

What information does List "L" use to decide whether to rewrite "From", for
each of the 10 domains?
How is that information obtained?

Doug Foster

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 08 Oct 2021 04:29:45 +0000

If we were the voting sort, my vote would be "rewriting from is a horrible hack that destroys UX".  That should be sufficient information.

Scott K

---

From: Benny Pedersen <[email-masked]>
Date: Fri, 08 Oct 2021 07:02:06 +0200

On 2021-10-08 02:47, Douglas Foster wrote:
> What information does List "L" use to decide whether to rewrite
> "From", for each of the 10 domains?

what info ?

are you asking how to break dkim ?

dkim have still adsp, and atleast this still stands in spamassassin, 
since it uses metacpan Mail::DKIM perl module

simple do not break dkim

i think its endless debate on we want to fix it, but no one can see the 
light in the jungle of solutions on problems never existed on servial 
maillists that does not break dkim

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 8 Oct 2021 13:59:39 +0200

> (I'm trimming my own message severely to avoid overwhelming the list)

Trimming even more, but it's still too long...

> Standards should stay neutral on this political matter.

Every now and then someone comes out saying that SMTP should be abandoned and 
it is time to switch to a modern communication protocol.  The usual analysis 
considers that in the old Internet trust was granted to any peer.  Email 
authentication was retrofitted.  It started with SPF, continued with DKIM, and 
now we have DMARC.  Every time, the attempt is watered by recognizing that only 
a few mail messages really need authentication, while the vast majority of 
traffic can continue as before.  Yahoo's and others' coup d'etat brought us to 
face DMARC in day to day email.  And, a good deal of people believes that 
p=none is only a first step toward p=reject.

> "traditional" munging, you can at least try and guess it; with this

The Author: header field seems to fit this need.  IMHO, it is the author's 
domain DKIM filter which should take the burden to duplicate the content of 
From: into that new field.  RFC 9057 allows MLMs to do that as well.  The 
semantic may differ accordingly, so perhaps the author's domain should sign 
Author: in order to make it clear.

> service expires eventually…)

Yes!  The point is that having the MUA use Author: to implement "Reply to 
author" will take an inordinate amount of time.  Most users seem to be unable 
to alter To:/From:/Subject: fields in the composition window.  I even proposed

    From: Marissa via List <[email-masked]>

but then the user would have to actually remove it.

> a change leaks up to the UI.

Oh, I see.  I'm always confused between incompatibilities which require 
software updates versus those which require end user training.

> of forcing list users to learn new usage patterns. We should not expect

I read that mailing lists cover a negligible percentage of global email 
traffic.  That may explain why DMARC designers apparently overlooked MLMs.

Is there some kind of characterization of mailing list users which explains 
their being a minority?

> rejected message or just trash it, why not take this affirmation at face

There are several newsletters which sport List-Id: header fields.  Some of them 
are spam.

> something to fix on its side.

If the list rewrites From:, it has nothing more to fix.  If it doesn't, it 
won't be notified by DMARC reports of any breakage.

> notified through DMARC Aggregate reports. The list operator doesn't need

If DMARC takes root, MLMs who want to keep their job have to be bothered.  It 
is not their fault, but they have to arrange for it.  They can do it in a 
somehow interoperable way, e.g. aware of possible unwrapping, or carelessly 
following the least resistance path.

> senders and receivers have none.

I never heard of alternatives like rejecting posts from authors whose domain 
publishes strict policies being put in practice.  Ignoring the problem 
completely is also a risky option.  Unless DMARC will be put aside, MLMs will 
have to comply.

It may happen that Yahoo mailing list users switch to Gmail, and DMARC strict 
policies become an exclusive feature of heavily abused domains.  That's the way 
many intended DMARC should always have been.  If evolution goes that way, we'll 
never know if strict authentication would have made spammers to feel 
responsible of what they send.

> alternatively, mailing list users will have an incentive to switch

Another way is to use Sender:
https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-sender-00

That I/D looked similar to Sender-ID.  It was abandoned because people objected 
that it would be enough to add an invisible header field to confer 
deliverability to a phish formally from BANK.example.  ARC provides exactly the 
same functionality, except that one needs to add three fields, not just one.

Best
Ale
--

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 08 Oct 2021 11:41:58 -0400

> Author: in order to make it clear.

The desktop MUA I use already has "Reply to Author".  Unsurprisingly it uses 
From as the identity to use as "Author".

It's not clear to me which you mean by author's domain?  Are you suggesting 
that the email originator include both Author and From and DKIM sign Author 
instead of From?

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Fri, 8 Oct 2021 08:58:16 -0700

> that the email originator include both Author and From and DKIM sign Author

Yes he is.  Please see:

    Email Author Header Field

    https://datatracker.ietf.org/doc/rfc9057/

>     Abstract
>
>         Internet mail defines the From: header field to indicate the author
>         of the message's content and the Sender: field to indicate who
>         initially handled the message on the author's behalf.  The Sender:
>         field is optional if it has the same information as the From: field.
>         This was not a problem until development of stringent protections on
>         use of the From: field.  It has prompted Mediators, such as mailing
>         lists, to modify the From: field to circumvent mail rejection caused
>         by those protections.  In effect, the From: field has become
>         dominated by its role as a handling identifier.
>
>         The current specification augments the altered use of the From: field
>         by specifying the Author: field, which ensures identification of the
>         original author of the message and is not subject to modification by
>         Mediators.  This document is published as an Experimental RFC to
>         assess community interest, functional efficacy, and technical
>         adequacy.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 8 Oct 2021 18:01:30 +0200

> From as the identity to use as "Author".

I imagine it is going to stay that way for several years.  Perhaps it's quicker 
to unmunge on delivery.

> that the email originator include both Author and From

Yes.

> and DKIM sign Author instead of From?

No, they should sign both.

For one thing, if the author's domain sign Author:, they should deserve a copy 
of DMARC report even if From: was rewritten (especially if the receiver tried 
to unmunge.)

Best
Ale
--

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 08 Oct 2021 16:04:27 +0000

I did read that before I replied.  I just read it again.  I don't see where it specifies which fields should be DKIM signed.  Did I miss it?

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 08 Oct 2021 16:09:13 +0000

>of DMARC report even if From: was rewritten (especially if the receiver tried 

So originator includes From and Author and signs both.  Then the mediator (e.g. MLM) minges From and signs again.  Receiver checks DMARC and it passes.  Then receiver sends feedback to both Author and From domains?

Is that right?

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Fri, 8 Oct 2021 09:13:50 -0700

> I did read that before I replied.  I just read it again.  I don't see where it specifies which fields should be DKIM signed.  Did I miss it?

No, that is outside its scope.  Its scope is defining a field.

Something like specifying what should be DKIM signed is a very different 
task and needs to be done within the scope of a specification that 
worries about message 'protections' or the like.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Dave Crocker <[email-masked]>
Date: Fri, 8 Oct 2021 09:18:45 -0700

> So originator includes From and Author and signs both.  Then the mediator (e.g. MLM) minges From and signs again.  Receiver checks DMARC and it passes.  Then receiver sends feedback to both Author…

The purpose of the Author field is to retain some information that 
presumably won't get modified.  Whether to actually 'believe' that 
information is a different matter, just as it is for all other header 
fields.  And let's be clear that including a field in a DKIM signature 
does NOT validate its contents.

DMARC adds to the semantics with its definition of alignment. It's part 
of DMARC, not DKIM.

So it's certainly reasonable to include the Author: field in the set 
that produce the DKIM signature, but that inclusions does not have any 
semantic other than it didn't get changed since the signing.  Data 
integrity is nice but is quite different from validation.

Since you are pressing the concern, perhaps you could characterize what 
danger/threat and what meaningful protection against it you are looking for?

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 08 Oct 2021 16:28:02 +0000

>worries about message 'protections' or the like.

Agreed.  I was confused because it appeared to me that you were directing me there for an answer about DKIM signing and I couldn't find it.

In shorthand terms, Author is the opposite of Sender.  In the existing Sender paradigm From is constant, the mediator would add Sender, which would result in sent by Sender on behalf of From.  Under this proposal the originator includes both From and Author, the mediator mangles From and the result could be sent by From on behalf of Author.  Is that right?

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Fri, 8 Oct 2021 09:31:03 -0700

> Agreed.  I was confused because it appeared to me that you were directing me there for an answer about DKIM signing and I couldn't find it.

 From your note I thought you didn't know about the spec.  (No, that 
doesn't seem like a reasonable believe on my part, but I'm still working 
on my second cup of coffee.)

> In shorthand terms, Author is the opposite of Sender.  In the existing Sender paradigm From is constant, the mediator would add Sender, which would result in sent by Sender on behalf of From.  Unde…

One of the reasons I pointed to the draft is that it discusses the 
history and semantics of Sender vs. From and makes the case the DMARC 
forces From to be Sender, but not really From any more. Author seeks to 
recover a purely From semantic.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 08 Oct 2021 16:32:53 +0000

>danger/threat and what meaningful protection against it you are looking for?

I don't have one yet.  I'm trying to make sure I understand the proposal.  

I completely agree about integrity versus validation.  Which fields to sign is only relevant here because a proposal to not sign From (which it had now been clarified this wasn't) would require an incompatible DKIM change.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 08 Oct 2021 16:45:35 +0000

>recover a purely From semantic.

Thanks.  That matches my understanding.

My vague recollection is that the reason not to use Sender (implicit or explicit) as the key for ADSP and later DMARC was concern that some MUAs didn't display the explicit Sender (mostly Outlook Express, IIRC).  The original Yahoo! DomainKeys had some sort of a policy component that keyed off Sender.  I haven't gone back and looked anything up to be sure, so no promises.

Maybe that was the right answer all along.  Are MUAs that don't display Sender still a concern?  Do we care?  Maybe keying off Sender instead of From gets us to a similar place without requiring upgrades to every MUA in existence?

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Fri, 8 Oct 2021 09:52:30 -0700

> Maybe that was the right answer all along.  Are MUAs that don't display Sender still a concern?  Do we care?  Maybe keying off Sender instead of From gets us to a similar place without requiring up…

Marc Delaney's original DomainKeys uses Sender.  The problem with that 
is that it often isn't in the message, given that its semantic is folded 
into the From field, when they (start with) the same string.

Since From is the only identification field that is always present, 
that's what DMARC latched on to.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Dave Crocker <[email-masked]>
Date: Fri, 8 Oct 2021 09:53:58 -0700

Sorry.  Hit send too soon....

On 10/8/2021 9:45 AM, Scott Kitterman wrote:
> Are MUAs that don't display Sender still a concern?  Do we care?

No we don't.  Display is irrelevant to any of this, 
sincesecurity-related user behavior is not affected by these kind of 
display choices.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 08 Oct 2021 17:34:09 +0000

>that's what DMARC latched on to.

I think it's fair to consider that Sender is at least implicitly always present.

Having a MLM add Sender and not munge From is a far better UX than the munged From.  Lots of software already supports it too.

Would it make sense, perhaps, to key DMARCbis off Sender (i.e. Sender if present or From if no explicit Sender)?  If that makes overall sense, it would substantially simplify the MLM's problem.

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Fri, 8 Oct 2021 10:43:43 -0700

> I think it's fair to consider that Sender is at least implicitly always present.

In the abstract, according to the spec, yes it is.  In practice, 
arguably it often is not.

To the extent that Sender should indicate the 'operator' of the 
mechanics, distinct from the 'author' of the content, the Sender 
information often is not present.

 From a DMARC perspective, what one would have wished for is for all 
mail to always have the Sender field included explicitly, and DMARC work 
off of that, independent of the From field.

> Having a MLM add Sender and not munge From is a far better UX than the munged From.  Lots of software already supports it too.

That requires trying to change DMARC.  That's not going to happen.

> Would it make sense, perhaps, to key DMARCbis off Sender (i.e. Sender if present or From if no explicit Sender)?  If that makes overall sense, it would substantially simplify the MLM's problem.

Do the transition matrix for that, showing interactions between changed 
and unchanged DMARC participants.  (I did that during this round of 
effort that lead to the Author proposal.)  The result isn't viable.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 8 Oct 2021 19:44:27 +0200

On Fri 08/Oct/2021 18:18:45 +0200 Dave Crocker wrote:
>> So originator includes From and Author and signs both.  Then the mediator 
>> (e.g. MLM) minges From and signs again.  Receiver checks DMARC and it 
>> passes.  Then receiver sends feedback to both Author and From domains?
> 
> The purpose of the Author field is to retain some information that presumably 
> won't get modified.  Whether to actually 'believe' that information is a 
> different matter, just as it is for all other header fields.  And let's be 
> clear that including a field in a DKIM signature does NOT validate its contents.

Whether signed fields are validated depends on the signing domain's policy. 
Some do check that From: is valid.  If they add Author:, I'd expect they 
faithfully copy it from From:.

Unfortunately, there is no automated way to learn a domain's policy.

> DMARC adds to the semantics with its definition of alignment. It's part of 
> DMARC, not DKIM.
> 
> So it's certainly reasonable to include the Author: field in the set that 
> produce the DKIM signature, but that inclusions does not have any semantic 
> other than it didn't get changed since the signing.  Data integrity is nice but 
> is quite different from validation.

If the author's domain signed Author:, then a receiver knows that they are 
aware of the mailing list problem and presumably interested in validation 
results.  So, I would send them an aggregate report in that case.  If Author: 
was added by a mediator, I'd report to the From:'s domain only.

Of course, if the signature does not validate, the tag h=Author:... could have 
been counterfeited by a malicious mediator, possibly in a DoS attempt at 
overflowing the Author's domain rua mailbox.  I think such worry can be neglected.

Best
Ale
--

---

From: Dave Crocker <[email-masked]>
Date: Fri, 8 Oct 2021 10:57:59 -0700

> Whether signed fields are validated depends on the signing domain's 

That statement is both true and misleading.

DKIM has a semantic that is not dependent on the choices of folk who use 
DKIM.

DKIM's semantic for what it signs does NOT include validation of the 
content.

That some signers might do some sorts of validation does not affect 
DKIM's semantics.

Within the context of the DKIM specification there is no way to tell 
that a signer has these added constraints or meanings.

Therefore, if you are interpreting a signature as meaning that some 
aspect of the data are valid, you have gone beyond DKIM.

DMARC is an example of going beyond DKIM semantics, with incremental 
specification, but only for the domain name in the From field.

> Some do check that From: is valid.  If they add Author:, I'd expect 
> they faithfully copy it from From:.
>

Exactly.

>> DMARC adds to the semantics with its definition of alignment. It's 
>> part of DMARC, not DKIM.
>>
>> that produce the DKIM signature, but that inclusions does not have 
>> any semantic other than it didn't get changed since the signing.  
>> Data integrity is nice but is quite different from validation.
>
>
> If the author's domain signed Author:, then a receiver knows that they 
> are aware of the mailing list problem and presumably interested in 
> validation results.

I think understand this thinking but I also think it imparts far too 
much thought and diligence that is going to validly apply.

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: "John Levine" <[email-masked]>
Date: 8 Oct 2021 15:08:40 -0400

It appears that Scott Kitterman  <[email-masked]> said:
>My vague recollection is that the reason not to use Sender (implicit or explicit) as the key for ADSP and later DMARC was concern that some MUAs didn't display the
>explicit Sender (mostly Outlook Express, IIRC).  The original Yahoo! DomainKeys had some sort of a policy component that keyed off Sender.  I haven't gone back and looked
>anything up to be sure, so no promises.

That was part of it.  Also remember there was Microsoft's Sender-ID which had the "Purported Responsible Address" to use for validation
which was (from memory perhaps slightly garbled) resent-sender else resent-from else sender else from.  Microsoft has a patent on PRA
with liceensing terms that made us stay away from the whole idea.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 8 Oct 2021 15:12:25 -0400

It appears that Dave Crocker  <[email-masked]> said:
>presumably won't get modified. ...

The problem for me is that this is just another entry in the list of
things that are supposed to help peek back and see what the original
message said.  Other things that immediately come to mind:

- wrap messages, like a single message digest

- DKIM unmunging hints like Ale has proposed

All of these share the characteristic that to be useful, they require
MUAs to do things they do not do now, so I don't see much reason to
put a lot of effort into any of them unless we see interest from
MUA providers.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Fri, 8 Oct 2021 13:18:42 -0700

On 10/8/2021 12:12 PM, John Levine wrote:
> It appears that Dave Crocker<[email-masked]>  said:

Language like 'wrap messages' typically means making the content 
inaccessible except to a recipient that supports the wrapping 
mechanism.  Saying 'message digest' typically means a hash, which is in 
addition to clear content.  So I'm not sure what you mean. Assuming you 
just mean a hash, I don't see its relevance here.

Changing DKIM is an infrastructure change, since it involves components 
in the handling stream, rather than just the MUA.

The Author field is a pure, incremental value-add.  It only requires MUA 
support, and it imposes no burden to a recipient MUA that does not 
support it.

These are very, very different barriers to adoption.

So while, of course, Author requires new code, the nature and amount is 
quite different from any requiring infrastructure change, and especially 
different from anything hiding content unless the recipient supports it.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: "John R Levine" <[email-masked]>
Date: 8 Oct 2021 16:51:02 -0400

> Language like 'wrap messages' typically means making the content inaccessible 
> except to a recipient that supports the wrapping mechanism.

I meant message/rfc822 MIME parts.  I agree that some MUAs support them 
better than others, despite them having been standardized 25 years ago.

>  Saying 'message digest' typically means a hash

No, I mean like a mailing list digest, you know, the one daily message 
with all of the day's messages as message/rfc822 MIME parts.  Same 25 
years, same so-so support.

> Changing DKIM is an infrastructure change, since it involves components in 
> the handling stream, rather than just the MUA.

That too, but if you want to recover the original unmunged message so you 
know who to reply to, that involves the MUA.

> support, ...

Well, yeah, just like the other two.  I don't understand the point here.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 08 Oct 2021 23:39:16 +0000

>effort that lead to the Author proposal.)  The result isn't viable.

Thanks.

My conclusion then is that I don't see anything particularly problematic with Author beyond every MUA in the world needs to be updated, but given the undeniable reality of From rewriting I can see that it might eventually be helpful.

I'm still on the notion that there isn't a single viable solution to the DMARC "mailing list problem" and we should focus on documenting things senders, mediators, and receivers can do to lessen the severity and frequency of it coming up.

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Fri, 8 Oct 2021 16:54:11 -0700

On 10/8/2021 1:51 PM, John R Levine wrote:
>> inaccessible except to a recipient that supports the wrapping mechanism.
>
> I meant message/rfc822 MIME parts.  I agree that some MUAs support 
> them better than others, despite them having been standardized 25 
> years ago.
>

I guess I'm not the only one who thinks "message digest" has a 
different, long-standing meaning.

https://www.techopedia.com/definition/4024/message-digest

There was a long list of additional entries, provided by a simple 
search, that produced the same interpretation.

I am pretty sure I heard the term, with this meaning, going back 40 
years, but maybe it was before that.

This is the problem with excessively casual references and no 
explanation, when trying to have a technical discussion.

>> Changing DKIM is an infrastructure change, since it involves 
>> components in the handling stream, rather than just the MUA.
>
> That too, but if you want to recover the original unmunged message so 
> you know who to reply to, that involves the MUA.

Recover from what?  You didn't explain what was distorting/hiding the 
address.

In any event, the Author approach is rather substantially simpler than 
any distorting/hiding process.

>> The Author field is a pure, incremental value-add.  It only requires 
>> MUA support, ...
>

Since I pointed out how and why they are in fact fundamentally different 
than the Author field, your comment, here is both wrong and confusing.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: "John R Levine" <[email-masked]>
Date: 8 Oct 2021 20:01:58 -0400

>> No, I mean like a mailing list digest, you know, the one daily message with 
>> all of the day's messages as message/rfc822 MIME parts.  Same 25 years, 
>> same so-so support.
>
> I guess I'm not the only one who thinks "message digest" has a different, 
> long-standing meaning. ...

If you're saying that you have never heard of a mailing list digest, well, 
I guess we can't argue with that.

Regards,

---

From: Douglas Foster <[email-masked]>
Date: Sat, 9 Oct 2021 08:05:55 -0400

I don't understand your user experience argument, because the proposed UX
would be very different from the current UX.   Nor do I think that security
should be compromised for user convenience.  But I am ready to withdraw the
proposal.

The substantive argument is the problem of trust in list operators.   My
proposal made list infrastructure significantly more complex, and allowed
list operators to intercept member-to-member communication.   This creates
an incentive for nation-state intelligence agencies and big tech privacy
violators to move into management of lists.    I underestimated that risk,
and it creates a veto.

Doug foster

On Fri, Oct 8, 2021 at 12:30 AM Scott Kitterman <[email-masked]>
wrote:

> If we were the voting sort, my vote would be "rewriting from is a horrible
> hack that destroys UX".  That should be sufficient information.
>
> Scott K
>
>
>

---

From: Douglas Foster <[email-masked]>
Date: Sat, 9 Oct 2021 08:23:23 -0400

I believe I asked a straightforward question, which I have asked previously
in other ways in other contexts.   The silence confirms that,
unfortunately, there is no good answer.

We have had much discussion which assumes that ARC will reduce From
rewrite, because ARC will allow an evaluator to identify
trustworthy changes made by mailing lists.   When the mailing list operator
is unaware that the recipient is using ARC to trust his messages, he must
continue to rewrite From.  This means that ARC must be combined with the
reverse-encoding techniques described by Ale, so that the diminishing of
>From rewrite is accomplished entirely by the evaluator before presenting
the message to the user.

List operators could diminish From rewrite by collecting data about which
evaluators require it.   There are two obvious ways to collect this data:
 asking subscribers and sending test messages.    Yet I have been
repeatedly told, most recently by Ale, that list operators are unwilling to
collect evaluator-specific data.    Perhaps this resistance exists because
the supporting software does not exist, and that could be fixed if the
concept was formalized by IETF.

Without reverse-encoding or evaluator-specific rewrite decisions, ARC has
failed at its original purpose.

Doug Foster

---

From: Grant Taylor <[email-masked]>
Date: Sat, 9 Oct 2021 10:35:17 -0600

On 10/9/21 6:05 AM, Douglas Foster wrote:
> proposal made list infrastructure significantly more complex, and 
> allowed list operators to intercept member-to-member communication. 
>   This creates an incentive for nation-state intelligence agencies and 
> big tech privacy violators to move into management of lists.

I believe that it makes the list operator effectively a communications 
proxy.  Nothing states that two parties need to use the proxy for any 
more than the minimum communications necessary to establish direct 
communications.  I also believe that this is a well established 
communications bootstrap method;  eBay, Craigslist, various dating 
sites, etc. tend to provide a way for people to say things like "please 
email me at my main email address".

-- 
Grant. . . .
unix || die

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 9 Oct 2021 18:46:03 +0200

On Fri 08/Oct/2021 19:57:59 +0200 Dave Crocker wrote:
> DKIM has a semantic that is not dependent on the choices of folk who use DKIM.
> 
> DKIM's semantic for what it signs does NOT include validation of the content.
> 
> That some signers might do some sorts of validation does not affect DKIM's 
> semantics.
> 
> Within the context of the DKIM specification there is no way to tell that a 
> signer has these added constraints or meanings.
> 
> Therefore, if you are interpreting a signature as meaning that some aspect of 
> the data are valid, you have gone beyond DKIM.
> 

Would it make sense to extend DMARC commitment to the whole From: field?  For 
example, assert that the local part and the display name have been set by an 
authenticated user?  (Rather than automatically munged.)

>>> other than it didn't get changed since the signing. Data integrity is nice 
>>> but is quite different from validation.
>>
>> results.
> I think understand this thinking but I also think it imparts far too much 
> thought and diligence that is going to validly apply.

It is the same sentiment that makes one add Author:.  There are mailbox 
providers who set p=quarantine or harder (and possibly pct=0) just so that MLMs 
are forced to rewrite From: and thus they get rid of aggregate reports 
containing failed DMARC checks.

Mailbox providers who add Author: must belong to a different category.  Perhaps 
they care that their signatures survive MLM transformations.  Such possibility 
depends on how they sign, relaxed rather than simple, which header fields, how 
to do Content-Transfer-Encoding:, and the like.  DMARC feedback is essential to 
guide those choices, so it should be addressed also to the author's domains.

Best
Ale
--

---

From: "Definitely Alessandro Vesely no question" <[email-masked]>
Date: 9 Oct 2021 15:12:40 -0400

>authenticated user?  (Rather than automatically munged.)

All of the mail that comes out of my system (other than the stuff sent
by scripts) is sent by authenticated users who can put whatever they
want in the From: header. It's quite useful, particularly for those of
use who use multiple addresses.  It puts info about who authenticated in
other places.

This partcular bad idea has been batted around for years.  Nobody has ever been
able to explain how you could distinguish "real" address comments from unreal ones.

If you're just wondering whether the header has been changed, DKIM already does that.

R's,
John

---

From: Douglas Foster <[email-masked]>
Date: Sat, 9 Oct 2021 15:31:51 -0400

Yes, savvy users could use the proxy to establish offline
communication, but it is not what most users would do, so the lure for bad
actors is real.

Our previous discussion about online stalking was very much in mind when I
wrote the specification.   Because of the proxy mechanism, stalking can be
stopped by (a) the list operator preventing messages from the stalker's
real address to the victim's alias address, or (b) the system operator
evicting the stalker from the list, or (c) the victim leaving the list.
 In any of these scenarios, the harassment is stopped immediately, as long
as the stalker does not have the real email address of his target.   In the
absence of such measures, the best defense is to use a separate email
address for each list in which one participates.

Doug Foster

---

From: Douglas Foster <[email-masked]>
Date: Sat, 9 Oct 2021 15:39:36 -0400

I would be pleased to see a document which explains why lists MUST or
SHOULD alter content.    After more than 2 years following this discussion,
no reason for this practice has ever been documented.

Content changes would be easier to justify if subscribers granted
authorization to modify as part of the subscription process.   But there
was not informed consent when I joined this list, so I doubt that informed
consent occurs on other lists either.

What if, after reviewing the SHOULD list, an organization says "That's
interesting but unconvincing.   Please send messages to our domain without
alteration?"   Are lists equipped to give participants what they want, or
not?

Doug

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 09 Oct 2021 22:08:41 +0000

Technically it's pretty easy to set up a mailing list which doesn't modify the message in ways likely to make DKIM fail.  Almost no one bothers to do so despite pressures resulting from widespread use of DMARC p=reject.

Operators do not need to justify anything to us.  We are not the internet police.

For our purposes it's enough to know that they do and there's no evidence that it's likely to change.

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Sat, 9 Oct 2021 16:19:24 -0700

> Technically it's pretty easy to set up a mailing list which doesn't modify the message in ways likely to make DKIM fail.  Almost no one bothers to do so despite pressures resulting from widespread…

This highlights the difference between technical details, versus group 
operational culture.  As we all keep noting, the humans using these 
lists have lived with a certain kind of operational style, for decades.  
Entirely legal and -- more important -- deemed useful.

So while one can describe various, feasible changes that circumvent the 
intrusive, destructive effects of DMARC, they requires changes to a long 
history of use.  The word that you might be looking for, here, is 
Procrustean.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: "John, come on" <[email-masked]>
Date: Sun, 10 Oct 2021 11:30:15 +0200

> use who use multiple addresses.  It puts info about who authenticated in

I think that's the most widespread policy.  Others pay attention not to trace 
users identity in any way, so that they cannot comply to whatever legal 
request.  On the opposite side, there are those who only allow their users to 
use addresses they provably own.

> This particular bad idea has been batted around for years.  Nobody has ever been

Yeah, the RFC acts out «The From header field MUST be signed», implying 
whatever its content.  That's the opposite of what my father taught me, to 
fully read before signing.  But I'm going OT...

Best
Ale
--

---

From: Douglas Foster <[email-masked]>
Date: Sun, 10 Oct 2021 13:11:34 -0400

This is disappointing and problematic.

So, AOL publishes a policy which says that they do not want their outbound
messages altered in transit, and implements filtering which demonstrates
that they do not want inbound messages modified in transit.

In opposition, we have mailing lists that claim an unrestricted right to
alter messages in transit.

What is the justification for IETF to be involved with developing
strategies to undermine AOL's interests in favor of a Mailing
List's interests?   It is capricious and misleading for you to say that we
are not being the Internet Police, because we are clearly taking sides.  If
we are not the Police, then apparently we are the Internet Smuggling
Cartel.    This just looks wrong.

Doug Foster

On Sat, Oct 9, 2021 at 6:09 PM Scott Kitterman <[email-masked]> wrote:

> Technically it's pretty easy to set up a mailing list which doesn't modify
> the message in ways likely to make DKIM fail.  Almost no one bothers to do
> so despite pressures resulting from widespread use of DMARC p=reject.
>
> On October 9, 2021 7:39:36 PM UTC, Douglas Foster <
> [email-masked]> wrote:
> >> > DMARC problem for a specific mailing list without needing anyone else
> to
> >> change

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 10 Oct 2021 17:19:46 +0000

How, pray tell, shall the IETF enforce it's will upon those who fail to see the light?

For a historical parallel, I would invite you to research the IETF's historical view on Network Address Translation (NAT) for IPv4 and it's effectiveness on influencing the operational use of NAT.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 11 Oct 2021 09:51:03 +0200

On Sun 10/Oct/2021 19:11:34 +0200 Douglas Foster wrote:
> In opposition, we have mailing lists that claim an unrestricted right to alter 
> messages in transit.

A MLM activity is rather akin to publishing than forwarding.

There was a time when a pointer to IETF's Note well was added in the footer.  I 
don't think that its omission indicates it's not any more valid.  You can take 
a look at our publisher's policy here:
https://datatracker.ietf.org/submit/note-well/

IANAL, but I don't think that the addition of subject tags and footers violates 
author's copyright.  Yet, adding a footer to state the right to add a footer 
might look paradoxical.

Best
Ale
--

---

From: Barry Leiba <[email-masked]>
Date: Mon, 11 Oct 2021 10:28:31 -0400

It's not that the IETF shouldn't be involved with advice on what
mailing lists should do.  It's that if we should put out a BCP or a
standard that says mailing lists MUST NOT alter messages that they
forward, those who write mailing list software (and those who deploy
it) will not listen.  That's where Scott's "we're not the police"
statement comes in.

For whatever it's worth, mailing lists have been behaving this way
for, as others have said, decades, and it has been considered good
practice and has been found useful.  Mailing lists add footers on
messages, whether to advertise the list, to add disclaimers, or
whatever.  They like it, and won't change.  Mailing lists add the list
name to the Subject line because it makes it easier to create filters,
and because it makes it easier for eyeballs to filter (for the vast
majority of users who don't know and don't want to know how to create
filters).  They like that too, and that, too, won't change.  We could
advise change, but it would be wasted effort.

In contrast, the mailing list folks are saying that it's DMARC that
came later, that is being deployed incorrectly, and that must change.
Clearly, those who find benefit from strict DMARC policies disagree,
and they've said clearly that they won't change.  And again, we're not
the police.  We could put, in the standards track version of DMARC,
that p=reject MUST be used ONLY for transactional mail, which MUST be
isolated from mail that might go to mailing lists (worded better than
that, but we all know what I mean here).  It would be shouting at the
wind.

We do the best we can to write reasonable standards and to give
reasonable advice about using them.  We can identify problems and
write our best advice about how to avoid/mitigate them.  Beyond
that....

Barry

On Sun, Oct 10, 2021 at 1:13 PM Douglas Foster
<[email-masked]> wrote:
> So, AOL publishes a policy which says that they do not want their outbound messages altered in transit, and implements filtering which demonstrates that they do not want inbound messages modified in transit.
>
> In opposition, we have mailing lists that claim an unrestricted right to alter messages in transit.
>
> What is the justification for IETF to be involved with developing strategies to undermine AOL's interests in favor of a Mailing List's interests?   It is capricious and misleading for you to say that we are not being the Internet Police, because we are clearly taking sides.  If we are not the Police, then apparently we are the Internet Smuggling Cartel.    This just looks wrong.
>
> Doug Foster
>
>
>
>

---

From: "John Levine" <[email-masked]>
Date: 11 Oct 2021 17:15:16 -0400

>author's copyright.  Yet, adding a footer to state the right to add a footer 

I can give you a long explanation about why copyright is not an issue but
I'll skip it and say that speculating about what laws might say (particularly
laws that are different in every country) is not productive here.

R's,
John

---

From: Douglas Foster <[email-masked]>
Date: Mon, 11 Oct 2021 22:40:12 -0400

Barry, you did a nice job of talking me off the ledge.

If this is about helping list operators and message evaluators to
collaborate in a way that avoids From-Munging, I have no objections.

Repeatedly, the topic has seemed to turn in directions that make the
evaluator appear irrelevant -- as if the Lists don't need to talk to them.

The reality right now is that a lot of From-Munging is unnecessary because:
- many evaluators do not enforce DMARC
- some evaluators enforce DMARC but have made exceptions for active lists
- some other evaluators enforce DMARC and will make exceptions if asked to
do so by their users
This leaves a small group, like AOL, who enforce DMARC and yet are
unresponsive to their users.   This small group needs From-Munging, or
unmodified messages, or different email accounts for list participation.

I claim, without proof, that many of the most vocal critics of From-Munging
are using domains that do not require From-Munging on incoming messages.
 In such cases, the DMARC-enforcing sender is not the real
problem, ignorance is.

Once the list and the evaluator have agreed to collaborate, we have a bunch
of signalling options, including options that survive forwarding.   They
are mostly simple extensions of things we are already doing, much simpler
and more determinative than ARC.

Doug Foster

.

On Mon, Oct 11, 2021 at 10:28 AM Barry Leiba <[email-masked]>
wrote:

> > So, AOL publishes a policy which says that they do not want their
> outbound messages altered in transit, and implements filtering which
> demonstrates that they do not want inbound messages modified in transit.
> >
> strategies to undermine AOL's interests in favor of a Mailing List's
> interests?   It is capricious and misleading for you to say that we are not
> being the Internet Police, because we are clearly taking sides.  If we are
> not the Police, then apparently we are the Internet Smuggling Cartel.
> This just looks wrong.
> >
> > Doug Foster
> >
> >
> >
> >
> >> Technically it's pretty easy to set up a mailing list which doesn't
> modify the message in ways likely to make DKIM fail.  Almost no one bothers
> to do so despite pressures resulting from widespread use of DMARC p=reject.
> >>
> >> >> > Personally, I think mailing lists changing From has horrible UX
> and I
> >> >> don't
> >> >> > DMARC problem for a specific mailing list without needing anyone
> else to
> >> >> change

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 12 Oct 2021 12:04:01 +0200

From: rewriting confers 100% deliverability on messages, but has a bad impact 
on the end user.

If we consider collaborative solutions, we see that, because of their very 
nature, they cannot cover all cases.  So, it is safer to look for collaborative 
solutions that allow unmunging than to solutions that avoid munging in the 
first place.  Indeed, in the former case the risk is to deliver a munged 
message, while in the latter one the risk is to either not deliver or not to 
implement DMARC.

Even ARC can be turned into a method to unmunge.  It requires collaboration 
between MLM and receiver.  My unmunging method requires cooperation between 
author's domain, MLM, and receiver.  Whitelisting can be done unilaterally by 
receivers, who can restore the original From: without validating the author's 
domain signature, just because they trust the MLM.  By collecting similar 
techniques, we might be able to cover almost all cases while still ensuring 
deliverability.

Best
Ale

---

From: Laura Atkins <[email-masked]>
Date: Tue, 12 Oct 2021 11:52:06 +0100

Looking at a tiny subset of mailman based lists currently in my inbox I see a couple different things. 

This list (mailman): rewrites From, puts ‘Original-From’ in the headers, does not have a Reply-To address configured (either the original author or the list). 

Another list (mailman): rewrites From:, does not put any indication of what the original was, does have a Reply-To: address configured to point to the unmunged author address. 

Another list (mailster): rewrites From:, does not put any indication of what the original was, does have a Reply-To: address configured to point to the unmunged author list. 

It strikes me that these fields (Original From, Reply To, Original Author) may be used rather than unmunging as well.

laura 

> On 12 Oct 2021, at 11:04, Alessandro Vesely <[email-masked]> wrote:
> 
> From: rewriting confers 100% deliverability on messages, but has a bad impact on the end user.
> 
> If we consider collaborative solutions, we see that, because of their very nature, they cannot cover all cases.  So, it is safer to look for collaborative solutions that allow unmunging than to solutions that avoid munging in the first place.  Indeed, in the former case the risk is to deliver a munged message, while in the latter one the risk is to either not deliver or not to implement DMARC.
> 
> Even ARC can be turned into a method to unmunge.  It requires collaboration between MLM and receiver.  My unmunging method requires cooperation between author's domain, MLM, and receiver.  Whitelisting can be done unilaterally by receivers, who can restore the original From: without validating the author's domain signature, just because they trust the MLM.  By collecting similar techniques, we might be able to cover almost all cases while still ensuring deliverability.
> 
> 
> Best
> Ale
> 
> 
> 

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

---

From: Douglas Foster <[email-masked]>
Date: Tue, 12 Oct 2021 07:10:01 -0400

If the evaluator domain might forward an unmunged message, the domain needs
to re-mung at the domain exit MTA.   How much of an obstacle will this be?

On Tue, Oct 12, 2021, 6:06 AM Alessandro Vesely <[email-masked]> wrote:

> >> >> >alteration?"   Are lists equipped to give participants what they
> want,
> >> or
> >> >> >not?
> >> >> >
> >> >> >Doug
> >> >> >
> >> >> >On Thu, Oct 7, 2021 at 9:58 AM Barry Leiba <[email-masked]
> >
> >> wrote:
> >> >> >
> >> >> >> > really think anyone disagrees.  It's only advantages are that
> it's
> >> >> >> relatively
> >> >> >> > easy to implement in a Mailing List Manager (MLM) and it solves
> the
> >> >> >> entire
> >> >> >> problems that it causes.  Why not get those horrible UX issues
> down
> >> on

---

From: Douglas Foster <[email-masked]>
Date: Tue, 12 Oct 2021 07:42:06 -0400

>From a security perspective, Ale's proposal is flawless.   But I don't like
solutions that make the recipient bear most of the costs of the list's
actions.     Unmunging creates a high cost of entry for new domains:

Under a collaboration solution, the subscriber goes to her email support
and says,"I joined list X, and they say that for the best user experience,
we need to configure a whitelist entry to bypass From Filtering on messages
from one SPF-verified SMTP address.    Then I need to give them a response
whether this change has been implemented or not."

Under an unmunging solution, the subscriber conversation is more like this,
"I joined list X, and they say that for the best user experience, we need
to configure an unmunging MTA.   Hope this is not too much trouble.  I hope
you can get this implemented quickly."

Doug Foster

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 12 Oct 2021 20:01:01 +0200

On Tue 12/Oct/2021 13:42:06 +0200 Douglas Foster wrote:
> actions.

Consider sites using p=quarantine; pct=0;.  Their mail admin chose to have 
From: munged in exchange for aggregate reports free of "failures".

> Unmunging creates a high cost of entry for new domains:

To collaborate costs more than doing nothing.

> Under a collaboration solution,

These are both collaborative solutions.  The first is non-munging, the second 
unmunging.

> [Under the non unging solution] the subscriber goes to her email support

At receiver, the filter skips DMARC check for a specific SPF-verified address.

At MLM, a filter skips From: rewriting for specific receivers.

> you can get this implemented quickly."

At receiver, the filter skips DMARC check for a specific SPF-verified address, 
and restores From:'s content from Author:'s.

The total cost looks about the same.  However, both examples assume an overly 
collaborative mail admin at the receiver.  For a realistic case, we need 
unmunging software which works out of the box.

Best
Ale
-- 

Unmunging note:  In neither of Doug's messages I could verify Gmail's 
signatures, due to IETF's code adding a '>' in front of "From ".  For Laura's 
message I got dkim=pass reason="transformed" header.d=wordtothewise.com;.  So I 
could have unmunged it, in case.

---

From: Baptiste Carvello <[email-masked]>
Date: Wed, 13 Oct 2021 15:35:52 +0200

Hi,

I'm happy to see the discussion advancing: we now seem to have consensus 
that redesigning mailing lists behind their backs is a bad idea, and 
that the existence of From rewriting as an emergency hot-fix does not 
preclude looking for more satisfactory solutions. Good work!

Now, I'm skeptical of your solution. First, I don't think 100% 
deliverability at all times is a hard requirement. The Open Source 
mailing lists I care about really don't have a deliverability problem: 
I'm sure LKML can afford that messages from and/or to a few peculiar 
domains get lost for a few months, if that's the price to pay to build 
incentives for a collaborative solution (I don't expect receivers to 
invest into unmunging if they don't have a strong incentive).

Also, having this munging-then-unmunging dance as the *normal* procedure 
sounds backwards. If the receivers make the delivery decision alone, why 
can't they implement it all on their side: let the incoming message 
pass, munge it with an alias under their control, wrap it into a 
message/rfc822 body part, silently discard it, whatever they want, it's 
their system, their UX, their users.

The only reason for insisting that mailing lists speculatively do the 
munging on their side is some strange fetish on the value of the From 
field during transit… where nobody will read it. Oh, and the risk of 
bounces, of course, which should IMHO be eliminated in this special case.

Cheers,
Baptiste

Le 12/10/2021 à 12:04, Alessandro Vesely a écrit :
> If we consider collaborative solutions, we see that, because of their 
> very nature, they cannot cover all cases.  So, it is safer to look for 
> collaborative solutions that allow unmunging than to solutions that 
> avoid munging in the first place.  Indeed, in the former case the risk 
> is to deliver a munged message, while in the latter one the risk is to 
> either not deliver or not to implement DMARC.
> 
> Even ARC can be turned into a method to unmunge.  It requires 
> collaboration between MLM and receiver.  My unmunging method requires 
> cooperation between author's domain, MLM, and receiver.  Whitelisting 
> can be done unilaterally by receivers, who can restore the original 
> From: without validating the author's domain signature, just because 
> they trust the MLM.  By collecting similar techniques, we might be able 
> to cover almost all cases while still ensuring deliverability.
> 
> 
> Best
> Ale
> 
> 
> 
>>> >> >> > easy to implement in a Mailing List Manager (MLM) and it 
>>> solves the
>>> >> >> entire

---

From: Dave Crocker <[email-masked]>
Date: Wed, 13 Oct 2021 07:26:11 -0700

On 10/12/2021 3:52 AM, Laura Atkins wrote:
> It strikes me that these fields (Original From, Reply To, Original 
> Author) may be used rather than unmunging as well.

And the purpose of the Author: specification is to suggest there be a 
single, common place for this.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Douglas Foster <[email-masked]>
Date: Wed, 13 Oct 2021 18:39:53 -0400

Baptiste, you are partially right.

For those who want more reliable delivery and better UX, improvement can
advance on two-prongs.    Evaluators who have the savvy and the motivation
to implement an unmunging algorithm can be advised to do so for the benefit
of their users.   Mailing List Operators who have the savvy and the
motivation to use recipient preferences to minimize munging can also be
advised to do so for the benefit of their subscribers.   Neither group will
see 100% deployment of a solution, so the best outcome will occur if each
participant implements what they can.   Both solutions depend on evaluators
knowing how to characterize messages from any particular mailing list, and
that becomes complicated if the message is forwarded.   IETF MAY be able to
facilitate all three aspects of the problem space, although that remains to
be seen.

Those who are unmotivated to optimize delivery rates can certainly wait for
others to implement a solution.

On Wed, Oct 13, 2021 at 9:36 AM Baptiste Carvello <
[email-masked]> wrote:

> >>> > On Sat, Oct 9, 2021 at 6:09 PM Scott Kitterman <[email-masked]
> >
> >>> wrote:
> >>> >>
> >>> >> >On Thu, Oct 7, 2021 at 9:58 AM Barry Leiba <
> [email-masked]>
> >>> wrote:
> >>> >> >

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 13 Oct 2021 21:47:53 -0700

On Tue, Oct 12, 2021 at 4:42 AM Douglas Foster <
[email-masked]> wrote:

> we need to configure a whitelist entry to bypass >From Filtering on
> messages from one SPF-verified SMTP address.    Then I need to give them a
> response whether this change has been implemented or not."
>
> Under an unmunging solution, the subscriber conversation is more like
> this, "I joined list X, and they say that for the best user experience, we
> need to configure an unmunging MTA.   Hope this is not too much trouble.  I
> hope you can get this implemented quickly."
>

It feels to me like an arrangement like this can't scale well.  Given
millions of users at a single email service provider, even a fraction of a
percent of those joining lists means thousands of people have register with
the MTA in some way.  This causes two problems:

a) Many users will forget, many others will be confused by the process
since they've never had to do that before; you should expect that all of
those will complain, screw it up, or both.

b) Teaching an MTA to use a configuration file with that scale of entries
seems like it would be a beast.  Large scale infrastructures can possibly
handle something like that, and boutique operators only have to do it for
their small handful of users, but the space in between could be pretty
unpleasant.

-MSK

---

From: Douglas Foster <[email-masked]>
Date: Thu, 14 Oct 2021 17:59:49 -0400

You miss the point.

Many domains are receiving From-Munged mail when they do not want or
require From-Munging.   I expect that this includes most of the .EDU
world.   If mailing lists asked their users whether munging was necessary,
they could make some of their users happier immediately.

If the big mailbox providers don't want to create exceptions, the lists can
continue to From-Mung for them.  No evaluator has to make any exceptions
than they do not want to make.

But if an evaluator is willing to make an exception, somebody internal
needs to ask for it, and the exception requirements need to be well-defined.

This is so obvious it should have been implemented by the lists a long time
ago.   Increasingly, I don't think this is a problem that matters.   If it
was, lists could have devised this strategy years ago, without my help.

Doug Foster

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 15 Oct 2021 11:31:03 +0200

Hi,

On Wed 13/Oct/2021 15:35:52 +0200 Baptiste Carvello wrote:
> 
> First, I don't think 100% deliverability at all times is a hard requirement.

That statement is wrong.  I experienced random deliverability when I 
thoughtlessly enabled ADSP in August 2010[*].  I can testify that 
deliverability /is/ required in order to participate to mailing list discussions.

Re-reading those messages, we don't seem to have made much progress during the 
intervening decade.

Best
Ale
-- 

[*] http://lists.elandsys.com/archive/opendkim/users/2010/08/0443.html

---

From: "John Levine" <[email-masked]>
Date: 15 Oct 2021 15:33:30 -0400

It appears that Baptiste Carvello  <[email-masked]> said:
>deliverability at all times is a hard requirement. ...

Since 100% deliverability at all times does not and cannot exist, it's just as well.

R's,
John

---

From: Douglas Foster <[email-masked]>
Date: Fri, 15 Oct 2021 18:36:13 -0400

To be completely clear about Murray’s concern:

There are three possible strategies for lists to handle postings from
DMARC-enforcing subscriber domains:

-          Never rewrite From

-          Conditional – rewrite From if required by evaluator

-          Always rewrite From

Similarly, there are three relevant security postures for evaluators:

-          Always block on DMARC Fail
-          Exempt my list from DMARC fail
-          Never block on DMARC FAIL

We can construct a grid showing the possible outcomes

             \ ---------  Evaluator Policy ---------------
List Policy   \   Block Fails | List Exempt | Ignore DMARC|
---------------+--------------+-------------+-------------+
Never Rewrite  |  Blocked*    | OK w/o Mung | OK w/o Mung |
---------------+--------------+-------------+-------------+
Conditional    | OK with Mung | OK w/o Mung | OK w/o Mung |
---------------+--------------+-------------+-------------+
Always Rewrite | OK with Mung | Wasted Mung*| Wasted Mung*|
---------------+--------------+-------------+-------------+

Asterisks indicate inferior outcomes.

As in all of life, some actionable information is better than none, as long
as the actionable information is used to take action.  Consequently,
the Conditional
strategy will always outperform a strategy based on no information.

Note that the Conditional strategy is superior even if no evaluators make
exceptions for the list.  Superior outcomes are achieved with as little as
one recipient domain with actionable information.

The Conditional strategy is also superior even though complete information
will not be available.  All that is needed for a win is to have SOME
information.   It just requires a list that is willing to collect and use
actionable information.

Doug Foster

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 15 Oct 2021 23:24:25 +0000

This assumes that email which transits a list will fail DMARC evaluation.  While that's the most common case, it's nowhere near universal.

This isn't something that can be reduced to a simple truth table and optimized to a single solution.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 16 Oct 2021 12:37:23 +0200

> Since 100% deliverability at all times does not and cannot exist, it's just as well.

That percentage is meant to be rounded to the nearest integer.  I think I can 
say I get 100% of dmarc-ietf messages, notwithstanding that 2010 and possibly 
other hiccups.

That's due to most author's domains as well as the IETF itself having p=none, 
plus me not enabling DMARC for those domains.  In addition, DMARC has the 
advantage over ADSP that SPF authentication suffices (which only works for 
subscribers who need no forwarding, but I'm one.)

Could we do better authentication?  For one point, after twelve years people 
still sign mime-version:, content-type:, and content-transfer-encoding: so that 
MLMs have to invalidate their signatures.

Best
Ale
--

---

From: Joseph Brennan <[email-masked]>
Date: Sat, 16 Oct 2021 21:10:21 -0400

Creating a DMARC record on your domain means (among other things) that you
expect no email sent from your domain to be a contribution to mailing
list discussions.

Telling mailing list owners and mailing list software designers to violate
RFC 5322 Internet message format's description of the From header line to
make you happy is abusive. How does your decision to implement DMARC become
their problem? That is not right. Your choice is not their problem. The
DMARC standard should say, implement this only for domains that will send
mail that should never be forwarded or sent to mailing lists. That was the
original purpose. It does very well for that use case and it is very
valuable for that use case. All of the problems come from misusing DMARC
for ordinary end-user email. I'm talking to you, yahoo.

I got tired of posting here, but that is still my position.

Joe Brennan
Columbia University IT

---

From: "John Levine" <[email-masked]>
Date: 16 Oct 2021 22:33:25 -0400

>expect no email sent from your domain to be a contribution to mailing

Assuming you mean "a DMARC record with a policy other than p=none" that would be sensible, 
but we have plenty of experience right here in the IETF that shows us that it's not true.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 17 Oct 2021 19:43:30 +0200

On Sun 17/Oct/2021 03:10:21 +0200 Joseph Brennan wrote:
> Telling mailing list owners and mailing list software designers to violate RFC 
> 5322 Internet message format's description of the From header line to make you 
> happy is abusive.

There is no abuse.  MLMs act as submitters.  Setting From: should be a must.

Best
Ale
--

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 17 Oct 2021 17:49:29 +0000

>There is no abuse.  MLMs act as submitters.  Setting From: should be a must.

Odd, I thought this message was from you, Ale?

Scott K

---

From: Grant Taylor <[email-masked]>
Date: Sun, 17 Oct 2021 12:05:27 -0600

> Odd, I thought this message was from you, Ale?

It depends if you are talking about the content or the SMTP 
communications path.

The content of this message is from me, but my email server will not 
have been the one that sent it to your server.  It will be the IETFs 
server that communicates with your server.

-- 
Grant. . . .
unix || die

---

From: Baptiste Carvello <[email-masked]>
Date: Sun, 17 Oct 2021 20:51:13 +0200

> It depends if you are talking about the content or the SMTP 

They say, DMARC chose the "From" field because it is *user-visible*.

Users care about who authored the content, not which machines it was 
relayed over.

If you rewrite From, all you do is bring irrelevant complication in the 
face of the users, and they will quickly learn to ignore it (thereby 
undermining DMARC in general).

Cheers,
Baptiste

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 17 Oct 2021 18:53:31 +0000

>server that communicates with your server.

True, but SMTP and the body From are unrelated.

At the SMTP level, mailing lists have quite commonly and unremarkably used a Mail From for the list.  That's why SPF doesn't have a "mailing list problem".

If mailing lists were merely a conduit for computer generated content, approximately no one would read them.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 17 Oct 2021 18:59:35 -0000

>undermining DMARC in general).

As Dave Crocker often reminds us, there is no evidence that the contents
of the From line has any effect on users' security decisions, even in
the ever more rare case that the MUA shows the address and not just
the comment.

But it is nice to know who a message is from.  I am on a few lists that
are misconfigured to put the list's address on the From line with no
hint about who wrote the message.  My impression is about half the
messages on such lists are "could you put your name in the body of
the message so we know who it's from, please."

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

---

From: Benny Pedersen <[email-masked]>
Date: Mon, 18 Oct 2021 00:44:58 +0200

On 2021-10-17 19:43, Alessandro Vesely wrote:
>> Telling mailing list owners and mailing list software designers to 
>> violate RFC 5322 Internet message format's description of the From 
>> header line to make you happy is abusive.
> 
> 

mlm is never origating, so dkim sign mlm fails

all it needs is that mlm start doing ARC-Seal, ARC-Sign, and both of 
them must be done BEFORE dkim is breaked

we all loose if order of things is inccorect

hope spamassassin 4.x.x will finaly help people understand the main 
problems of breaking dkim

---

From: Douglas Foster <[email-masked]>
Date: Sun, 17 Oct 2021 22:07:52 -0400

Scott writes
"True, but SMTP and the body From are unrelated."

He is correct, and it is exactly why I have been so upset that the group
embraced an SMTP-derived (SPF-precursor) rule to test for a non-existent
value of the RFC5322.From address.

Doug

---

From: Douglas Foster <[email-masked]>
Date: Sun, 17 Oct 2021 22:33:56 -0400

As Scott eloquently said, we are not the Internet Police.    We need to
produce a document that responds to RFC 7960 in the context of DMARCbis.
The best that we can do is lay out the options, and let the senders, list
operators, and receivers make their choices.   We need to move away from
fault-finding and SHOULDs, and simply lay out the best options that we can
construct.

I submit my recent treatise as the basic outline of that document, simply
because the options seem inherently comprehensive:
- Never rewrite From
- Always rewrite From if the sender policy risks possible delivery failures.
- Conditionally rewrite From if the sender-receiver combination makes it
necessary because whitelisting status is not granted or not known.

All of these options need to be presented well, which means that they
need to be presented by someone who can advocate for that option.
Baptiste, you should write the case for never rewriting.    Any of the
long-term participants should be able to write the case for always
rewriting and how to do the rewriting.   I have more to add about the case
for conditional rewrite, but the group has my first draft.

To my understanding, ARC, Sender, and Author proposals are variant ways to
obtain whitelisting status with the evaluator, and that these only work if
(a) the list has feedback that the method will work for a particular domain
and (b) the list is able to handle different domains differently.   We need
advocates to explain how these options provide the most effective way to
obtain whitelisting status.

What we like or dislike is irrelevant.   Difficulty of implementation does
not matter.  Both are judgement calls to be made by the implementer.   Our
role is to ensure that they understand their options, along with the
advantages and disadvantages of each.

Not giving up my opinions, but I am giving up the idea that only one
opinion can survive.   Let's  get the options documented.

Doug Foster

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 18 Oct 2021 14:11:19 +0200

>> Users care about who authored the content, not which machines it was 

A MLM is not just a machine.  It is also a context, and often an active filter.

> of the From line has any effect on users' security decisions,

Yet, showing authentication results is useful.  For example:

     We observe that the security cue has a clear impact on the user action.
     Comparing with the groups “without security cues”, the click-through rate
     of those “with security cue” drops by 12.3%–37.9%. [...] The results
     suggest that security cues have a significant impact to reduce the user
     tendency of clicking on phishing URLs
                                         https://arxiv.org/abs/1801.00853

> hint about who wrote the message.

That, and the ability to reply to author.

> My impression is about half the messages on such lists are "could you put
> your name in the body of the message so we know who it's from, please."

Perhaps an RFC could improve the way average MLMs rewrite From:?

Best
Ale
--

---

From: Baptiste Carvello <[email-masked]>
Date: Mon, 18 Oct 2021 14:56:20 +0200

Hi,

> There is no abuse.  MLMs act as submitters.  Setting From: should be a

This all habit of telling other actors what they should or must do has
to stop. This hubris is the original sin of Yahoo, which started all the
trouble.

In a sound interoperation situation, each actor has a bit of wiggle room
to assess the situation in their own area of responsibility according to
their worldview. Which means for example:

* originating domains are free to choose their preferred treatment of
DMARC FAILing messages, while remembering to be careful what they wish…

* mailing lists can send as their own domain if or when they act as a
proper editor, but can also keep the original From field when they act
as a technical helper. And they don't need to second-guess evaluators.

* evaluators make the final delivery decision based on the originating
domain's wishes, but most of all based on their assessment of their
users' interest. And yes, they can rewrite whichever headers they feel
like, they control their own UX.

Corollary to this freedom, there must be incentives to keep each actor
accountable. This is where the problem currently lies: the originating
domains take no responsibility at all for their choices, which is why
Yahoo could get away so easily with their disruptive move.

That's why I suggest that REJECTed messages should be silently discarded
and thus possibly lost, which makes all actors equally bear the
consequences, instead of bounced, which disproportionately punishes the
mailing list operators.

If it decreases deliverability in the short term, so be it: making all
actors accountable is a prerequisite for any consensual solution in the
long term.

Cheers,
Baptiste

---

From: Dave Crocker <[email-masked]>
Date: Mon, 18 Oct 2021 06:51:19 -0700

>> But it is nice to know who a message is from. ...
>

And for the recipient's MUA to organize messages from the same author as 
if they were from the same author, rather than from a variety of 
different authors.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Benny Pedersen <[email-masked]>
Date: Tue, 19 Oct 2021 02:33:09 +0200

> Perhaps an RFC could improve the way average MLMs rewrite From:?

what is the point of dkim then ?

note i did not write dmarc here

---

From: Benny Pedersen <[email-masked]>
Date: Tue, 19 Oct 2021 02:44:37 +0200

> to stop. This hubris is the original sin of Yahoo, which started all 

yahoo follow same error as this maillist here ?, why is ietf add dkim 
signing to my mlm message at all ?, amazonaws does the same error, 
sendgrid does the same error, all foolsly forwarding service dkim sign 
mails that is not originating from them, if thay stop this and did a 
openARC seal/sign we would all be happy, but that process of openARC 
must be done BEFORE dkim is breaked, period :)

lets talk about dmarc when this is solved or even is rfc stable

note its fairly simple to add Mail::DKIM::ARC::Signer and 
Mail::DKIM::ARC::Seal instaed of using dkim signer for non origination 
mails in amavisd, who will make that path ?

if done problem solved

remember mails that is in amavisd origination must not be ARC signed or 
Sealed but it must be dkim signed

rest is handled downstrem on breaking dkim forward hosts

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 21 Oct 2021 13:16:43 +0200

> what is the point of dkim then ?

In general, DKIM can pass across simple forwarding, where SPF fails.

If used properly —signing the fields recommended in Section 5.4.1 of DKIM and 
not, e.g., Content-Type:, Content-Transfer-Encoding:, and MIME-Version:— then 
it can pass across well behaved MLM transformations, if the header is 
canonicalized in relaxed mode.

The l= tag had a similar purpose, but it would only be usable for text/plain 
messages where the transformation only appends a footer and not a subject tag. 
  Few signers use it.

> note i did not write dmarc here

DMARC, and Yahoo and others, only made DKIM relevant.

Best
Ale
--