Privacy Policy
Last updated: 29 August 2026 · Applies to the Hmelj web app and the Hmelj Android app
Short version: Hmelj is self-hosted software. The app is a client — it only ever talks to the server address you enter when you set it up, and that server only ever talks to the mail providers you configure. The Hmelj project operates no server, receives no data, and builds no analytics, ads or trackers into anything it ships.
Who this policy covers
Hmelj is free, open-source software (AGPL-3.0) that you, or someone you trust, run on your own server — a home NAS, a small VPS, a machine in an office. The app you installed is a client for that server. It has no independent connection to the Hmelj project, and the people who develop Hmelj never receive, see, or store any of your data.
This policy describes what the software does. It cannot describe what the person running your particular server does with it; see Your server's own responsibilities below.
What data Hmelj handles, and where it goes
- Your Hmelj username and password — chosen by you, stored on your own server with the password hashed using scrypt. It is never sent to any mail provider.
- Mailbox credentials — the passwords, app passwords or OAuth refresh tokens for the mail accounts you attach. Stored on your own server, encrypted at rest with AES-256-GCM, and sent only to the mail servers they belong to.
- Your mail — message headers and, for recently read messages, bodies are cached on your own server so lists and reopening are fast. Attachments are held briefly in that server's memory and are never written to its disk by the cache. If you switch on the full-text index for an account, the words of those cached bodies are also indexed on that same server, so search can look inside them without asking the mail provider; the index is deleted the moment you switch it off.
- Your settings, identities, signatures, contacts, calendars and filters — stored on your own server, per user, and exportable from Settings at any time. Snoozed messages are recorded there too: which message, and when it should come back.
- The server address, and your session — in the Android app, the server URL you type and the session cookie it receives are stored locally on your device.
None of the above is sent anywhere except the server address you configured, and the mail providers you told that server about. There is no Hmelj-operated backend of any kind.
Notifications
If you turn on new-mail notifications, your server sends them through the push service your device already uses — Mozilla's service for Firefox, Google's Firebase Cloud Messaging for Chrome and for the Android app, Apple's relay for Safari. That is how push works on every platform; there is no way to deliver a notification to a closed app without passing through the platform's own service.
A notification carries the sender, the subject, and identifiers your server uses to open the right message. Those services therefore transport that content, subject to their own privacy policies. If that is not acceptable for a particular mailbox, leave notifications off for it — Hmelj works fully without them, and the notification schedule can also be set to Never per account or per folder.
Notifications are also held only briefly: by default a push service may hold one for an unreachable device for 15 minutes, after which it is dropped rather than delivered late.
Optional integrations you control
Hmelj contacts nothing by default beyond the mail servers you configure. These are opt-in:
- Your mail providers — IMAP/SMTP servers, Microsoft Graph, or an Exchange server, whichever accounts you add.
- Google or Microsoft sign-in — only if you choose an account type that uses it. Authentication happens between your browser and that provider; your server receives only the resulting token.
- Remote images in messages — loading them tells the sender you opened the message. Hmelj's default is to load them only from domains you have trusted, and the policy can be set to never load them at all.
- Unsubscribe requests — sent only when you press the button, and the confirmation always names where the request will go.
- Read receipts — never confirmed automatically.
In every case the connection goes from your device, or from your own server, directly to the service you specified. The Hmelj project is not an intermediary and does not see any of that traffic.
What Hmelj does not do
- No analytics or crash-reporting SDKs are built into the app or the server.
- No advertising, no ad identifiers, no ad networks.
- No data is sold or shared with third parties by the Hmelj project, because the Hmelj project never receives any data to begin with.
- Nothing phones home. There is no update check, no licence check and no usage ping.
- Message content is never sent to any translation, spam-scoring or AI service.
Android permissions
The Android app requests four permissions, and nothing else:
INTERNET— to talk to the server you configure.ACCESS_NETWORK_STATE— to notice when connectivity comes back.POST_NOTIFICATIONS— only if you turn notifications on; Android 13 and later ask you for it directly.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS— to offer you the system prompt that exempts Hmelj from Doze, so notifications are not killed in the background. The app cannot grant this to itself.
It does not request access to your contacts, location, camera, microphone, or files beyond what you explicitly pick with the system file picker when attaching something to a message.
Children's privacy
Hmelj does not knowingly collect personal information from anyone, including children, because it does not collect personal information at all — everything described above is stored on the server you or your household controls, not on any Hmelj-operated system.
Your server's own responsibilities
Because you, or your administrator, run the actual server, you are the one in control of that data. Backups, retention, who has an account, and whether the server is exposed to the internet are all decisions made where the server runs. This policy covers the software's own behaviour; it is not a substitute for securing a server you expose publicly. Hmelj should be run behind TLS, since mailbox passwords travel over that connection.
Note also that an administrator of a Hmelj instance has filesystem access to its data directory, exactly as they would with any self-hosted mail client. Trust your server's operator accordingly.
Changes to this policy
If this policy changes, the updated version will be posted at this same URL with a new "last updated" date above.
Contact
Questions about this policy or how Hmelj handles data can be raised as an issue on the project's repository: github.com/thehijacker/hmelj/issues.