The fix does not makes sense in that what you discribe and addContent is for sure wrong to fix this. We don't want to change the mail it self, we attach a extra part.
I think the problem is that the partent Node (mNode) is not added as extra node. nodehelpertest should be test this.

If it is encrypted this part only CryptoMessagePart::startDecryption(KMime::Content *data) should be called that does decrypt+verification. But maybe you have a "special" opaque SMIME message, that triggers the verification.

Can you places add a test for this.
attachmenttest and/or rendertest (that lives in messageviewer/src/messagepartthemes/default/autotests)

To create a test mail, you can run kmail like we does it for the tests and select than a key in the test keyring:
GNUPGHOME=<BUILDPATH>/messagelib/messagecore/autotests/gnupg_home gpg-agent --daemon kmail

So, the problem here is the following. Upon decrypting the message we end up with the current "tree" of parts:

application/pkcs7-mime; smime-type: "enveloped-data"
application/pkcs7-mime; smime-type: "signed-data"
   multipart/mixed
      text/plain
      application/octet-stream; content-disposition: attachment

and the NodeHelper::mExtraContents table is like this:

application/pkcs7-mime; smime-type: "enveloped-data" => [ application/pks-7-mime; smime-type: "signed-data" ]
application/pkcs7-mime; smime-type: "signed-data" => [ multipart/mixed ]

The problem here is that although mExtraContents indicates relation between the signed-data and enveloped-data, in reality the signed-data part is not a child of the enveloped-data message, although it should be (IMO), because the signed-data message is the content of the enveloped-data message, similar to multipart/mixed being the content of signed-data.

The fact that this relationship is not present is visible on the URL of the attachment part:

attachment:0:0::2?place=body

Notice the double colon? That's NodeHelper::persistentIndex() failing to find the position of signed-data within its parent - because it has none!

The problem is that NodeHelper::persistentIndex() is recursive only within the KMime::Content tree hierarchy, but it is not recursive in the terms of mExtraContents relationships.

There are IMO two possible ways to fix this:

1. Make signed-data a child of the original enveloped-data part.

This is what I tried to do in my initial patch. The problem is that when the signature is being verified we no longer have the parent enveloped-data part available in pointers and such, and it happens in a code that is too generic to be the right place for this. Possibly larger change would be required to make this work

2. Make NodeHelper::persistentIndex() smarter.

The idea is to support recursive relation lookup through both KMime::Content::parent() as well as the mExtraContents table, using special prefix for the indexes in mExtraContents. As an example, the URL of the attachment with approach would be something like

attachment:0:0:e0:2?place=body

See the "e0"? That indicates that the part is not first child enveloped-data, but is the first element in mExtraContents[enveloped-data-node].

i think this is the root problem of https://bugs.kde.org/show_bug.cgi?id=343795