Subject: [dmarc-ietf] ARC vs reject

From: Michael Thomas <[email-masked]>
Date: Sat, 5 Dec 2020 11:50:09 -0800

As I understand ARC, it is means of transporting the original auth-res 
to the destination in case the origin signature is broken by an 
intermediary. From there the destination can decide one way or the other 
to override the DMARC policy of, say, reject. There are, however, use 
cases where that is exactly wrong and in no case does the originating 
domain want such an override to happen. Consider my bank sending me 
transactional email. If somehow somebody managed to get that mail 
through a mailing list and arc-resigned it, my bank does *not* want that 
mail to be delivered regardless of the reputation of the mailing list 
because something weird and wrong is happening on its face.

Mike

---

From: "John Levine" <[email-masked]>
Date: 5 Dec 2020 16:03:51 -0500

In article <[email-masked]> you write:
>to override the DMARC policy of, say, reject. 

Right.

>There are, however, use 
 
If you get a message from a bank via a trustworthy mailing list with a
valid ARC chain that starts with a DMARC pass, that means someone at
the bank really did send the message to the list. I don't think it's
our job to try to guess whether the bank's users are following some
internal policy we can't see.

In practice, I can tell you that many organizations publish p=reject
because it is "more secure" and have no clue about mailing lists, so
it's a feature that ARC lets their users participate in mailing lists
without totally ignoring their DMARC policy. 

Ditto organizations that publish p=reject and only have SPF, no DKIM,
so all of their mail fails when it's forwarded. I can tell you this
latter situation happens a lot, particularly in US government
organiations where DMARC is just another checklist item.

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Sat, 5 Dec 2020 13:13:02 -0800

> internal policy we can't see.

There is no guarantee of that. If my bank says reject that mail, I want 
my provider to reject that mail, period. No amount of ARC shenanigans 
should change that policy.

> without totally ignoring their DMARC policy.

I'm not talking about misconfigured mail systems. I'm talking about a 
policy state that is not in the current set of p values.

Mike

---

From: "John Levine" <[email-masked]>
Date: 5 Dec 2020 17:02:32 -0500

>should change that policy.

OK, ARC doesn't do that. This does not mean that ARC is broken, only
that you appear to have different policy priorities than other people.
As you know, DMARC has never obliged recipients to follow senders'
policies so this is nothing new.

My system does a lot of forwards of SPF-only p=reject mail to
addresses that belong to individuals, e.g. [email-masked] to the
town clerk's gmail account. No matter how loudly someone might shout
that I should never ever forward that mail, I will ignore them,
because their policy is in this case silly. We have seen that senders
often publish policies that have silly effects and I see no reason to
pay them more attention than they deserve.

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Sat, 5 Dec 2020 14:07:12 -0800

> policies so this is nothing new.

If ARC is advocating for a bypass of p=reject that introduces a new 
state. If my policy is reject, I want you to reject the mail. If I want 
you to reject the mail unless you think it has come from an acceptable 
place with receipts, then you need a new policy tag like 
reject-except-valid-arc.

Mike

---

From: "John Levine" <[email-masked]>
Date: 5 Dec 2020 18:10:58 -0500

>place with receipts, then you need a new policy tag like 

Other people will have to speak for themselves but on my system

a) I don't believe you.

2) I don't care.

I think you will find this reaction pretty common.

I see lots of mail going through my system like the stuff I described
for the town clerk. It is obvious who it is intended for, the only way
to deliver it to that recipient is to forward it, and if the DMARC
policy says not to do that, the policy is wrong. I don't even need ARC
for that, although ARC can be useful for mail that takes indirect
routes for the mailing lists they subscribe to.

You can say, no I am smarter than those guys and I REALLY REALLY mean
it, but see 2) above.

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Sat, 5 Dec 2020 15:15:53 -0800

> You can say, no I am smarter than those guys and I REALLY REALLY mean

Can you keep your contempt for me off this list? This is not even 
responsive to what I wrote, and is nothing more than an ad hominem.

And  your anecdotal evidence drawn from a tiny system is very suspect.

Mike

---

From: Dave Crocker <[email-masked]>
Date: Sat, 5 Dec 2020 15:24:17 -0800

> responsive to what I wrote, and is nothing more than an ad hominem.

Wow. It wasn't an ad hominem.  His response followed the exact form that 
was established in your note, in the way the requirement/expectation was 
specified. If you didn't want that form used, don't use it.

In any event...

There is a fundamental flaw in the publisher of a dmarc record thinking 
they have any rights or expectations about how a receiver will choose to 
handle a dmarc failure.  It's fine for the publisher to offer their own 
assessment of what the failure means to them.  It is not fine for the 
publisher to pretend to tell the receiver what to do about it.

Even having a publisher's assessment be cast as 'advice' sets up the 
false expectation that the receiver should believe and care about that 
assessment.  Some might.  Others don't.  Talking about a receiver 
'overriding' DMARC policy exemplifies this false and inappropriate 
expectation.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
[email-masked]

---

From: Michael Thomas <[email-masked]>
Date: Sat, 5 Dec 2020 15:37:10 -0800

On 12/5/20 3:24 PM, Dave Crocker wrote:
> Wow. It wasn't an ad hominem.

"You can say, no I am smarter than those guys and I REALLY REALLY mean 
it, but see 2) above."

This is really not about questioning my intelligence. eye roll. If I 
said the same thing to you, you'd be screaming bloody murder to the 
chairs to try to get me banned again.

>
> There is a fundamental flaw in the publisher of a dmarc record 
> thinking they have any rights or expectations about how a receiver 
> will choose to handle a dmarc failure.  It's fine for the publisher to 
> offer their own assessment of what the failure means to them.  It is 
> not fine for the publisher to pretend to tell the receiver what to do 
> about it.
>
If the publisher of the DMARC record cannot accurately state its 
desires/policy, that is a deficiency in the protocol. Reject means I 
want you to reject it. It doesn't carve out exceptions. ARC is trying to 
carve out exceptions. If it wants an exception, the originating domain 
should have a say in whether it desires the receiving domain to carve 
out an exception one way or the other.

