Security Policy and Vulnerability Disclosure

Last updated: September 26, 2026

This page explains how to report a security vulnerability in Smailor, what we commit to in return, and what testing is and is not permitted. It is the disclosure process referred to in the Acceptable Use Policy and the DPA.

1. How to report

Email [email protected], or use the reporting form on smailor.com/security.

Please include:

• what you found and why it matters;
• the exact steps, request, or proof of concept needed to reproduce it;
• the affected URL, endpoint, host, or app version;
• the account or test data you used; and
• how you would like to be credited, if at all.

Encrypt or redact any personal data or credentials you need to show us. If you believe a vulnerability is being actively exploited, say so in the subject line.

2. What we commit to

• Acknowledgement within 3 business days.
• An initial assessment and severity view within 10 business days.
• Regular updates while we work on a fix, and notification when it ships.
• Credit in our acknowledgements if you want it, once the issue is resolved.
• We will not take legal action against you, or ask your employer or hosting provider to, for research carried out in good faith within Section 4.

We are a small operation and we do not run a paid bug bounty. We have no budget for rewards, and we will not negotiate a payment in exchange for withholding or disclosing a report. Please report anyway — we take it seriously.

3. Disclosure

Please give us a reasonable period to fix an issue before publishing — 90 days from our acknowledgement is our normal expectation, or sooner once a fix is live. If you believe users are at immediate risk and we are not responding, tell us you intend to publish and give us a date. We will not ask you to stay silent indefinitely.

4. Permitted testing

You may test against your own account and data. In doing so you must:

• stay within your own account, data, and infrastructure, and stop at the first sign that you can reach someone else's;
• not access, modify, download, retain, or disclose another person's data, mail, or credentials — a single record is enough to prove an access-control flaw, and you must delete it and tell us;
• not run denial-of-service, load, stress, or volumetric tests, or anything that degrades service for others;
• not send spam, phishing, or unsolicited mail to third parties from the platform, including as a test;
• not use social engineering, phishing, or physical intrusion against us, our users, or our providers;
• not test the systems of our providers, marketplace sellers, or customers — their infrastructure is not ours to authorise;
• use your own test accounts, not accounts you do not control, and not credentials found elsewhere;
• avoid automated scanning that generates high volumes of traffic, and identify your traffic where you can; and
• not exploit an issue beyond what is needed to demonstrate it, and not leave backdoors, persistence, or planted data behind.

Testing outside these limits is not authorised, is a breach of the Acceptable Use Policy, and forfeits the protection in Section 2.

5. Out of scope

The following are usually not accepted as vulnerabilities on their own:

• missing security headers or cookie flags with no demonstrated impact;
• reports generated solely by an automated scanner, with no analysis or proof of exploitability;
• rate-limiting or brute-force findings on non-sensitive endpoints without demonstrated impact;
• self-XSS, clickjacking on pages with no sensitive action, or issues requiring a fully compromised device or browser;
• SPF, DKIM, or DMARC configuration on domains we do not control, including customer and seller domains;
• email spoofing that our published authentication records already mitigate;
• outdated browsers, unsupported platforms, or third-party services we merely link to;
• disclosure of information that is already public;
• the deliberate design choices we document, such as mail not being end-to-end encrypted, the reversible storage of credentials that must be replayed to work, or open tracking being available as a feature.

If you think one of these has real impact in our specific case, explain the impact and we will look.

6. Our own security posture

Our current technical and organisational measures are described in DPA Section 7 and summarised on the Trust page, including what is encrypted and what is not. In outline: EU hosting, TLS 1.2+ in transit, storage encryption at rest at the infrastructure layer, hashed login and mail-access credentials, role-based and per-route access control, rate limiting, security logging with monitoring, and tested backups.

Incident response. Confirmed security incidents involving personal data trigger the notification procedure in DPA Section 6 — supervisory authority and affected individuals where the law requires, and business customers without undue delay and in any event within 72 hours of our becoming aware.

7. If your own account is compromised

Contact [email protected] immediately, and in the meantime: change your Smailor password, revoke every mail access credential for the affected mailboxes, revoke API keys and webhook secrets, disconnect third-party integrations and revoke their tokens at the provider, and review your routing, forwarding, and auto-reply rules for changes you did not make. We can help you audit recent access.

8. Contact