Subject: [dmarc-ietf] Reversing modifications from mailing lists

From: Wei Chuang <[email-masked]>
Date: Mon, 22 Nov 2021 15:28:01 -0800

Hi all,

[Standard disclaimer, that the comments below are my own and don't
represent my employer at all]

I saw Ale's draft draft-vesely-dmarc-mlm-transform
<https://datatracker.ietf.org/doc/html/draft-vesely-dmarc-mlm-transform> in
the ARC list, and wanted to discuss some of the ideas.  Just to put in
context my points- My understanding is we have to trust the forwarders to
use the ARC authentication results, which we might not have because the
forwarder is new, or has low volume.  Moreover mailing lists do much of the
modifications that break DMARC.  This is a common enough scenario that I
think it's useful to consider alternatives such as the ideas found in Ale's
draft.  The numbered bullets are ideas summarized from Ale's draft, and
asterix * bullets are my comments about that.

1. Ale's draft suggests not reversing all possible transforms, and rather
focuses on a subset caused by mailing lists that are reversible
  * Could ARC be suitable for those other scenarios? Could we expect that
forwarders that do more substantial irreversible rewriting such as
modifying URLs in a spam/phishing filter MTA, already have a strong
relationship with the receiver?  Presumably, might they be trusted by the
receiver and their ARC result could be used?
2. Footers must only be added with as a) append on single text/plain part
b) mime part appended to multipart/mixed c) mime wrap where a footer is
added in a new multipart/mixed.
  * It's not very clear to me how Ale's draft handles the b) and c)
scenario.   (There is mention of "reason="transformed"", but this still
seems incomplete)  I saw that Murray has a draft
draft-kucherawy-dkim-list-canon
<https://datatracker.ietf.org/doc/html/draft-kucherawy-dkim-list-canon> that
identifies addition of new mime parts that could be helpful there.
3.  Footers added to text/plain must be identified with at least four "_"
as a separator.
  * Would the DKIM length "l=" field be helpful?  Understood there are
abuse risks.
4. "quoted-printable encoding must not be used for... single-part
text/plain messages, as it is impossible to guess original soft line breaks
after re-encoding"
   * Are you suggesting quoted printable encoding aren't fully reversible?
