Files

T

jcoffey-dev bb25355c23 AGPL source offer and name cleanup

Every build writes the exact source it was built from, uncommitted work and
new files included, as source.tar.gz next to the app, named after that tree.
Docker builds, which have no git, pack the build context and name it by a
hash of its files. The sign-in page and Settings > About link to it instead of
a repository that can drift.

What users, operators and packagers see no longer names the upstream server:
- interface text, in all nine catalogues, with a token-session line for
  Security;
- server messages;
- the settings, now MAIL_SERVER_URL, MAIL_SERVERS_FILE, ADMIN_URL and
  MAIL_SERVER_FOLLOW_ADVERTISED_URLS, and mail-servers.example.json;
- the Tenants notice, which is gone;
- the README, CONTRIBUTING and SECURITY.

ihasmail's own FEATURES, KNOWN-ISSUES and ROADMAP stay with public ihasmail,
and INBUXA.md is folded into the README.

2026-09-19 00:13:12 -07:00

2.6 KiB

Raw Blame History

Security Policy

Supported Versions

ihasmail is under active development. Security fixes are applied to the latest release on the main branch. Older tags/releases are not guaranteed to receive backported fixes.

Version	Supported
`main` (latest)	✅
Older releases	❌

Reporting a Vulnerability

Please do not open a public GitHub issue for security vulnerabilities. Public issues are visible to everyone, including potential attackers, before a fix is available.

Instead, report security issues privately by emailing:

johnellisATlinuxDOTcom

Please include as much of the following as you can:

A description of the vulnerability and its potential impact
Steps to reproduce, or a proof-of-concept
The version/commit of ihasmail affected
The version of the mail server you were testing against, if relevant
Whether the issue is in the webmail itself, in how it talks to the mail server over JMAP, or in a dependency

What to Expect

Acknowledgment: You should receive a response within a few days confirming the report was received.
Assessment: The issue will be triaged and its severity assessed. Because ihasmail holds no data of its own and relies entirely on the mail server's store over JMAP, some reports may need to be routed to or coordinated with the mail server's own project if the root cause lives there rather than in ihasmail's client code.
Fix & disclosure: Once a fix is ready, a new release will be published. We'll coordinate with you on public disclosure timing and credit, if you'd like to be credited.

Scope

In scope:

Authentication and session handling in ihasmail
Cross-site scripting (XSS), CSRF, or injection issues in the webmail UI
Improper handling of JMAP responses that could lead to data leakage between accounts
Dependency vulnerabilities that are actually exploitable in ihasmail's usage

Out of scope (please report upstream instead):

Vulnerabilities in the INBUXA mail server itself: report those to the mail server's own project
Vulnerabilities in third-party libraries with no demonstrated impact on ihasmail
Issues requiring physical access to a user's device or an already-compromised mail server

Disclosure Policy

We follow coordinated disclosure: please give us a reasonable window to investigate and release a fix before any public disclosure. In turn, we'll keep you updated on progress and won't leave you waiting indefinitely.

Thank you for helping keep ihasmail and its users safe.

2.6 KiB Raw Blame History