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
_______________________________________________
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives:
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe:
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
Security Policy: http://wiki.list.org/x/QIA9
