Self-hosted Mattermost sends full DM contents to Google and Apple push services by default

A fresh install of Mattermost's self-hosted server transmits the full text of direct messages and @mentions to Google's and Apple's push notification services by default, according to a hands-on test published on dev.to. The finding contradicts Mattermost's own documentation, which describes generic, content-free notifications as the default for self-hosted deployments.

What the test showed

The author ran a brand-new Mattermost 12.1 server in Docker on a network with no outbound internet access, changing only the push relay's address so that notifications arrived at a local listener. Every direct message and @mention was packaged as readable JSON containing the complete message body, the sender's handle, the channel name, the client platform and a device identifier, then dispatched to push-test.mattermost.com, Mattermost's free Test Push Notification Service (TPNS). That relay forwards payloads to Firebase Cloud Messaging for Android or Apple's push service for iOS, which then place the text on the recipient's lock screen.

The post reports this happens for every DM and @mention by default, except when the recipient is already viewing that conversation or has Do Not Disturb enabled.

The docs and the code disagree

Mattermost's mobile FAQ states that default server settings keep message contents out of notifications, and the settings documentation lists a generic sender-and-channel description as the default. The tested server instead shipped with push notifications enabled, pointed at the test relay, with the contents setting at "full".

The explanation, per the dev.to post, is a May 2020 pull request that made "full" the built-in default to improve the out-of-the-box experience for new installs. Servers created before version 5.24 had "generic" written explicitly into their config files and kept it; anything newer inherits "full". The Helm chart and Mattermost's official Docker setup do not override the value, and the documentation still says generic today. Admins can check their own server with mmctl --local config get EmailSettings.PushNotificationContents; a result of "full" means message bodies are being sent.

Who can read the message

The connection from server to relay is HTTPS, but the relay itself receives the payload as plain JSON, and the post quotes Mattermost's terms as saying TPNS messages "will not be encrypted" and that users "assume all risk". Mattermost's own documentation recommends against TPNS for production, even though every new install points at it. Beyond the relay sit Google and Apple, which receive the text, sender and channel. The post also recalls Senator Wyden's December 2023 disclosure that foreign governments had been asking both companies for push notification data.

How other chat servers compare

The author contrasts defaults across projects: Rocket.Chat also sends the message in plaintext, something its staff confirmed on the project forum back in 2021; Matrix with the Element X client sends only an event ID and lets the app fetch the message itself; Prosody (XMPP) sends no message or sender, at most a "New Message!" placeholder; and Zulip 12 ships only ciphertext the app can decrypt. Mattermost and Rocket.Chat both offer the ID-only model, but gate it behind paid licences. The author reports selecting that mode on the free Team Edition and observing the server quietly send the generic variant instead.

How to switch it off

Admins can set Push Notification Contents to a generic option in the System Console under Site Configuration, Notifications, or run mmctl --local config set EmailSettings.PushNotificationContents generic on the server (the setting oddly lives under EmailSettings). In Docker, the environment variable MM_EMAILSETTINGS_PUSHNOTIFICATIONCONTENTS=generic achieves the same result. Recipients then see only that a message arrived, and must open the app to read it.

Self-hosting the relay does not fully solve the problem, because only Mattermost's relay holds the Apple and Google keys used by the store-distributed mobile apps; going that route also means building your own apps. The post closes on an ironic detail: step four of Mattermost's admin onboarding checklist is to enable full-content push notifications.

Why it matters

Mattermost is often chosen precisely because self-hosting keeps conversations off third-party infrastructure. This finding shows that, by default, plaintext chat traverses at least three additional parties — Mattermost's test relay plus Google and Apple — on servers where admins never knowingly opted in. Documentation that misstates the default undermines informed consent: even diligent operators may believe they deployed generic notifications. With documented government interest in push notification data, and projects like Matrix and Zulip demonstrating that ID-only push is practical, the gap between Mattermost's docs and its code is a privacy defect worth auditing on any server set up since mid-2020. The fix is a single config line, but only for admins who know to look.