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

From: Alessandro Vesely <[email-masked]>
Date: Fri, 12 Jun 2020 10:02:27 +0200

Hi all,
I'm sorry I didn't queue to talk yesterday.  After so many months without
speaking one word of English, I really didn't feel like...

*Why ARC cannot solve the mailing list problem*
===============================================

Assume all mailing lists in the world duly did ARC.  Somewhat
science-fictitious, given that some of them are not even able to add valid DKIM
signatures.  Let's hypothesize they all did ARC, anyway.  Would the mailing
list problem be solved?  No, because recipients cannot blindly accept DMARC
failures just because there is an ARC-chain claiming authenticity.  Doing so
would completely defeat DMARC, because ARC chains can be forged.

In order to safely override a reject or quarantine policy based on ARC, a
receiver needs a complete list of legitimate mailing lists.  Conversely, having
such a list, a receiver can override DMARC failures also based on DKIM or SPF
authentication.  ARC adds nothing to the mailing list problem.  (However, huge
mailbox providers do have a complete list of legitimate MTAs.  That's where ARC
is useful, AIUI.)

*From rewriting is the real thing*
==================================

Rewriting From: is the de-facto standard.  In a (science-fictitious) scenario
where all mailing lists rewrite the From: header field, DMARC would just work
smoothly.

Hence, we have to specify an acceptable way to rewrite From:.

I'd have said so.

Best
Ale
--

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Fri, 12 Jun 2020 16:33:13 -0700

I would like to understand what you mean by:

On Fri, Jun 12, 2020 at 1:02 AM Alessandro Vesely <[email-masked]> wrote:

> . . . ARC chains can be forged.
>

--Kurt

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 13 Jun 2020 00:06:16 +0000

>> . . . ARC chains can be forged.

Not sure what is confusing about that.  There's no requirement that signatures from previous hops still verify, so anyone can build an ARC chain that claims they got something from an arbitrary source.  ARC is only usable if you know you trust the source.

Which still leaves the question of what the value proposition is since if you trust the source, what more does ARC really do (I suspect that the answer is more tokens to run through your bayesian or whatever filter)?

Scott K

---

From: "John Levine" <[email-masked]>
Date: 12 Jun 2020 20:45:36 -0400

In article <[email-masked]> you write:
>Which still leaves the question of what the value proposition is since
>if you trust the source, what more does ARC really do (I suspect that
>the answer is more tokens to run through your bayesian or whatever
>filter)?

When I asked that a while ago I got a quite reasonable response.

Mailing lists do a lousy job of spam filtering, often only checking
that the From: address is a subscriber, and it is quite common for a
legit list to start leaking or even gushing spam. I've often seen it
when someone's address book gets stolen, spammers start taking 
(from, to) from) pairs from the address book, and one of the pairs happens
to be (another subscriber, list).

ARC lets the recipient look back and retroactively do the filtering
the list didn't. As a concrete example, I find that it is extremely
rare for legit mail coming into a list to be DMARC unaligned (as
opposed to mail coming out of the list) so if you can look back at the
ARC chain and demote mail which failed DMARC coming in, you will catch
a lot of spam without a lot of mistakes.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Fri, 12 Jun 2020 17:51:53 -0700

> the list didn't.

The concern about the creator of an ARC chain spoofing the purported 
origin of a message is valid.  The above statement is correct, but needs 
to be augmented:

      Based on the reputation of the creator of an ARC chain, ARC let's 
the receiving filtering engine do filtering based on the proffered 
address of the originator.

(Recipient end-users are irrelevant to this process.)

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Hector Santos <[email-masked]>
Date: Sat, 13 Jun 2020 01:19:21 -0400

> Rewriting From: is the de-facto standard.

I don't support it.

> In a (science-fictitious) scenario where all mailing lists
>rewrite the From: header field, DMARC would just work
> smoothly.

Occam's razor. The simplest and most honorable protocol solution is to 
follow the specs.  DMARC will work just fine without tampering with 
headers if the list server simply honored the restrictive policy. It 
works greats!!

A DKIM Policy compliant list server simply needs to do two things:

1) Prohibit new subscribers using addresses with restrictive domains, 
just like it is done here:

https://secure.winserver.com/public/code/html-subscribe?list=winserver

2) Prohibit submission from existing subscribers using addresses with 
restrictive domains. The existing subscriber becomes a read-only 
subscriber.

We had very little complaints at the beginning. But the member, for is 
own domain protection, had to use another list restrictive domain to 
participate. Right now, it works this way and it works without complaints.

> Hence, we have to specify an acceptable way to rewrite From:.

This is no acceptable way to tamper the mail in this way.  But I did 
suggest with following. For an example of what it did to my headers:

X-Original-From: Hector Santos <[email-masked]>
From: Hector Santos <hsantos=[email-masked]>

In order to close the loophole the rewriting has opened, in addition, 
to falsely associate my name with dmarc.ietf.org domain,  the rewriter 
needs to use a signer domain that matches the original protection.

dmarc.ietf.org is currently using::

v=DMARC1; p=none; 
rua=mailto:[email-masked],mailto:[email-masked]

The dmarc.ietg.org policy should be, at a minimum, p=quarantine. 
dmarc.ietf.org is only used for rewriting when the submission has a 
restrictive author domain, so the dmarc.ietf.org should be restrictive.

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

---

From: Hector Santos <[email-masked]>
Date: Sat, 13 Jun 2020 01:22:59 -0400

> participate. Right now, it works this way and it works without

That should be "another less restrictive or non-restricted domain"

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 13 Jun 2020 11:31:53 +0200

On Sat 13/Jun/2020 02:45:36 +0200 John Levine wrote:
> [...]

Most of us keep p=none because we'd likely loose deliverability with a strict 
policy.  In particular, lists' functioning is smoother that way.  When DMARC 
takes root, non-aligned messages could be filtered inbound by the list 
themselves.  In this respect, strict policies are more effective, and we should 
consider strategies to get there.

I'd guess ARC has more arrows than just retroactive filtering.  Anyway, it 
remains a tool for very large operators.  Mailing lists cannot afford to lose 
participation by small operators.  Therefore they won't give up rewriting 
From:.  ARC doesn't help DMARC adoption.

Best
Ale
--

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 13 Jun 2020 11:32:00 +0200

On Sat 13/Jun/2020 07:19:21 +0200 Hector Santos wrote:
> Occam's razor. The simplest and most honorable protocol solution is to follow 
> the specs.  DMARC will work just fine without tampering with headers if the 
> list server simply honored the restrictive policy. It works greats!!
> 
> 1) Prohibit new subscribers using addresses with restrictive domains, just like 
> it is done here:
> 
> restrictive domains. The existing subscriber becomes a read-only subscriber.

Restricting mailing list usage to domains with no DMARC policy is a hindrance 
to DMARC effectiveness.  Those mailing list cannot filter out unauthenticated 
spammers.

> This is no acceptable way to tamper the mail in this way.  But I did suggest 
> with following. For an example of what it did to my headers:
> 

Why is that unacceptable?

After all, the message comes from dmarc.ietf.org.  They are responsible for 
filtering.  The message comes from them.  You just authored it —compare with 
digest mode.

I like to see the author's name displayed in the folder view.  However, 
choosing how to rewrite should be an author's decision.

For another effect, if the list broadcasted messages maintaining the original 
From:, then isdg.net would receive an explosion of rows in the aggregate 
report, loosing the ability to match it with the mail they actually sent.

Best
Ale
--

---

From: [email-masked]
Date: Sat, 13 Jun 2020 12:22:07 +0200

Hi,

I'm but a mere user, but I cannot let this be presented as an obvious or 
consensual solution. Header munging is inadequate because:

1) It makes the wrong tradeoffs. DMARC started as a solution for a very 
specific problem (phishing targetting high impact domains) and made 
tradeoffs accordingly. Now that it is deployed as a general anti-spam 
tool, the appropriate tradeoffs are different: most users are willing to 
live with some degree of spam rather than have their communication 
tampered with and their name associated with random intermediaries. 
"Fait accompli" is not acceptable, even if you call it "de-facto standard".

