On Mon 06/Jul/2020 19:17:42 +0200 ned+dmarc wrote:
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.
So that kind is going to go among forbidden transformations.
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.
Yet, setting no-changes does guarantee no breakage occurs. Hm... does it? I
didn't carry out thorough tests.
Looking at my own messages to this list, which are signed with l=, I see my
DKIM signatures are broken intermittently. It would be enough to turn off
base64 encoding. It is no major rewrite...
I think that's unlikely to happen.
Which is probably why this draft was let expire.
Best
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
