Trust & Transparency

Why this page exists

Linux users are right to be skeptical of closed-source email clients. Email is sensitive, and "trust me" doesn't carry much weight when you can't read the code.

But the real problem with closed-source software isn't that the source is closed. It's that the behavior is opaque. Software that hides what it does on the network, locks your data into formats only it can read, and quietly phones home in ways you can't observe is the kind of software that deserves the skepticism.

Melia is closed-source, but it isn't opaque. The network behavior is observable. The license server takes a documented, minimal payload that you can capture with tcpdump. The local data lives in a standard SQLite database you can query with one command. The release binaries are signed with a published key, and the license validation is offline-first by design. If Melia is ever abandoned, the source gets released. The rest of this page shows you how to confirm each of those for yourself.

This is the single document we point skeptics at. If you read it through and find something we've claimed that you can't independently verify, please tell us and we'll fix it.

How Your Mail Moves

Melia runs entirely on your machine and talks to your mail provider using the standard IMAP and SMTP protocols your provider already supports. Nothing sits in the middle. There is no Melia-owned relay, proxy, or cloud cache.

Your email goes between Melia and your mail server, and the local database sits at ~/.config/melia/, where it stays.

Verify It Yourself in 60 Seconds

Three commands, run on your own machine, that should confirm the central claims on this page. Run them while Melia is open and syncing.

You should see exactly what this page describes. If anything you observe disagrees, please let us know.

Connection Monitor

Melia ships with a built-in Connection Monitor: a toggleable fourth pane in the main application that gives you a live view of every outbound connection the app makes. It lives next to your mail, not buried in a debug menu, because you shouldn't have to wonder what your email client is up to on the network.

The Connection Monitor surfaces every outbound connection Melia makes: DNS lookups, IMAP and SMTP sessions, HTTPS calls to locksmith.buxjr.com, and the HTTPS fetches Melia performs when you choose to load remote images in a message. It taps into the same code paths the rest of the application uses, so it can't show one story to you while doing something different in the background.

Each server gets a row with a color identifier, the protocol (IMAP, SMTP, HTTPS, DNS), the hostname and port, and a call count. Every entry in the Recent Activity feed shows you which of your accounts caused the connection, what it was doing (Sync INBOX, List folders, Reconcile, Primary, DNS Lookup, fetching a remote image, and so on), and how long ago it happened. The whole picture is right there: who Melia is talking to, why, and on whose behalf.

Click any server and you get the full forensic record: total calls, failure count and percentage, first-seen and last-seen timestamps, every resolved IP address, the reverse DNS, which of your accounts use it, and what purposes it's been used for. The Recent Activity feed simultaneously filters to just that server, so you can see exactly how Melia is using it.

Click any individual entry in the Recent Activity feed and you get a card for that one specific call: when it happened, what it was for, whether it succeeded or failed, and (for DNS lookups) the full resolver chain showing your local stub, the upstream servers it forwarded to, and which resolver did the work.

Where it gets genuinely revealing is when you click an “Email opened” event. The card shows the full network cascade Melia made to render that single message: total requests, total bytes, every host contacted, and a categorized inventory of what was fetched — trackers, images, fonts, stylesheets. Tracking pixels are shown with their full URLs intact, campaign IDs and identifiers and all, so you can see for yourself what the sender was trying to learn about you. Anything Melia blocked appears with a fail indicator. What looks on the surface like “I opened a newsletter” becomes, in this view, a forensic record of what that newsletter was trying to do.

The Connection Monitor is session-scoped. It holds up to 5,000 entries in memory and discards them when you quit Melia. Closing the panel doesn't discard anything; the data is still there if you re-open it during the same session. None of it ever gets written to disk or sent anywhere.

What Locksmith Knows About You

Locksmith is our licensing service, hosted at locksmith.buxjr.com. Its job is to enforce per-license machine limits, and that's it. It doesn't know who you are, what email you read, or what addresses you have configured.

The four endpoints, and what they send