2) It buys you nothing. As was discussed last week, DMARC by design 
relies on the expectation that users (or their MUA's adress book) will 
recognize legitimate From addresses. If you teach users that "Joe User 
by Random Intermediary" is the same as "Joe User", this expectation is 
doomed.

Cheers,
Baptiste

---

From: "Douglas E. Foster" <[email-masked]>
Date: Sat, 13 Jun 2020 15:19:15 GMT

About this comment
  
         If you teach users that "Joe User by Random Intermediary" is the same as "Joe User", this expectation is doomed.

Based on the response to my previous post, "Trained User" is not a meaningful concept, for purposes of this discussion.   However, a user who subscribes to a mailing list should be able to recognize its distinctive message characteristics, so I think training is not a significant issue.   I have had fun looking at the different ways that IETF mailing list entries are presented in my different MUAs.

More to the point:  

I suggest that the "Mailing List Problem" is a problem that does not need to be solved (and evidence suggests that it cannot be solved.)   I can think of no purpose served by a public mailing list, like this one, which is not be better solved by a community forum website with user login.   Even in its heyday, I think mailing list subscribers were a narrow subset of email users, heavily skewed toward Unix-oriented technology people.   Solving the mailing list problem seems like saying, "I want a secure and reliable way to order my Walmart groceries using the text feature of my flip-phone."  It is time for a different technology.

There are other indirect mail scenarios that are problematic, but these seem well understood and I do not see that any improvement is available.   These include:
DKIM (configured at the sender), SRS Encoding (configured at the forwarder), and Trusted forwarder registration or another exception mechanism (configured at the recipient filter).    Incoming email filters have inadequacies when looking backward on a forwarded message, but this mailing list is not concerned with specifying the desired features of incoming mail filters.
DF

----------------------------------------
From: [email-masked]
Sent: 6/13/20 8:04 AM
To: [email-masked]
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
Hi,

Cheers,
Baptiste

> *Why ARC cannot solve the mailing list problem*

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

---

From: "John Levine" <[email-masked]>
Date: 13 Jun 2020 12:42:56 -0400

In article <[email-masked]> you write:
>I suggest that the "Mailing List Problem" is a problem that does not need to be solved (and evidence suggests that it cannot be solved.)   I
>can think of no purpose served by a public mailing list, like this one, which is not be better solved by a community forum website with user
>login. ...

That's OK, the rest of us can.

R's,
John

---

From: "Douglas E. Foster" <[email-masked]>
Date: Sat, 13 Jun 2020 17:39:18 GMT

The "mailing list problem" was introduced into this discussion as an objection to DMARCs progresss, by implication suggesting that DMARC must be delayed until a solution is found which creates no inconvenience to mailing list operators.    

That concerns me, First, a a new solution has not really been proposed; all of the discussed options are already available to mailing list operators.  Secondly, articulating a required mailing list operational mechanism is unlikely to produce rapid or uniform adoption.   The supposed problem is not big enough to warrant that much control over this initiative.

---

From: "John Levine" <[email-masked]>
Date: 13 Jun 2020 16:13:00 -0400

In article <[email-masked]> you write:
>The "mailing list problem" was introduced into this discussion as an objection to DMARCs
>progresss, by implication suggesting that DMARC must be delayed until a solution is found which
>creates no inconvenience to mailing list operators.    

At this point I truly have no idea what your point is. The fact that
DMARC screws up mailing lists is enough of a problem that a lot of
people have put considerable time and money into inventing and
implementing ARC.

More than that, DMARC exists, it's deployed, it's not going to change
beyond minor tweaks to clarify unclear parts of the spec, perhaps to
deprecate minor parts that don't work the way we anticipated, and
perhaps minor additions like https reporting.

In particular, there is no chance whatsoever that any DMARC policy
will become mandatory, because the IETF doesn't do mandatory. The word
MUST only means "do this to interoperate with other systems", not do
this or else.

R's,
John

---

From: Benny Pedersen <[email-masked]>
Date: Sat, 13 Jun 2020 22:46:53 +0200

On 2020-06-13 18:42, John Levine wrote:
>> I suggest that the "Mailing List Problem" is a problem that does not 
>> need to be solved (and evidence suggests that it cannot be solved.)   
>> I
>> can think of no purpose served by a public mailing list, like this 
>> one, which is not be better solved by a community forum website with 
>> user
>> login. ...
> 

if no one breaked dkim then arc would not even be needed

IMHO ietf is gone to far of fixing problems

---

From: Benny Pedersen <[email-masked]>
Date: Sat, 13 Jun 2020 22:56:06 +0200

On 2020-06-13 22:13, John Levine wrote:
>> progress, by implication suggesting that DMARC must be delayed until a 
>> solution is found which

even if ietf tribble dkim sign mails it still gives

X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on 
localhost.junc.eu
X-Spam-Status: No, score=-9.3, required=5.0, Autolearn=unavailable
	autolearn_force=no, LastExt=4.31.198.44
X-Spam-Rules_score: DKIM_INVALID=0.1,DKIM_SIGNED=-0.1,
	HEADER_FROM_DIFFERENT_DOMAINS=0.25,LOCAL_WHITELIST_URI=-0.5,
	MAILING_LIST_MULTI=-10.1,SPF_HELO_NONE=1.1,SPF_PASS=-0.1

hmm

---

From: Jim Fenton <[email-masked]>
Date: Sat, 13 Jun 2020 19:53:46 -0700

On 6/13/20 1:13 PM, John Levine wrote:
> will become mandatory, because the IETF doesn't do mandatory. 

Alas, others do, apparently because they see that DMARC has an RFC
number (even though it's informational). For example, in
https://cyber.dhs.gov/bod/18-01/ :

"All agencies are required to...enhance email security by...Within one
year after issuance of this directive, setting a DMARC policy of
“reject” for all second-level domains and mail-sending hosts."

---

From: Dave Crocker <[email-masked]>
Date: Sat, 13 Jun 2020 20:17:55 -0700

On 6/13/2020 7:53 PM, Jim Fenton wrote:
> Alas, others do,

Other groups do all sorts of things.  They once mandated OSI, for example.

Please explain how that is relevant, here and now.

Are you perhaps suggesting that the technical work of the IETF should 
worry less about technical quality and more about possible use/abuse by 
other agencies?

d/

---

From: Hector Santos <[email-masked]>
Date: Sun, 14 Jun 2020 01:16:11 -0400

On 6/13/2020 11:17 PM, Dave Crocker replied to Jim Fenton wrote:
> worry less about technical quality and more about possible use/abuse
> by other agencies?

Dave,

It didn't look good when the IETF officially abandoned the ADSP 
protocol citing technical quality issues, yet helped a special 
interest group reintroduce "Super ADSP" under a different name with 
the same exact technical quality issues and fast tracked it as an 
informational RFC proposal.

---

From: [email-masked]
Date: Sun, 14 Jun 2020 11:24:42 +0200

Le 13/06/2020 à 17:19, Douglas E. Foster a écrit :
> Based on the response to my previous post, "Trained User" is not a meaningful concept, for purposes of this 
> discussion [...]

That's not my point. My point is: this working group needs to make a 
determination whether From addresses being displayed to the users 
matters to DMARC or not, and then follow up consistently.

If it is, then don't break From addresses with munging.

If it is not, then use Sender field as a fallback for alignment, and 
don't break From either.

> [...] > I suggest that the "Mailing List Problem" is a problem that does not 
need to be solved (and evidence suggests that it> cannot be solved.)   I 
can think of no purpose served by a public mailing list, like this one, 
which is not be better > solved by a community forum website with user 
login.

Thanks for you honesty. Then the relevant question is whether open and 
interoperable standards still matter, or if they should be replaced by 
proprietary web apps one feature at a time.

Cheers,
Baptiste

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Sun, 14 Jun 2020 10:07:37 -0700

On Fri, Jun 12, 2020 at 5:06 PM Scott Kitterman <[email-masked]>
wrote:

> Not sure what is confusing about that.  There's no requirement that
> signatures from previous hops still verify, so anyone can build an ARC
> chain that claims they got something from an arbitrary source.  ARC is only
> usable if you know you trust the source.
>

Perhaps we are debating semantics here, but a wholesale replacement of the
message content within the bounds of an ARC-chain-span is not what I would
call "forgery". One can not simply "build an ARC chain" because each
ARC-Seal header is cryptographically created by the entities which control
the respective private keys.

Trust matters, but really has nothing to do with the interoperability or
validity of the chain itself.

--Kurt

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 14 Jun 2020 13:18:43 -0400

On Sunday, June 14, 2020 5:24:42 AM EDT [email-masked] wrote:
> >     If you teach users that "Joe User by Random Intermediary" is the same
> >     as "Joe User", this expectation is doomed.> 
> > Based on the response to my previous post, "Trained User" is not a
> > meaningful concept, for purposes of this discussion [...]
> 

I don't think that's the question at all.

Whether user's knowledge of the from address has any bearing on anti-abuse 
methods or not, it has plenty of value for other purposes.  DMARC is not all 
of email.

From rewriting is a gross hack that exists only due to dire necessity.  If 
this working group can't move the space towards a more usable solution, I'm 
not at all sure DMARCbis is worth the trouble.

Scott K

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Sun, 14 Jun 2020 10:25:17 -0700

On Fri, Jun 12, 2020 at 5:52 PM Dave Crocker <[email-masked]> wrote:

> origin of a message is valid.
>

By "creator" do you mean "initiator" (aka, the source of the first ARC set,
i=1)?

In general ARC chains are the product of a series of co-creators through
the handling sequence for the message, so I think that "creator" in a
singular sense is a little misleading.

--Kurt

---

From: Dave Crocker <[email-masked]>
Date: Sun, 14 Jun 2020 10:47:53 -0700

On 6/14/2020 10:25 AM, Kurt Andersen (b) wrote:
> On Fri, Jun 12, 2020 at 5:52 PM Dave Crocker <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
> By "creator" do you mean "initiator" (aka, the source of the first ARC 
> set, i=1)?

yes.

d/

---

From: "John Levine" <[email-masked]>
Date: 14 Jun 2020 14:42:59 -0400

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

I think it't the other way around. Let's say you get a message with
three ARC seals. For i=3 both the AMS and AS headers should validate,
since the message came directly from the entity that put on that seal.
For i=1 and i=2 the AS should validate but the AMS probably won't. The
cv= tag in each AS header tells us whether the AMS was good when it
arrived at that intermediary, so the i=1 and i=2 seals are only as
good as the i=3 signer's reputation.

I were a certain kind of bad guy, I would take the two seal ARC chain
from a message from a virtuous sender, replace the message body and
>From and Subject line with my spam, add a fresh new i=3 seal and blast
it out. That ARC chain is 100% valid, even though the messsage is
spam.

That's why (as Kurt knows) you only pay attention to ARC seals from
senders that are otherwise credible.

-- 
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: Jim Fenton <[email-masked]>
Date: Sun, 14 Jun 2020 22:29:55 -0700

> Please explain how that is relevant, here and now.
The WG needs to consider the operational impact of DMARC deployment if
it is going to publish DMARC as a WG document.
> worry less about technical quality and more about possible use/abuse

That is a false dilemma. We can (and should) consider possible use/abuse
of specifications we publish, but that does not imply worrying less
about technical quality.

-Jim

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 15 Jun 2020 09:33:36 +0200

> I don't think that's the question at all.

+1, we're not going to reinvent DMARC, just elucidate it.

> not at all sure DMARCbis is worth the trouble.

Let me quote a list of nineteen usable solutions:

     1 Sending side workarounds
         1.1 Exclude domains that require alignment
         1.2 Turn off all message modifications
         1.3 Replace address with a generic one
         1.4 Add fixed string such as .invalid to addresses
         1.5 Rewrite addresses to forwarding addresses
         1.6 Message wrapping
         1.7 Mandatory digests
         1.8 Ignore DMARC bounces
         1.9 Third Party Authorization
     2 Recipient workarounds
         2.1 Forwarder whitelist
     3 Cooperative solutions
         3.1 Shared whitelist
         3.2 Per sender whitelist
         3.3 Original-Authentication-Results header
         3.4 Forwarding token
     4 Authorization approaches
         4.1 Authenticated Received Chain (ARC)
         4.2 Signing key delegation
         4.3 Relay through author domain server
         4.4 Relay one copy through author domain server
         4.5 Have author domains sign camera-ready posts
     [https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail]

That page hasn't been updated since 2016.  I don't think we can devise any new 
solution now.  There's been a natural selection.  Solution 1.3 prevailed, with 
a minority of lists opting for 1.2.  Let's face facts.

Best
Ale
--

---

From: Dave Crocker <[email-masked]>
Date: Mon, 15 Jun 2020 05:48:32 -0700

> of specifications we publish, but that does not imply worrying less

Some people send spam.  We'd better deprecate all the email specifications.

Some agencies make silly or terrible rules.  And there are so many 
agencies. We'd better shut down the IETF because any specification can 
be abused and probably will be.

Perhaps you can offer a rather more focused, specific and deterministic 
concern?

d/

---

From: "John Levine" <[email-masked]>
Date: 15 Jun 2020 09:56:17 -0400

>Let me quote a list of nineteen usable solutions:

I wouldn't call them all usable.  Proposed, perhaps.

>That page hasn't been updated since 2016. 

If anyone has any new bright ideas, let me know and I'll send you a
password so you can update the wiki.

R's,
John

---

From: Jesse Thompson <[email-masked]>
Date: Mon, 15 Jun 2020 12:08:00 -0500

On 6/15/20 2:33 AM, Alessandro Vesely wrote:
> That page hasn't been updated since 2016.  I don't think we can devise any new solution now.  There's been a natural selection.  Solution 1.3 prevailed, with a minority of lists opting for 1.2.  Let's face facts.

Precisely.  Let's work from a basis of reality.

I'm representing an EDU here.  Mailing lists are still heavily used in EDU for cross-institution and cross-sector collaboration.  They aren't going to be replaced by web forums or Yammer (or whatever corporate enterprise aspire to do) because faculty are open and collaborative by their nature.

We have over $1bn in research expenditures, most of which are funded by federal grants, and so we need to receive mail (sometimes indirectly) from federal agencies who are adhering to BOD 18-01.  A growing number of universities are publishing DMARC policies, and an unknown but presumably growing number of universities and agencies are enforcing DMARC policies for other domains.  It's becoming increasingly difficult to ignore DMARC.

Given that Microsoft and Google have essentially soaked up the entire EDU email market (hey, the price is right), let's say for sake of argument[*] that most EDUs are faced with 2 choices for their MLM:  Google Groups and Microsoft 365 Groups.

Microsoft's solution: 1.2 (conditionally, based on some logic, it seems)
Google's solution: 1.3 (conditionally, based on DMARC p=quarantine or p=reject)

We can delve into *why*, but the reality is that we have failed with using Microsoft 365 Groups with external collaborators from domains that have adopted DMARC *even though* we use Microsoft 365 for mailbox hosting, and we heavily use Microsoft 365 Groups for internal collaboration.  

Given that choice in this context, I believe that Google Groups will be chosen as their MLM by anyone taking DMARC into consideration.  I would not be surprised if Microsoft falls in line with solution 1.3.

So, solution 1.3 has been naturally selected.  Does it need to be standardized, or is a BCP good enough?  I'd still like to see a solution for receivers to "un-munge" trustworthy messages in a safe and consistent way.  Is that where ARC comes in?

Thanks,
Jesse

[*] Glossing over the fact that a university is not a single entity.  There are hundreds of entities within a university that all may individually choose their own solution.

---

From: "John Levine" <[email-masked]>
Date: 15 Jun 2020 13:44:22 -0400

>> That page hasn't been updated since 2016.  I don't think we can devise any new solution now.  There's
>been a natural selection.  Solution 1.3 prevailed, with a minority of lists opting for 1.2.  Let's face
>facts.

Here in the IETF we use 1.5 but, yes.

>Google's solution: 1.3 (conditionally, based on DMARC p=quarantine or p=reject)

They both claim they're working on ARC.

>So, solution 1.3 has been naturally selected.  Does it need to be standardized, or is a BCP good enough? 
>I'd still like to see a solution for receivers to "un-munge" trustworthy messages in a safe and
>consistent way.  Is that where ARC comes in?

No.  ARC lets mail systems accept list mail without munging.

R's,
John

---

From: Brandon Long <[email-masked]>
Date: Mon, 15 Jun 2020 11:18:16 -0700

> >Google's solution: 1.3 (conditionally, based on DMARC p=quarantine or

We sometimes use a different solution that isn't listed, which is basically
where internal groups have access to the
domain DKIM key, so they just re-sign.  Those aren't really an interesting
case, though.

Also, we chose that due to expediency at the time with the possible theory
of doing 1.5... and I don't imagine at this
point doing 1.5 will ever be high enough on the list to be done.

Honestly, ARC is probably going to be used for things besides mailing lists
first, since the main challenge is that there are a
lot of places where 1.2 isn't maintained during relaying which may never be
fixed (or can not be).  We're already
using it to know when not to trust SPF, for example.  I imagine the ability
to handle third party security filters better
will also happen before mailing lists.  In some respects, using it to make
local receiving decisions is easier than knowing
when it's possible for a mailing list to rely on ARC being implemented by
it's receivers and to stop using one of the other
work arounds.

Brandon

---

From: Jesse Thompson <[email-masked]>
Date: Mon, 15 Jun 2020 13:19:22 -0500

> No.  ARC lets mail systems accept list mail without munging.

How will a random intermediary know if random destination has implemented ARC and will trust their claim?  Even domains hosted by SaaS providers will have their own ARC reputation to manage, and might have to do things like configure munging on a per-recipient/domain basis, assuming the SaaS provider grants that level of control.  It's safer and easier to munge everything.  

Even if you ignore my line of reasoning, I think that Ale made in the OP a compelling case that the practice of From rewriting is here to stay.

Jesse

---

From: Tim Wicinski <[email-masked]>
Date: Mon, 15 Jun 2020 14:22:25 -0400

(no hats)

On Mon, Jun 15, 2020 at 2:18 PM Brandon Long <blong=
[email-masked]> wrote:

>
> We sometimes use a different solution that isn't listed, which is
> basically where internal groups have access to the
I used to encourage creating CNAMEs to DKIM keys that internal groups
managed themselves.
(DNS things like that are like nice BCP for DMARC deployment.)

Large corporations with legacy domains and multiple business units
operating semi-independently
are the same problem space as Jesse's University case.

tim

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 15 Jun 2020 14:27:08 -0400

On Monday, June 15, 2020 2:19:22 PM EDT Jesse Thompson wrote:
> >> So, solution 1.3 has been naturally selected.  Does it need to be
> >> standardized, or is a BCP good enough? I'd still like to see a solution
> >> for receivers to "un-munge" trustworthy messages in a safe and
> How will a random intermediary know if random destination has implemented
> ARC and will trust their claim?  Even domains hosted by SaaS providers will
> have their own ARC reputation to manage, and might have to do things like
> configure munging on a per-recipient/domain basis, assuming the SaaS
> provider grants that level of control.  It's safer and easier to munge
> everything.

They won't.  Bypassing DMARC based on ARC requires some level of trust in the 
source of the message.

> Even if you ignore my line of reasoning, I think that Ale made in the OP a
> compelling case that the practice of From rewriting is here to stay.

As a practical matter, that's certainly true for the short to medium term, but 
it doesn't follow that the IETF should standardize the practice.

To follow-up on Brandon's note about Google's use of ARC, it's bigger than 
mailing lists and so is this problem.  It's any intermediary that modifies a 
message in such a manner that DKIM fails (SPF is only useful for direct source 
ADMD to destination ADMD tranmissions).

I suspect that by hyper focusing on mailing lists, we're missing part of the 
problem.

Scott K

---

From: Tim Wicinski <[email-masked]>
Date: Mon, 15 Jun 2020 14:30:36 -0400

> I suspect that by hyper focusing on mailing lists, we're missing part of
I think the mailing list issue looms so large as to block out everything
else.  We (probably the chairs) should make sure we don't miss the the
non-mailing list part of this problem.

tim

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Mon, 15 Jun 2020 13:56:55 -0700

> non-mailing list part of this problem.

That's what RFC 7960 (the first work product from this group) was all about.

--Kurt

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 15 Jun 2020 17:20:25 -0400

> That's what RFC 7960 (the first work product from this group) was all about.
So problem solved?  No need to revisit?

Scott K

---

From: "John Levine" <[email-masked]>
Date: 15 Jun 2020 17:43:35 -0400

>So problem solved?  No need to revisit?

The only indirect flows it talks about in any detail is mailing lists.

It's worth a look to see if there are others we understand well enough
to describe.

---

From: "Douglas E. Foster" <[email-masked]>
Date: Tue, 16 Jun 2020 03:25:43 GMT

Other uses of indirect mail:

My university offered an alumni account implemented as a relay to whatever hosting service I was using at the moment.   Never took them up on it, and glad that I did not.   Perhaps RFC 7960 talked about that scenario, because I think I have seen it mentioned in an IETF document.

Header munging vs Alternatives:

Header munging vs.  Perfect author attribution

I have been considering an alternative world where header munging is eliminated because author content is not modified and therefore author identified is fully verifiable using DKIM and DMARC.   Several concerns come to mind:

We do a fair amount of geographic filtering, so some of the postings to this list would be blocked, because of coming from countries where we do not do business.  Header munging provides a single point of origin; if one message is allowed through the geographic filters, then all messages will be allowed through.   If an exception is needed, the list member and system manager can be confident that only a single exception is necessary.

One of the reasons that IETF breaks DKIM is because it converts everything to a plain text.   This is a significant security benefit, by lowering the threat potential of the message.  It makes the IETF messages more trustworthy than if they came to me directly from the author.   Other mailing lists may use other criteria, but they should all use some sort of filtering to protect their reputation and their members.  Header munging allows me to distinguish between IETF-filtered traffic and other traffic.

As an extension of that point, successful sender authentication establishes identity, but it does not establish trust.   Trust is assigned by the recipient, largely based on experience, so message from unrecognized senders is given a low trust level by default.    I know how to trust IETF.   I do not know whether to trust the next random person who contributes to this mailing list.   

ARC assumes that after a user subscribes to a mailing list, he negotiates with his I.T. staff to have the mailing list operator authorized.   I expect this to be problematic for many users.
To mitigate these concerns, the non-munging solution would presume that recipient systems have the ability to filter differently between ( unknown sender + known mailing list ) and ( unknown sender without mailing list ).    To prevent spoofing of the mailing list, list identity would need to be verified as well as author identity.   As we add complexity to the inbound mail process design, some extra processing logic is applied to all messages, not just the mailing list messages.   How many filtering solutions will be unable or unwilling to add this complexity?    

Others have already noted that the mailing list operator must choose a configuration without knowledge of what capabilities will exist in the receiving system message filter.   This seems to limit the range of possible solutions.

Given all of that, I think a non-munging solution would be more problematic for me than what IETF is already doing.

DF

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 15 Jun 2020 23:00:59 -0700

> proprietary web apps one feature at a time.

Both have been around for a long time now and I've seen no evidence
that the Internet public at large is keen to make such a wholesale
migration.

We apparently really, really like our mailing lists.

-MSK, hatless

---

From: Brandon Long <[email-masked]>
Date: Tue, 16 Jun 2020 11:17:27 -0700

> We apparently really, really like our mailing lists.

I for one am always amazed how much people use web forums, which are almost
all universally worse at providing a reading interface or keeping people
up-to-date on new messages... which might be why most of the one's I look
at are nearly dead, maybe there are better ones that are active.

Brandon

---

From: "John Levine" <[email-masked]>
Date: 16 Jun 2020 14:46:28 -0400

>at are nearly dead, maybe there are better ones that are active.

Well, there's Reddit, and um, er.  Flyertalk, I guess.

One thing web forum fans seem to miss is how poorly they scale. I
subscribe to at least 150 mailing lists, most of which are only active
occasionally. As mailing lists, that works fine. The busier ones go
into separate folders, less busy into a general folder, and MUAs tell
me which folders have new messages so I can scan through all of my
list mail about as fast as I can hit the tab key to move on to the
next message. This works equally well for public and private lists.

In theory RSS or Atom does this for web forums, in practice, it's
amazing how lousy their RSS support is and how lame RSS readers are
for public fora, and hopeless for private ones where you have to log in.

---

From: [email-masked]
Date: Tue, 16 Jun 2020 11:53:22 -0700 (PDT)

> for public fora, and hopeless for private ones where you have to log in.

And that assumes the site supports RSS/Atom. Many don't.

The other problem with all of these tools is that someone else gets to
decide how to organize your life. If you decide that two different fora
should be grouped together, good luck getting your reader to do that for
you.

But Slack is the true nadir of usability in this regard. I have dozens of
channels I need to monitor, the breakdown of same is not remotely aligned with
how I would prefer to consume them. Add in a complete crap UI, and I honestly
can't think of a mail UI I've used that's worse. Not ever.

				Ned

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 16 Jun 2020 19:16:13 -0400

On Tuesday, June 16, 2020 2:53:22 PM EDT [email-masked] wrote:
> > In article 
<[email-masked]> you 
write:
> channels I need to monitor, the breakdown of same is not remotely aligned
> with how I would prefer to consume them. Add in a complete crap UI, and I
> honestly can't think of a mail UI I've used that's worse. Not ever.

It's like someone took IRC and decided to actively worsen it.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 17 Jun 2020 11:23:30 +0200

> it doesn't follow that the IETF should standardize the practice.

There are a few shortcomings of From: rewriting, which could be mitigated 
adopting suitable conventions.  For example, MUAs' replying to author, or 
storing rewritten addresses in address books.

As evidenced in the page cited[*], methods 1.* are characterized by being MLM 
side workarounds[†].  That is, they can be applied unilaterally, without 
collaboration nor mutual support.  A state of affairs dictated by the lack of 
standardization.

Now, if we make a semantic effort, we must recognize that the address of From: 
as a matter of fact refers to the "managing editor" of the corresponding mail 
flow, whereas the display name may indicate the actual author.  To say nothing 
of the Sender: field, which wasn't designed for that role anyway.  That's how 
email has evolved after introducing authentication.  I'd hope rfc5322bis will 
recognize those changes.  Meanwhile, if we gather consensus on how to do it 
better, it'd be fair to write it down, no?

Best
Ale
-- 

[*] https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail

[†] Hm... except for 1.9 TPA.  It should be moved downward, methinks.

---

From: "Pete Resnick" <[email-masked]>
Date: Wed, 17 Jun 2020 11:56:07 -0500

On 17 Jun 2020, at 4:23, Alessandro Vesely wrote:

> There are a few shortcomings of From: rewriting, which could be 
> mitigated adopting suitable conventions.  For example, MUAs' replying 
> to author, or storing rewritten addresses in address books.

As soon as you start down that path, you have eliminated one of the 
purported values of From: alignment: MUAs will start using those 
conventions (X-Original-From:, decoding encoded Froms) and display that 
information to the user instead of what's in the From: field, in which 
case you're going to need X-Original-From: alignment, and down the 
spiral we go. (For those who are amused by such things, do a web search 
for "X-X-Sender".) I am not convinced by many of the arguments for From: 
alignment, and think the problems lie with the lack of semantics able to 
be conveyed by a DMARC record in these cases, but I seem to be in the 
rough on these points. But there is no magic bullet in "suitable 
conventions".

> Now, if we make a semantic effort, we must recognize that the address 
> of From: as a matter of fact refers to the "managing editor" of the 
> corresponding mail flow, whereas the display name may indicate the 
> actual author.

No, the semantics of From: have not changed generally. It's that some 
mailing lists have to change the semantics of From: in the face of the 
inability of DMARC to express the semantics that they want. I can get 
together with a group of my friends and decide that the word "sunny" 
really means "cloudy", but unless the whole English-speaking world is on 
board with me, communication is bound to have problems.

> To say nothing of the Sender: field, which wasn't designed for that 
> role anyway.

Sender: has had pretty much the same definition back to RFC 733. It was 
perfectly designed for "the thing that sent the message, independent of 
the author."

> That's how email has evolved after introducing authentication.

For most email, the meanings haven't changed at all. For a certain class 
of mail, authentication of a certain sort has forced arbitrary changes 
that have made the semantics ambiguous as compared to the past.

> I'd hope rfc5322bis will recognize those changes.

I sure hope not.

> Meanwhile, if we gather consensus on how to do it better, it'd be fair 
> to write it down, no?

Assuming you can gather consensus. I'm not convinced you can.

pr
-- 
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best

---

From: Jesse Thompson <[email-masked]>
Date: Wed, 17 Jun 2020 11:58:17 -0500

On 6/17/20 4:23 AM, Alessandro Vesely wrote:
> There are a few shortcomings of From: rewriting, which could be mitigated adopting suitable conventions.  For example, MUAs' replying to author, or storing rewritten addresses in address books.
> 
> As evidenced in the page cited[*], methods 1.* are characterized by being MLM side workarounds[†].  That is, they can be applied unilaterally, without collaboration nor mutual support.  A state of affairs dictated by the lack of standardization.
> 
> Now, if we make a semantic effort, we must recognize that the address of From: as a matter of fact refers to the "managing editor" of the corresponding mail flow, whereas the display name may indicate the actual author.  To say nothing of the Sender: field, which wasn't designed for that role anyway.  That's how email has evolved after introducing authentication.  I'd hope rfc5322bis will recognize those changes.  Meanwhile, if we gather consensus on how to do it better, it'd be fair to write it down, no?

There at least needs to be a consensus and an official-looking place that we can point intermediaries when they're getting hit by the DMARC train; as policy publication and enforcement accelerates.  A M3AAWG BCP, perhaps?

Some MLM operators think that setting the Sender header is recommended/good enough.  Some MUAs display the Sender instead of the From if it's set, which is why I think some people think it's equivalent to changing the From header.  That wiki[*] doesn't even mention the Sender header, so it doesn't really serve as a mechanism to dissuade the notion.

If there is no consensus on a single recommendation, then perhaps there needs to be more than one recommendation articulated in a preferential, guided, fashion:
1) If 100% of receivers will trust ARC from the intermediary - do X
2) If DKIM signing and intermediary survival is 100% - do Y
3) Else, do Z
etc...
Along with recommendations for each party regarding what they should do in each situation. 

