Attachments randomly not visible in webapp/deskapp

[Coffee_is_life]

Hello Forum,

i hope i dont doublepost, but i didnt find my exact problem.

Problem description:
External user sends mail with attachment (in my example its an rtf file) to more than one user within our company (single company installation)
some of them can see the attachment in webapp/deskapp, for some users (random) the attachment is not visible (nor in the overview - the little icon, nor in the mail)
if the user who can see the attachment redirects the mail to a user who received the mail without it, in the redirected mail, the attachment is visible again.
Sometimes relog into webapp/deskapp will solve this issue, sometimes its persistent.

if i export the mail without visible attachment as eml and import it into another folder, the attachment is visible again.

If i use outlook for the users who cant see the attachment, outlook will show it.

all headers of the mail are identical at all stages.

Reproduce:
dont know - this is random

workaround:
using outlook - but i dont want too many users with outlook in my installation, since some of them got huge mailboxes (despite clearing/archiving it after a certain time )

didnt find errors in php/httpd24/kopano-server/mariadb on KC nor webapp-server
note, that i seperated KC and Webapp
im using attachmentstorage, not in the db.

attachment_storage = files
attachment_path = /export/data/mail/attachments

someone got an idea whats the problem or where i can get more infos?

best regards,
Coffee_is_life

[mpraunegger]

I have a similar problem, and I’ve already opened some support tickets:
KS-46752 and KS-46711

WebApp: 4.7.0.0+157.1
Kopano Core: 11.0.0

[marty]

@coffee_is_life

Did this problem occur after upgrading Kopano core?

[Coffee_is_life]

@marty I dont know exactly when this occured the first time
i got the report from users this year and my investigations (with eml file etc.) started then.

//EDIT: no KC updates were performed this year - bug could be present the whole time

[marty]

@coffee_is_life Are the emails also signed?

[Coffee_is_life]

@marty doesnt look like it.

got no MIME or PGP signature.
DKIM is present, but disabled if i read this correctly:

[...]
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=fail (sender ip is
 206.164.xxx.xx) smtp.XXXXX smtp.mailfrom=xxxxxxxx.com;
 dmarc=none action=none header.from=xxxxxxx.com; dkim=none (message not signed);
 arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
[...]
X-Mlf-SPF: SPF Disabled (result=disabled;)
X-Mlf-DKIM: DKIM Disabled (result=disabled;)
X-Mlf-DMARC: DMARC Disabled (result=disabled;)

The attachment content looks like this in the eml file:

Content-Type: application/octet-stream;
	name="26.01.2021_16_25_101226473739TRTPEX20R11.RTF"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="26.01.2021_16_25_101226473739TRTPEX20R11.RTF"

[TGM]

@mpraunegger

did you received any feedback on your tickets? I can not find these tickets on jira.kopano.io. We have this problem too with Kopano WebApp 5.0.1.0+166.1 and Core 8.7.20.0-0+debian10~56.3

Best, Tobias

[mpraunegger]

@tgm Yes, but it is not satisfactory. My customers could not really reproduce the problem and they did not report such an issue any more; maybe they are angry about me, Kopano and everything else…

Since last weekend, we use WebApp 5.0.0; it looks really good, the Kopano team did a really good job!

In the past, we had some other problems with inline attachments, so we switched this value to false in /etc/kopano/webapp/config.php:
// Use DOMPurify to filter HTML
// Caution: disabling DOMPurify is a potential security risk.
define(“ENABLE_DOMPURIFY_FILTER”, true);