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.