Mike

---

From: Tim Wicinski <[email-masked]>
Date: Sat, 5 Dec 2020 18:49:20 -0500

Michael

I don't see john's comments as ad hominem.  He's describing how his mail
system interprets mail flow.

But I do think a lot of this discussion is getting into very
esoteric cases.
I'd suggest trying to put your thoughts into a draft we can sit and chew on.

Tim

On Sat, Dec 5, 2020 at 6:16 PM Michael Thomas <[email-masked]> wrote:

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

---

From: Michael Thomas <[email-masked]>
Date: Sat, 5 Dec 2020 15:59:16 -0800

On 12/5/20 3:49 PM, Tim Wicinski wrote:
> Michael
>
> I don't see john's comments as ad hominem.  He's describing how his 
> mail system interprets mail flow.
>

Wow, you don't see the last line as questioning my intelligence? The two 
of them have been tag teaming me to get me thrown off of here since I 
returned just like they did on the DKIM list which I finally left 
because it wasn't worth their nastiness. I'll probably do the same here 
since the chairs seem to not care about their continuing hostility, but 
I will always have the fact that myself and two others created and wrote 
DKIM well before IETF came into the picture and the politics and credit 
seeking personalities it brings.

Mike

>
> Tim
>
>
> On Sat, Dec 5, 2020 at 6:16 PM Michael Thomas <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>     > In article <[email-masked]
>     <mailto:[email-masked]>> you write:
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/dmarc>
>

---

From: Dave Crocker <[email-masked]>
Date: Sat, 5 Dec 2020 16:21:23 -0800

> chairs to try to get me banned again.

Note that what you have just done is, in fact, an ad hominem and 
arguably does violate IETF participation rules.

Again, the response you are objecting two exactly followed the 
linguistic form of the setup you offered.  As such, the response was not 
directly at you, the author of the posting, but at the hypothetical 
person you formulated.

> want you to reject it. It doesn't carve out exceptions. ARC is trying 
> to carve out exceptions. If it wants an exception, the originating 
> domain should have a say in whether it desires the receiving domain to 
> carve out an exception one way or the other.

The domain owner might want all sorts of unreasonable things. Having a 
way to let the domain owner publish demands that are widely ignored 
indicates a seriously flawed semantic model. And that is, indeed, the 
current reality for DMARC.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Michael Thomas <[email-masked]>
Date: Sat, 5 Dec 2020 16:41:57 -0800

On 12/5/20 4:21 PM, Dave Crocker wrote:
>> "You can say, no I am smarter than those guys and I REALLY REALLY 
>> mean it, but see 2) above."
>>

How can me pointing out that you would call that an ad hominem, become 
ad hominem?

This is the bizzarro world that caused me to leave the last time.

> linguistic form of the setup you offered.  As such, the response was 
> not directly at you, the author of the posting, but at the 
> hypothetical person you formulated.

Oh yeah, I just missed the implied royal you in the reply directed at me 
from somebody who has a long history of antagonism to me including petty 
5xx messages from direct mail to him. Whatever was I thinking in the 
Panglossian world we live in?

>> domain should have a say in whether it desires the receiving domain 
>> to carve out an exception one way or the other.
>
You are fixated on what the receiver must or must not do. I never said 
anything about that. That is a strawman. I'm pointing out that ARC is 
trying to get two states out of reject where there only is one. It is 
certainly not unreasonable for my bank to say "please reject anything 
that is not by the letter of the law". I don't want somebody to figure 
out how to game all of this ARC stuff to phish me from my bank. That is 
far from unreasonable.

But you can say, no I am smarter than those banks and I REALLY REALLY 
mean it, but I don't care.

Mike

---

From: Douglas Foster <[email-masked]>
Date: Sat, 5 Dec 2020 20:20:47 -0500

1) Michael. you have belabored your questions about DKIM vs ARC rather too
long.    It is what it is.

2) On the issue of "Do Not Forward":  It is certainly an available feature
of postal mail, which the postal service enforces.   Email has no central
authority to reliable enforce such a policy.   Just as importantly, no one
should (and few businesses do) consider email to be an environment where
sensitive information is transmitted.   Any competent bank will send an
email telling you to log into their website to obtain the sensitive
information.   I do not see a "Do Not Forward" policy as something that is
useful or likely to be used.

3) On the issue of p=reject:    You have been usefully pressing the
question of what purpose lies behind the technology.    In the case of
DMARC, the purpose is to block spoofed messages.    We know that mailing
lists turn a legitimate message into a looks-like-spoof message.   ARC is
trying to fix the false spoof, which is a worthy goal.   More precisely, it
is trying to provide information to the recipient system so that the
recipient system can determine that the message is forwarded but not
spoofed.

4) On the future of ARC:   The idea is harmless, but I do not see it
achieving the list-industry goal of eliminating From rewrite.  It actually
reminds me of DKIM without DMARC - a technology looking for an algorithm to
which it can contribute.    Since nobody can articulate how a recipient
uses ARC information to reach an expected conclusion, something important
is still missing.    As I wrote in my last post, I think it fails to
provide enough information for a useful algorithm to be defined.    Even if
that can be solved, there are bigger problems.   We have no algorithm for a
list to know if a particular recipient uses ARC, or whether it will use the
ARC information to draw the desired conclusion about list messages.
 Without those answers, the list is doomed to continue From rewrite even if
when it would not be necessary.    And much of this is about AOL in
particular, and the currently available information suggests that AOL is
not on board with ARC.

5) The work you and Alessandro have done with reverse transformation is
more likely to produce a solution for the mailing lists.   The lists will
continue to do From rewrite, but reverse-transform recipients can validate
the true source of the message and restore the From if desired.

---

From: Michael Thomas <[email-masked]>
Date: Sat, 5 Dec 2020 17:34:45 -0800

On 12/5/20 5:20 PM, Douglas Foster wrote:
> 1) Michael. you have belabored your questions about DKIM vs ARC rather 
> too long.    It is what it is.

ARC is an experiment. Experiments require peer review.

