Bug Bounty Program Policy

1. Program Introduction

Atmail is committed to protecting our customers and their users. As part of this commitment, we invite security researchers to help protect Atmail and its users by proactively identifying security vulnerabilities through our bug bounty program. The program covers all Atmail brands and technologies and offers rewards for a wide array of vulnerabilities.

These terms exist to protect both sides. Researchers who act in good faith get legal safe harbor, defined response commitments, and a fair appeal process. Atmail gets research conducted within clear boundaries. Read this Policy in full before testing: participation constitutes acceptance of these terms, and the version of this Policy in force at the time you submit a report governs that report.

2. Eligibility and Identity

1. One identity per researcher. You must participate under a single, consistent identity (one email address). Submitting reports under multiple identities, sharing or transferring your reporting identity, or using an alternate identity to circumvent a suspension or ban is prohibited and results in permanent removal from the program and forfeiture of all pending rewards.

2. Excluded persons. Atmail employees (including former employees who separated from Atmail within the prior 12 months), contingent workers, contractors and their personnel, consultants, and the immediate family and household members of any of these, are not eligible for rewards under any Atmail program, whether hosted by Atmail or a third party.

3. Sanctions. You may not participate if you are a resident of, or located in, a country or territory on any U.S. sanctions list (including those administered by the U.S. Department of the Treasury’s OFAC), the Australian Consolidated List (Department of Foreign Affairs and Trade), or the E.U. Sanctions Map, or if you are individually named on any such list. Atmail may accept and act on a report from an ineligible person, but no reward will be paid.

4. Verification before payment. Rewards are paid only to the verified individual who submitted the report — never to third parties, anonymous wallets, or unverified accounts. Taxes on rewards are your sole responsibility.

5. Age. If you are under 18, you may participate only with the consent of a parent or legal guardian, and any reward will be paid to that parent or guardian.

3. Rules of Engagement

By submitting reports or otherwise participating in this program, you agree that you have read and will follow this Policy in its entirety. The following rules are conditions of authorization — testing outside them is not authorized by Atmail.

3.1 Accounts and data

1. Test only against accounts you own or accounts whose holder has given you documented permission to test against. Where possible, register test accounts using the same email address you use to contact Atmail.

2. Never use a finding to compromise or exfiltrate data, escalate beyond the minimum needed for proof, or pivot to other systems. A proof of concept must demonstrate the issue with the least possible data access: read one record or file you control rather than many; demonstrate a write in a location you are permitted to write to; demonstrate execution with harmless commands (id, hostname, pwd).

3. Stop at first proof. Once you have evidence sufficient to demonstrate the vulnerability, stop. Do not establish persistence, install backdoors, move laterally, run internal scans, or repeat exploitation to enlarge impact. If continuing would risk damage or access to data you are not authorized to see: stop, report what you have, and request written permission for further testing.

4. If you inadvertently access sensitive information (personal information, credentials, message content, etc.), you must immediately stop, report the exposure, and permanently delete all copies. Sensitive information must not be saved, stored, transferred, shared, or otherwise processed beyond the moment of initial discovery, and must never appear in public locations (including pastebins, screenshots posted externally, or AI tool prompts).

5. Report promptly. Vulnerabilities affecting live Atmail assets must be reported within 72 hours of discovery. Withholding a known vulnerability — to stockpile it, time its submission, or seek leverage — is a material violation of this Policy.

3.2 Prohibited activities

The following are never authorized, void safe harbor, and result in removal from the program:

1. Social engineering or phishing of Atmail staff, customers, or users

2. Physical attacks against Atmail offices, infrastructure, or personnel

3. Denial of service, resource exhaustion, or any testing that degrades availability or integrity of production systems or data

4. Attacks against Atmail’s third-party suppliers, or any system not explicitly in scope

5. Extortion in any form (see Section 9.2)

6. Spamming forms, notification systems, or Atmail mailboxes

3.3 Traffic identification and rate limits

So we can distinguish your testing from real attacks:

1. Include a custom HTTP header in all testing traffic and state in your report which value you used:

2. Provide your source IP address(es) in your report. We keep this private and use it only to correlate logs with your activity.

3. Rate limit: automated tooling must not exceed 5 requests per second per host. Unattended scanners that fire untargeted payloads are prohibited — their payloads can trigger state changes or damage production systems, and their raw output is ineligible anyway (Section 6).

