0006263: .p7s file appears attached in composer but is silently omitted from message, even when uploaded alone - SOGo | BTS

ID	Project	Category	View Status	Date Submitted	Last Update

0006263	SOGo	Web Mail	public	2026-10-23 13:03	2026-10-23 13:56

Reporter	BorisEagle	Assigned To
Priority	normal	Severity	major	Reproducibility	always
Status	new	Resolution	open

Summary	0006263: .p7s file appears attached in composer but is silently omitted from message, even when uploaded alone
Description	SOGo Webmail gives the impression that a selected .p7s file has been added as an attachment, but the file is not actually attached to the message. No visible error or warning tells the user that the attachment is missing. This also happens when the .p7s file is the only file selected in a new message with no existing attachments. The important symptom is the mismatch between the apparent success in the composer and the actual absence of the attachment. The original case involved letter.pdf and its detached signature letter.pdf.p7s. The PDF attaches normally, but the signature is omitted. Selecting the signature alone produces the same failure, so the problem does not require the PDF to be present or a filename collision. The .p7s file is a detached signature for a document. It is being attached as a file, not used to sign the email through SOGo's S/MIME functionality. Expected result: A file that appears successfully attached in the composer must actually be included as an attachment in the message, with its original filename and contents preserved. If the file cannot be attached, SOGo must clearly display an error instead of presenting apparent success.
Steps To Reproduce	Open SOGo Webmail and compose a new message with no attachments. Select only the detached-signature file letter.pdf.p7s as an attachment. Do not attach the corresponding PDF or any other file. Observe that the composer gives the impression that the attachment has been added, without reporting an error. Check the message's actual attachments rather than relying on the composer display. Actual result: The .p7s file appears to have been added in the composer, but is not actually included as an attachment in the message. No visible error or warning indicates the omission. The same problem occurs when the PDF and its .p7s signature are selected together: the PDF is attached, but the signature is omitted despite apparent success in the composer. Reproduction with renamed ASCII filenames has not yet been verified.
Additional Information	Environment: SOGo 5.12.12 SOGo Webmail bundled with mailcow Version 5.12.12 is not currently available in the report form's Product Version list, so that field is left blank; the affected version is recorded here. Investigation notes: application/pkcs7-signature handling may be relevant, but the root cause has not been established. The failure is reproduced with a single .p7s file in an otherwise empty draft, so no second file or filename collision is required. Bug observed in 5.12.12, not claiming that the bug is from that release. Related reports: https://bugs.sogo.nu/view.php?id=1077 — historical .p7s/.p7m attachment problem, but the email was sent and subsequently failed to save in Sent. Closed in 2012. https://bugs.sogo.nu/view.php?id=5490 — comments discuss smime.p7s attachment visibility, but not silently discarded uploads. Neither appears to describe this reproduction.
Tags	attachement

BorisEagle 2026-10-23 13:23 reporter ~0018592	I had a quick look at the source and found something that might help explain this behaviour. In SOGo 5.12.12, bodyPartsForAllAttachments in SoObjects/Mailer/SOGoDraftObject.m contains this check: if ([contentType isEqualToString: @"application/pkcs7-signature"]) // Skip SMIME signature as it will be resigned later continue; https://github.com/Alinto/sogo/blob/SOGo-5.12.12/SoObjects/Mailer/SOGoDraftObject.m#L1633-L1636 I understand why an existing S/MIME signature would need to be skipped when signing the email again. Could this check also be catching .p7s files that users attach as signatures for separate documents? The check seems to apply to any attachment with this MIME type, without checking whether it belongs to the email's own signature or whether S/MIME signing is enabled. If my uploaded file is being classified as application/pkcs7-signature, that would fit what I'm seeing: it appears in the composer, but is missing from the actual message, even when attached on its own. The same check is also present on master: https://github.com/Alinto/sogo/blob/master/SoObjects/Mailer/SOGoDraftObject.m#L1634-L1637 Perhaps it would be worth distinguishing the email's own S/MIME signature from a document signature attached by the user, so the latter can be kept. This is just a possible explanation from reading the code, rather than a confirmed fix. Thanks for taking a look!

BorisEagle 2026-10-23 13:56 reporter ~0018593	Just a quick follow-up: I tried removing the three lines that skip `application/pkcs7-signature` attachments, rebuilt the SOGo 5.12.12 Docker image in my Mailcow installation, and tested it with the same `.pdf.p7s` file. It worked! The attachment is now preserved when saving and reopening the draft, including after refreshing the page. So it looks like this check is indeed responsible for the behaviour I described earlier. To test whether removing it affects S/MIME signing or re-signing is way above my paygrade, so I wouldn't suggest this as a fix without further investigation. But at least it seems to confirm where the problem is. Hopefully this helps with finding a proper solution, because p7s is very common extension for CAdES signed files in government, judicial (including court documents) and business messaging in Ukraine.

Date Modified	Username	Field	Change
2026-10-23 13:03	BorisEagle	New Issue
2026-10-23 13:03	BorisEagle	Tag Attached: attachement
2026-10-23 13:23	BorisEagle	Note Added: 0018592
2026-10-23 13:56	BorisEagle	Note Added: 0018593