Actually, could the RFC2045 canonical encoding of the message be used as
the source for doing the DKIM content hashing?  This would bypass having to
worry about additional transfer re-encodings by forwarders.
5. Finding the original FROM by looking at From, Author, Original-From,
X-Original-From, Reply-To, and Cc.
  * Can this be standardized to a fixed location such as Author?  (Sorry
I'm unfamiliar with the discussion on Author)
6. Subject
  * Agreed that some simple heuristic as proposed in the draft is a good
approach.  Perhaps the original subject suffix length also might work here
too.

Comments and discussion are very much welcome.
-Wei

---

From: "John Levine" <[email-masked]>
Date: 23 Nov 2021 15:34:05 -0500

It appears that Wei Chuang  <[email-masked]> said:
>the ARC list, and wanted to discuss some of the ideas. ...

Please humor me for a moment while I turn the clock way back to 1958.

Fortran and Cobol had shown that compilers worked, and people were busy
writing compilers for lots of languages for lots of computers.  But that
was a daunting amount of work, N languages for M computers is NxM compilers.

Mel Conway, best known for the law "Organizations, who design
systems, are constrained to produce designs which are copies of the
communication structures of these organizations", published a paper
proposing a Universal Computer Oriented Language or UNCOL.  The front
end of each compiler would translate from Fortran or whatever to UNCOL,
and the back ends would translate from UNCOL to IBM 7070 machine code
or whatever, reducing the work from NxM to N+M.

Work started with great enthusiasm in the early 1960s, and people
produced UNCOLs that could handle one or two input languages, and one
or two output machine codes, and reported great success. But they
found that every new input language or output machine required more
and more special cases which swamped whatever was supposed to be
common, and UNCOL experienced heat death, was quietly shelved and forgotten. 

The Open Software Foundation had an ANDF, Architecture Neutral
Distribution Format around 1989.  They were very offended when I said it
sounded just like UNCOL, but it died the same way.

This proposal is UNCOL for mailing lists. Can you come up with a demo
that handles a few common changes that Mailman makes? Sure. How about
if you add the slightly different changes that Sympa makes? Probably.
What about LISTSERV and phpList and ezmlm and listproc and groups.io
and Google Groups and Yahoo Groups and body headers and MIME footers
and all the other things that mailing lists do?  Maybe not.

Uh, perhaps we could focus on how to get ARC more widely adopted,
since it has the advantage of not making any unrealistic assumptions
about what changes lists might make.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 24 Nov 2021 12:00:18 +0100

> sounded just like UNCOL, but it died the same way.

The GNU Compiler Collection includes front ends for C, C++, Objective-C, 
Fortran, Ada, Go, and D.  It doesn't cover all languages, but it's still alive.

> and all the other things that mailing lists do?  Maybe not.

Without going beyond Mailman lists, some of them remove DKIM signatures 
altogether, so there is no chance to recover anything.

For the M computers part of the equation, we may match the metaphor by 
considering authors' domains signing practices.  Thus far, I basically see just 
two sets, those who sign rfc6376-recommended fields, and those who sign 
transport-specific fields like MIME-Version, Content-Transfer-Encoding and 
Content-Type.  The latter cannot be recovered.

This is a striking difference w.r.t. UNCOL.  There are cases where it makes no 
sense to try to cover them.  So the above proposal is not an attempt at a 
universal solution for indirect mail flows.  Rather, it says that if people 
really want to set up an authenticated indirect mail flow, there is a way to do it.

> about what changes lists might make.

ARC implies a reliable global reputation system, which only giant providers can 
afford.  In addition, rfc8617 doesn't even consider From: rewriting and how to 
undo it.  It is a different thing, used for different purposes, and focusing on 
it doesn't preclude recovering original signatures.

Thanks for the flashback, anyway

Best
Ale
--

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 24 Nov 2021 12:00:43 +0100

Hi,

On Tue 23/Nov/2021 00:28:01 +0100 Wei Chuang wrote:
> forwarders that do more substantial irreversible rewriting such as modifying 
> URLs in a spam/phishing filter MTA, already have a strong relationship with the 
> receiver?  Presumably, might they be trusted by the receiver and their ARC 
> result could be used?

Sure.  Note that if the receiver trusts the MLM, simply recognizing it would be 
enough to pass DMARC per the "mailing_list" policy override.  ARC additionally 
provides the ability to learn the authentication status of the message when it 
was received by the MLM.  That way, reputation can be reckoned with great 
precision.

> 2. Footers must only be added with as a) append on single text/plain part b) 
> mime part appended to multipart/mixed c) mime wrap where a footer is added in a 
> new multipart/mixed.
>    * It's not very clear to me how Ale's draft handles the b) and c) scenario.  
>   (There is mention of "reason="transformed"", but this still seems incomplete) 
>   I saw that Murray has a draft draft-kucherawy-dkim-list-canon 

I tried and implemented Murray's draft, but it requires that MLMs declare which 
transformation they do.  Since they don't, you need a pre-parser that guesses 
the transformation type.  That's the difference between the two drafts.

If there are two top-level MIME parts, the transformation must be (c), because 
no one writes a MIME structure with just one part.  Otherwise it's (b).

> 3.  Footers added to text/plain must be identified with at least four "_" as a 
> separator.
>    * Would the DKIM length "l=" field be helpful?  Understood there are abuse 
> risks.

Yes, l= could be a useful hint.

The risk of l= is that an attacker could exploit a poor HTML interpreter to add 
a part that completely hides the original content when rendered.  Requiring 
attachments to be plain text avoids that risk.

> 4. "quoted-printable encoding must not be used for... single-part text/plain 
> messages, as it is impossible to guess original soft line breaks after re-encoding"
> Actually, could the RFC2045 canonical encoding of the message be used as the 
> source for doing the DKIM content hashing?  This would bypass having to worry 
> about additional transfer re-encodings by forwarders.

Mailman can copy MIME structures without changes, but simple text is often 
re-encoded.  Many messages on this list are converted to base64.  If the 
original text was quoted printable, its form depends on the agent.  An agent 
can choose where to break lines, whether to encode some characters or represent 
them as ASCII, whether to break lines at column 76 or, to increase readability, 
at white spaces.  That can vary too widely.

>    * Can this be standardized to a fixed location such as Author?  (Sorry I'm 
> unfamiliar with the discussion on Author)

That's exactly the purpose of Author.  However, no one is using it yet.

> approach.  Perhaps the original subject suffix length also might work here too.

I don't get this, I'm afraid.  What is the subject suffix length?

Best
Ale
--

---

From: Douglas Foster <[email-masked]>
Date: Wed, 24 Nov 2021 07:11:16 -0500

