Hello Alec,

just as a confirm of your hypothesis, if you look at the raw source of the message within Roundcube (Action -> show source) it's layout is different from the one that gets thrown at gpg.

This is the very same mail:

Raw source:

[....]

Message-ID: <5d3b75e68692f4a51fa1d361fdc6d1f1@brancatelli.it>
X-Sender: andrea@brancatelli.it
User-Agent: Roundcube Webmail/1.2.1

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)

--=_ad16315c31f34b75fe12de9a5f6ff9c3
Content-Type: multipart/mixed;
 boundary="=_0c2026a878accfb67f4729bf2f2a522d"

--=_0c2026a878accfb67f4729bf2f2a522d
Content-Type: multipart/alternative;
 boundary="=_4f6a45d8f3d31b8528676bb2b9630c46"

--=_4f6a45d8f3d31b8528676bb2b9630c46
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII

[...]

Console LOG:

[...]

[28-Jul-2016 15:19:22 +0200]: <s4r01i4d> ---------------------------------
[28-Jul-2016 15:19:22 +0200]: <s4r01i4d> VERIFY INPUT
[28-Jul-2016 15:19:22 +0200]: <s4r01i4d> Content-Type: multipart/mixed; boundary="=_0c2026a878accfb67f4729bf2f2a522d"^M
^M
--=_0c2026a878accfb67f4729bf2f2a522d^M
Content-Type: multipart/alternative;^M
boundary="=_4f6a45d8f3d31b8528676bb2b9630c46"^M
^M
--=_4f6a45d8f3d31b8528676bb2b9630c46^M
Content-Transfer-Encoding: 7bit^M
Content-Type: text/plain; charset=US-ASCII^M
^M
Mail firmata mandata tramite potassio.^M
--=_4f6a45d8f3d31b8528676bb2b9630c46^M
Content-Transfer-Encoding: quoted-printable^M
Content-Type: text/html; charset=UTF-8^M

[...]

Andrea Brancatelli
Schema31 S.p.a.
Responsabile IT

ROMA - BO - FI - PA 
ITALY
Tel: +39.06.98.358.472
Cell: +39.331.2488468
Fax: +39.055.71.880.466
Società del Gruppo SC31 ITALIA

Il 2016-07-28 11:28 A.L.E.C ha scritto:

On 07/28/2016 10:54 AM, sgironella@schema31.it wrote:

Enabled IMAP and SMTP debug (see attachments) and tested against a
DBMail internal mail server and an external one (GMail to simplify test
repeatability).

Attached files are related to the GMail session.

As you can see, IMAP response differs on main mime part headers
structure, so i think that's the reason for sign verification failure.

I created a ticket for this issue
https://github.com/roundcube/roundcubemail/issues/5371

I don't see a simple workaround now, we'd need to get the whole signed
message body and parse it instead of fetching headers and body of the
first part separately. I'll take a look at this over the weekend.