Those of us who are opinionated about this topic can focus our arguments on the order/criteria/nuances of the recommendations rather than trying to agree on a single one.

The main benefit to making the recommendation(s) more standard is that it will serve to help intermediaries configure things in a "DMARC compatible" fashion and justify any change as necessary to skeptical stakeholders.  It will also serve as a way for IT staff to evaluate alternative software/services if they are considering upgrades vs. replacement.

> [†] Hm... except for 1.9 TPA.  It should be moved downward, methinks. 

Seems in the Cooperative category.  Maybe there needs to be a distinction between Sending (user/MSA vs domain owner?) vs Intermediary solutions?  Or a matrix to capture different qualities.  I don't know, there's a lot about that doc that makes it hard for an average person even know where to start tackling the problem.  Most people don't have years of experience in the email domain to understand all of the nuances.

Jesse

---

From: "John Levine" <[email-masked]>
Date: 17 Jun 2020 14:00:33 -0400

In article <[email-masked]> you write:
>inability of DMARC to express the semantics that they want. ...

I'm with Pete here.  Please leave this bunch of worms in the can.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Wed, 17 Jun 2020 11:27:44 -0700

On 6/17/2020 9:56 AM, Pete Resnick wrote:
> inability of DMARC to express the semantics that they want. 

The two sentences seem to be in conflict. If there is a degree of 
practice that creates a different semantic for the field, then its 
semantics have changed, at least for the portion of email traffic.

Here's a simple operational test:  MUAs typically can aggregate messages 
'from' the same author.  After all, that's always been the primary role 
of From, to indicate who created the content. Such aggregation is 
usually found to be helpful.

Historically -- for 40+ odd years -- this has worked for mail going 
through mailing lists.  Now it usually doesn't. I'd appreciate an 
explanation of how that does not constitute a change in semantics.

Have a folder with a variety of messages from correspondents, where some 
of a person's messages are sent directly to you and some of their 
messages are sent through mailing lists that adapt the From: field 
content in order to avoid DMARC rejection.  The MUA will handle mail 
from the same person, but that went through these two different paths, 
as being from different sources.

DMARC relies on From: because it is the only field with an identifier 
that is always present. Sender is not reliably present, except 
virtually.  The nature of what DMARC is actually doing looks more like 
relying on the operations-related Sender: field than the author-related 
From: field.

DMARC has nothing to do with display of author information to a 
recipient, and everything to do with differential handling by a 
receiving filtering engine.  Were the Sender: field always present, that 
would be the one that DMARC should have used.

So, really, DMARC has altered the semantics of the From: field to be the 
Sender: field.  The nature of the hack that mailing lists do, when 
altering the From: field, makes this clear:  They alter information 
about the operator handling the message, destroying the original 
information about content authorship.

d/

---

From: "Pete Resnick" <[email-masked]>
Date: Wed, 17 Jun 2020 14:11:31 -0500

On 17 Jun 2020, at 13:27, Dave Crocker wrote:

>> mailing lists have to change the semantics of From: in the face of 
>> the inability of DMARC to express the semantics that they want.
>

You'll note the word "generally". Most of my email carries the same 
semantics it always has in From:. There is a small subset that doesn't. 
But (and not to get too philosophical here), even when the semantics 
aren't the same, it is often a surprise: I find that something didn't 
match my expectations, only to discover that the originator of the email 
didn't use the same semantics I was expecting as recipient. That doesn't 
necessarily constitute a change in semantics for the email, but a 
mismatch: The originator said "sunny" and I thought that meant "without 
clouds". Even if I figure out the mismatch, I might not agree to "the 
semantics changed"; I might prefer to go with, "The originator made a 
mistake." In the present case, some mailing lists are using the same old 
semantics and some are using a new set; that doesn't convince me that we 
have an interoperable semantics to which we have "changed".

