Alessandro Vesely writes:
First, what Mailman are you talking about? Only Mailman 3 is likely
to get these improvements, as Mailman 2 is end-of-life. However,
Mailman 2 installations are likely to be around in large numbers for
several years, and if Mailman 2 is any evidence, likely few Mailman 3
installations would use these features unless forced to by a disaster
like the Yahoo/AOL sudden switch to DMARC p=reject.
> Yet, it is possible to undo the transformation that Mailman put in
> place, thereby validating the original DKIM signature.
It would always be possible to undo all transformations by supplying
the original email as part of a multipart/alternative, or perhaps a
new multipart subtype, maybe with some kind of device to make reading
the message/rfc822 original difficult in standard MUAs. Then the
problem is much simpler: the validator need only validate the whole
and the original, and the receiver would have all information
necessary to decide whether the alleged Mailman version is based on
normal processing or is a malicious fake. This would require some
changes to Mailman to implement, and to Postorius for a configuration
UI. (In the case of Microsoft MUAs, if Mailman is configured to strip
HTML, the result might be less than 10% bigger than the original! ;-)
It is sometimes possible to reverse transformations with only the
information in the post after Mailman processing. However, some very
desirable changes are destructive (eg, anonymized lists, conversion of
HTML to plain text, removal of prohibitive attachments). Some
non-destructive changes (headers and footers) are highly customizable.
So the question is what are the transformations that users want to
reverse, and whether that's really possible.
This kind of transformation reversal probably requires no changes to
Mailman, just an addition of a Handler which could be written
independently and "dropped in" (with a configuration change to the
default pipeline). The necessary information about transformations
that are configured would be available from Mailman in the usual way
(existing Handlers need that information).
> Mailman carries out some irreversible changes, such as rewriting
> To: or Cc: changing the order of the mailboxes,
Does this happen outside of DMARC mitigation? Can you show examples?
> or rewriting Content-Transfer-Encoding: irrespective of quotation
s > marks and case (for example "7bit" even if the original, signed
> field was spelled as "7Bit").
I'm not aware of such behavior *unless other modifications were done*.
In that case, Mailman is specifying the C-T-E it uses, it is not
rewriting the original C-T-E.
> I guess this behavior is coded deeply in Python libraries,
I don't think so. As far as I know, the email module in Python 3
provides some support for parsing header fields but I don't know why
this would change order or spelling of field contents. I would guess
that to the extent that it happens it has to do with Mailman-level
processing (for example, collecting addresses from the same domain so
they can be presented as multiple RCPT TO with a single DATA). I can
say for sure that some care was taken to ensure that the order of
header fields, including multiple instances of the same field is
carefully preserved.
> but would like to know developers' opinions. Is that something
> that could be fixed?
First, the issues with headers could be improved, though not entirely
fixed, in DKIM itself by further canonicalizing structured headers
before signing or verifying.
I'm not saying that this is the right way forward, but it should be
considered.
> 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
This could be done easily, but it would be at best a hint. Among
other things, it might be desirable to identify the agent that
performs the transformation, as well as the algorithm and perhaps the
host and/or the list. Mailman adds footers in different ways,
specifically appending text and adding a MIME part. Third party
patches are available that dig into HTML structure (at least for
Mailman 2). There are lists that feed into lists, and apply their own
transformations.
> or as an extra tag in a DKIM signature, for example:
>
> DKIM-Signature: v=1; (...) tf=footer; (...)
Not possible without a lot of effort and specific cooperation from
MTAs. Mailman doesn't DKIM sign messages, really doesn't want to
(there are Python modules for this, but use and configuration would be
our responsibility so we'd like to have specialists do it), and
probably shouldn't (we're not specialists) -- that should be left to
the border MTA of the administrative domain.
> 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