4. Persistent failure to identify your traffic after a warning may reduce an otherwise valid reward by up to 50%, at Atmail’s discretion. Traffic that is indistinguishable from an attack may be treated as one.

4. Scope

Only assets explicitly listed as in scope are authorized for testing. The scope list may change without notice:

4.1 In scope

All domain scopes exclude any host that is a CNAME alias for a third-party system or is proxied directly to a third-party platform (e.g. billing.atmail.com) — see Section 4.2. Private scope is accessible to invited researchers only.

4.2 Out of scope

4.3 Scope boundaries are not negotiable

1. Testing out-of-scope assets is not authorized and is not covered by safe harbor, regardless of the outcome or of any connection the asset has to an in-scope system.

2. A vulnerability chained through an out-of-scope or third-party vector (for example, compromising a third-party service to reach an in-scope asset) is not authorized and not eligible for reward.

3. If you discover a vulnerability in an out-of-scope Atmail-owned asset accidentally and without deliberate testing, report it to bugbounty@atmail.com. We are grateful for these reports, but do not expect a bounty and do not continue testing the asset.

4. Atmail’s determination of what is and is not in scope is final. Reports on out-of-scope assets carry no appeal rights under Section 11.

5. Crafting a Report

If our security team cannot reproduce and verify an issue, no reward can be awarded. Submissions must include:

1. Description of the vulnerability

2. Step-by-step reproduction instructions

3. A working proof of concept against a live in-scope asset or supported product version (screenshot, video, or PoC code), demonstrating actual exploitability — not theoretical possibility

4. Perceived impact to another user or to Atmail

5. Proposed CVSS vector and base score using the latest published CVSS version (no environmental or temporal/threat modifiers)

6. Affected URLs and parameters; additional vulnerable endpoints and payloads

7. Browser, OS, and/or product version used during testing

8. The X-Bug-Bounty header value and source IP(s) you used

All supporting evidence must be contained within the report itself. Do not host evidence on external services. Submit reports by email, with attachments, to bugbounty@atmail.com.

Failure to meet these minimum requirements may result in your report being rejected, and your report not being recognized before other complete reports for the same issue. reduction or potential loss of reward.

6. Report Quality and Use of Automated Tools

1. Spamming the program by submitting reports based on assumptions, or on automated tool hypotheses without manual verification, is a violation of this Policy and is sanctioned at the same level as the most serious researcher misconduct: removal from the program and forfeiture of pending rewards.

2. Reports that consist of unverified tool output, speculative or fabricated findings, hallucinated code paths or endpoints, or apparent unedited AI generation may be closed without response and without triage, and do not start any timeline under this Policy.

3. Basically, anything reported by passive or active automated scanners is ineligible — we already run these tools ourselves. Scanner or AI output only becomes a reportable finding once you have manually confirmed it and built a working proof of exploitability against an in-scope asset.

4. Repeat-invalid throttle: if you submit three or more invalid, non-reproducible, or fabricated reports within any 90-day period, Atmail may suspend you from the program for six months. Continued low-quality submissions after a suspension result in permanent removal.

5. Knowingly submitting a fabricated report, or a report for a vulnerability you did not discover (plagiarized from another researcher or a public source), is treated as bad faith under Section 9.2.

7. Triage, Duplicates, and First Reporter

1. First reporter wins. You are eligible for a bounty only if you are the first person to report a previously unknown issue. Eligibility is determined by order of receipt of a complete, reproducible report — a vague placeholder submitted to reserve priority, later “completed” with details, takes priority from the completion, not the placeholder. Deliberate placeholder farming is a violation of this Policy.

2. Internally known issues are duplicates. Issues already known to Atmail — discovered internally, found in a prior penetration test or audit, reported by another researcher, or tracked by our n-day monitoring team — are not eligible. Where we close a report as internally known, we will on request provide reasonable evidence (such as an internal ticket reference and its creation date).

3. One root cause, one reward. Once a vulnerability is reported, it is reported. The same bug appearing on a different host, endpoint, parameter, or payload variant is the same vulnerability and earns no additional payment. Note any additional affected instances within your existing report — it helps remediation and we appreciate it — but reports of the same root cause filed separately are closed as duplicates with no reward.

4. Splitting one root cause across multiple reports, identities, or collaborators to multiply payouts is a violation of this Policy.

8. Severity, Rewards, and Payment

