On Mon 2021-01-11 16:09:18 +0100, Lars Ingebrigtsen wrote:
> Well, we'd have to include the relevant headers at a minimum:
>
>   Content-Type: multipart/signed; boundary="=-=-=";
> 	micalg=pgp-sha256; protocol="application/pgp-signature"

I agree, but if the user is stripping the Content-Type header, i think
they're going to break a lot more than digital signatures or encryption
(imagine what that does to a multipart/alternative message).  I think
that stripping Content-Type is more of a case of "don't do that, then".
Maybe we even want to warn if the user tries to strip any of the
Content-* headers more generally.

> But this code is almost a couple of decades old, and I have no idea what
> the thought process behind this was at this date.  Anybody know?

As long as the code doesn't attempt to strip *internal* MIME headers
(that is, headers of subparts of the MIME structure) i think it should
be safe to apply it to the forwarded message.  

Note also that if we care about breakng cryptographic signatures more
generally, DKIM signatures are *more* likely to break if headers are
stripped than PGP/MIME or S/MIME, as DKIM is capable of covering headers
directly.  Even given that concern, i think the most we'd want the
"best" setting to do to constrain header stripping would be to compare
the stripped version of the file to the non-stripped version -- if the
non-stripped version passes DKIM validation, but the stripped does not,
then either produce a warning message about DKIM signature breakage or
(if in an interactive mode) prompt the user about whether they want to
apply the filter or not.

      --dkg