>
> 2) On the issue of "Do Not Forward":  It is certainly an available 
> feature of postal mail, which the postal service enforces.   Email has 
> no central authority to reliable enforce such a policy.   Just as 
> importantly, no one should (and few businesses do) consider email to 
> be an environment where sensitive information is transmitted.   Any 
> competent bank will send an email telling you to log into their 
> website to obtain the sensitive information.   I do not see a "Do Not 
> Forward" policy as something that is useful or likely to be used.

DKIM is a mechanism which allows you to be assured that the forwarding 
was done without altering. Since email is more like postcard than a 
letter in an envelope that is a good property.

> DMARC, the purpose is to block spoofed messages.    We know that 
> mailing lists turn a legitimate message into a looks-like-spoof 
> message.   ARC is trying to fix the false spoof, which is a worthy 
> goal.   More precisely, it is trying to provide information to the 
> recipient system so that the recipient system can determine that the 
> message is forwarded but not spoofed.

Yes, but my bank seriously does not want any "acceptable" 
transformations. There are no acceptable transformations. DMARC needs to 
provide for that use case (and, in fact, it does currently). ARC is 
setting up a situation where there is no way for my bank to say, "no 
way, never".

>
> 4) On the future of ARC:   The idea is harmless
To the contrary security protocols often create unintended consequences. 
The are never "harmless" until proven so. An experiment is hardly 
confidence-inspiring that it has been fully vetted.
>
> 5) The work you and Alessandro have done with reverse transformation 
> is more likely to produce a solution for the mailing lists.   The 
> lists will continue to do From rewrite, but reverse-transform 
> recipients can validate the true source of the message and restore the 
> From if desired.

I'm starting to get a little more serious about my quip that the MLM can 
insert a sed script in a header to unmangle the message since it knows 
what transforms it has done, unlike the receiving MTA trying to guess 
the common transformations.

Mike

>
> On Sat, Dec 5, 2020 at 7:42 PM Michael Thomas <[email-masked]

---

From: "John Levine" <[email-masked]>
Date: 5 Dec 2020 20:47:59 -0500

>current reality for DMARC.

Thanks. Lest anyone think this is a new issue, see this message I sent
to the DKIM list in 2006, fourteen years ago:

https://mailarchive.ietf.org/arch/msg/ietf-dkim/CBsHbUVtM512vgiwljiA6dtVJ1Q/#

I reprised it six years ago in 2014:

https://mailarchive.ietf.org/arch/msg/ietf/ngPmSfa0b_B5Q72G1JwzGG2IYKY/

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Sat, 5 Dec 2020 17:51:54 -0800

> https://mailarchive.ietf.org/arch/msg/ietf/ngPmSfa0b_B5Q72G1JwzGG2IYKY/

because a domain owner might want an unreasonable thing doesn't imply 
that a domain owner can't want a reasonable thing. this is a logical 
fallacy designed to dismiss any request as unreasonable.

Mike

---

From: "Jim Fenton" <[email-masked]>
Date: Sat, 05 Dec 2020 18:04:44 -0800

> internal policy we can't see.

I’d like to step back from the specific use case of “a bank”.

If a domain publishes p=reject, they’re requesting particular handling 
of a message they originate. ARC modifies that, which is good for 
mailing lists and similar intermediaries, but depends on a list of 
trusted intermediaries that is not under the control of the originating 
domain. That increases the attack surface for DMARC considerably.

The question I have is: Should DMARC have a policy (or policy modifier) 
that says, “Do not accept modifications to this message?” In other 
words, that the originator values the integrity of their messages over 
deliverability.

-Jim

---

From: "John R Levine" <[email-masked]>
Date: 5 Dec 2020 21:22:18 -0500

> If a domain publishes p=reject, they’re requesting particular handling of a 
> message they originate. ARC modifies that, which is good for mailing lists 
> and similar intermediaries, but depends on a list of trusted intermediaries 
> that is not under the control of the originating domain. That increases the 
> attack surface for DMARC considerably.

Not if the recipients use ARC reasonably, e.g., only on mail from hosts 
with a history of not sending botware, use it to see whether a message was 
originally aligned.  Anyone who misuses ARC is going to have worse spam 
leakage than anyone can fix for them.

> The question I have is: Should DMARC have a policy (or policy modifier) that 
> says, “Do not accept modifications to this message?” In other words, that the 
> originator values the integrity of their messages over deliverability.

Of course not.  That's just the tiny gorillas stamping their teensy feet. 
Why would anyone expect that the people publishing that flag actually 
understood what it meant?  Many will just turn it on because someone said 
it's "more secure."

A lot of this boils down to what if some entity sends signed valid DMARC 
aligned mail but somehow doesn't mean it, e.g., an internal policy says no 
mailing lists but their users participate in lists anyway.  If they can't 
control their own mail system, it is not anyone else's job to do it for 
them.

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Sat, 5 Dec 2020 18:27:00 -0800

On 12/5/20 6:22 PM, John R Levine wrote:
>> The question I have is: Should DMARC have a policy (or policy 
>> modifier) that says, “Do not accept modifications to this message?” 
>> In other words, that the originator values the integrity of their 
>> messages over deliverability.
>
> Of course not.  That's just the tiny gorillas stamping their teensy 
> feet. Why would anyone expect that the people publishing that flag 
> actually understood what it meant?  Many will just turn it on because 
> someone said it's "more secure."
Financial institutions are "tiny gorillas"? Who knew? The federal 
government is "tiny gorillas"? What is the metric here?

Mike

---

From: Michael Thomas <[email-masked]>
Date: Sat, 5 Dec 2020 18:31:18 -0800

On 12/5/20 6:22 PM, John R Levine wrote:
>
>
> A lot of this boils down to what if some entity sends signed valid 
> DMARC aligned mail but somehow doesn't mean it, e.g., an internal 
> policy says no mailing lists but their users participate in lists 
> anyway.  If they can't control their own mail system, it is not anyone 
> else's job to do it for them.
>
PS: if IETF must assume that people cannot understand our standards and 
their intent, then we might as well shut down. if they cannot understand 
our intent, that is squarely on us, not them. This sort of cynicism is 
poisonous.

