Hey,

Just forget my last mail. I just dug a bit deeper and found the culprit
I think.

With commit 84ef1ea8b524f8998fc8674b99cf8069e38dce4f these lines were
added:

--8<---------------cut here---------------start------------->8---
modified   lisp/gnus/mm-decode.el
@@ -1672,6 +1672,8 @@ If RECURSIVE, search recursively."
                    (t (y-or-n-p
                        (format "Decrypt (S/MIME) part? "))))
                   (mm-view-pkcs7 parts from))
+         (goto-char (point-min))
+         (insert "Content-type: text/plain\n\n")
          (setq parts (mm-dissect-buffer t)))))
      ((equal subtype "signed")
       (unless (and (setq protocol
@@ -1739,6 +1741,7 @@ If RECURSIVE, search recursively."
--8<---------------cut here---------------end--------------->8---

I don't quite know why the content-type is forced here to text/plain. So
if this line is removed the mm-dissect-buffer call does it's thing and
returns correctly whats inside the envelope (the real content-type
header in the decrypted envelope is parsed). Well almost...

I wrote in my last mail that I had to adjust mm-copy-to-buffer:

> and also mm-copy-to-buffer to check for carriage returns like this:
>
> (search-forward-regexp "^\r\n" nil 'move)
>
> (can't send the carriage return properly so \r it is here instead of ^M)

This is still needed as the decrypted content may still have carriage
returns in it. One could also remove the carriage returns in
mm-view-pkcs7-decrypt function of course. I'm not quite sure which is
the better approach.

In such a case the "Decrypt (S/MIME) part?" is asked too times. But hey
that isn't too bad I think.

I have attached a patch with the explained fix.

Best regards
Sebastian