I'm sorry, but i think there is a missunderstanding. After analysis 
with different mail clients, the problem with the signature 
verification is in thunderbird, not in horde. Outlook 2013 works fine.
There was never a problem with displaying in case of signature verification.

I have investigated that *horde* can't display e-mails. These e-mails 
are written with horde webmail (imp), encrypted with S/MIME in horde. 
S/MIME encryption without signing. Sent to myself. Open immediately 
with imp 6.2.7 after sending in webmail: horde does not display. Not 
the general purpose use case. I think now that this has nothing to do 
with this ticket.

You might be on to something. The messages verify fine in Microsoft 
Outlook 2013. Unfortunately I don't have any other mail client 
available to check.

You haven't confirmed anything.

What does display in TB have to do with whether the message is correct 
or not?  "Displaying in Thunderbird" is not the standard.  It is just 
as likely *thunderbird* is broken.

We sign/encrypt messages via the S/MIME PHP functions.  It has been 
VERIFIED that openssl (the library) verifies these messages just fine.

So until someone can explain how IMP messages are broken, there's 
nothing to do here.

I can confirm, that is issue exists in imp 6.2.7/ Webmail 5.2.5. The 
verification failed using thunderbird mail client. There is also an 
other problem when encrypting only with S/MIME and imp 6.2.7 when the 
same message is decrypted which imp. Then the decyrption failed with 
imp only, thunderbird can decrypt.

_parseSignedData() method in IMP_Mime_Viewer_Smime class.

This line does the verification:

                 $sig_result = $this->_impsmime->verifySignature($raw_text);

$raw_text contains the full string of the message to be verified.

Can anybody give me a hint where and how I can get to the data before 
and after is passed to openssl? What data can I provide to help with 
this issue?

I can't reproduce with master.

Creating a message with IMP, taking the raw message data, and passing 
it directly to openssl, I see:

slusarz@bigworm % openssl smime -verify -in /tmp/test.smime -noverify
Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes
Content-Disposition: inline

Test
Verification successful


Verified that changing the text content of the message cause incorrect 
verification:

slusarz@bigworm % openssl smime -verify -in /tmp/test.smime -noverify
Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes
Content-Disposition: inline

1Test
Verification failure


Someone is going to have to identify where the issue is on their system.

Confirmed, in master too. Interesting: the validation succeeds in IMP.

When signing a mail with S/MIME via the composer the content seems to 
get modified by IMP/Horde after signing and/or encryption. A 
verification by the reciever fails. The same happens if the mail is 
encrypted and signed. The decryption is not affected by this which 
points to either a header-issue or a encoding problem.
The MTA has no part in this. Sending signed mails via the 
ActiveSync-interface doesn't suffer from this problem.