That's the whole surface. Requests carry no authentication header, no bearer token, no cookies, and no session; the license key itself acts as the credential. Run tcpdump -A against any of these requests and you'll see the fields above, and nothing else.

The machine ID is not a hardware fingerprint

The machine_id field we send is just the contents of /etc/machine-id, a UUID your operating system generates once at install time. It's stable across reboots, but it isn't derived from your MAC address, your CPU serial, your disk UUID, or any other piece of hardware. You can read your own:

That string is the only machine-identifying data Locksmith ever receives. The device_name field is just your hostname, included once at activation so you can recognize your laptop in the device list (“Buddy-Laptop is one of your 5 active machines”). Locksmith doesn't log IP addresses, and we never see your email address, your hardware details, your account count, or any usage data.

After activation, validation is local

Activation returns an Ed25519-signed token. Melia saves it at ~/.config/melia/license-token.json (file mode 0600, encrypted with a master key held in your OS keyring). From then on, every launch verifies that token offline using a public key embedded in the binary. There's no further network call needed to confirm you're licensed.

Here's the public key:

You can confirm the same key is present in your installed binary:

A forged Locksmith couldn't issue a token your client would accept, because it wouldn't have the matching private key. The cryptographic basis is the same one Debian uses for its package repositories.

Fail-open, on purpose

Block locksmith.buxjr.com at your firewall after activation, and Melia just keeps running as a licensed copy, indefinitely. There's no “you must reach the server within N days or your license expires” clock. The function that checks your license never touches the network; it reads the cached token, verifies the signature, checks the machine ID, and returns.

That's a deliberate trade-off. We'd rather keep validation light and rarely involve the network than tighten revenue control. Heavy-handed phone-home tactics aren't worth alienating the audience we want.

How often Melia contacts Locksmith, in steady state

• Licensed users: one validate every 14 days, plus an update check on launch and every 48 hours while Melia is running.
• Free (unlicensed) users: only the update check. No license data ever leaves your machine.

Verifying the Binary You Downloaded

Every Melia release ships with a SHA256SUMS manifest covering all of the artifacts (.deb, AppImage, Flatpak, tarball), and a detached PGP signature (SHA256SUMS.asc) signed by the Melia release key. The fingerprint is:

The public key is published at melia.buxjr.com/keys/melia-public-key.asc. Verifying any download takes two commands:

This is the same chain of trust Debian, Tor Browser, and Bitcoin Core all use. You trust the published key fingerprint, the key signs the manifest, the manifest names each binary by hash. A single wrong byte will fail verification.

We don't currently offer reproducible builds. Electron's build pipeline makes byte-identical reproduction a meaningful engineering effort, and it's one we haven't taken on yet. Signed checksums are the floor today. Reproducibility may come later for major versions.

Sandboxed by the Kernel

Alongside the standard .deb and AppImage, Melia is built as both a Flatpak and a Snap. Both of those formats run the application inside a kernel-enforced sandbox. Every permission they request (filesystem paths, network access, portals) is declared up front in the bundle metadata, and the kernel refuses anything beyond that, no matter what the application code might try.

If you want the strongest isolation, install Melia as a Flatpak or Snap instead of the .deb or AppImage.

A note on distribution channels. Melia is now listed on the Snap Store — install it with snap install melia and updates flow automatically through snapd. Flathub is still on our roadmap and isn't a current property yet; until that listing exists, we ship the .flatpak bundle directly with every release and you install it locally from the downloaded file. You can also still sideload the .snap from a local file if you prefer, but only the Snap Store channel gives you automatic updates. For any install that doesn't come from the Store, update prompts come from Melia's own update check.

Your Data Stays Yours

Four ways your data stays portable, even if you decide to leave Melia tomorrow:

1. Your mail isn't local-only. Melia is IMAP-first, which means every message already lives on your provider's server. Stop using Melia, point Thunderbird (or mutt, or aerc) at the same account, and you're up and running.
2. Your local cache is inspectable. Melia stores its local data in an unencrypted SQLite database at ~/.config/melia/melia.db. Run sqlite3 ~/.config/melia/melia.db .tables and read it yourself. There's no proprietary format and we don't try to hide anything in there.
3. Your credentials live in your OS keyring. Account passwords and OAuth tokens are kept in your system's native secret-service (GNOME Keyring or KWallet, via libsecret), encrypted by your OS login session. They never sit in plaintext, never appear in the SQLite database, and don't get logged.
4. Your settings are portable. Melia can export your accounts, contacts, trust-center rules, and preferences into a single .meliaconfig file. Credentials are left out on purpose: you re-authenticate on the new machine so secrets never ride along in an exportable file.

Why Gmail Uses an App Password, Not OAuth

Microsoft accounts (Outlook.com, Office 365) authenticate with OAuth2. Gmail and Google Workspace authenticate with a Google App Password — a 16-character, app-scoped secret you generate in your Google account (with 2-Step Verification enabled) and paste into Melia. It's stored encrypted in your OS keyring alongside your other credentials, never in plaintext.

The reason isn't technical. Google's OAuth2 path for IMAP and SMTP falls under their restricted scopes, which require a third-party security assessment called CASA (Cloud Application Security Assessment), performed by a Google-authorized lab. CASA isn't a one-time hurdle — it's a paid audit with annual renewal. Until Melia is established enough to absorb that as an ongoing cost, App Passwords are the supported path. They're a legitimate, Google-blessed authentication method (Gmail still maintains the App Password feature precisely for cases like this); they're just less convenient than a one-click OAuth flow.

When CASA makes financial sense for Melia, we'll go through it and add OAuth2 as an option for Google accounts. Until then, this is the honest answer rather than a marketing one.

If Melia Goes Away

We hope Melia is around for a long time. But you shouldn't have to bet on that.

If Melia development stops (defined as no public release for twelve consecutive months, or formal dissolution of buxjr.com's commercial operation), the complete source code for the most recent shipped version will be released to the public under a permissive open-source license (MIT or Apache 2.0). The release happens within ninety days of the triggering condition.

This commitment lives in our EULA, not just on this page, which makes it a contractual obligation. A temporary slowdown doesn't trigger it; abandonment does. The 90-day window is the deadline for the release itself.

Even before any of that ever matters, your data is portable today. It sits on your IMAP server, in a queryable SQLite file, with exportable settings.

Security Disclosure

If you find a vulnerability in Melia, the application binary, melia.buxjr.com, or locksmith.buxjr.com, please get in touch:

• Email: security@buxjr.com
• PGP: encrypt sensitive reports with our release key.
• Policy: our disclosure policy covers scope, response timelines, and a safe-harbor commitment for good-faith research.
• Machine-readable: /.well-known/security.txt, signed with the same release key.

We aim to acknowledge reports within five business days, share an initial assessment within fourteen, and coordinate public disclosure within ninety days of a fix being available. We won't pursue legal action against researchers who act in good faith within the scope of our policy.

Independent Audit

Melia hasn't yet had a formal third-party security audit. As the project grows, we plan to commission an independent review under NDA and publish the auditor's findings. That's a roadmap commitment, not a current property. We're putting it here so you can hold us to it.

Closed-Source, On Purpose

We've kept Melia's source closed because the IMAP/SMTP stack, the threat-scoring engine, the indexing layer, and the rendering pipeline together took years to build. They're what makes this product worth paying for. Open-sourcing them today would mean giving away the work that funds the project.

That's a commercial decision, and we don't apologize for it. What we offer in place of source review is everything else you've read on this page: a transparent license server, signed releases, sandboxed builds, a built-in Connection Monitor, an inspectable local database, a portable data format, and a contractual promise to release the source if we ever walk away.

So that's the trade. Closed source, but with everything else you'd need to confirm what the software is actually doing. If you got to the end of this page and still have a question we didn't answer, please tell us.

Related: Licensing Transparency (commercial terms, refunds, machine limits) · Inbox Protection (defenses against hostile email) · Privacy Policy · EULA