On Mon 06/Jul/2020 11:24:19 +0200 Murray S. Kucherawy wrote:
> On Mon, Jul 6, 2020 at 1:49 AM Alessandro Vesely <[email protected]> wrote:
>
>> For multipart messages, transformations may need to replace boundaries.
>> In that case, the "restricted patch" to undo the transformation may
>> require more data than it is convenient to store in a DKIM tag. >>
>
> Replace why? It might need to add its own, but it's easy to undo that.
Oops, I thought MLM generated boundaries anew. It seems that's not the case.
Depends on the MLM and what it is doing. For example, boundary marker
regeneration can happen if you're adding a header or a footer to a multipart
message.
Still, the original Content-Type is difficult to reproduce exactly. You need
to know whether the boundary= parameter is written as a token or a
quoted-string, and, if not c=relaxed, spaces and newlines. If longer than a
few bits, the info to undo the transformation (a reverse patch?) could be
stored in its own field, or even in an attachment.
Another difficulty, IIRC, is reordering of To:. This can simply be avoided.
> In order to be useful, this only needs to do what MLMs commonly do
> already. We don't need to cover the universe of possible futures right
> away.
Agreed. MLMs code has no lack of conditionals. Probably this technique can
address a class of mailing lists somewhat wider than the "no-changes" class,
without trying to cover even one half of /present/ MLM possibilities. Shall
say just enough to cover IETF mailing lists?
The problem is that list software wasn't designed with the idea of keeping
changes to an invertible/removable minimum in mind. So you're going to see
many/most of the transformations this document deals with done in ways other
than what the document describes. So in order to make use of this document
you're basically talking about a fairly major rewrite.
I think that's unlikely to happen.
Ned
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