Mike

---

From: Hector Santos <[email-masked]>
Date: Sat, 05 Dec 2020 22:51:44 -0500

On 12/5/2020 5:07 PM, Michael Thomas wrote:
> state. If my policy is reject, I want you to reject the mail. If I
> want you to reject the mail unless you think it has come from an
> acceptable place with receipts, then you need a new policy tag like
> reject-except-valid-arc.

I have long suggested one way to resolve this is by using a new DMARC 
extended "arc=" switch.  Allow the author domain define what is 
acceptable from an ARC standpoint, if interested.

arc=N   where N is the arc seal count, whatever amount is allow to 
"promote" a failed DKIM to a pass.  The inherent default arc=0 would 
suggest arc should not be a consideration DKIM fails.

In principle, I am for using DMARC extended switches to outline the 
different protocol behaviors.

arc=1  DMARC Receiver MAY consider using arc for failure promotion

atps=1  DMARC MAY consider using RFC6541

rewrite=0 Mailing List SHOULD NOT rewrite 5322.From

Keep it simple folks.

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

---

From: "Jim Fenton" <[email-masked]>
Date: Sat, 05 Dec 2020 19:56:08 -0800

On 5 Dec 2020, at 18:22, John R Levine wrote:

>> If a domain publishes p=reject, they’re requesting particular 
>> handling of a message they originate. ARC modifies that, which is 
>> good for mailing lists and similar intermediaries, but depends on a 
>> list of trusted intermediaries that is not under the control of the 
>> originating domain. That increases the attack surface for DMARC 
>> considerably.
>
> Not if the recipients use ARC reasonably, e.g., only on mail from 
> hosts with a history of not sending botware, use it to see whether a 
> message was originally aligned.  Anyone who misuses ARC is going to 
> have worse spam leakage than anyone can fix for them.

“Use ARC reasonably” then seems to depend on whether the recipient 
has a good reputation system for evaluating the trustworthiness of 
message modifiers. There isn’t a good track record in creating and 
deploying such reputation systems, as you well know. In this case 
specifically, there is the question of what happens when a domain user 
subscribes to a mailing list, or has their mail forwarded with 
modification, from a new intermediary.

>> modifier) that says, “Do not accept modifications to this 
>> message?” In other words, that the originator values the integrity 
>> of their messages over deliverability.
>

FWIW, I don’t think a lot of the people publishing p=reject understood 
the implications of that, either. This is not significantly more arcane.

> else's job to do it for them.

It isn’t a question of controlling their own mail system. One of the 
value propositions of DMARC is effectiveness against phishing. Suppose a 
phishing attacker composed a message purporting to be from someone the 
victim trusts (including a DKIM signature that doesn’t verify because 
the message has supposedly been modified), and then makes it look like 
it has been forwarded by a throw-away intermediary they control and adds 
valid ARC header fields signed by the supposed intermediary. If the 
recipient domain accepts modifications by zero-reputation intermediaries 
(because there are so many of them, after all), DMARC policy is ignored 
and the message is delivered normally. The premise of DMARC is that the 
originating domain has an interest in expressing how messages purporting 
to come from their domain should be handled, and this attack uses ARC to 
override that.

I’d be interested in other opinions on this. Or whether this is a 
fundamental problem with ARC.

-Jim

---

From: "John R Levine" <[email-masked]>
Date: 5 Dec 2020 23:14:18 -0500

On Sat, 5 Dec 2020, Jim Fenton wrote:
> FWIW, I don’t think a lot of the people publishing p=reject understood the 
> implications of that, either. This is not significantly more arcane.

Then I think we agree.  There's no difference from p=reject and 
p=reject-I-really-mean it.

> ... If the recipient domain accepts modifications by zero-reputation 
> intermediaries (because there are so many of them, after all)

I wouldn't call that a reasonable implementation of ARC.  The set of hosts 
that are likely to send you mail with interesting ARC chains is relatively 
small, and I don't think it changes very fast.  Most of the hosts that 
send you non-spam mail aren't going to send you mail that needs ARC.

If you're setting up a new mailing list host or forwarder, getting 
yourself into whatever whitelists people use will be somewhat painful but 
there's nothing new about that.

> I’d be interested in other opinions on this. Or whether this is a fundamental 
> problem with ARC.

I'd certainly be interested in hearing how people plan to compile and 
maintain their lists of ARC-worthy hosts.

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

---

From: Michael Thomas <[email-masked]>
Date: Sat, 5 Dec 2020 20:18:37 -0800

On 12/5/20 8:14 PM, John R Levine wrote:
>>> actually understood what it meant?  Many will just turn it on 
>>> because someone said it's "more secure."
>>
>> FWIW, I don’t think a lot of the people publishing p=reject 
>> understood the implications of that, either. This is not 
>> significantly more arcane.
>

If the operating assumption is that people implementing DMARC is that 
they are all illiterate, then our project is done.

Mike

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 6 Dec 2020 14:35:49 +0100

On Sun 06/Dec/2020 02:20:47 +0100 Douglas Foster wrote:
> which it can contribute.    Since nobody can articulate how a recipient uses 
> ARC information to reach an expected conclusion, something important is still 
> missing.    As I wrote in my last post, I think it fails to provide enough 
> information for a useful algorithm to be defined.    Even if that can be 
> solved, there are bigger problems.  We have no algorithm for a list to know if 
> a particular recipient uses ARC, or whether it will use the ARC information to 
> draw the desired conclusion about list messages.   Without those answers, 
> the list is doomed to continue From rewrite even if when it would not be 
> necessary.   And much of this is about AOL in particular, and the currently 
> available information suggests that AOL is not on board with ARC.

I agree with the above analysis.

I'd add that ARC is most useful to large sites that develop a global reputation 
system, as ARC allows to fine tune message attribution and thereby adjust the 
very computation of reputation.  On the opposite, small sites may have problems 
trusting last hop's ARC data.  They can still seal forwarded mail, though.

As far as working around From: rewriting is concerned, given the premises 
quoted above, the only way is to reverse such rewriting upon final message 
delivery.