If you are evaluating messages, you are free to use any strategy that seems
worth your effort.

However, if you are the sender of messages that cannot produce DMARC PASS,
you have a bigger problem.  You need an algorithm which can be trusted to
usefully distinguish between malicious and non-malicious senders, and has
an expectation of widespread implementation.   I don't think such an
algorithm exists.

For the evaluator, we need to consider diminishing returns on effort.
 First, I discard any messages from senders with bad reputations, then I
discard messages with bad content, then I allow messages that pass sender
authentication.   What is left is a set of messages which have no visible
problems but which might (or might not) represent malicious impersonations
of a legitimate sender.   How much additional processing power is required
to achieve how much improved decision-making?

It might be useful to parse the RECEIVED chain to look for known-bad IP
addresses or DNS names, but it is not an easy algorithm.   It might be
possible to develop a reliable NP rule that blocks messages with domain
names that are unregistered or not used for email, but we are not there yet
and those messages are likely to be a small subset of the problem.

Attempts at additional granularity will encounter problems like "Can I
reliably identify messages that were forwarded?" and "Can I reliably
identify messages that come from a mailing list?"   Not easily.

Of course, one can choose "Always Block" as AOL has done, or choose "Always
Allow", as I suspect many others have done.   Neither approach is optimal.

At some point, the best answer comes from actually looking at the message
to answer the question, "Is this a message that I want?"   Once an answer
is obtained, I need to create a local policy rule which implements my
answer for all future messages that have the same fingerprint.   We have
never described the exception process, and as a result many products have
exception mechanisms that are inadequate and inappropriate.  I believe that
a document which describes the exception process will be the best that we
can do and will be a big step forward.   I have begun experimenting with
drafts, but am not ready to submit one yet.

Doug Foster

On Mon, Nov 22, 2021 at 6:28 PM Wei Chuang <weihaw=
[email-masked]> wrote:

> <https://datatracker.ietf.org/doc/html/draft-vesely-dmarc-mlm-transform>
> in the ARC list, and wanted to discuss some of the ideas.  Just to put in
>    * Are you suggesting quoted printable encoding aren't fully
> reversible?  Actually, could the RFC2045 canonical encoding of the message
> be used as the source for doing the DKIM content hashing?  This would
> bypass having to worry about additional transfer re-encodings by
> forwarders.
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: "John Levine" <[email-masked]>
Date: 24 Nov 2021 11:22:51 -0500

>Fortran, Ada, Go, and D.  It doesn't cover all languages, but it's still alive.

Sure and it's not an UNCOL. The front ends are mostly common from one
machine to the next but there are plenty of local tweaks. It also
helps that all of those languages have similar semantics. Try Cobol or
Lisp.

>> This proposal is UNCOL for mailing lists. ...

>altogether, so there is no chance to recover anything.

I don't understand that comment unles you're pointing out another reason that
your proposal is not worth working on.

>ARC implies a reliable global reputation system, ...

No, it does not.  You know better than that.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 24 Nov 2021 11:30:08 -0500

>was received by the MLM.  That way, reputation can be reckoned with great 

If you trust the mailing list, you can just have a whitelist and
completely ignore DMARC. If only.

Someone else from Google told me that they know perfectly well where
all the mailing lists are but they cannot do that because many lists
leak spam when spammers steal address books and send spam with
a fake From: of a subscriber. ARC specifically addresses this
situation by letting the recipient do the filtering that the list
didn't, e.g., reject unaligned input messages.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 24 Nov 2021 20:05:04 +0100

On Wed 24/Nov/2021 17:22:51 +0100 John Levine wrote:
> I don't understand that comment unless you're pointing out another reason that

Why?  DKIM says signatures SHOULD NOT be removed, so a MLM may opt for not 
letting existing signatures through.  They may also anonymize posters.

Likewise, users may opt to sign in such a way as to grant that MLM-transformed 
messages won't verify by any means.

Reversibility is an opt-in.  However, people who don't want indirect mail flows 
to be authenticable, should not complain that DMARC disrupted the end-to-end 
nature of the From: identifier.  They can choose.

> No, it does not.  You know better than that.

Yet, the proposal to accept and validate any possibly faked message as if it 
passed DMARC is not acceptable.  It completely voids DMARC's meaning.

Best
Ale
--

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 24 Nov 2021 20:06:12 +0100

> completely ignore DMARC. If only.