> Here's a simple operational test:  MUAs typically can aggregate 
> messages 'from' the same author.  After all, that's always been the 
> primary role of From, to indicate who created the content. Such 
> aggregation is usually found to be helpful.
>

Of course, I'd be interested in the "usually" part. It's not true of my 
mailstore, but my mailstore is far from average. I do know that even on 
the local non-profit board to which I belong (and had no hand in setting 
up), the Outlook server uses the semantics to which I am accustomed, 
though maybe having a smaller list where most people using their gmail 
addresses makes it equally "not average".

> Have a folder with a variety of messages from correspondents, where 
> some of a person's messages are sent directly to you and some of their 

I'm sure that happens.

> virtually.  The nature of what DMARC is actually doing looks more 
> like relying on the operations-related Sender: field than the 
> author-related From: field.
>
> receiving filtering engine.  Were the Sender: field always present, 
> that would be the one that DMARC should have used.

It could have chosen the more complicated, "Sender unless not present, 
in which case From". But yes, this bit I get. That said, there are 
people who have argued that From: was chosen because Sender: was not 
displayed. I think that's a silly argument, but it's one that people 
still believe.

> So, really, DMARC has altered the semantics of the From: field to be 
> the Sender: field.

Wait a minute: I think this point needs some clarification. We know that 
the pre-DMARC semantics of the From: field are "the entity that authored 
the message". Originators were expressing that meaning and recipients 
were interpreting that meaning. My understanding of the meaning that 
DMARC added was, "The author of this message, as expressed in the From: 
field, always has their messages properly signed by the domain in the 
 From: address." You seem to be saying that, no, what DMARC did was 
changed the semantic to be, "The From: field now represents the 
transmitter of the message (as used to be expressed in the Sender: field 
when present), not the author, and that transmitter always has their 
messages properly signed by the domain in the From: address". Do I have 
that right? (And I presume that either way, these are de facto 
semantics, not intentional ones that are documented anywhere, right?)

> The nature of the hack that mailing lists do, when altering the From: 
> field, makes this clear:  They alter information about the operator 
> handling the message, destroying the original information about 
> content authorship.

Mailing lists that make other choices (throwing away messages from DMARC 
reject senders, denying subscriptions from them, or simply ignoring them 
and ending up with bad consequences) have obviously not gone along with 
the certain forms of the semantic change.

pr

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 18 Jun 2020 09:46:48 +0200

On Wed 17/Jun/2020 21:11:31 +0200 Pete Resnick wrote:
>>> No, the semantics of From: have not changed generally. [...]
> 
>> Sender: field.
> Wait a minute: I think this point needs some clarification. We know that the 
> pre-DMARC semantics of the From: field are "the entity that authored the 
> message".

