[Mailman-Developers] MIME footers

[Daniel Kahn Gillmor]

Hi Murray--

On Fri 2015-02-27 14:46:40 -0500, Murray S. Kucherawy wrote:
> Sorry, by "sign" I meant "add a footer".  I probably said "sign" because
> this is related to some DKIM work I've been planning, and the morning's
> caffeine was already wearing off.

:)

> Thanks for that detailed answer (and Barry for his followup).  It's
> precisely what I was looking for.
>
> How absurd would it be to propose a flag for Mailman that would take your
> first case (non-MIME, or single-part text/plain) and convert it to a
> multipart/mixed with a child part of the original text/plain, and then
> apply the algorithm you have?

I'm not one to make any decisions for mailman, but this sounds pretty
reasonable to me.  In fact, the only argument against ever having such a
switch *not* set is that non-MIME-aware text-only MUAs will now see some
crufty MIME boundaries in the message that they didn't see before.

I'd bet the number of users of non-MIME-aware text-only MUAs receiving
mail from mailman that are incapable of wading through a bit of extra
MIME boundary info on otherwise text/plain messages is vanishingly
small.  Most of those folks are probably at least used to seeing it as a
result of the overwhelming predominance of multipart/alternative on
today's SMTP network.

> The impetus here is DKIM survivability across lists.  Suppose we had a DKIM
> canonicalization that was MIME-aware, so that it could sign the specific
> MIME parts or sets of parts.  That signature would fail on the message as a
> whole -- with the footer part added -- but could in theory pass if an
> appended part were omitted from canonicalization.  To put it in context,
> suppose there were a DKIM canonicalization where the signer signed (using
> your examples) the CDE message; the receiver gets FGHI which fails, but
> also has enough information to know that merely verifying FGH will pass; it
> then knows that FGH was "legitimate" and I was added post-signing, and may
> or may not be "safe" (for some value thereof) content.
>
> What I'm worried about with such a design is the trivial text/plain
> message.  Obviously merely appending the footer destroys any hope of
> validating only the original content.  We'd have to entertain the idea that
> Mailman would make the simple message into a multipart/mixed + text/plain,
> then append the footer part and sign that; the verifier would drop the
> footer and then strip off the MIME to see if it can verify the original
> signature that way.  That seems like its easy to get wrong, though it's
> likely to be a very common case.

right, the MIME boundaries provide the parsing framework to enable this
kind of sub-part DKIM-verification.

One issue this process brings up is that it's now necessary to treat
pretty much every part of the message as though it is
multipart/signed -- that is, it needs to be handled bytewise opaquely,
on pain of breaking the DKIM header.

We already know that there are tools that do things like re-encode
messages from base64 to q-p, or change character sets, or just re-flow
long lines (FSVO "long") in the mime boundary subheaders.  They're not
supposed to do this with multipart/signed messages, because the RFCs
point out that opaque handling is required, but they sometimes break
them anyway.  I imagine the same risk would now apply to all DKIM-signed
messages using your scheme.

With that caveat in mind, it's clear that without your proposal, all
DKIM-signatures of messages with footers will break anyway.  So this
does seem to be a strict improvement, even if there are a few corner
cases that aren't fully covered.

      --dkg