Including the accepted message in aggregate reports with proper indications is 
not ignoring DMARC.

> didn't, e.g., reject unaligned input messages.

I don't understand that.  If the message was rejectable of quarantinable why 
did the MLM pass it?  It looks as if the MLM implements ARC but not DMARC.

Best
Ale
--

---

From: Baptiste Carvello <[email-masked]>
Date: Wed, 24 Nov 2021 21:54:41 +0100

Hi,

Le 24/11/2021 à 12:00, Alessandro Vesely a écrit :
> 
> ARC implies a reliable global reputation system, which only giant 
> providers can afford.

Not necessarily. It only imply that the evaluator has some reason to 
consider acceptable that this particular message be handled by this 
particular forwarder.

If, for example, the evaluator can know for sure that the author 
designated in the From field really sent a message to the forwarder 
immediately before the forwarded message came in, the probability that 
the message is genuine is much higher [1].

Beginning of this month, I proposed an idea to achieve just that.

Cheers,
Baptiste

note [1]:
indeed, the attack model then changes from "send a message with a faked 
 From header" (easy) to "somehow have your target send you a genuine 
message so you can modify and forward it" (possible, but much harder, 
needs a targeted attack). Only high profile targets need to care about 
the second type of attack.

---

From: Douglas Foster <[email-masked]>
Date: Wed, 24 Nov 2021 17:18:36 -0500

Have you noticed the ARC set on Alex Brotman's messages?   Microsoft
declares the message as having passed DMARC before the message leaves the
Office 365 environment.  Assume that the average attacker decides to do the
same, and applies a DMARC-PASS ARC Set to everything he sends.   At
minimum, the evaluator needs an algorithm to determine if the ARC Set was
applied before or after a meaningful point in the delivery chain.    Do we
have a defined algorithm for that?

You are correct that a single sender can be whitelisted with the help of
ARC, but a single sender can be whitelisted more easily without ARC.

ARC requires a global reputation system so that the appropriate disposition
is known in the general case of ANY message source.    Ale's assertion
stands.

Doug Foster

---

From: Wei Chuang <[email-masked]>
Date: Thu, 25 Nov 2021 00:07:36 -0800

Thanks for the feedback and answers.

On Wed, Nov 24, 2021 at 3:01 AM Alessandro Vesely <[email-masked]> wrote:

> modifying
> scenario.
> abuse
> text/plain
> reversible?
> the