"Authoring" can have subtly different acceptations, though.  The exact sentence is:

              The "From:" field specifies the author(s) of the message,
    that is, the mailbox(es) of the person(s) or system(s) responsible
    for the writing of the message.
                    [https://tools.ietf.org/html/rfc5322#section-3.6.2]

That is not so far from real.  The term "writing" sounds ambiguous, as it is 
not clear whether it means "typing" or "publishing", in the case of public 
mailing lists.  Given that Sender: is dedicated to the typist, I'd opt for the 
latter interpretation.

For a newspaper, if you pardon the analogy, the masthead is more visible than 
columnist signatures at the end of the articles.  For a mailing list, publisher 
visibility used to be provided by subject tags, leaving the From: intact.  Why? 
  Presumably, because it just worked that way.  However, if the MLM is the 
system responsible for writing, not modifying From: should be considered a 
violation.

> My understanding of the meaning that DMARC added was, "The author of this
> message, as expressed in the From: field, always has their messages properly
> signed by the domain in the From: address." You seem to be saying that, no,
> what DMARC did was changed the semantic to be, "The From: field now
> represents the transmitter of the message (as used to be expressed in the
> Sender: field when present), not the author, and that transmitter always has
> their messages properly signed by the domain in the From: address".

Sender: was not meant to be the transmitter in that sense.  It was meant to be 
the secretary who writes on behalf of a responsible person or system.  It never 
had traction, AFAIK.  Most clients don't allow secretaries to add their mailbox 
to the messages they write.  Google «How do I change the sender in Outlook?»

Sender ID tried to hijack Sender: —much like DMARC hijacked From:— to introduce 
the concept of an entity responsible for the last hop.  DMARC requires that the 
last hop is also the first one, or else that the forwarding is mechanically 
smooth, an unparticipated transmission which breaks no signatures.

Mailing lists match neither case.  Couldn't we consider From: rewriting a sort 
of message/rfc822-wrap lite?

It may well be that X-Original-From: is not a good convention.  There's a bunch 
of questions to clarify, such as whether users see the domain part of a mailbox 
address, whether they can tell authenticated messages, or whether they should 
be trusted at all.  However, unlike Sender ID, DMARC seems to have enough 
success to cause a semantic shift.  If it can result in a simplified filtering, 
I'd accept it.

RFC 5322 says display names are "associated" to a mailbox.  Certainly, changing 
just the addr-spec breaks the association and wreaks havoc to address books. 
The convention to write "MLM on behalf of" seems sound, but it takes sixteen 
columns of real estate in the folder view.  Can't we do better?

Best
Ale
--

---

From: Hector Santos <[email-masked]>
Date: Thu, 18 Jun 2020 15:01:29 -0400

Alessandro,

There are long time solid reasons why the "Local.From" field needs to 
be stable. In particular, with local messaging, unless the local 
system allows for anonymous entry of the Local.From field when 
creating a Local message, there is a MUST for a 1 to 1 association 
with the account.

If local mail is exported for a external network, it doesn't matter 
what mail network it is, you really don't want to introduce the idea 
of allowing the changing of the Network.from field and making it 
anonymous or disassociated with the original source. The domain is 
associated with the source of the message, and the user part of the 
address reflects the user account at the domain.  There are good 
reasons for that.   Lets say the user is causing a problem on a remote 
system. Using the network.From, the remote system could contact the 
original system and issue a complaint.  If we were "free" to remove 
that idea, it be would harder to trace it.   DKIM allows you to lock 
that field down so that it can't be tampered with.

You have to understand the long time pov of developers that have been 
at this for 40 years.  Every system I have worked, the different 
networks, it was the same thing -- leave the from field alone! Do not 
make it "anonymous" or capable of being an "unknown."

Its the same for Instant Messaging, for Chatting, the TELEPHONE, the 
Caller ID, etc, it is a TABOO to change the "From" entity.

If you want to continue your line of logic to rationalize Rewriting, 
then you need to make it "protocol complete"  to help keep the 
association of the From field with the original source intact. But 
more importantly, it should have get permission from the original 
domain in order to rewrite. This can be done with a DMARC tag extension:

DMARC p=reject|quarantine ... rewrite=0|1

The default sides with highest security -- No Rewriting. But if the 
domain wishes to allow for rewriting, then it should explicitly state 
it in this policy record, rewrite=1.

This is something I could possibly support IFF the originating domain 
allows it. There would other things to consider to tie the loose ends, 
but the #1, would be the rewrite=1 tag.

On 6/18/2020 3:46 AM, Alessandro Vesely wrote:
>>> So, really, DMARC has altered the semantics of the From: field to
>>> be the Sender: field.
>>
>> Wait a minute: I think this point needs some clarification. We know
>> that the pre-DMARC semantics of the From: field are "the entity that
>> authored the message".
>
>
> That is not so far from real.  The term "writing" sounds ambiguous, as
> it is not clear whether it means "typing" or "publishing", in the case
> of public mailing lists.  Given that Sender: is dedicated to the
> typist, I'd opt for the latter interpretation.
>
> For a newspaper, if you pardon the analogy, the masthead is more
> visible than columnist signatures at the end of the articles.  For a
> mailing list, publisher visibility used to be provided by subject
> tags, leaving the From: intact.  Why?  Presumably, because it just
> worked that way.  However, if the MLM is the system responsible for
> writing, not modifying From: should be considered a violation.
>
>
> Sender: was not meant to be the transmitter in that sense.  It was
> meant to be the secretary who writes on behalf of a responsible person
> or system.  It never had traction, AFAIK.  Most clients don't allow
> secretaries to add their mailbox to the messages they write.  Google
> «How do I change the sender in Outlook?»
>
> Sender ID tried to hijack Sender: —much like DMARC hijacked From:— to
> introduce the concept of an entity responsible for the last hop.
> DMARC requires that the last hop is also the first one, or else that
> the forwarding is mechanically smooth, an unparticipated transmission
> which breaks no signatures.
>
> Mailing lists match neither case.  Couldn't we consider From:
> rewriting a sort of message/rfc822-wrap lite?
>
> It may well be that X-Original-From: is not a good convention.
> There's a bunch of questions to clarify, such as whether users see the
> domain part of a mailbox address, whether they can tell authenticated
> messages, or whether they should be trusted at all.  However, unlike
> Sender ID, DMARC seems to have enough success to cause a semantic
> shift.  If it can result in a simplified filtering, I'd accept it.
>
> RFC 5322 says display names are "associated" to a mailbox.  Certainly,
> changing just the addr-spec breaks the association and wreaks havoc to
> address books. The convention to write "MLM on behalf of" seems sound,
> but it takes sixteen columns of real estate in the folder view.  Can't
> we do better?
>
>
> Best
> Ale

---

From: Jim Fenton <[email-masked]>
Date: Thu, 18 Jun 2020 14:10:43 -0700

> displayed. I think that's a silly argument, but it's one that people

I'm trying to understand why alignment to any header field is important
to DMARC in that case. If whatever it's aligning to is not visible, the
sender can trivially achieve alignment by choosing the From: (or
Sender:, whatever) address to match the domain of the DKIM signature
and/or envelope-from address. I don't see how that contributes at all to
differential handling by a receiving filtering engine. If it's because
From: is visible, the address part of From is getting to be a lot less
visible, plus typical users will ignore the address anyway.

And if From: alignment doesn't matter, the mailing list can just sign
the message and no rewriting is needed.

-Jim

---

From: "Douglas E. Foster" <[email-masked]>
Date: Thu, 18 Jun 2020 21:13:35 GMT

There are some basic principles that need to be considered:.

DMARC did not break mailing list privileges, unwanted mail did.

A fully legitimate message has these characteristics:
Intended by the originatorAcceptable to the policies of the domain owner, which are partially implemented in its outbound mail filterDesired by the recipientAcceptable to the recipient domain owner, as partially implemented in its inbound mail filter.
One example of a message that is not acceptable to the originator is a message spoofed by an authorized server.   This is one of the problems addressed by DMARC.

More specifically, what characteristics make a message acceptable to the recipient:
A recognized / trusted senderA message which looks like previous-good messagesA message with no identifiable risk factors.
To elaborate, incoming mail filters separate mail into three buckets:
Probably unwantedUnknown and hopefully harmlessDefinitely wanted

The administrators of the incoming mail filter will be continually seeking to move traffic from bucket 2 to bucket 1 or bucket 3, so a strategy based on bucket 2 is not guaranteed to work indefinitely.

>From the viewpoint of the inbound mail filter, forwarded mail is indistinguishable from spoofed mail using an open relay.   In a world where all mail was wanted mail, mailing lists could do what they want.  But we are not on Arpanet anymore, and unwanted mail is a huge problem.

If a mailing list is violating DMARC, it is likely to be put in bucket 1.   Once one message ends up in bucket 1, all messages from that source are likely to be blocked as well.

For a sender to be promoted from bucket 1 to bucket 2, messages need to distinguish themselves from untrusted email.   Preserving DKIM signatures is one way of doing so.  Header munging is another way of doing so.

To move into bucket 3, the forwarder needs to obtain a sponsor to negotiate with the recipient organization's email security team..

For two messages from the same forwarder to land in the same bucket, both messages must have similar qualifying characteristics.

An Example

Consider the risk profile of a request to auto-forward from UserA@DomainA to UserB@DomainB

This request could reflect a range of behaviors from low risk to high risk.
UserB actually wants the forward to occur.UserB is the accidental victim of a typing error.UserA is going to be used as a proxy to attack UserB.Forwarding to UserB is contrary to DomainA policy because it is likely to permit violation of DomainA's regulatory obligations under GDPR, PCI DSS, HIPPA, Sarbanes-Oxley or something else.Forwarding to UserB is in conflict with DomainB policy for whatever reason.UserA is an inside attacker seeking to exfiltrate data to an external accomplice.
So both DomainA and DomainB administration have reasons to be involved in this request.   Even for legitimate requests, DomainA does not want to forward traffic to DomainB if it is unwanted, since unwanted mail may impact the reputation of DomainA, and likely cause unwanted blacklisting of other messages.

Therefore, the wisest procedure is as follows:
DomainA detects the forward request and begins an approval workflow.DomainA reviews the request to see if they are willing to grant internal approval.Postmaster@DiomainA contacts UsersB@DomainB asking them to submit the request to their email security team for approval.Administrators for DomainA and DomainB communicate to discuss the administrative controls at DomainA as well as the fingerprint characteristics of the incoming mail.Upon approval, DomainB administration gives DomainA administration permission to proceed.  DomainA activates the forwarding and notifies the user.DomainA monitors the outbound mailstream for deliverability and terminates the forwarding if repeated failures occur, or upon request from DomainB administration or UserB@DomainB.
I suspect most mailing systems would need a lot of new code to implement a workflow like this, but my perspective is limited and may be wrong.

The mailing list scenario is not much different, except that the request process begins when UserB@DomainB attempts to subscribe to the mailing list, and the approval process involves both the handling of messages coming from the list as well as messages going to the list.

The process may be limited by the features of the DomainB email filter.   Without header munging, fingerprinting the mailing list will require combining the list headers with forward confirmed host names, or something along those lines.    Low-end email filters may be unable to filter on list name, or filter on multiple attributes together.

Getting prior approval will be a lot of work, and i wonder how many lists will be willing to try.     In the absence of prior approval, I see no solution better than header munging.   Header munging is an inferior solution because neither sender policies nor receiver policies are evaluated or respected, but it is the path of least resistance.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 18 Jun 2020 14:29:26 -0700

On 6/18/2020 2:10 PM, Jim Fenton wrote:
> to DMARC in that case.

Because operators have found useful correlations in distinguishing 
between messages that are aligned and being 'genuine' versus ones that 
are not aligned.

In the abstraction of theory, you are correct that it shouldn't matter.  
In the brutality of practice, it appears that it does.

d/

-- 

Dave Crocker

---

From: Jim Fenton <[email-masked]>
Date: Thu, 18 Jun 2020 15:24:09 -0700

On 6/18/20 2:29 PM, Dave Crocker wrote:
> In the abstraction of theory, you are correct that it shouldn't
> matter.  In the brutality of practice, it appears that it does.
>
We need to consider not just what's a useful correlation today, but what
will continue to be so. As soon as the {spammers, phishers, etc.} catch
on that they can achieve alignment at will, it will cease to be a useful
correlation. History teaches us that will happen quickly.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 18 Jun 2020 15:26:10 -0700

On 6/18/2020 3:24 PM, Jim Fenton wrote:
> will continue to be so.

Oh good.  Let's predict the future.  That should be fun.

d/

---

From: Tim Wicinski <[email-masked]>
Date: Thu, 18 Jun 2020 18:28:04 -0400

Have to agree with Dave here.   We have to accept it's a
constantly moving target.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 18 Jun 2020 15:42:21 -0700

> constantly moving target.

And now I'll note that when DMARC moved from being a way to authenticate 
a tightly controlled mail stream, as was originally discussed during its 
development, into its broader role, I expressed the same concern that a 
correlation not inherently tied to the misbehavior is one easily routed 
around.

However, there is too much industry force behind this broader use of 
DMARC for such simple logic to have any useful effect.  Rather, we'll 
just have to wait for the bad actors to catch on.

d/

---

From: Jim Fenton <[email-masked]>
Date: Thu, 18 Jun 2020 16:01:26 -0700

On 6/18/20 3:42 PM, Dave Crocker wrote:
>
> And now I'll note that when DMARC moved from being a way to
> authenticate a tightly controlled mail stream, as was originally
> discussed during its development, into its broader role, I expressed
> the same concern that a correlation not inherently tied to the
> misbehavior is one easily routed around. 
>

It would be remarkable for IETF to achieve rough consensus on a
specification with a known vulnerability while we "wait for the bad
actors to catch on." Particularly when that vulnerability relates to an
aspect of the specification that has caused widespread deployment problems.

---

From: Hector Santos <[email-masked]>
Date: Thu, 18 Jun 2020 22:26:42 -0400

>> The nature of the hack that mailing lists do, when altering the
>> From: field, makes this clear:  They alter information about the
>> operator handling the message, destroying the original information
>> about content authorship.
>
> Mailing lists that make other choices (throwing away messages from
> DMARC reject senders, denying subscriptions from them, or simply
> ignoring them and ending up with bad consequences) have obviously not
> gone along with the certain forms of the semantic change.
>

+1.

I preferred the "let's honor the policy" list system adaption 
approach.  It was the simplest, less programmatic approach. I did get 
some initial complaints from users who wanted to continue using their 
"junk" ESP email addresses like yahoo.com, aol.com and now icloud.com 
accounts and other larger esp domain accounts with restrictive mail 
policies who switched to restrictive policies. They understood the 
dilemma and used other domains - problem solved.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 18 Jun 2020 19:35:58 -0700

> aspect of the specification that has caused widespread deployment problems.

vulnerability?

d/

---

From: Hector Santos <[email-masked]>
Date: Thu, 18 Jun 2020 22:54:26 -0400

On 6/18/2020 6:28 PM, Tim Wicinski wrote:
> On Thu, Jun 18, 2020 at 6:26 PM Dave Crocker wrote:
>>

We, as engineers, do believe we are making the proper decisions, and a 
good bit of the time, we are correct, otherwise we are worthless.

Its called IETF Engineering. I also called it striving to "Getting it 
Right ... the First Time." -- old Westinghouse QA Engineering motto, 
not about perfection but just at least to do it correct and fairly to all.

We have allowed for some real bad decisions to take place within the 
IETF-DKIM work in the last 15+ years.

That is my assessment.

I am seriously hoping through this IETF/DMARC work rendition some real 
solid outcomes can be reached that the entire IETF community, not just 
the self-interest groups behind the scenes, benefit.

No offense to anyone, 15 yrs on this, is not a good thing.

---

From: Jim Fenton <[email-masked]>
Date: Thu, 18 Jun 2020 22:16:30 -0700

>> aspect of the specification that has caused widespread deployment

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 18 Jun 2020 23:59:57 -0700

> correlation. History teaches us that will happen quickly.

RFC 7489 was published just over five years ago now.  I would imagine
that if Jim is correct, we would see evidence of it by now.

So to those of you with access to such (e.g., M3AAWG regulars among
us), is there evidence in the wild of spammers and phishers using
discardable (ahem) domains to achieve alignment and improve their
delivery success stories?

-MSK, sans chapeau

---

From: Laura Atkins <[email-masked]>
Date: Fri, 19 Jun 2020 08:40:59 +0100

> On 19 Jun 2020, at 07:59, Murray S. Kucherawy <[email-masked]> wrote:
> 

There is certainly ample evidence that spammers are: sing disposable domains / rotating through domains and aligning authentication so that they will pass DMARC. 

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

laura 

-- 
Having an Email Crisis?  We can help! 800 823-9674 

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

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

---

From: Dave Crocker <[email-masked]>
Date: Fri, 19 Jun 2020 05:36:32 -0700

> by a receiving filtering engine (again your choice of words), that is a

Thanks for explaining what vulnerability means, but my question was 
meant to prod you to explain what vulnerability you claim is there.

I've looked over your postings of the last few days and somehow I'm not 
seeing that described.

d/

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 19 Jun 2020 17:38:09 +0200

Hector,

consider a mailing list as a publishing organization, which is what it
is.  If article submission happened via HTTP, say, like in web fora,
there would be no reason to talk about From: rewriting.  The
fortuitous circumstance that both article submission and the final
distribution happen through SMTP generated the current conundrum.

It presumably seemed to be easier or less intrusive to tag the
Subject: and leave the From: unaltered.  The correct approach should
have been to use the publishing organization's own From:, possibly
adding the author's name or initials to the Subject:.  We only realize
that mistake now, after the introduction of email authentication.

Yes, we kept using the wrong arrangement for 40+ years.  That is not a
good reason to persevere.

Best
Ale
--

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Fri, 19 Jun 2020 08:47:56 -0700

On Fri, Jun 19, 2020 at 12:41 AM Laura Atkins <[email-masked]>
wrote:

> There is certainly ample evidence that spammers are: sing disposable
> domains / rotating through domains and aligning authentication so that they
> will pass DMARC.
>

Here's an article citing exactly such an example from today's headlines:
https://threatpost.com/bofa-phish-gets-around-dmarc-other-email-protections/156688/
Sadly, the explanation of what DMARC is/does is botched. (related original
article:
https://www.armorblox.com/blog/blox-tales-7-bank-of-america-credential-phishing/
which details the specifics of the phishing attack - sent from Yahoo,
misleading display name, misleading newly registered domain and URL)

--Kurt

---

From: "Pete Resnick" <[email-masked]>
Date: Fri, 19 Jun 2020 11:40:27 -0500

On 19 Jun 2020, at 10:38, Alessandro Vesely wrote:

> is.

No, it isn't. It is a Mediator. See RFC 5598.

> If article submission happened via HTTP, say, like in web fora,
> there would be no reason to talk about From: rewriting.

Take my particular case: I don't get SMTP email from IETF mailing lists. 
I point my email client to imap.ietf.org and read the messages directly 
out of the mailboxes there. As people send email to the list, the 
messages are deposited into the appropriate IMAP mailbox for the list. 
Some of the messages (mistakenly IMO) have their Subject's munged, but 
not on all lists, and certainly not on the main IETF list. Usually, only 
trace info (Received: fields), a set of List-*: fields, an Archived-At: 
field, and similar are added, but otherwise, the contents of the message 
(including the normal headers) are unadulterated. That's good: I can 
reply to the author directly, reply to the list, or reply all as I see 
fit, or I can check S/MIME signatures, or I can use the "Add person to 
my address book" feature of my client, etc. It all works because nothing 
is munged. It is as it should be.

> The

Why should using SMTP for *message* (not "article") distribution change 
anything in the example above?

And let's not pretend that it is just mailing lists that have this 
problem. The "resend" feature on my email client breaks if servers honor 
p=reject and can't be bothered to check the Resent-*: fields and realize 
that I am a legit sender. Alias expansion breaks. The problem is that a 
whole set of legitimate and documented features in email were simply 
dismissed as unimportant to keep in the first round of DMARC (or, more 
fairly, probably weren't properly considered).

> Subject: and leave the From: unaltered.

No, that's rewriting history. The presumption of all Mediator-type 
transactions was that the receiving email client was to deal with the 
message (the thing with the identical Message-ID) with its original 
semantics, adding only Resent-*: or List-*: fields to add the semantic 
of the mediation event. Even rewriting Subject: is a problematic hack 
which the List-*: fields were created to avoid.

> The correct approach should

No, sorry, you've got the history entirely on its head. For 40+ years, 
we had a set of features of the email system which allowed an email 
message to be copied and/or moved around in loads of different ways (in 
archives, in IMAP stores, in mail clients), and one of those ways was 
always "reintroduce the message back into the transport system" using 
trace info in the message header to see the details of that 
reintroduction. DMARC came along and decided that that particular set of 
features was not worth addressing, or too hard to address, or maybe 
didn't realize that such features were going to be a problem.

Maybe it's time to abandon that set of features. I personally don't 
think so, but I could be in the rough part of the rough consensus. But I 
do think that set of features can be preserved with a bit of work, and I 
think that work is worth doing. But if we are going to abandon those 
features, a better argument will need to be made than "Oh, in retrospect 
we realize that email was doing it wrong for 40+ years." That argument 
is bogus.

pr

---

From: "Pete Resnick" <[email-masked]>
Date: Fri, 19 Jun 2020 11:46:11 -0500

On 19 Jun 2020, at 11:40, Pete Resnick wrote:

> The presumption of all Mediator-type transactions was that the 
> receiving email client was to deal with the message (the thing with 
> the identical Message-ID) with its original semantics, adding only 
> Resent-*: or List-*: fields to add the semantic of the mediation 
> event.

That sentence got munged due to cuts and pastes that didn't all add up. 
It should read:

"The presumption of all Mediator-type transactions was that the 
receiving email client was to deal with the message (the thing with the 
identical Message-ID) with its original semantics, with the sender 
adding only Resent-*: or List-*: fields to add the semantic of the 
mediation event."

---

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

> No, it isn't. It is a Mediator. See RFC 5598.

The description of what a Mediator might do is not incompatible with 
also viewing it as having characteristics of a publisher:

>
>       5.3 <https://tools.ietf.org/html/rfc5598#section-5.3>. Mailing Lists
>
>     ...
>     In addition to sending the new message to a potentially large number
>     of new Recipients, the Mailing List can modify content, for example,
>     by deleting attachments, converting the format, and adding list-
>     specific comments.

Note that in terms of email transport, it is posting a new message.

Mediators really have complete freedom to do whatever they want. If 
describing the full range of what a publisher might do, it would cover 
the same range.

But typical mediators are trying to maintain a sense and ability for the 
original author and the final recipient to experience an end-to-end 
message exchange.  The degree to which the mediator asserts itself more 
visibly to the recipient is probably the degree to which it looks more 
like a publisher and less like a simple relaying service.

d/

---

From: "Pete Resnick" <[email-masked]>
Date: Fri, 19 Jun 2020 14:02:07 -0500

On 19 Jun 2020, at 13:38, Dave Crocker wrote:

>> ### [5.3](<https://tools.ietf.org/html/rfc5598#section-5.3>). Mailing 
>> Lists
>>
>>
>>        ...

Fair enough, but as you mention below, in the case of the common mailing 
list, the intent is simply to redistribute the message with minimal 
change (hence the retention of the Message-ID: and the From:). That 
said, I do disagree with the reasoning given with regard to why 
5321.MailFrom has changed: It's not because of the authorship, but 
rather because it is responsible for the submission onto the network, 
just as the ReSender is in 5.2.

> Note that in terms of email transport, it is posting a new message.

Strictly in terms of transport, yes. But in terms of the layer above 
(the 5322 layer), it is usually the same message; see the second Note: 
in RFC 5322 section 3.6.4:

       Note: There are many instances when messages are "changed", but
       those changes do not constitute a new instantiation of that
       message, and therefore the message would not get a new message
       identifier.  For example, when messages are introduced into the
       transport system, they are often prepended with additional header
       fields such as trace fields (described in section 3.6.7) and
       resent fields (described in section 3.6.6).  The addition of such
       header fields does not change the identity of the message and
       therefore the original "Message-ID:" field is retained.  In all
       cases, it is the meaning that the sender of the message wishes to
       convey (i.e., whether this is the same message or a different
       message) that determines whether or not the "Message-ID:" field
       changes, not any particular syntactic difference that appears (or
       does not appear) in the message.

> describing the full range of what a publisher might do, it would cover 

Well, "complete freedom" in the sense that no Internet police prevent 
such actions. But for most mediators, large substantive (for interesting 
definitions of "substantive") changes are outside of the scope of their 
definitions, and would probably invite someone to say, "That's not being 
a mediator." Certainly that would happen in the case of an alias or a 
resender.

> But typical mediators are trying to maintain a sense and ability for 
> the original author and the final recipient to experience an 
> end-to-end message exchange.

Yep. That's the point I was trying to make.

> The degree to which the mediator asserts itself more visibly to the 
> recipient is probably the degree to which it looks more like a 
> publisher and less like a simple relaying service.

And eventually, I would contend, less like a mediator.

pr

---

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

On 6/19/2020 12:02 PM, Pete Resnick wrote:
>>> ### [5.3](<https://tools.ietf.org/html/rfc5598#section-5.3>). 
>>> Mailing Lists
>>>        ...
> Fair enough, but as you mention below, in the case of the common 
> mailing list, the intent is simply to redistribute the message with 
> minimal change (hence the retention of the Message-ID: and the From:). 

While, yes, that's the goal of some and probably most lists, that isn't 
quite what I said.

Please re-read my text, which notably did not contain the word 'minimal' 
and frankly had a different focus. That focus doesn't exclude 
minimality, but it wasn't the point.

> That said, I do disagree with the reasoning given with regard to why 

I did not anything about MailFrom, or for that matter anything about any 
field with an identifier.

I'm guessing that your reference is to the fact that a mailing list 
service might put its own address into the MailFrom, so it gets handling 
error messages?  That issue and behavior predates DMARC by a lot.  
Probably two decades. Maybe more.

>       message, 

Except that there are many instances when messages might be changed that 
DO constitute a new instantiation of that message, and 5322 gives no 
guidance about what determine one versus the other.

None of which is relevant to the point that a mailing list service has 
its own agency and is free to do what it wishes to and with the messages 
it is re-posting.  That most seek to preserve essentially all of the 
author's text is fine, but whether and how much is more of a 'business' 
decision than a technical one.

>> describing the full range of what a publisher might do, it would 
>> cover the same range.
>
> such actions.

I didn't mean anything so nit-picky.  I mean that they are providing a 
value-added service to users and have their own agency to decide what 
that service looks like. If they want to do assorted message 
modifications that are substantial, and if users of the service like the 
nature of those modification, the service is free to do them.  There is 
no specifications that dictate or even suggest, what one of the services 
must, or even should, do. So your reference to Internet police is 
ironic, because there is nothing to guide enforcement.

> But for most mediators, large substantive (for interesting definitions 
> of "substantive") changes are outside of the scope of their 
> definitions, and would probably invite someone to say, "That's not 
> being a mediator." Certainly that would happen in the case of an alias 
> or a resender.

If there is a specification that would move such a declaration out of 
people's personal opinions and into objective, technical assessment, I 
apologize that I don't know what it is.

> Yep. That's the point I was trying to make.

Except you seem to be pressing this as essentially a requirement they 
have whereas I'm pressing it as a business decision, not something 
inherent in the nature of mailing list behavior.

> And eventually, I would contend, less like a mediator.

I probably wouldn't like it either, but we don't have objective criteria 
for accurately and reliably applying or withholding the term, do we?

d/

---

From: "Pete Resnick" <[email-masked]>
Date: Fri, 19 Jun 2020 16:11:27 -0500

We seem to be having a discussion with some premises misunderstood, so 
let me attempt to answer your message upside down, in hopes of undoing 
that:

On 19 Jun 2020, at 15:07, Dave Crocker wrote:

> have

Ah, no, I think that's the crux of the misunderstanding: I was 
responding to Alessandro, who I interpreted to be saying that *all* 
mailing lists were, by definition, publishers, defining a publisher like 
a newspaper, where the true author of the content are the folks in the 
masthead, even though they acknowledge individual authors in the 
by-line. I disagree with that view. Indeed, I think for most of the 
mailing lists we have been referring to in this discussion, they are not 
publishers in Alessandro's sense, but rather view themselves as 
redistributors of author messages. As 5598 points out, there is variance 
in how much "editing" is done by any given mailing list, but again, for 
the discussion we've been having about how the From: field should be 
used, we've been talking about mailing lists which do the sort of 
minimal editing of messages.

(For mailing lists that do more substantial editing, I may not be as 
motivated to keep the From: field unchanged. If we get more deeply into 
the discussion, it might be useful to start drawing more distinct 
circles around types of mailing lists.)

So the purpose of pointing to 5598 was simply to explain to Alessandro 
that redistribution of messages through the transport system does not 
ipso facto make something a publisher.

> whereas I'm pressing it as a business decision

I'm not really sure what that means or how it is relevant to the 
discussion, but again, I think we've been talking past eachother for the 
last two messages.

> not something inherent in the nature of mailing list behavior.

No, sorry. I meant to simply point out the converse: That becoming a 
publisher is not in the nature of mailing list behavior.

> I did not anything about MailFrom, or for that matter anything about 
> any field with an identifier.

I didn't say you had. I brought it up only because I re-read the section 
in 5598 on mailing lists, and it makes this claim. Just objecting in 
passing (because it seems to support Alessandro's view), not because I 
thought you were making some claim about it.

> service might put its own address into the MailFrom, so it gets 
> handling error messages?  That issue and behavior predates DMARC by a 
> lot.  Probably two decades. Maybe more.

I agree. Which is why I thought it relevant to the overall discussion. 
It was not directed at a particular statement of yours.

>> But in terms of the layer above (the 5322 layer), it is usually the 
>> same message; see the second Note: in RFC 5322 section 3.6.4:
>>
> Except that there are many instances when messages might be changed 
> that DO constitute a new instantiation of that message, and 5322 gives 
> no guidance about what determine one versus the other.

That's not true. In what you elided:

       In all

It doesn't give any algorithmic guidance, if that's what you meant.

> its own agency and is free to do what it wishes to and with the 
> messages it is re-posting.

Well, it seems exactly to that point. See above.

> That most seek to preserve essentially all of the author's text is 
> fine, but whether and how much is more of a 'business' decision than a 
> technical one.

We appear to be in violent agreement, as the quip goes. Importantly, I 
think we agree that if a mailing list decides to preserve the original 
 From: field, in an attempt to preserve all of the author's semantics, 
they are not "doing it wrong", as Alessandro's message appears to claim.

> I didn't mean anything so nit-picky.  I mean that they are providing 
> a value-added service to users and have their own agency to decide 
> what that service looks like.

Again, exactly supporting my point: If a mailing list desires to provide 
the service of redistributing mail with its original semantics, that's a 
fine thing for it to do, and not something that should be rejected as 
having been done wrong for the past 40+ years.

> If they want to do assorted message modifications that are 
> substantial, and if users of the service like the nature of those 
> modification, the service is free to do them.

Of course. And the protocols we produce should be able to support both 
scenarios, not dismiss one (rather widespread) way of doing things.

>> But for most mediators, large substantive (for interesting 
>> definitions of "substantive") changes are outside of the scope of 
>> their definitions, and would probably invite someone to say, "That's 
>> not being a mediator." Certainly that would happen in the case of an 
>> alias or a resender.
>

I believe 5322 makes quite clear what a resender mediator is. For alias 
mediators, I'd have to go look if there is anything beyond 5598's 
description. We have historically been quite resistant about defining 
mailing list behaviors, for assorted reasons.

> I probably wouldn't like it either, but we don't have objective 
> criteria for accurately and reliably applying or withholding the term, 
> do we?

I'm not sure if "liking" it has any bearing on the discussion, and I'm 
pretty sure we don't have criteria that will take any arbitrary behavior 
and count it as in or out, but I think I can give you examples of action 
which you (and most of us) would agree would not fall into the criteria 
and others that would. Just because a definition is fuzzy doesn't make 
it useless.

pr

---

From: "Pete Resnick" <[email-masked]>
Date: Fri, 19 Jun 2020 16:15:25 -0500

[Offlist]

On 19 Jun 2020, at 15:07, Dave Crocker wrote:

> Please re-read my text...

> If there is a specification ... I apologize that I don't know what it 
> is.

These little passive-aggressive turns of phrase are not useful habits to 
teach to others on the list.

pr

---

From: "Pete Resnick" <[email-masked]>
Date: Fri, 19 Jun 2020 16:20:53 -0500

> [Offlist]

Crap. My deepest apologies to Dave. I am very embarrassed by fat 
fingering that. It is not the worst private thing I've ever sent to a 
list, but still.

(*Sigh*)

pr

---

From: Brandon Long <[email-masked]>
Date: Fri, 19 Jun 2020 15:13:39 -0700

> a mediator." Certainly that would happen in the case of an alias or a

And if we knew how to encode and verify that the mediator sticks to that,
we could
enforce it with policy.

There were several attempts to come up with alternative signing schemes
that would
allow messages to pass through mailing lists and still be verified as
"untampered" with,
and we were unable to come up with such a thing.

Perhaps we could have constrained ourselves to a 80 or 90% solution, and
that would have been
sufficient and a better solution than From header rewriting.  Everyone has
their opinion on the must
haves for mailing list message modification, and it becomes quickly
intractable.

Brandon

---

From: Dave Crocker <[email-masked]>
Date: Fri, 19 Jun 2020 15:29:18 -0700

> fingering that. It is not the worst private thing I've ever sent to a 

A bigger concern should be with thinking that such paternalism is 
appropriate.

d/

---

From: Dave Crocker <[email-masked]>
Date: Fri, 19 Jun 2020 15:32:33 -0700

On 6/19/2020 3:13 PM, Brandon Long wrote:
> There were several attempts to come up with alternative signing 
> schemes that would
> Perhaps we could have constrained ourselves to a 80 or 90% solution, 
> and that would have been
> sufficient and a better solution than From header rewriting. Everyone 
> has their opinion on the must

There's a chance that it is possible to specify a small range of 
modifications and arrange a style of signing that could survive them.  
So for originating and mediating sites that conform to that range, a 
'preserved' original authentication might be possible.

However...

I don't remember enough detail from the original dmarc discussions, so I 
don't remember how much of this was discussed, but I vaguely think it 
was covered.

Anyhow, there is a long track record of difficulties getting mailing 
list systems and operators to adopt external standards, and it isn't 
clear (to me) that the small range would be useful enough.  These risk 
factors do not encourage pursuing the complexities and costs of a global 
standard.

That leaves just a staged trust model, establishing a basis of 
accountability (and reputation) for the mediator sequence. Hence, ARC.

d/

---

From: "John Levine" <[email-masked]>
Date: 19 Jun 2020 20:09:02 -0400

>don't remember how much of this was discussed, but I vaguely think it 

It definitely came up in DKIM.  It rapidly became clear that there
are many things that lists do that have simple user semantics but
are hopeless to describe in terms of bytes in the message, e.g.,
reordering or deleting MIME parts.

>accountability (and reputation) for the mediator sequence. Hence, ARC.

Agreed, it seems unlikely we can do any better.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 19 Jun 2020 17:48:07 -0700

> reordering or deleting MIME parts.

A number of drafts were floated, as I recall.  I had a couple.

In one case, I think it was a new DKIM signature tag.  The idea was to
place a small annotation on the message of some kind that effectively
meant something like "MTA X asserts that it added '[foobar]' to the
Subject: field".  Another might be the usual "--" followed by a short
signature added to a plain text (or maybe non-MIME) body.  A validator
could then try undoing that and repeating validation to see if the
author signature then verified.  At the time, the feedback was that
this was too fragile to get right, but I don't think anyone ever
looked at it in the 80-20 sense.  I wish in hindsight I'd tried it
anyway as an experiment, with maybe a couple of senders, receivers,
and mailing lists as participants.

-MSK

---

From: "John R Levine" <[email-masked]>
Date: 19 Jun 2020 20:52:55 -0400

> A number of drafts were floated, as I recall.  I had a couple.

There's always my conditional signing hack, in which one puts a very weak 
signature on the message which says it only counts if it's resigned by X, 
where X is the expected mediator.

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

---

From: Dave Crocker <[email-masked]>
Date: Fri, 19 Jun 2020 17:54:54 -0700

On 6/19/2020 5:48 PM, Murray S. Kucherawy wrote:
> I wish in hindsight I'd tried it

While I can imagine devising something that would look appealing, I 
believe it would have had a foundation of sand, in terms of operational 
realities, since none of what it would be relying on was documented 
standards and, again, there was (and I suspect remains) a view that 
mailing list operators did not make good candidates for reliable 
adherence to IETF 'standards'.

d/

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 20 Jun 2020 13:13:02 +0200

On Sat 20/Jun/2020 02:52:55 +0200 John Levine wrote:
> There's always my conditional signing hack, in which one puts a very
> weak signature on the message which says it only counts if it's
> resigned by X, where X is the expected mediator.

Conditional signatures should be paired with a mechanism that tells
the author's MTA when to apply them.  For example, a water tight
opt-in protocol whereby author, MLM, and author's MTA can do a
three-hand handshake.  Without that, we're back to depending on
reputation, for which simple whitelisting suffices.

Best
Ale
--

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 20 Jun 2020 13:32:53 +0200

On Fri 19/Jun/2020 23:11:27 +0200 Pete Resnick wrote:
>>>> But typical mediators are trying to maintain a sense and ability
>>>> for the original author and the final recipient to experience an
>> Except you seem to be pressing this as essentially a requirement
>> they have
> 
> mailing lists were, by definition, publishers, defining a publisher
> like a newspaper, where the true author of the content are the folks
> in the masthead, even though they acknowledge individual authors in
> the by-line. I disagree with that view. Indeed, I think for most of
> the mailing lists we have been referring to in this discussion, they
> are not publishers in Alessandro's sense, but rather view themselves
> as redistributors of author messages. As 5598 points out, there is
> variance in how much "editing" is done by any given mailing list, but
> again, for the discussion we've been having about how the From: field
> should be used, we've been talking about mailing lists which do the
> sort of minimal editing of messages.

First, although the emphasis was on publishers, I didn't mean *all*
mailing lists.  Options 1.2 (Turn off all message modifications) and
4.5 (Have author domains sign camera-ready posts), with all in-between
variations (e.g. have users manually add the subject tag on new
messages, or attach a footer) are all valid alternatives.  And there
may be more (for this list in particular, it'd be enough for me to
convert the body to base64 before signing.)

Second, looking closely a the roles, what all mailing list do is
keeping the list of recipients.  Authors have no say on that, albeit
they can add a few "direct" recipients themselves.  Defining the end
points is an essential point in communication, which prevents from
considering the authors as agents.  Also consider that authors have to
keep on-topic, or they'd get reproached by the chairs.

> motivated to keep the From: field unchanged. If we get more deeply
> into the discussion, it might be useful to start drawing more distinct

100% agreed.  We should also loosely consider that in most countries
there are legal constraints which practically force the addition of a
footer.  There are "informal" mailing list which ignore that pressure.

There will always also be mailing lists which ignore DMARC.  I don't
think the latter should be among the possibilities specified in a
standard.

>> fine, but whether and how much is more of a 'business' decision than
>> a technical one.
> 

What is wrong is to wittingly break DMARC.  I just try for rationale.

Best
Ale
--

---

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

Pete, you should see my draft folder! <g>

---

From: "John Levine" <[email-masked]>
Date: 20 Jun 2020 11:48:09 -0400

In article <[email-masked]> you write:
>For example, a water tight opt-in protocol ...

There's no such thing, unless you can somehow ensure that the list
never sends anything that any of the subscribers don't expect.

> Without that, we're back to depending on

No, please see my message a few days ago about why ARC works the way
it does.

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 20 Jun 2020 19:48:52 +0200

On 2020-06-20 5:48 p.m., John Levine wrote:
> There's no such thing, unless you can somehow ensure that the list never sends anything that any of the subscribers don't expect.

Small MTAs can trust their (not anonymously registered) users, so they could blindly accept to weakly sign messages destined to a MLM that a user of theirs has implicitly recommended by starting such a (yet unspecified[*]) water tight opt-in.

>> Without that, we're back to depending on reputation, for which simple whitelisting suffices.> 
> No, please see my message a few days ago about why ARC works the way it does.

Do you mean https://mailarchive.ietf.org/arch/msg/dmarc/gll_AD80SzysVJi9GDeKM12OslA ?

That message proves that ARC depends on reputation too.  I mentioned whitelisting because it's simpler than ARC.

My point is that, if an MTA is not Google, Yahoo, or some such, that is if it doesn't have the list of all MTAs worldwide, then the mailing list problem precludes reliable DMARC inbound filtering.

I don't think, as Douglas suggests, that the MLM problem stems from not wanting to seek domain owner involvement.  IMHO, it stems from domain owners not being able to maintain a global reputation list.  The MTAs who can do that can do ARC, can whitelist, can do DMARC filtering; they don't have a "mailing list problem".

Best
Ale
-- 

[*] See rough ideas at http://fixforwarding.org/wiki/Water_tight_opt-in

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 20 Jun 2020 13:08:07 -0700

> adherence to IETF 'standards'.

All true, but if it had yielded useful results, there might have been
encouragement to change that.  Then, suddenly, there would be common
ground from which to do future work such as this.

It wouldn't be hard to put a draft together that described the trivial
things like Subject field tagging and "two dashes at the end mark the
start of a signature', and maybe a couple of popular and mostly
harmless mutations the popular list servers do.  I might know someone
who could help with such a publication.

(I can hear Dave and Pete, and perhaps Jim, chortling at my altruism...)

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Sat, 20 Jun 2020 13:24:03 -0700

> (I can hear Dave and Pete, and perhaps Jim, chortling at my altruism...)

Were I to chortle about any of this, it would be at the idea that any 
serious effort associated with email authentication could be considered 
altruistic...

In terms of pragmatics, I think the issues here are time and risk.  To 
get to a useful point will take too long for the current working group 
effort, and, given history and environment, its likelihood of being 
successful seems pretty low.

That doesn't mean that none of it is worth pursuing, but rather than it 
might be worth considering independently of the current work and 
initially as IRTF-ish work, rather than IETF-ish.

Perhaps if the effort were viewed as a staged sequence, over an extended 
time.  Staging along the lines of:

  * Document a modest number of highly common 'patterns' of mailing list
    patterns.
  * Get reasonable community support (rough consensus) for the document
    -- including from MLM developers and operators
  * Formulate survivable authentication choices
  * Get reasonable community support for that approach
  * ...

d/

---

From: Dave Crocker <[email-masked]>
Date: Sun, 21 Jun 2020 10:32:26 -0700

> typist, I'd opt for the latter interpretation.

In simple terms, author is the creator of the content and sender is the 
agent for getting the content processed.  The latter was distinguished 
to provide a means of improving accountability if there were problems.  
When SMTP was created, later, MailFrom was added as an address for 
sending message handling reports.

When first specified, Sender: was to cover the case of someone doing the 
online work, on behalf of  authors who weren't online, or at least not 
online for processing the message.  Back in those days, that was not 
uncommon.  Even if the author officially had an online presence, they 
often did not do the typing.

(To underscore this a bit: in most of the business world, knowing how to 
type was deemed a menial, secretarial skill and not appropriate for an 
executive. To carry this a bit further: around the time RFC733 was 
developed, in 1977, I managed to get the person in charge of department 
administration functions to authorize my getting a desk with a 
right-hand return, where a secretary's typewriter would go, and where I 
put my terminal. This was extremely unusual and the immediate, similar 
requests from all the other staff like me were rejected. Also, when I 
announced my departure, the next year, the admin was instantly flooded 
with requests for my desk...)

For most email, From: and Sender: are the same person (and the same 
email address.)  This fact was the reason the original specification of 
Sender: in RFC 733 only required an explicit Sender: field be present 
when the addresses are different.

For today, these same abstract constructs have -- or should have -- only 
slightly different application.  From: is still supposed to be the 
author, which remains the creator of the (original) content.  Sender: 
could be any separate party responsible for processing the message.

So, in abstract terms, if I go to a greeting card site and have it send 
a greeting on my behalf, the From: field should be my own email address 
and Sender: should an address at the greeting card company.  But I said 
'abstract' because current realities mean this isn't as useful an 
arrangement as the theory intended.

I believe this is because Sender: is not reliably present. Hence, it 
literally cannot be relied upon.  The Sender field is not created 
reliably to indicate such distinctions and the receive side does not 
reliable note the distinctions.

> writing, not modifying From: should be considered a violation.

If a Mediator makes 'substantial' changes to a message, then it can be 
considered a new and different message?  Yes, but note that we have no 
objective criteria for this.  That's why I class this reference to 
'publisher' as a business issue rather than a technical one.  (And an 
ethical one, as some wayward journalists discover when they claim to be 
quoting someone but it turns out the reporter invented the content.)

However I think that referencing the role of an MLM as 'publisher' can 
be helpful to remind us that MLMs have their own agency and can, 
legitimately, make all sorts of changes.  Whether authors and recipients 
like those changes is a non-technical matter.

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

In practical terms, today, the MLMs arguably don't have a choice.  But 
it still can be helpful to understand the problems created by this 
alternation.

>> their messages properly signed by the domain in the From: address".

For reference, I consider this an accurate summary of why I say that the 
From: field semantic is changed as a result of DMARC. Specifically so 
that mailing list mail can be delivered.

> or system.
RFC 5322 has preserved the semantic of the Sender: field:

      "The "Sender:" field specifies the mailbox of the agent 
responsible for the actual transmission of the message. "

I consider that to be exactly the role the MLM is performing.

> RFC 5322 says display names are "associated" to a mailbox.

I don't see such language in RFC 5322.  In fact, other than the ABNF for 
display-name, I don't see any explanation of its semantic.

> Certainly, changing just the addr-spec breaks the association and 
> wreaks havoc to address books. 

Exactly.

d/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 21 Jun 2020 16:35:00 -0700

On Sat, Jun 20, 2020 at 1:24 PM Dave Crocker <[email-masked]> wrote:
> Perhaps if the effort were viewed as a staged sequence, over an extended time.  Staging along the lines of:
>
> Document a modest number of highly common 'patterns' of mailing list patterns.
> * Get reasonable community support (rough consensus) for the document -- including from MLM developers and operators

I'm curious enough (and have been since the discussions that led to
draft-kucherawy-dkim-transform-00 five years ago) to give this effort
some energy orthogonal to what this working group is doing, and with
minimum distraction.

Apart from Mailman, what would be a reasonable set of MLMs to
approach?  I don't need a universal set here, just enough to get us to
at least what we are pretty sure would be 80% or better of the active
modern use cases.

Armed with such a list and a plan, I can see what the IRTF Chair
thinks of the idea.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Sun, 21 Jun 2020 16:40:57 -0700

> Armed with such a list and a plan, I can see what the IRTF Chair

cool!

d/

---

From: "John Levine" <[email-masked]>
Date: 21 Jun 2020 21:07:25 -0400

>at least what we are pretty sure would be 80% or better of the active

Mailman and Sympa seem to tbe the popular open source list managers.

LISTSERV is an expensive commercial product and is I gather popular
among users who have money to pay for an SLA.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 21 Jun 2020 18:21:29 -0700

> among users who have money to pay for an SLA.

Thanks, I've reached out to all three and will report back.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 22 Jun 2020 13:23:56 +0200

On 2020-06-21 7:32 p.m., Dave Crocker wrote:
>> That is not so far from real.  The term "writing" sounds ambiguous,
>> as it is not clear whether it means "typing" or "publishing", in the
>> case of public mailing lists.  Given that Sender: is dedicated to
>> the typist, I'd opt for the latter interpretation.
> 
> In simple terms, author is the creator of the content and sender is
> the agent for getting the content processed.  The latter was
> distinguished to provide a means of improving accountability if there
> were problems.  When SMTP was created, later, MailFrom was added as an
> address for sending message handling reports.
> 
> When first specified, Sender: was to cover the case of someone doing
> the online work, on behalf of  authors who weren't online, or at least
> not online for processing the message.  Back in those days, that was
> not uncommon.  Even if the author officially had an online presence,
> they often did not do the typing.
> 
> (To underscore this a bit: in most of the business world, knowing how
> to type was deemed a menial, secretarial skill and not appropriate for
> an executive. To carry this a bit further: around the time RFC733 was
> developed, in 1977, I managed to get the person in charge of
> department administration functions to authorize my getting a desk
> with a right-hand return, where a secretary's typewriter would go, and
> where I put my terminal. This was extremely unusual and the immediate,
> similar requests from all the other staff like me were rejected. Also,
> when I announced my departure, the next year, the admin was instantly
> flooded with requests for my desk...)

Thank you for sharing the above historic perspective.

> [...]
> 
> So, in abstract terms, if I go to a greeting card site and have it
> send a greeting on my behalf, the From: field should be my own email
> address and Sender: should an address at the greeting card company. 
> But I said 'abstract' because current realities mean this isn't as
> useful an arrangement as the theory intended.

Agreed.  I'd derive it's time to revise the theory, however slightly.

> reliable note the distinctions.

The fact that it cannot be set by a MUA implies Sender: already lost
its menial meaning.  So it became a Mediator sort of thing.  This list
sets it to "dmarc" <[email-masked]>.  Does anybody use it, or
ever happened o take a look at it?

See below for an alternative arrangement.

> ethical one, as some wayward journalists discover when they claim to
> be quoting someone but it turns out the reporter invented the content.)

You certainly recall the level of sophistication described in Nelson's
Literary Machines.  Email is nowhere near that precision, therefore we
/have/ to relegate such issues to ethical or business ones.

As you say, an add-on to check quotation authenticity would require
access to the whole thread, and even then it wouldn't be trivial to
get it done.

> legitimately, make all sorts of changes.  Whether authors and
> recipients like those changes is a non-technical matter.
> 

IMHO, the choice is how to do rewriting given the constraint that the
domain of From:'s addr-spec must match d= in MLM's signature.

>>> My understanding of the meaning that DMARC added was, "The
>>> author of this message, as expressed in the From: field, always
>>> has their messages properly signed by the domain in the From:
>>> address." You seem to be saying that, no, what DMARC did was
>>> transmitter of the message (as used to be expressed in the 
>>> Sender: field when present), not the author, and that
>>> transmitter always has their messages properly signed by the
>>> domain in the From: address".>
> For reference, I consider this an accurate summary of why I say that
> the From: field semantic is changed as a result of DMARC. Specifically
> so that mailing list mail can be delivered.

Yes.

>> meant to be the secretary who writes on behalf of a responsible
>> person or system.

Sender ID already tried that path.  It didn't work.  Why insist?

For the rationale, that quoted sentence of RFC 5322 is followed by an
example which doesn't seem to match a Mediator role.  Why not use the
Resent-From: field and its companions instead?

> I don't see such language in RFC 5322.  In fact, other than the ABNF
> for display-name, I don't see any explanation of its semantic.

    Note: Some legacy implementations used the simple form where the
    addr-spec appears without the angle brackets, but included the
    name of the recipient in parentheses as a comment following the
    addr-spec.  Since the meaning of the information in a comment is
    unspecified, implementations SHOULD use the full name-addr form of
    the mailbox, instead of the legacy form, to specify the display
    name *associated* with a mailbox.  Also, because some legacy
    implementations interpret the comment, comments generally SHOULD
    NOT be used in address fields to avoid confusing such
    implementations.
                    [https://tools.ietf.org/html/rfc5322#section-3.4]
                    [(my emphasis)]

>> wreaks havoc to address books. 

Here's an alternative arrangement for the fields:

An author composes a message and submits it to the MLM.  The publisher
can accept it or not.  It's their business policy whether to moderate,
blindly trust (some) authors, or whatever.  If they accept the
article, then they send it back to the author, accompanied by the
MLM's marks of acceptance for publication.  Hence, From: the MLM, To:
the author, Bcc: the rest of subscribers.

That arrangement saves the association and the ability to reply all.

There is an unusual MLM option to individually send messages To: each
recipient, which neither supports the above arrangement nor advanced
sending schemes, such as Courier-MTA's VERP SMTP extension.

Best
Ale
--

---

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

> Thanks, I've reached out to all three and will report back.

This exchange does not read right.

Decisions like this should not be made on the basis of open source, 
nor commercial.  The magical Pareto margin with just those three 
mentioned may not be reached. There are others out there that may not 
be represented in this group, and there are those like my own 
commercial add-on product line, Wildcat! List Server, which does come 
with an optional SLA and it should not matter if it does or not, a 
smaller entity but has been "around" far longer than most except ListServ?

https://secure.santronics.com/products/winserver/wcListServer.php

I provided a guideline to a MLS approach back in the 2006 DSAP proposal:

https://tools.ietf.org/html/draft-santos-dkim-dsap-00#section-3.3

    3.3.  Mailing List Servers

    Mailing List Servers (MLS) applications who are compliant with DKIM
    and DSAP operations, SHOULD adhere to the following guidelines:

    Subscription Controls

       MLS subscription processes should perform a DSAP check to
       determine if a subscribing email domain DSAP policy is restrictive
       in regards to mail integrity changes or 3rd party signatures.  The
       MLS SHOULD only allow original domain policies who allow 3rd party
       signatures.

    Message Content Integrity Change

       List Servers which will alter the message content SHOULD only do
       so for original domains with optional DKIM signing practices and
       it should remove the original signature if present.  If the List
       Server is not going to alter the message, it SHOULD NOT remove the
       signature, if present.

I have since then employed a very simple first item, Prevent 
Subscription, added preventing submissions from restrictive domains 
and avoided the more complex, integrity change part.

I understand there are those who want to bypass the DKIM Policy 
security to be able to blindly resign any domain regardless of the 
submission's direct mail policy. But my take is, if a MLS is going to 
"change" then we should recommend to consider the preemption approach 
by simply honoring the policy.

I hope to read from the report those 3 packages are willing to offer 
the option to prevent restrictive domains. Even if rewriting remains 
as an IETF "sanctioned" option (I hope not), the recommendation should 
suggest a SHOULD to incorporate it as an authorized permission concept 
with the subscriber:

Your domain has a restrictive DMARC policy. Here are your options:

1) Use another non-restrictive domain,
2) Prevent your domain from subscription and submission, or
3) Authorize the Rewriting of your secured domain to a secured 
resigner domain.

