Hi all,
there's been quite some discussion about signature breaking in indirect mail
flows. Rewriting the From: header field seems to be the most popular
workaround. Yet, it is possible to undo the transformation that Mailman put in
place, thereby validating the original DKIM signature. I have a few questions
about this.
That technique is described by the DKIM Transformations draft[*]. It considers
a number of reversible transformations, such as adding a footer or adding a
mime part containing a footer. I implemented a utility to carry out that task,
and it works in a good deal of cases. However, it fails in some cases.
Mailman carries out some irreversible changes, such as rewriting To: or Cc:
changing the order of the mailboxes, or rewriting Content-Transfer-Encoding:
irrespective of quotation marks and case (for example "7bit" even if the
original, signed field was spelled as "7Bit"). I guess this behavior is coded
deeply in Python libraries, but would like to know developers' opinions. Is
that something that could be fixed?
The second question is about producing a hint to the verifier telling which
transformation(s) have been applied to the message. That would come as an
additional header field, for example:
DKIM-Transform: footer
or as an extra tag in a DKIM signature, for example:
DKIM-Signature: v=1; (...) tf=footer; (...)
That hint could spare the verifier one pass over the message. Is it something
that could be implemented? If not, I'd try guessing, according to this scheme:
outermost Content-Type: | first entity Content-Type: | transformation |
------------------------+-----------------------------+-----------------+
text/plain | any | footer |
------------------------+-----------------------------+-----------------+
multipart/mixed | multipart/mixed | add-part |
------------------------+-----------------------------+-----------------+
multipart/mixed + any other | mime-wrap |
------------------------+-----------------------------+-----------------+
any other | any | non-reversible |
------------------------+-----------------------------+-----------------+
Does that look correct?
I know that Mailman has many more features that can hardly be amenable to a
fixed set of easily reversible transformations. The point is to be able to
preserve DMARC for /some/ mailing lists which care to do so. Currently, there
are mailing lists which don't do any change, not even subject tags, in order to
avoid breaking DKIM signatures. A somewhat Procrustean solution.
I don't think From: rewriting is going to be disabled any time soon. Of
course, the original From: must be known in order to validate the original
signature. In this respect, I'm hesitant about using Reply-To:. I read in the
wiki the original content of From: /may/ be added to Reply-To: or to Cc:. In
addition, Reply-To: usually comes after From:, thereby requiring to go back to
change already parsed fields. As an alternative, I'd provide for yet another
field to be put near the top of the header. Original-From:, say. This may
seem redundant, however it serves a different goal. In addition, if the
Original-From: is put in place by the original signer, it ratifies its
knowledge that From: will be rewritten and its willingness to recover it
afterwards.
Is this endeavor completely useless, given that the current settings work well
enough? Or could it help keeping a consistent DMARC semantics among
participants yearning to do so? I'd be glad to hear your opinions...
Best
Ale
--
[*] https://tools.ietf.org/html/draft-kucherawy-dkim-transform
_______________________________________________
Mailman-Developers mailing list -- mailman-developers@python.org
To unsubscribe send an email to mailman-developers-le...@python.org
https://mail.python.org/mailman3/lists/mailman-developers.python.org/
Mailman FAQ: https://wiki.list.org/x/AgA3
Security Policy: https://wiki.list.org/x/QIA9