8.1 Severity assessment

Severity is assessed against the latest published CVSS version using the base score as a starting point, adjusted by Atmail for actual business impact and environmental context in our deployments. Your proposed CVSS vector is an input we genuinely consider; the final severity classification and reward amount are determined by Atmail in its sole discretion, subject only to the appeal process in Section 11.

8.2 Payout table

Reports are classified against the Common Weakness Enumeration. The table below lists the classes we accept, with example findings. It carries no severity pre-assignment: severity is determined per report by Atmail under Section 8.1, based on demonstrated impact in our environment. Non-listed vulnerability classes may also be eligible.

8.4 Payment terms

1. Rewards are paid within 30 days after Atmail awards the bounty. Delays caused by incomplete researcher documentation do not count against this window.

2. Rewards are discretionary good-faith payments. They are not wages, fees for service, or contractual debt; payment of a reward is not an admission of fault, liability, or the severity of any issue.

3. This program does not create any employment, agency, partnership, or contractor relationship between you and Atmail.

9. Ineligible Findings and Conduct

9.1 Ineligible findings (“borderline / no bounty”)

The following may be submitted and, if valid, will be closed as Informative ($0); if invalid, as Spam. They are excluded because they lack demonstrated real-world impact — when reporting, always consider (1) a plausible attack scenario and (2) actual security impact. Exploitability must be demonstrated, not asserted.

Email and DNS posture (we are an email company — these are checked continuously and reports add no value):

• Incomplete or missing SPF/DKIM/DMARC/BIMI records, including on parked or non-mail domains

• Mail server banner or software version disclosure

• Email spoofing claims without a bypass of an enforced control

Theoretical or self-inflicted:

• “Self” XSS and “self” exploitation; issues requiring unlikely user interaction

• Clickjacking/UI redressing on pages with no sensitive state-changing actions

• Login/logout/unauthenticated CSRF and CSRF with minimal security impact

• Open redirects without additional demonstrated impact; reflected file download

• Tabnabbing, content spoofing, text injection; Flash-based anything

• HTTP Host header XSS; autocomplete attributes on web forms

• CSV injection

Hardening preferences without proof of exploitability:

• Missing security HTTP headers; missing cookie flags; CSP preferences

• SSL/TLS configuration best practices; use of known-vulnerable library versions without a working exploit in our deployment

• Verbose error pages; software version disclosure; account/email enumeration without demonstrated PII exposure

• Most rate-limiting issues; general best-practice concerns

Prohibited-to-test (also Policy violations, not just ineligible):

• Results of automated scanners without verification

• Denial of service; physical attacks; social engineering

• Internal pivoting, scanning, exploiting, or data exfiltration beyond minimal PoC

• Issues in third-party services, or anything that resolves to third-party infrastructure

9.2 Bad-faith conduct (per-se violations)

The following are treated as bad faith. They immediately and permanently remove you from the program, void safe harbor retroactively for the related conduct, forfeit all pending rewards, and may be referred to law enforcement — they skip the strike ladder in Section 9.3 entirely:

1. Extortion or coercion — including conditioning the report, its details, or non-disclosure on payment; demanding amounts beyond the published payout table; threatening publication, regulator contact, media contact, or customer contact to influence triage, severity, or payment; or “selling” the vulnerability back to us. A demand with a deadline attached to a threat is extortion regardless of how it is phrased.

2. Ban evasion or identity abuse — circumventing a suspension or ban via another identity; sock-puppet submissions (Section 2.1).

3. Data theft or destruction — exfiltrating, retaining, publishing, or selling Atmail or customer data; modifying or destroying data or systems beyond a minimal authorized PoC.

4. Unauthorized disclosure after a written warning, or any disclosure carried out as leverage.

5. Fabrication — knowingly false reports, fabricated evidence, or claiming another’s work.

9.3 Strike system (all other violations)

Other Policy violations earn strikes, scaled to intent, impact, and repetition. One strike may also reduce or void the reward on the affected report.

10. Coordinated Disclosure

10.1 Your obligations

1. Do not publicly disclose a vulnerability, or share any details with anyone other than authorized Atmail personnel, without Atmail’s express written permission. This includes conference talks, blog posts, social media, CVE requests, and sharing with other researchers or platforms.

2. Disclosure before a fix is available, without written permission, forfeits the reward for that report and eligibility for all future Atmail rewards, in addition to any strike or per-se consequence.