Thanks

---

From: Jesse Thompson <[email-masked]>
Date: Mon, 22 Jun 2020 18:34:30 -0500

> ever happened o take a look at it?

Yes, and I assume that's partially why the OP (who I was posting on behalf of) brought this Sender dilemma up in the first place.

Outlook on the Web displays:

dmarc <[email-masked]> on behalf of [email-masked]

and for those domains that have DMARC policies

dmarc <[email-masked]> on behalf of todd.herr=[email-masked]

Jesse

---

From: Jesse Thompson <[email-masked]>
Date: Mon, 22 Jun 2020 18:40:33 -0500

On 6/22/20 10:48 AM, Hector Santos wrote:
> 3) Authorize the Rewriting of your secured domain to a secured resigner domain.

If those were the only choices then no EDU would publish DMARC policies. 

Jesse

---

From: Dotzero <[email-masked]>
Date: Tue, 23 Jun 2020 10:26:42 -0400

On Sun, Jun 21, 2020 at 1:32 PM Dave Crocker <[email-masked]> wrote:

> It's important to note that in those times the "Sender:" was almost
certainly in the same organization/location/address/namespace as the
author. If that were still true today we wouldn't be having this discussion
because the RH side of the email addresses would align.

> could be any separate party responsible for processing the message

"Processing"? That covers a whole lot more than sending. A security
appliance "processes" the message but is clearly not the Sender.