Best
Ale
--

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 6 Dec 2020 14:40:46 +0100

On Sun 06/Dec/2020 02:34:45 +0100 Michael Thomas wrote:
>>
>> 5) The work you and Alessandro have done with reverse transformation is more 
>> likely to produce a solution for the mailing lists.   The lists will continue 
>> to do From rewrite, but reverse-transform recipients can validate the true 
>> source of the message and restore the From if desired.
> 
> I'm starting to get a little more serious about my quip that the MLM can insert 
> a sed script in a header to unmangle the message since it knows what transforms 
> it has done, unlike the receiving MTA trying to guess the common transformations.

But then the receiving MTA will have to guess whether the sed script 
considerably alters the intended meaning of the message.  For example, does it 
change a bank account number?

Best
Ale
--

---

From: Michael Thomas <[email-masked]>
Date: Sun, 6 Dec 2020 09:01:04 -0800

On 12/6/20 5:40 AM, Alessandro Vesely wrote:
>>> recipients can validate the true source of the message and restore 
>>> the From if desired.
>>
>> I'm starting to get a little more serious about my quip that the MLM 
>> can insert a sed script in a header to unmangle the message since it 
>> knows what transforms it has done, unlike the receiving MTA trying to 
>> guess the common transformations.
>
>
> considerably alters the intended meaning of the message. For example, 
> does it change a bank account number?
>
This actually highlights why my observation is correct. If the 
intermediary showed how to reverse their changes perfectly to be able to 
validate the original signature, it says nothing about whether those 
changes to be delivered to the recipient are acceptable to the 
originating domain. for the case of a bank sending me sensitive mail, 
the answer is that it is never ok. for somebody working on internet 
standards working on ietf lists, the answer is that it is fine. hence 
trying to get two states of the one "reject" is insufficient.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Sun, 6 Dec 2020 09:41:13 -0800

> the implications of that, either. This is not significantly more arcane.

The audience for what I am bringing up are exactly the clueful set who 
are paranoid about any modifications at all to their mail. I want my 
bank to be paranoid because, you know, money. Anybody can be clueless 
and select the wrong policy, but that doesn't mean that the clueful 
should not have a policy that meets their wishes.

Mike

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 6 Dec 2020 19:31:30 +0100

On Sun 06/Dec/2020 18:01:04 +0100 Michael Thomas wrote:
>>> insert a sed script in a header to unmangle the message since it knows what 
>>> transforms it has done, unlike the receiving MTA trying to guess the common 
>>> transformations.
>>
> This actually highlights why my observation is correct. If the intermediary 
> showed how to reverse their changes perfectly to be able to validate the 
> original signature, it says nothing about whether those changes to be delivered 
> to the recipient are acceptable to the originating domain. for the case of a 
> bank sending me sensitive mail, the answer is that it is never ok. for somebody 
> working on internet standards working on ietf lists, the answer is that it is 
> fine. hence trying to get two states of the one "reject" is insufficient.

For MLM transformations, this choice can be done by tuning DKIM signatures.  A 
bank can choose to sign Sender: field (or lack thereof), or any other fields 
that a MLM has to change, and possibly use simple canonicalization.  In that 
conditions, transformation reversion won't work.  It isn't a distinct DMARC 
state, formally.  Yet, tuning DKIM signatures allows to harden or weaken the 
given DMARC state.

Best
Ale
--

---

From: Douglas Foster <[email-masked]>
Date: Sun, 6 Dec 2020 13:45:36 -0500

The recent discussion has introduced two challenges to ARC:  first, that it
is too complicated, and second, that it opens up security holes that should
be unacceptable.    John's response appears to be that the technology will
only be used by a small group of lists in cooperation with a small group of
recipients, that the complexity will be a non-issue for the participants
and the risk, while present, will be mitigated by the limited scope of
participation.    All of this is problematic.

On security issues, we have to assume attacks by state-sponsored actors,
not just fortune seekers.   So the security challenge needs to be
thoroughly vetted.

But the participation assumption is even more worrisome.    If this is a
limited participation protocol, supported by a private but not-yet-created
communication network, then it does not solve the chair's requirement for a
general solution.

I ask the chairs to formally endorse development of an alternative to ARC
as an additional approach to the mailing list problem, a solution based on
reverse transformation.   Alessandro and Murray have submitted drafts.   It
is time to study their proposals and merge their work.

Doug Foster

On Sat, Dec 5, 2020 at 11:14 PM John R Levine <[email-masked]> wrote:

> feet.
> the

---

From: Michael Thomas <[email-masked]>
Date: Sun, 6 Dec 2020 10:47:24 -0800

On 12/6/20 10:31 AM, Alessandro Vesely wrote:
>> intermediary showed how to reverse their changes perfectly to be able 
>> to validate the original signature, it says nothing about whether 
>> those changes to be delivered to the recipient are acceptable to the 
> For MLM transformations, this choice can be done by tuning DKIM 
> signatures.  A bank can choose to sign Sender: field (or lack 
> thereof), or any other fields that a MLM has to change, and possibly 
> use simple canonicalization.  In that conditions, transformation 
> reversion won't work.  It isn't a distinct DMARC state, formally.  
> Yet, tuning DKIM signatures allows to harden or weaken the given DMARC 
> state.
>
It seems a lot simpler for the originating domain to just be explicit 
about how they feel about transformations by intermediaries. It's not 
like another short ascii string is going to break the bank.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Sun, 6 Dec 2020 11:02:30 -0800

On 12/6/20 10:45 AM, Douglas Foster wrote:
> The recent discussion has introduced two challenges to ARC:  first, 
> that it is too complicated, and second, that it opens up security 
> holes that should be unacceptable.    John's response appears to be 
> that the technology will only be used by a small group of lists in 
> cooperation with a small group of recipients, that the complexity will 
> be a non-issue for the participants and the risk, while present, will 
> be mitigated by the limited scope of participation.    All of this is 
> problematic.
>
> On security issues, we have to assume attacks by state-sponsored 
> actors, not just fortune seekers.   So the security challenge needs to 
> be thoroughly vetted.
>
> limited participation protocol, supported by a private but 
> not-yet-created communication network, then it does not solve the 
> chair's requirement for a general solution.