10.2 Atmail’s commitments

So that the embargo is not open-ended, Atmail commits to:

1. Acknowledge receipt of your report within 7 days.

2. Communicate a triage decision (accepted / duplicate / informative / declined) within 30 days of acknowledgment for complete, reproducible reports.

3. Make every effort to remediate accepted vulnerabilities within 90 days of triage, and keep you informed of material status changes.

4. Consider, in good faith, requests for coordinated public disclosure after remediation, including researcher credit where requested.

10.3 Backstop

If Atmail has provided no substantive response for 180 consecutive days despite your documented good-faith attempts to follow up, you may disclose the vulnerability publicly as a last resort, limited to the minimum detail necessary, and excluding any Atmail or customer data. This backstop does not apply while Atmail is actively communicating a remediation timeline, and never applies to reports tainted by Section 9.2 conduct.

10.4 n-day and third-party CVEs

Vulnerabilities in third-party components bundled with Atmail products for which a public CVE or PoC exists (“n-days”) may be reported no earlier than 30 days after initial publication, and are eligible only if you demonstrate actual exploitability in a supported Atmail deployment. Our n-day tracking team monitors public disclosures; issues already identified and internally ticketed by that team are not eligible (evidence available on request under Section 7.2). Merely reporting a version match against a CVE database is ineligible (Section 9.1).

11. Disputes and Appeals

1. You may appeal a triage outcome, severity classification, reward decision, or sanction once per report or sanction, in writing to security@atmail.com, within 30 days of the decision, and only on the basis of new technical evidence or a specific, articulated error in the original assessment. “I believe it deserves more” without new substance is not grounds for appeal.

2. Appeals are peer-reviewed: an Atmail security team member other than the original triager re-assesses the report and the new evidence, with a response target of 30 days.

3. Opening multiple threads, re-submitting the same report, escalating to unrelated Atmail staff or executives, or contacting customers to relitigate a decision is a Policy violation, not an appeal.

4. Reports on out-of-scope assets, reports closed under Section 6.3 (unverified/AI-generated), and Section 9.2 determinations are not appealable.

5. Following the appeal decision (or the lapse of the appeal window), all Atmail decisions under this program are final and binding.

12. Safe Harbor

Atmail considers security research conducted in good-faith compliance with this Policy to be authorized, and:

1. Atmail will not initiate or support legal action or a law enforcement investigation against you in response to such research or reporting, including for accidental, good-faith violations of this Policy;

2. Atmail waives any restrictions in its Terms of Service and Acceptable Use Policy that would conflict with research authorized by this Policy, solely for the limited purpose of that research;

3. If a third-party initiates legal action against you and you have complied with this Policy, Atmail will take reasonable steps to make it known that your actions were conducted in compliance with this Policy.

Limits of safe harbor:

• Safe harbor is conditional on good faith. Research conducted for the purpose of extortion, data theft, or any Section 9.2 conduct is not in good faith, is not authorized, and receives no protection — retroactively, for the conduct concerned.

• Safe harbor covers only in-scope assets (Section 4). Atmail cannot and does not authorize research against third parties — including our suppliers, CDN and hosting providers, and customers’ own systems — and they are not bound by this safe harbor.

• You remain responsible for complying with all applicable laws and regulations.

• If you are unsure whether contemplated conduct is consistent with this Policy, ask first via security@atmail.com before proceeding.

13. Legal Terms

1. In connection with your participation, you agree to comply with Atmail’s Terms of Service and Privacy Policy (except as waived in Section 12), and all applicable laws and regulations, including those governing privacy and lawful data processing.

2. Atmail does not authorize anyone to (a) extract personal information or content of Atmail customers or their users, or publish such information, or (b) modify or corrupt Atmail programs or data in order to extract and publicly disclose data.

3. Atmail may amend, suspend, or terminate this program, in whole or in part, at any time. Each report is governed by the Policy version in force when that report was submitted.

4. This program is a discretionary reward program, not a competition, offer, or contract for services.

5. This Policy is governed by the laws of the State of Queensland, Australia, and the parties submit to the exclusive jurisdiction of the courts of the State of Queensland. Australia.

14. Questions

Questions about Atmail’s Bug Bounty Program: security@atmail.com. If you want to do something this Policy doesn’t clearly address, ask before you act. Thank you for helping keep Atmail and its users safe