Attachments with Co...
 
Notifications
Clear all

Attachments with Content-Type "application/pkcs7-signature" are hidden in Carbonio webmail (composer and Sent folder)

1 Posts
1 Users
0 Reactions
3 Views
(@manul)
New Member
Joined: 3 hours ago
Posts: 1
Topic starter  

Hi everyone,

We've run into an issue with Carbonio CE 4.25.2 and would like to share our findings, since it looks like a known long-standing behavior inherited from Zimbra rather than something new.

Problem description

Attachments with Content-Type application/pkcs7-signature (typically .p7s files — standalone signed documents, e.g. tax/legal/HR documents signed with a qualified electronic signature) are not shown in the Carbonio web client, neither while composing a message nor when reopening a message from the Sent folder. The attachment simply doesn't appear in the UI, as if nothing were attached.

The attachment is NOT actually lost, though:

  • The file is correctly received and stored by FileUploadServlet (confirmed via mailbox.log — "saveUpload(): received Upload" entries show the file coming in fine).
  • The message is sent with the attachment intact.
  • Any other mail client (Thunderbird, Outlook, other IMAP clients) correctly shows and downloads the very same attachment from the very same message.

So it's purely a web client display issue — not an MTA, antivirus, or attachment-blocking problem. We already ruled out:

  • zimbraMtaBlockedExtension (p7s/p7m are not in that list)
  • Antivirus/antispam (mail is delivered with the attachment intact either way)

Example MIME headers of the affected attachment part

Content-Type: application/pkcs7-signature;
 name="...filename...pdf.p7s"
Content-Disposition: attachment;
 filename="...filename...pdf.p7s"
Content-Transfer-Encoding: base64

Important detail: in our case this attachment is NOT part of a multipart/signed structure — it's not a signature over the message itself (S/MIME-style). It's a plain regular attachment whose payload happens to be a PKCS#7 signed document, which is a common pattern in several countries' e-government/e-document workflows (e.g. Italian PEC "atti.p7m", Ukrainian tax/HR documents "*.pdf.p7s"). It looks like the client filters/hides any attachment part with this Content-Type regardless of the surrounding MIME structure.

This looks like the same issue as an old Zimbra bug

This exact behavior existed in Zimbra for years and is documented as Zimbra Bugzilla #69476: the web client was changed to ignore application/pkcs7-signature parts, apparently to hide the actual S/MIME signature part of signed messages. The side effect was that any attachment using this same Content-Type got hidden too, breaking legitimate cases where the p7s/p7m file is a standalone signed document rather than a signature over the message.

A community-maintained Zimlet was published back then specifically to work around it: zimbra-patches (folder tk_barrydegraaff_enable_pkcs7_signature) — described as reverting the ignoring of application/pkcs7-signature introduced by that bug.

Since Carbonio's web client is a full rewrite (React-based, not Ext/Zimlet-based anymore), that old Zimlet fix obviously doesn't apply here, but the same filtering logic seems to have carried over conceptually.

Possibly related area of the code

Carbonio added native S/MIME support in carbonio-mailbox (PR #646, released in 4.20.0, Feb 2025). That's likely the place where application/pkcs7-signature parts get special-cased and excluded from what's shown to the client.

What we'd love to see

Ideally, the filtering would only apply when the pkcs7-signature part is actually a child of a multipart/signed structure (i.e. a real S/MIME signature on the message), so that standalone p7s/p7m attachments — a very common real-world document type in several jurisdictions — show up normally in the UI, just like they already do in any IMAP client.

Happy to share full raw message headers or a test message/log excerpt if that helps track this down. Has anyone else run into this, or found a workaround on the Carbonio side?

Thanks!

This topic was modified 3 hours ago by manul

   
Quote