Indeed, I wonder if ietf.org would meet that criteria for "small group 
of lists".

>
> I ask the chairs to formally endorse development of an alternative to 
> ARC as an additional approach to the mailing list problem, a solution 
> based on reverse transformation.  Alessandro and Murray have submitted 
> drafts.   It is time to study their proposals and merge their work.
>

Based on the work I did at Cisco 15 years ago which essentially was a 
heuristic based form of those two drafts, I found that it worked for 
about 90 some percent. I unfortunately do not know what the nature of 
the remaining messages that could not be recovered (either I never did 
the analysis or don't remember). Things may have changed some since 
then, but that was what we got for the entire mail stream of a large 
company. Is that "good enough"? Or better yet, what is the definition of 
"good enough"?

That's probably the most important question out of all of this: what is 
the success criteria? Our success criteria was that we wanted to mark up 
messages that were possible spear phishing, so the success criteria was 
some given false positive rate, with whitelists to mop up some of the 
corner cases. But that was a very enterprise-y criteria. The larger 
success criteria needs to encompass a far larger set of use cases.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Sun, 6 Dec 2020 13:12:29 -0800

On 12/5/20 6:04 PM, Jim Fenton wrote:
> trusted intermediaries that is not under the control of the 
> modifier) that says, “Do not accept modifications to this message?” In 
> other words, that the originator values the integrity of their 
I'm in the middle of reading rfc  7960 and lo and behold I found this. 
So I'm not the only one who has thought about this.

"

To further complicate the usage of mitigations, mitigation may not be
    desired if the email in question is of a certain category of high
    value or high risk (security-related) transactional messages (dealing
    with financial transactions or medical records, for example).  In
    these cases, mitigating the impact of DMARC due to indirect email
    flows may not be desirable (counterproductive or allowing for abuse)"

And the example they use is exactly the example I used.

Mike

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 6 Dec 2020 21:05:29 -0800

> company. Is that "good enough"? Or better yet, what is the definition of

