bug#26918: 25.2; rmail edit corrupts mail if content-type header not displayed

[Glenn Morris <rgm@gnu.org>]

Ken Olum wrote:

> If you have a message in rmail which is in MIME format with base64
> encoding and consists only of a single text/plain part, and if you do
> not display the "Content-Type" header (e.g. by having it in
> rmail-ignored-headers), the message will get corrupted.  The problem is
> this: under the circumstances above, rmail-edit-current-message allows
> you to edit your view of the message (which is good, since you don't
> want to edit the base64).  But when it goes to reencode the message, it
> looks in the headers it gave you to edit and doesn't see the
> Content-Type.  Later it does see the Content-Type in the original
> headers, and the result is massive confusion.  In some circumstances it
> corrupts only that message, but in others it corrupts your mail file by
> merging this message with the one before.
>
> To reproduce:
>
> 1. emacs -Q
>
> 2. Visit attached rmail-test file
>
> 3. M-x rmail-mode
>
> 4. Set variable rmail-ignored-headers to ignore "Content-Type", e.g., by
> editing it in customization system.
>
> 5. Push "t" twice so that previous change takes effect.  Verify that
> Content-Type is not displayed.
>
> 6. Push "e" to edit message.  Insert a character at the end.  C-c C-c to
> finish.
>
> 7. Observe corrupted message on screen
>
> I'm not sure how to reproduce the situation where it corrupts your mail
> file, but it has happened to me several times.
>
> I can provide a fix for this bug if we agree on the right strategy.

It seems neither rmail user has an opinion. ;)
What do you suggest?
Two ideas that come to mind are:
1) force the relevant header(s) to be visible when editing a message
2) if the headers are not found in the message as edited, consult the
full unswapped message. (I wonder what happens if an edit adds a new,
duplicate Content-Type header that disagrees with the pre-existing one...)