Update: Found the root cause and a working (temp) fix.

carbonio-auth (the upstream on port 20008, handling /zx/login/ and /zx/auth/) has no backing service on my system — confirmed via consul catalog services (not registered at all, not just unhealthy), no .hcl file, no systemd unit, no owning package anywhere in the repo (dpkg -S, apt-cache search). Also confirmed this endpoint doesn't exist on mailboxd itself on either of its own ports (8080, 7071 — both return 404 for these paths directly).

My working theory: carbonio-auth may be the advanced-auth-policy service (2FA/SAML/trusted-device policy management — note the CLI has separate WebUI vs ZmWebUI policy commands) that's part of paid Carbonio but not shipped in CE, while the proxy's nginx template references it unconditionally regardless of edition. If anyone from Zextras can confirm/deny this, it'd help a lot.

Workaround that's fully resolved it for me: since the legacy /service/soap/AuthRequest login path works fine independent of carbonio-auth, I edited the nginx templates to make the /zx/login/ and /zx/auth/ locations return a clean 404 instead of attempting to proxy to the missing service:

location ^~ /zx/login/
{
    return 404;
}

location ^~ /zx/auth/
{
    return 404;
}

(applied in /opt/zextras/conf/nginx/templates/nginx.conf.web.https.template and the matching .default.template, then zmproxyctl restart)

This let the frontend gracefully fall back instead of hard-failing on the connection reset from the missing backend. Both regular webmail and the admin console (port 6071) now log in and work normally.

Caveat: this is a workaround, not a real fix — it just disables whatever carbonio-auth was supposed to provide (likely advanced auth policy features, which may not matter for anyone not using 2FA/SSO anyway). If someone knows the actual intended fix, I'd still like to hear it.

Environment: Carbonio CE carbonio-core 4.5.12-1jammy, Ubuntu 22.04.

Webmail/admin login fails with 502 Bad Gateway on GET /zx/login/v3/auth/config. Traced this to the carbonio-proxy upstream carbonio-auth, which routes to 127.78.0.1:20008 (an Envoy sidecar). The sidecar itself is up and listening, but nothing is registered behind it.

What I've confirmed:

• consul catalog services shows no carbonio-auth entry at all (not unhealthy — completely absent)
• No .hcl file for it exists in /etc/zextras/service-discover/ (only carbonio-proxy.hcl references the name, as a destination)
• No systemd unit carbonio-auth-sidecar.service exists anywhere on disk
• dpkg -S carbonio-auth-sidecar returns no matching package
• apt-cache search carbonio | grep auth and apt list -a carbonio-auth* show only carbonio-auth-ui (a frontend module), no backend service
• Not served directly by mailboxd either (curl localhost:8080/zx/login/v3/auth/config → 404)
• No trace of any process ever attempting to register this service name in mailbox.log
• pending-setups -a runs clean, nothing pending
• Full zmcontrol restart and individual service restarts don't resolve it
• Repointing the proxy upstream to carbonio-user-management (the service that appears to actually handle auth-related SOAP requests) also didn't resolve it — reverted that change

What's healthy: everything else — mail delivery, IMAP, SMTP, LDAP, MTA, proxy itself, mailbox backend. This is isolated to the webmail/admin login flow specifically.

Found one other user with the exact same symptom (community.zextras.com/forum/carbonio-general-thread/carbonio-auth-problem/, Feb 2024) with no public resolution shown.

Is carbonio-auth supposed to be provided by a specific package? Was it possibly deprecated/replaced by carbonio-user-management in a later version and this proxy template just wasn't updated to match? Any pointers appreciated.

Webmail/admin login fails with 502 Bad Gateway on GET /zx/login/v3/auth/config. Traced this to the carbonio-proxy upstream carbonio-auth, which routes to 127.78.0.1:20008 (an Envoy sidecar). The sidecar itself is up and listening, but nothing is registered behind it.

What I've confirmed:

• consul catalog services shows no carbonio-auth entry at all (not unhealthy — completely absent)
• No .hcl file for it exists in /etc/zextras/service-discover/ (only carbonio-proxy.hcl references the name, as a destination)
• No systemd unit carbonio-auth-sidecar.service exists anywhere on disk
• dpkg -S carbonio-auth-sidecar returns no matching package
• apt-cache search carbonio | grep auth and apt list -a carbonio-auth* show only carbonio-auth-ui (a frontend module), no backend service
• Not served directly by mailboxd either (curl localhost:8080/zx/login/v3/auth/config → 404)
• No trace of any process ever attempting to register this service name in mailbox.log
• pending-setups -a runs clean, nothing pending
• Full zmcontrol restart and individual service restarts don't resolve it
• Repointing the proxy upstream to carbonio-user-management (the service that appears to actually handle auth-related SOAP requests) also didn't resolve it — reverted that change

What's healthy: everything else — mail delivery, IMAP, SMTP, LDAP, MTA, proxy itself, mailbox backend. This is isolated to the webmail/admin login flow specifically.

Found one other user with the exact same symptom (community.zextras.com/forum/carbonio-general-thread/carbonio-auth-problem/, Feb 2024) with no public resolution shown.

Is carbonio-auth supposed to be provided by a specific package? Was it possibly deprecated/replaced by carbonio-user-management in a later version and this proxy template just wasn't updated to match? Any pointers appreciated.

Thanks

Thanks for the log. But it is still a bit unclear to me. Could you please share some more details like:

• What did you mean by forwarding on distribution list
• How you are setting the forward to external address, where you are setting it.
• What is your OS and Carbonio CE version
• description of the flow: sender -> Receiver -> Forward to -> External address

Thanks!

I'm sorry if I got your post wrong. But in my setup, I can:

• create contact groups
• edit it later using right click context menu or the edit icon in the details
• After creating or edit, I see that change is successfully propagated/reflected to my account.

Please let me know if I am missing anything. 

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!

Thanks for pointing that out!

Gruesse

Michael

Description=Restart Carbonio Video and Collaboration Services\

After=network-online.target



Type=oneshot

ExecStart=/usr/bin/systemctl restart carbonio-message-dispatcher

ExecStart=/usr/bin/systemctl restart carbonio-videoserver

ExecStart=/usr/bin/systemctl restart carbonio-ws-collaboration



WantedBy=multi-user.target

sudo nano /etc/systemd/system/carbonio-restart.timer

Description=Timer to restart Carbonio services 3 minutes after boot



OnBootSec=3min

Unit=carbonio-restart.service



WantedBy=timers.target

sudo systemctl daemon-reload

sudo systemctl enable --now carbonio-restart.timer

systemctl status carbonio-restart.timer

reboot

journalctl -u carbonio-restart.service

At this point I could say Certbot renews as the zextras user, so if /opt/zextras/common/etc/letsencrypt has ended up root-owned for any reason, the renewal can't write the new cert and fails. Your chown -R zextras:zextras gives the directory back to the account that actually runs the renewal.

When someone faces this kind of situation could try checking:

find /opt/zextras/common/etc/letsencrypt \! -user zextras \! -type l

If that lists any files,where the owner isn't the zextras uid, then should run:

chown -R zextras:zextras /opt/zextras/common/etc/letsencrypt

That's all I can say for now!

The path specified:

find /opt/zextras/common/etc/letsencrypt \! -user zextras \! -type l

doesn't exist in my installation, but the following does:

find /opt/zextras/common/certbot/etc/letsencrypt \! -user zextras \! -type l

Just wondering if my setup is different.

Regards,
Henrik