A counter-argument I've heard often to the idea of reversible
transformations is that it can become a spam vector, no different than the
argument against "l=".  For instance, if we start chopping off typical list
signatures ("delete everything at and after the lowest line containing only
hyphens"), then I can take a message from a good actor, tack a spam list
signature onto it, claim I'm an MLM, and it'll still pass with the author
domain signature when it gets delivered downstream, though the spam will
still be there.

Another is that it's not actually easy to describe all or even most of the
mutations an MLM might make to a message.  (Mailman sent me the list of
changes they might make to a message.  It's not a small list.)

Yet another is that two different MLMs might implement MIME-izing actions
ever so slightly differently, yet both results are fully compatible with
MIME and indistinguishable when rendered by most MUAs.

So in the limit, this comes down to defining a set of transformations
everyone agrees are allowed, and then all MLMs and filters implementing
exactly those and no more.  There doesn't seem to be much of an appetite in
the community for this path.

-MSK

---

From: Michael Thomas <[email-masked]>
Date: Sun, 6 Dec 2020 21:23:58 -0800

On 12/6/20 9:05 PM, Murray S. Kucherawy wrote:
> On Sun, Dec 6, 2020 at 11:02 AM Michael Thomas <[email-masked] 
> transformations is that it can become a spam vector, no different than 
> the argument against "l=".  For instance, if we start chopping off 
> typical list signatures ("delete everything at and after the lowest 
> line containing only hyphens"), then I can take a message from a good 
> actor, tack a spam list signature onto it, claim I'm an MLM, and it'll 
> still pass with the author domain signature when it gets delivered 
> downstream, though the spam will still be there.
>
> Another is that it's not actually easy to describe all or even most of 
> the mutations an MLM might make to a message. (Mailman sent me the 
> list of changes they might make to a message.  It's not a small list.)
>
> Yet another is that two different MLMs might implement MIME-izing 
> actions ever so slightly differently, yet both results are fully 
> compatible with MIME and indistinguishable when rendered by most MUAs.
>
> everyone agrees are allowed, and then all MLMs and filters 
> implementing exactly those and no more. There doesn't seem to be much 
> of an appetite in the community for this path.
>

An idea that i've been rolling around in my head is that the MLM could 
give a sed-like script to rollback the changes. since they know their 
modifications, they can obviously express how to unmodify them. it may 
have less issue with the mime hackery you were thinking about.

But as far as your point about spam vectors it is surely just as true 
about ARC, right? at least with recovering the original text i have the 
ability to remove all of the transforms and deliver the original text.  
ARC not so much. it's all or nothing on the trust front.

But I really think the key thing about all of this is figuring out what 
defines success. That is the most important thing by far.

Mike

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 6 Dec 2020 21:30:28 -0800

On Sun, Dec 6, 2020 at 9:24 PM Michael Thomas <[email-masked]> wrote:

> modifications, they can obviously express how to unmodify them. it may have
> less issue with the mime hackery you were thinking about.
>

You'd need a way to assert, and then evaluate, that something equivalent to
"s/.*/spam/g" is a transformation you're not willing to reverse and say
"yep, we're good."  I don't know how you'd go about automating that.

> ability to remove all of the transforms and deliver the original text.  ARC
> not so much. it's all or nothing on the trust front.
>
I think ARC, like PSD, is meant to run for a while and see what we've
learned from it.  Maybe it's the silver bullet, or maybe it's ineffective
complexity.  That should be part of the experiment's definition; Section 11
of the ARC RFC does try to capture all of that.

-MSK

---

From: Michael Thomas <[email-masked]>
Date: Sun, 6 Dec 2020 21:42:52 -0800

On 12/6/20 9:30 PM, Murray S. Kucherawy wrote:
> On Sun, Dec 6, 2020 at 9:24 PM Michael Thomas <[email-masked] 
>     An idea that i've been rolling around in my head is that the MLM
>     could give a sed-like script to rollback the changes. since they
>     know their modifications, they can obviously express how to
>     unmodify them. it may have less issue with the mime hackery you
>     were thinking about.
>
>
> You'd need a way to assert, and then evaluate, that something 
> equivalent to "s/.*/spam/g" is a transformation you're not willing to 
> reverse and say "yep, we're good."  I don't know how you'd go about 
> automating that.

yes, definitely. but that's just as true of your draft. these are all 
heuristics at some level to feed into some hypothetical filtering 
machine to make sure there is no fuckery going on. such is the nature of 
spam filtering. i think that is the part that is hard thing to swallow 
from a standards standpoint and is what causes so much roiling. it's 
hard for me to say if that's a good thing or a bad thing.

>     But as far as your point about spam vectors it is surely just as
>     true about ARC, right? at least with recovering the original text
>     i have the ability to remove all of the transforms and deliver the
>     original text.  ARC not so much. it's all or nothing on the trust
>     front.
>
>     But I really think the key thing about all of this is figuring out
>     what defines success. That is the most important thing by far.
>
> learned from it.  Maybe it's the silver bullet, or maybe it's 
> ineffective complexity.  That should be part of the experiment's 
> definition; Section 11 of the ARC RFC does try to capture all of that.
>
As I've been harping on, we need to have an agreed on definition of 
success. We know that 100% is not among them. What in the long tail 
don't we care about?

Mike

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 7 Dec 2020 10:35:26 +0100

On Sun 06/Dec/2020 19:47:24 +0100 Michael Thomas wrote:
>>> original signature, it says nothing about whether those changes to be 
>>> delivered to the recipient are acceptable to the originating domain. for the 
>>> case of a bank sending me sensitive mail, the answer is that it is never ok. 
>>> for somebody working on internet standards working on ietf lists, the answer 
>>> is that it is fine. hence trying to get two states of the one "reject" is 
>>> insufficient.
>>
>> For MLM transformations, this choice can be done by tuning DKIM signatures.  
>> A bank can choose to sign Sender: field (or lack thereof), or any other 
>> fields that a MLM has to change, and possibly use simple canonicalization.  
>> In that conditions, transformation reversion won't work.  It isn't a distinct 
>> DMARC state, formally. Yet, tuning DKIM signatures allows to harden or weaken 
>> the given DMARC state.
>>
> It seems a lot simpler for the originating domain to just be explicit about how 
> they feel about transformations by intermediaries. It's not like another short 
> ascii string is going to break the bank.

A stated policy is certainly more explicit about the intent.  However, it is 
subject to receivers interpretation and I-dont-care syndrome.

Best
Ale
--

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 7 Dec 2020 11:31:31 +0100

On Sun 06/Dec/2020 05:14:18 +0100 John R Levine wrote:
> I wouldn't call that a reasonable implementation of ARC.  The set of hosts that 
> are likely to send you mail with interesting ARC chains is relatively small, 
> and I don't think it changes very fast.

Trustworthiness has to account for the probability that a trusted host is 
hacked, even occasionally, so as to spew phishing.  Reasonableness is a number 
in [0, 1].  In the presence of a chain, one must consider the joint probability 
that any intermediary is hacked.

Anyone observed long ARC chains?

> I'd certainly be interested in hearing how people plan to compile and maintain 
> their lists of ARC-worthy hosts.

There should be a means of exchanging trustworthiness values, so as to build 
the transitivity required to compute the joint probabilities.

Best
Ale
--

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 7 Dec 2020 11:44:10 +0100

On Mon 07/Dec/2020 06:05:29 +0100 Murray S. Kucherawy wrote:
> 
> A counter-argument I've heard often to the idea of reversible transformations 
> is that it can become a spam vector, no different than the argument against 
> "l=".

    Compared with the use of "l=" tag (Section 8.2 of [RFC6376]), the
    fact that footers are written in plain text removes the main security
    objection about footer additions.  Namely, footers cannot completely
    replace the original content in the end recipient's eyes by
    exploiting lax HTML parsing in the MUA.

https://tools.ietf.org/html/draft-vesely-dmarc-mlm-transform-00#section-6

Best
Ale
--

---

From: Dotzero <[email-masked]>
Date: Mon, 7 Dec 2020 07:05:29 -0500

On Mon, Dec 7, 2020 at 12:30 AM Murray S. Kucherawy <[email-masked]>
wrote:

> You'd need a way to assert, and then evaluate, that something equivalent
> to "s/.*/spam/g" is a transformation you're not willing to reverse and say

I've asked here and in other places that validators/receivers consuming ARC
headers provide data regarding the results of such consumption. To date we
have not seen any data provided by participants in the ARC experiment. It
may be that ARC is a useful standard or it may not be. So far I'm seeing a
lot of supposition and speculation but no useful data for evaluation.

Michael Hammer

---

From: Michael Thomas <[email-masked]>
Date: Mon, 7 Dec 2020 08:46:51 -0800

On 12/7/20 1:35 AM, Alessandro Vesely wrote:
> A stated policy is certainly more explicit about the intent. However, 
> it is subject to receivers interpretation and I-dont-care syndrome.
>
>
Yes, the best the sending domain can ever do is state their wishes. But 
they should be able to state their wishes concisely. We're only talking 
about code points here. As a standards organization, we shouldn't be 
hung up about whether people will care. That is extremely defeatist and 
begs the question of why bother doing anything.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Mon, 7 Dec 2020 08:59:45 -0800

> definition; Section 11 of the ARC RFC does try to capture all of that.
Btw, what is PSD?

Mike

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 7 Dec 2020 10:32:22 -0800

On Mon, Dec 7, 2020 at 4:05 AM Dotzero <[email-masked]> wrote:

> I've asked here and in other places that validators/receivers consuming
> ARC headers provide data regarding the results of such consumption. To date
> we have not seen any data provided by participants in the ARC experiment.
> It may be that ARC is a useful standard or it may not be. So far I'm seeing
> a lot of supposition and speculation but no useful data for evaluation.
>

I wonder if we might ask our compatriots at M3AAWG if they might be willing
or able to undertake a data collection project in this area.  Most of the
ARC proponents are also participants there.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 7 Dec 2020 10:33:40 -0800

> Btw, what is PSD?

A working group document:
https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/

-MSK

---

From: Michael Thomas <[email-masked]>
Date: Mon, 7 Dec 2020 10:39:29 -0800

On 12/7/20 10:32 AM, Murray S. Kucherawy wrote:
> On Mon, Dec 7, 2020 at 4:05 AM Dotzero <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     I've asked here and in other places that validators/receivers
>     consuming ARC headers provide data regarding the results of such
>     consumption. To date we have not seen any data provided by
>     participants in the ARC experiment. It may be that ARC is a useful
>     standard or it may not be. So far I'm seeing a lot of supposition
>     and speculation but no useful data for evaluation.
>
>
> I wonder if we might ask our compatriots at M3AAWG if they might be 
> willing or able to undertake a data collection project in this area.  
> Most of the ARC proponents are also participants there.
>
What I'm particularly curious about is what the difference is with the 
arc auth-res on the filtering decisions. Why would a decision turn on 
that result? That's something I've been trying to understand, but 
haven't managed to get. Naively it seems like it could be useful, but is 
it in reality? Like can somebody show some A-B kind of examples, and 
whether or not they are statistical noise?

Mike

---

From: Seth Blank <[email-masked]>
Date: Mon, 7 Dec 2020 10:40:26 -0800

On Mon, Dec 7, 2020 at 10:34 AM Murray S. Kucherawy <[email-masked]>
wrote:

> willing or able to undertake a data collection project in this area.  Most
> of the ARC proponents are also participants there.
>

This data collection is taking place at M3AAWG; Kurt Andersen is leading,
with myself and Todd Herr supporting. However, this got slowed dramatically
due to COVID-- we won't realistically see data that's useful to this
working group for another few months. In the meantime, ARC discussions
continue between many international receivers, and the DMARC WG chairs are
being kept in the loop. Once there's something material to bring back, that
will happen publicly.

-- 

*Seth Blank* | VP, Standards and New Technologies
*e:* [email-masked]
*p:* 415.273.8818

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

---

From: Michael Thomas <[email-masked]>
Date: Mon, 7 Dec 2020 10:41:00 -0800

On 12/7/20 10:33 AM, Murray S. Kucherawy wrote:
> On Mon, Dec 7, 2020 at 8:59 AM Michael Thomas <[email-masked] 
> <https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/>
>
>
Oh that. I figured out the acronym and obviously immediately forgot 
about it. Graci.

Mike

---

From: "John Levine" <[email-masked]>
Date: 7 Dec 2020 14:19:59 -0500

In article <[email-masked]> you write:
>    fact that footers are written in plain text ...

They are?  Some are, some are added as MIME parts.

We really need to keep in mind that there is a lot of list management
software with a vast array of configuration options.

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Mon, 7 Dec 2020 11:25:45 -0800

> software with a vast array of configuration options.

This is why we need actual numbers instead of anecdotes about the long 
tail. We know that there is no silver bullet. Mailing lists who are 
configured in a way that causes their traffic to not get delivered can 
be configured in a way that will. It's not our problem.

Mike

---

From: Tim Wicinski <[email-masked]>
Date: Mon, 7 Dec 2020 16:00:29 -0500

> be configured in a way that will. It's not our problem.
Are you talking about integrating ARC?  Then you are correct, operational
data.  This is why until that happens, we're not talking about adding ARC
into
the DMARC flow, and it's why the ARC work is Out Of Scope in this WG.

tim

---

From: Michael Thomas <[email-masked]>
Date: Mon, 7 Dec 2020 13:07:19 -0800

On 12/7/20 1:00 PM, Tim Wicinski wrote:
>
>
> On Mon, Dec 7, 2020 at 2:26 PM Michael Thomas <[email-masked] 
> data. This is why until that happens, we're not talking about adding 
> ARC into

Do you mean that it is out of scope wrt DMARC? I can understand that 
since it's an experiment. It would probably be best documented in the 
context of ARC itself and dealt with if it ever becomes standards track. 
In the mean time, reject should mean reject.

As it turns out, rfc 7489 does seem to document the issue though.

Mike

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Mon, 7 Dec 2020 14:19:46 -0800

On Sat, Dec 5, 2020 at 5:21 PM Douglas Foster <
[email-masked]> wrote:

> ...much of this is about AOL in particular, and the currently available
> information suggests that AOL is not on board with ARC.
>

I would point you to
https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-22#section-12.2
(note that per normal IETF procedure, section 12 is removed in the
editorial conversion from an I-D to an RFC).

--Kurt

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Mon, 7 Dec 2020 14:27:11 -0800

On Sun, Dec 6, 2020 at 10:46 AM Douglas Foster <
[email-masked]> wrote:

> as an additional approach to the mailing list problem...
>

So you are asking the WG to go back to our second milestone and put the
current work on milestone 3 on hold?

--Kurt

---

From: Seth Blank <[email-masked]>
Date: Mon, 7 Dec 2020 14:48:48 -0800

> current work on milestone 3 on hold?

This thread is now extremely off topic.

As Kurt rightly mentioned, addressing indirect mailflow was a WG milestone
that has been completed. We are now in another phase of work -- driving
DMARC to a standards track document -- which has open tickets and editors
waiting on WG consensus. This conversation around indirect mail streams,
which the chairs had hoped would run its own course, is now counter
productive.

The Chairs are officially calling discussion of indirect mail flows OFF
TOPIC until all open bis tickets in trac are resolved. After all tickets
are resolved, but prior to WGLC on the bis documents, we will return to a
discussion of indirect mail flow and where ARC stands. For now, move on to
open tickets.

Seth, for the Chairs

--

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 8 Dec 2020 13:51:58 +0100

> They are?  Some are, some are added as MIME parts.

The Content-Type: of the added MIME part, in that case.

> software with a vast array of configuration options.

The idea of the draft is that being reversible is a MLM configuration option.

The simplest case is that of lists that don't modify messages at all.  Nothing 
to revert in this case.

We can extend that case so as to include the addition of a simple footer and a 
subject tag.  That way, at least, we can discuss DMARC standardization on a 
DMARC-compliant mailing list.

Best
Ale
--