> .

Now you are in a space I know a tiny bit about. There's a little bit of
history here, starting with the  FTC spam workshop in 2003 and the FTC
email authentication workshop in 2004 we saw a lot of changes starting to
occur in the email authentication space. The FTC was forcing things by
indicating that if the private sector didn't come up with solutions, the
FTC was going to regulate. SPF took a spot in the limelight and DK and IIM
were merged to create DKIM. A number of people on this list were involved
in all the happenings. Anyways, I wrote a 46 page document for internal
consumption at the greeting card company I worked for. At the time, pretty
much all greeting card companies sent email in the manner you describe
except that many didn't even bother with Sender... and the emails typically
got through to the recipient. In my analysis, I posited that there would be
drastic changes coming in practices for greeting card sites along with news
sites (share with a friend) or sites that had a refer a friend function
(and which typically sent the email using the email address of the person
doing the referring on the theory it would result in more opens. In any
event, my thesis was that all of these types of websites would have to
start sending emails as themselves rather than using an email address not
their own. This was specifically linked to these nascent email
authentication efforts. In 2007, the Storm Worm started spewing "greeting
card notifications" (along with other sites) purporting to be from a
variety of greeting card sites. The volume of these sends was orders of
magnitude greater than any greeting card site was sending itself. This
caused management to ask me what could be done about this problem. We
implemented changes like strict SPF and DKIM across the board for all our
end user facing websites (mail), moving all our employees (with the
exception of role accounts and a handful of user accounts that responded
directly to end users or partners and publicizing to receiving domains and
security companies what we were doing and that if mail claiming to be from
our domains failed to pass either SPF or DKIM, throw it away. Absent the
feed back loop and the formal definitions in the standard, this is the
essence of DMARC. If someone cares to look back in the DKIM-OPS list from
that time frame you can find posts from me making those assertions.

At roughly the same timeframe, Pat Peterson, who was still at IronPort,
organized a small group of senders (mostly financials and a greeting card
company), a couple intermediaries (like ReturnPath and eCert) and some
major receiving sites (like Yahoo! and AOL). PayPal and Yahoo! at the time
were working on a private peering solution which was successful. This all
eventually became the DMARC "team" and later dmarc.org. It is important to
remember that both SPF and DKIM function at the domain level, not the
individual account level (with the exception of edge cases like a domain
which is a personal domain with a single user account). Yes, there was the
d= vs i= debate with DKIM... and i= lost out in practice.

Today you won't find any (major) greeting card site sending email in the
way you describe. This isn't because they wanted to change. It's because
they were forced to change. Email authentication has a network effect that
in essence makes unauthenticated mail "second class" from a receivers point
of view. Yes, there are certain types of mail scenarios (MLMs for example)
that are problematic, but one always has to ask, for whom? Some in the MLM
community responded to the changing environment by saying "We were here
first so go fuck off with telling us to change how we do things". Yet MLMs
have changed in various ways in attempts to deal with the environment
presented by changing practices, particularly by major receiving sites and
the security industry.

> reliable note the distinctions.

I absolutely disagree. It's not because Sender: is not reliably present but
because Sender: is inherently unreliable because unless it is in the same
domain space we have absolutely no way to validate the relationship between
Sender: and From:. This was the problem inherent in the SenderID PRA
algorithm. I could and did send emails to the folks who were promoting
SenderID at MS using their email addresses and random nonSPF publishing
domains as the Sender: to consistently achieve a neutral from the PRA
algorithm. Until and unless there is a way to specify such a link, any
proposal to rely on Sender: is doomed to failure. And no, that does not
mean I think Hector's proposals regarding Sender: are valid approaches.

> > writing, not modifying From: should be considered a violation.

MLMs can be both at the same time. Digests vs individual (unmodified)
messages.

> quoting someone but it turns out the reporter invented the content.)

The real question is what works, not whether it is a business issue vs a
technical issue. If there is a standard that works, great. If there are
heuristics or algorithms that work, they will get implemented whether they
have been standardized or not. To the extent that standards bodies provide
meaningful solutions in (somewhat)  timely manner, they will remain
relevant to a given (problem) space.

> like those changes is a non-technical matter.

At the end of the day, mailbox providers will determine the outcome of the
subject of these discussions based on how they handle and treat mail
passing through MLMs and whether there is authentication they find useful
(as one part of determining how they will treat mail streams and individual
messages within those streams)

> effective destroy author information, by putting in a different email

Destroy? or modify? As long as the original email address is available in
some identifiable form in the received email message then it is possible
for MLMs to work in a manner akin to how they work today. Yes it involves
rewriting code and logic to support those changes but there you have it.

> it still can be helpful to understand the problems created by this

It's not a technical issue for MLMs, it is a business issue at its essence
- change or don't change. Such change can be on an individual basis (or
not) or it could be standardized.

