attachments on message with multiple encryption layers remain encrypted

It's not intentional. MailMate decrypts anything which uses the OpenPGP/MIME format (and some variations of inlined OpenPGP). I believe MailMate would just see your example files as attachments.

Do you know how this happened? Do you get them often?

It was a first-time thing and I hope it stays a one-time thing as well ;-) if you're curious about the background story: The message (including those attachments you see) was decrypted without MDC. Probably because of that, my mail server decided that the incoming mail was unencrypted and encrypted it (as it does with all mail that is not already PGP or S/MIME encrypted). That resulted in an inner layer (sender key + my public key, without MDC) as well as an outer layer of encryption (the keys I have my mailserver use to encrypt incoming mail, with MDC).

MailMate does happily decrypts the outer layer and – if I make it ignore the missing MDC – also the inner layer, but the attachments don't get decrypted. They stay .asc files. The message body that holds the text does get decrypted just fine and the text is being displayed and the attachments decrypt just fine on the command line.

MailMate just doesn't automatically decrypt and display them inline. I don't understand why.

That all sounds fair enough! Thanks very much for thinking about it; it does make sense the way you're handling it now.

I will check if that once I solve the double encryption issue, maybe that also means the attachments turn into regular attachments. That will most likely need the sender to implement MDC and/oder the mail server to detect "unencrypted" messages differently. Both issues have been addressed and at least for the first one there is a fix expected to be rolled out next month.

Should any new insights arise after those fixes have been applied, I will update this ticket.

For debugging, I would like to be able to created messages without MDC using this gpg2 switch (running 2.2.8):

--rfc2440
Reset all packet, cipher and digest options to strict RFC-2440 behavior.  Note that by using 
this option encryption packets are created in a legacy mode without MDC protection.  This is 
dangerous and should thus only be used for experiments.  See also option --ignore-mdc-error.

I can't seem to get it to work by just adding rfc2440 to my gpg.conf. Is there another way I can force MailMate to use it upon encryption?

You can enable debug output like this:

defaults write com.freron.MailMate MmDebugSecurity -bool YES

Then launch from a Terminal window like this:

/Applications/MailMate.app/Contents/MacOS/MailMate

You should then be able to see how MailMate calls gpg2. That might make it easer to track down why this doesn't work.

Thanks for pointing out that debug flag. You seem to have hardcoded the gpg2 call into MailMate?

OpenPGP
 gpg2 --no-verbose --batch --no-tty --openpgp --status-fd 2 --textmode --armor --local-user "#######" --detach-sign
 Input string (40): "Content-Type: text/plain\r\n\r\nInhalt 3"

In addition, the documentation states that only one compliance option may be active at any given time. You are already using "--openpgp", which means I would need to replace that instead of just adding "rfc2440" to gpg.conf.

Even if I ignore the documentation, putting rfc2440 into gpg.conf doesn't seem to work… Is there a way to change that gpg2 call directly?

As you have noted, this is hardcoded and I'm hesitant with respect to not setting --openpgp. Instead I've introduced a preference to change it:

defaults write com.freron.MailMate MmOpenGPGComplianceString -string "rfc2440"

It defaults to openpgp and is used for the following command line argument:

--compliance

This is going to be part of the next update (r5523+).

Indeed, I would also strongly advise against not setting --openpgp, even this option you introduced now should clearly only be used for debugging.

Which is what I am off to do now, thanks for making that possible :-)