If the RFC2045 canonical representation at the final destination can be the
same as the canonical representation at the original sender, (and assuming
there isn't some content modification like adding inline footers etc). then
that might be a way of side stepping some of the issues with quoted
printable encoding.  Understood that would be a departure from DKIM/ARC
hashing and verification.

> I don't get this, I'm afraid.  What is the subject suffix length?

Sorry I wasn't too clear here.  It's largely the same idea as the DKIM body
length "l=" field above except for reformulated for the Subject header and
its mailing list mutations.  The original sender would encode a length of
the original subject say "s.l=<value>".  A receiver would only hash the
right most "s.l=<value>" length string when validating a Subject hash from
the original sender.  This assumes that mailing lists may prepend a string
typically for identification.

thanks again,
-Wei

---

From: Wei Chuang <[email-masked]>
Date: Thu, 25 Nov 2021 00:42:04 -0800

On Tue, Nov 23, 2021 at 12:34 PM John Levine <[email-masked]> wrote:

> in

Understood there is a lot of complexity in this space.  On the other hand
there doesn't seem to be a complete solution to email authentication with
regard to content modification by email forwarders.  The result is that
DMARC adoption is low despite its benefit in preventing important classes
of email impersonation.  I guess it makes sense that a lot of these are
experimental, and that hopefully one of these will emerge to be the best,
and thereby make the other techniques redundant, and clean up some of the
complexity.

> about what changes lists might make.

There ought to be a thread trying to figure out why that is.  (FWIW as
mentioned in the other thread, IMO there are places where ARC makes more
sense to use, hence should figure this out)
-Wei

---

From: "John R Levine" <[email-masked]>
Date: 25 Nov 2021 13:17:49 -0500

> of email impersonation.

Huh?  DMARC is nearly universal among commercial senders.  It's not widely 
adopted among mail systems with human users but it was never supposed to 
be.

Remember that AOL and Yahoo only turned on p=reject after they each had 
all their users' address books stolen, spammers were forging mail with 
addresses that the recipients knew, and they used DMARC to force the cost 
of their security failures on the rest of the Internet.

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

---

From: "John Levine" <[email-masked]>
Date: 25 Nov 2021 23:29:45 -0500

It appears that Wei Chuang  <[email-masked]> said:
>same as the canonical representation at the original sender, ...

When we were working on DKIM canonicalization we had lengthy discussions about
what to do about MIME and we decided not to even try.  There is no canonical
representation of a MIME message and nobody to my knowledge has ever tried to
describe what it would mean for two MIME messages to be equivalent, since they
could vary in a fantastic number of ways.  Part separators can change, the
pieces of multipart/whatever might change, line breaks in quoted-printable
and base64 can change, spacing and capitalization of headers can change, and
that's just what I can think of in two minutes.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 26 Nov 2021 09:03:33 +0100

> Thanks for the feedback and answers.

You're welcome

>>> [...]
>>> approach.  Perhaps the original subject suffix length also might work 
>>> here too. >>

Oh, yeah.  However, unless we store sl= as an additional DKIM tag, we'd need an 
extra header field such as Subject-Length.  In that case, Original-Subject is 
much more straightforward.

Original-Subject also covers possible AW: to Re: translations.

Finally, the MLM prefix must be short.  It is not acceptable to have an entire 
phrase followed by hundreds of white space before the original subject.

Best
Ale
--

---

From: [email-masked]
Date: Sat, 27 Nov 2021 19:04:34 -0800 (PST)

> what to do about MIME and we decided not to even try.

A mistake IMO.

> There is no canonical
> could vary in a fantastic number of ways.

First, a caonnical form doesn't have to produce a 100% reliable equivalency
test in order to be useful.

Second, there can be more to a hash computation than a canonical form. This
is especially true given that a MIME message is a tree.

> Part separators can change, the

If you treat the message as a Merkle tree with:

o Separate header and body hashes
o Decoding message bodies prior to hashing
o Applying the already-defined unfolding/capitalization stuff from DKIM
  to part headers.
o Removing the CTE field and boundary value from CT fields in the header

You end up with a value that's:

o Invariant in regards to part separator changes
o Invariant in regards to CTE changes
o Invariant in regards to many/most common header changes 
o Allows for rapid computation of hashes for large numbers of large messages
  that share common content.

Which I note takes care of your list.

But the question is, as always, whether or not defining such a thing is worth
the trouble. At this point I think the answer is "no".

				Ned

---

From: Wei Chuang <[email-masked]>
Date: Sun, 28 Nov 2021 15:31:06 -0800

> Which I note takes care of your list.

This approach and benefit was what I was thinking could be feasible as
well.  The cited draft-kucherawy-dkim-list-canon
<https://datatracker.ietf.org/doc/html/draft-kucherawy-dkim-list-canon>
draft notes
your contribution to the concept described there i.e. to perform hashing as
a mime-tree (though that draft doesn't do content transport decoding).

> the trouble. At this point I think the answer is "no".

What type of concern do you have?  Is it algorithmic complexity?  Or
runtime or header size overhead?

-Wei

---

From: Dave Crocker <[email-masked]>
Date: Sun, 28 Nov 2021 15:38:49 -0800

> runtime or header size overhead?

Biggest concern, for changing anything that has a significant installed 
base of use and users, is their willingness to make the changes.

They have to see a compelling case for the time, effort and expense.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

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

---

From: "John Levine" <[email-masked]>
Date: 28 Nov 2021 22:03:57 -0500

>> what to do about MIME and we decided not to even try.

This was part of the discussion about what sort of body modifications
to allow. We ended up with optionally ignoring white space changes,
and l= to ignore added text. My impression is that neither is useful.
Very few messages pass with relaxed canonicalization that don't also
pass strict. The goal of l= was to allow mailing lists to add footers,
but as we've seen in this discussion, if a list adds a footer it's
likely to make other changes too.  I think the main use case for
relaxed mode was an old bug in sendmail that added an extra \r\n
on the way through, but it's long gone.

For MIME, the question wasn't just whether two versions of messages
were equivalent, but the impossible question of what other changes
keep the message "the same" and which are too different. As you note
there are lots of ways that a message could be recoded into equivalent
MIME parts, but again it is my impression that those sorts of changes
are rare without also adding or removing body parts which gets us into
the swamp of how different is too different. So we didn't try.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 29 Nov 2021 10:51:43 +0100

On Mon 29/Nov/2021 04:03:57 +0100 John Levine wrote:
> This was part of the discussion about what sort of body modifications to
> allow. We ended up with optionally ignoring white space changes, and l= to
> ignore added text. My impression is that neither is useful. Very few
> messages pass with relaxed canonicalization that don't also pass strict.

Using relaxed rather than strict is quite different between header and body. 
It is fairly frequent to find reflowed headers, especially with MLM handling, 
while bodies remain mostly untouched, except for CR additions and removals.

Of course, X-MIME-Autoconverted rewrite bodies beyond strict/ relaxed range. 
(That's the original mistake.)

> The goal of l= was to allow mailing lists to add footers, but as we've seen
> in this discussion, if a list adds a footer it's likely to make other
> changes too.

It'd be enough to add the subject tag on new messages to address the other 
changes.  Using l= works well with a wide range of mailing lists.  However, it 
only works with plain text.

Best
Ale
--

---

From: "John R Levine" <[email-masked]>
Date: 29 Nov 2021 09:17:45 -0500

> (That's the original mistake.)

Well yeah, welcome to mail UNCOL land.

> changes.  Using l= works well with a wide range of mailing lists.  However, 
> it only works with plain text.

I suppose if by wide range you mean lists that do not add subject tags and 
do not handle html or multipart bodies.  That may be common among nerd 
lists but take a look beyond mailman and I don't think it is.

Regards,

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 29 Nov 2021 23:27:34 -0800

On Thu, Nov 25, 2021 at 12:07 AM Wei Chuang <[email-masked]> wrote:

> Sorry I wasn't too clear here.  It's largely the same idea as the DKIM
> body length "l=" field above except for reformulated for the Subject header
> and its mailing list mutations.  The original sender would encode a length
> of the original subject say "s.l=<value>".  A receiver would only hash the

Seems to me that means I could insert anything I want before the last N
octets of Subject -- say, a URI pointing you to an ad or other unsavory
content -- and the original signature will verify.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 29 Nov 2021 23:29:00 -0800

On Sun, Nov 28, 2021 at 3:31 PM Wei Chuang <weihaw=
[email-masked]> wrote:

> <https://datatracker.ietf.org/doc/html/draft-kucherawy-dkim-list-canon> draft notes

It does, in Section 3.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 30 Nov 2021 11:39:36 +0100

> Well yeah, welcome to mail UNCOL land.

Those conversions used to afflict direct mail flows as well.

> I suppose if by wide range you mean lists that do not add subject tags and do 
> not handle html or multipart bodies.  That may be common among nerd lists but 
> take a look beyond mailman and I don't think it is.

OTOH, it'd feel cringing to discuss the standardization of solutions to deal 
with indirect mail flows using a mailing list where neither of those solutions 
apply.

Best
Ale
--

---

From: Wei Chuang <[email-masked]>
Date: Tue, 30 Nov 2021 08:59:18 -0800

> content -- and the original signature will verify.

Agreed the original signature will verify.  We could also encourage
resigning by forwarders as done in your list-cannon draft in section 5 and
with a new "s.l=" field value, in which case we can determine who added the
URI to the subject in the above example.  Partially signed messages i.e.
signed by the original sender but not the forwarder might be treated with
more suspicion, than messages with full coverage.

-Wei

---

From: Wei Chuang <[email-masked]>
Date: Tue, 30 Nov 2021 08:59:43 -0800

>> a mime-tree (though that draft doesn't do content transport decoding).

Got it.  Sorry I missed that.

-Wei

---

From: Wei Chuang <[email-masked]>
Date: Tue, 30 Nov 2021 09:26:08 -0800

On Tue, Nov 30, 2021 at 2:40 AM Alessandro Vesely <[email-masked]> wrote:

> to
What about adding a footer to some html mime part is poorly handled when
using "l="?  Multipart bodies could be handled by other techniques.
-Wei

---

From: "John R Levine" <[email-masked]>
Date: 30 Nov 2021 12:30:39 -0500

> using "l="?  Multipart bodies could be handled by other techniques.

See section 8.2 in the DKIM spec which says if you use l= you need to be 
careful with your MIME boundaries so naughty people can't add another part 
that overlays the real message.

I have seen lists that edit the footer into the HTML of the body, I think 
at Yahoo groups.  Don't see how you're going to describe that in a 
reversible way.

Regards,

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 30 Nov 2021 19:04:59 +0000

>at Yahoo groups.  Don't see how you're going to describe that in a 

Or, we could stop trying to design a DKIM replacement and work on DMARC.

Scott K