> that mailing list mail can be delivered.

And yet Sender: can still be the transmitter as long as they are in the
same RH address space OR can sign the message with a valid DKIM key from
the From: address domain space. Of course, MLMs putting their own email
address in the From: is a change but I'm not sure it quite matches the
semantics you suggest.

> I consider that to be exactly the role the MLM is performing.

Sender: can still be a useful field but not necessarily from an
authentication POV absent some way of determining whether the purported
Author authorized the Sender to send the message on their behalf.

> > RFC 5322 says display names are "associated" to a mailbox.

As long as the display name is free form it is not associated with anything
in particular other than the message which contains it.

> display-name, I don't see any explanation of its semantic.

+1

Michael Hammer

---

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

I believe this document provides a path forward for solving this problem, and it has relatively low complexity of implementation.

Doug Foster

Current situation

Incoming mail filters options when evaluating mailing list messages:Filter evaluates the message as if it is a direct message from the list domain    This is the header munging solution that creates problems for the MUA.  This can also be achieved if the sender uses SRS encoding of the RFC5321 MailFrom address, and the incoming filter does no evaluation of the  “From” header  address.Filter evaluates the message as if it is a direct message from the originator domain, ignoring the evidence that the message came from servers on the list domain, but accepting the message as long as it has a verifiable DKIM signature for the “From” header address.   This is the situation when a DKIM-signed message is relayed without modification.    Messages may be blocked by the incoming filter because the list members are viewed as unfamiliar and therefore untrusted senders.

An ideal filtering configuration should recognize that there are three potential mail flows, not two.    In an ideal world, all three should be identifiable uniquely, since the recipient organization may wish to apply differential policies:Direct messages from the list domain.Direct messages from the originator domain.Forwarded messages from the originator domain through the list.

As long as the mailing list applies signature-invalidating changes, Any option requires that the incoming filter chooses to given enhanced trust to the list domain.  Specific aspects of that trust:The list performs no deception.  Header records are relayed legitimately.The list inserts no malicious content.The list has reasonable controls on list enrollment.The list has reasonable controls to ensure that list submissions are really from the stated email address.The list applies its best effort to block content that the recipient systems would find objectionable.If objectionable content is detected, the fault should be attributed to the originator, not the list domain, so that list message from other originators will continue to be accepted.

Once trust is granted to the list, SPF and DKIM checking of the originator becomes relaxed:SPF and DKIM checking can be computed using relayed header information, because the incoming filter trusts that the headers are not fraudulent, orSPF and DKIM checking can be omitted, because the incoming filter trusts the controls applied by the list.

A few issues remain:How does the incoming filter prove that the message is really from the list, rather than someone spoofing the list?   Since the RFC5321 M<ail+From address and theHow does the list know that the incoming filter will allow them to bypass From-header rewrite?

Alternate Authentication

I begin by assuming that the incoming mail filter is willing to grant preferred treatment to the mailing list, and that this trust is obtained by administrative processes external to this document.   In the case of a new subscription to a mailing list, the list may send an enrollment notice to the subscriber, asking him to request preferred treatment from his email security team.   Once that administrative grant has been obtained, the technical side can be configured to allow list authentication and originator authentication to be performed using alternate algorithms.

I also assume that messages exchanged using an alternate authentication algorithm will preserve the originator value for RFC5321 MAILFROM and RFC5322 “From” header address.   (No SRS encoding.)  

For lists, I propose that the list source be verified by applying the LIST-ID address to the SPF algorithm. For other types of forwarders, I propose that Postmaster@Helodomain be passed o the SPF algorithm.      Checking for a verifiable DKIM signature which aligns with those addresses would be an additional option, or a cautious incoming filter might require both SPF and DKIM to verify.  The configured requirements need not be standardized.  I tentatively call this FWDRAUTH – alternate authentication of a forwarder.

Once the forwarding tests have been passed, the incoming filter has a range of options for evaluating the originator:No checking – assume that the originator was adequately verified by the forwarding system’s controls.DKIM – For messages that were not altered during the forwarding process, a DKIM-verified signature can be matched to the From header address.Authentication Results Chain – accept ARC results provided by the forwarder, describing the tests performed by the forwarder when the message was received.Inferred SPF – Parse the received header chain to determine when the message entered the forwarding domain, and evaluate SPF based on the IP address of the server that submitted the message to the forwarder.

Again, the choice of techniques is specific to the incoming filter, and need not be standardized.   All that matters is that the incoming filter has the capability to evaluate the list and the originator using alternate authentication methods.  Collectively, these alternate authentication algorithms allow the From address to match the originator without causing desired messages to be blocked.

Forwarder Notification

All of the above is useless unless the mailing list or other forwarder knows that a particular subscriber can evaluate messages using Alternate Authentication, so a signalling technique is needed, in the form of a DNS entry , within the recipient domain, that the forwarder can use to verify that the recipient domain has the ability to apply alternate authentication.

My current thinking is that this would be as simple as txt=”FWDAUTH v-1”.   It seems too complex and too risky for the receiving domain to publish the specific lists for which it is willing to apply alternate authentication.   But if the forward detects the signal, it can invoke supporting administrative processes, including test messages, to determine if the alternate authentication method is successful.

Changes required for implementation:At least some email recipient filters would need to implement the code for alternate authentication, then publish the DNS entry to indicate that it is available.MLMs would need to track which approach to use for each recipient:   For recipients that can use the alternate authentication method, messages would be sent without header munging.   For recipients that do not use the alternate authentication method, header munging would still be needed.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 23 Jun 2020 22:00:13 -0700

On Tue, Jun 23, 2020 at 4:08 PM Douglas E. Foster
<[email-masked]> wrote:
> A few issues remain:
>
> How does the incoming filter prove that the message is really from the list, rather than someone spoofing the list?   Since the RFC5321 M<ail+From address and the

Was there supposed to be more to this line?

-MSK

---

From: "Douglas E. Foster" <[email-masked]>
Date: Wed, 24 Jun 2020 12:01:18 GMT

Good question, Murray.    Please ignore the broken sentence, as I think it was text intended for somewhere else in the document.   I just reread and found a few other typos, but not enough to require a resend of the whole document.   My proofreading should have been better.

Doug Foster

----------------------------------------
From: "Murray S. Kucherawy" <[email-masked]>
Sent: 6/24/20 1:00 AM
To: [email-masked]
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dmarc-ietf] Header munging: A solution proposal for alternate authentication
On Tue, Jun 23, 2020 at 4:08 PM Douglas E. Foster

-MSK