Re: [dmarc-ietf] Apropos of the de-munging draft
On 2020-08-02 7:51 p.m., John Levine wrote: > In article you write: >>> Unwrapping a MIME attachment is a lot easier than the proposed DKIM >>> unmunging but I doubt either is going to show up in MUAs any time >>> soon. Perhaps you could do it in a mail gateway. >> >> >> Looking at the steps required to carry out the proposed unmunging, "a lot >> easier" doesn't seem to be an accurate measurement. > > In python it's about two lines since there are well debugged libraries to > handle MIME. Same in most other languages. If you use a library, most common operations can be done better than unusual ones, the actual complexity notwithstanding. The steps I outlined for tf=footer[*] can be done adding a few lines to Murray's library, in C. > I still would be amazed if any MUAs did this, also keeping in mind that the > changes that MLMs make ARE USEFUL. Agreed. IMHO, Murray's lib should do just a virtual unmunge, while canonicalizing. To actually replace From: with the original Author: can be done by the MDA, based on trusted A-Rs, after any dot-forward. Best Ale -- [*] https://mailarchive.ietf.org/arch/msg/dmarc/2ZN7DS5NktoyEPItZ5vzr-xd0Mc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Apropos of the de-munging draft
Looking at the steps required to carry out the proposed unmunging, "a lot easier" doesn't seem to be an accurate measurement. In python it's about two lines since there are well debugged libraries to handle MIME. Same in most other languages. I agree, the code to do this is easy and well tested, and it works so long as the MLM is doing the mutation in exactly the same way the verifier will undo it. The concern comes down to two different MIME library implementers disagreeing on their choices for where an extra newline might be helpful, for example. I was actually thinking of wrapping the original message as an attachment, sort of like a one-message digest. You can always recover the original message, the problem is that MUAs display attached messages badly, and if you unwrap you lose the useful changes the list manager makes like subject tags and footers with unsubscribe instructions. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Apropos of the de-munging draft
On Sun, Aug 2, 2020 at 10:51 AM John Levine wrote: > >Looking at the steps required to carry out the proposed unmunging, "a lot > easier" doesn't seem to be an accurate measurement. > > In python it's about two lines since there are well debugged libraries > to handle MIME. Same in most other languages. > I agree, the code to do this is easy and well tested, and it works so long as the MLM is doing the mutation in exactly the same way the verifier will undo it. The concern comes down to two different MIME library implementers disagreeing on their choices for where an extra newline might be helpful, for example. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Apropos of the de-munging draft
In article you write: >> Unwrapping a MIME attachment is a lot easier than the proposed DKIM >> unmunging but I doubt either is going to show up in MUAs any time >> soon. Perhaps you could do it in a mail gateway. > > >Looking at the steps required to carry out the proposed unmunging, "a lot >easier" doesn't seem to be an accurate measurement. In python it's about two lines since there are well debugged libraries to handle MIME. Same in most other languages. I still would be amazed if any MUAs did this, also keeping in mind that the changes that MLMs make ARE USEFUL. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Apropos of the de-munging draft
On 2020-07-29 1:41 a.m., John R Levine (quoting Jesse) wrote: > >> I think that draft-kucherawy-dkim-transform-02 is getting at what >> I was originally thinking. In my opinion, MLMs will *always* need >> to munge, because they will never know if an arbitrary receiver >> will trust their non-munged mail. Giving the receivers a way to >> un-munge (if they can and/or want and/or trust) would be a >> productive path forward out of this situation.> > We already have a couple of ways to do reversible message munging, > starting with MIME message wrapping. In principle it works fine, in > practice it's awful because MUAs don't show wrapped messages > consistently and often in ways that are painful, e.g., you can see the > original author address but there's no button you can push to respond > to it. > > Unwrapping a MIME attachment is a lot easier than the proposed DKIM > unmunging but I doubt either is going to show up in MUAs any time > soon. Perhaps you could do it in a mail gateway. Looking at the steps required to carry out the proposed unmunging, "a lot easier" doesn't seem to be an accurate measurement. Actually, reversing the tf=footer is simpler than unwrapping a message/rfc822 attachment.[*] The major difficulty is for MLMs to produce modifications that consist of the allowed transformations _only_. Perhaps, it is a lot easier to create a message/rfc822 without breaking its signatures...? From: rewriting in particular should be added to the set of allowed transforms. The MLM should make sure the Author: field mirrors the original From: exactly. Then it rewrites From:. It may seem redundant to set a tf= tag on the one hand and undo transforms on the other, since a munged From: is enough to pass. However, if receivers send aggregate reports back to the MLM, we can hope that one day they'll all succeed and the MLM can stop rewriting From:. In the interim, an MX which verified the original signature up to allowed transforms can replace the value of From: with that of Author:. This action is legitimate if all agree that the only reason why MLMs rewrite From: is to pass DMARC checking. I'd leave footers and subject tags in place. Best Ale -- [*] https://mailarchive.ietf.org/arch/msg/dmarc/2ZN7DS5NktoyEPItZ5vzr-xd0Mc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Apropos of the de-munging draft
[ sent last week but got stuck due to a laptop upgrade which helpfully reset all my mail settings to the defaults ] I think that draft-kucherawy-dkim-transform-02 is getting at what I was originally thinking. In my opinion, MLMs will *always* need to munge, because they will never know if an arbitrary receiver will trust their non-munged mail. Giving the receivers a way to un-munge (if they can and/or want and/or trust) would be a productive path forward out of this situation. We already have a couple of ways to do reversible message munging, starting with MIME message wrapping. In principle it works fine, in practice it's awful because MUAs don't show wrapped messages consistently and often in ways that are painful, e.g., you can see the original author address but there's no button you can push to respond to it. Unwrapping a MIME attachment is a lot easier than the proposed DKIM unmunging but I doubt either is going to show up in MUAs any time soon. Perhaps you could do it in a mail gateway. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
