01 How to report a vulnerability
Email security@supermailos.com. A person who can fix the problem reads every report. Please include:
- what you found and where (the URL, API endpoint, or mail host and port);
- the steps to reproduce it, and any proof-of-concept code or requests;
- the impact as you understand it: what an attacker could read, change, or do;
- how to reach you, and whether you'd like to be credited.
Please report first and privately. Don't post details publicly, open a public issue, or share them with anyone else until we've agreed a disclosure date (see below).
02 What to expect from us
These are our targets for every report:
- Acknowledgement within 2 business days.
- An initial assessment (confirmed or not, and a severity) within 5 business days.
- Updates at least weekly until it's resolved.
- A fix for critical issues within 7 days and for high-severity issues within 30 days; lower-severity issues are scheduled with the rest of our work.
We'll tell you when the fix is live. With your permission we'll credit you by name or handle once it is. We don't run a paid bug bounty at the moment.
03 In scope
- The website and web app at supermailos.com, including sign-up, login, two-factor authentication, sessions, and workspace administration.
- The public REST API (/api/v1) and API keys, and the signed webhooks we send.
- The mail service we operate for customer domains: IMAP, SMTP submission, inbound mail (MX), and the DNS records and authentication (SPF, DKIM, DMARC, MTA-STS) we generate and manage.
- Isolation between workspaces: any way to read, change or send as another workspace's mail, mailboxes, domains or users is the most serious class of report we can receive.
04 Out of scope
- Denial of service, load or stress testing, and anything that degrades the service for others.
- Sending spam or unsolicited mail, or mail to addresses you don't own.
- Social engineering or phishing of our staff or customers, and physical attacks.
- Automated scanner output with no demonstrated, exploitable impact.
- Missing security headers, cookie flags, TLS cipher preferences or version banners without a working exploit.
- Self-XSS, clickjacking on pages with no sensitive action, CSRF on logout, and rate-limit observations without real impact.
- Email configuration of domains we don't manage, or choices a customer made in their own DNS.
- Vulnerabilities in third-party services we use (for example our payment provider) — please report those to the vendor.
05 Rules for testing
- Only test against accounts, workspaces and domains you own or have explicit permission to test. A free trial workspace is fine.
- Never access, change, or delete other people's data. If you reach someone else's data by accident, stop, don't keep or share it, and tell us what you saw.
- Use the minimum access needed to show the problem, and don't pivot further into our systems.
- Don't run tests that could disrupt mail delivery or the sending reputation of our IP addresses or customers' domains.
- Give us a reasonable chance to fix the issue before disclosing it.
06 Safe harbour
If you make a good-faith effort to follow this policy, we consider your research authorised. We will not take legal action against you or ask law enforcement to investigate you for it, and if a third party takes action against you for research done under this policy, we'll make it known that you acted with our authorisation.
This doesn't cover deliberately harming users or our service, accessing or keeping data beyond what's needed to demonstrate the issue, or demanding payment in exchange for not disclosing a vulnerability.
If you're unsure whether something is allowed, ask us first at security@supermailos.com.
07 Coordinated disclosure
We'll agree a disclosure date with you. By default you're free to publish once the fix is live, or 90 days after your report if we haven't fixed it by then — unless we've agreed otherwise because a fix needs longer and the risk to customers justifies it.