Security issue reporting guidelines

If you think you have found a security vulnerability in FastMail, please report it to us straight away by emailing bugreport@fastmail.com. Please include detailed steps to reproduce and a brief description of what the impact is. We encourage responsible disclosure (as described below), and we promise to investigate all legitimate reports in a timely manner and fix any issues as soon as we can.

We aim to respond to all emails within 24 hours, although fixing the problem may often take longer. If you don't receive some response to your email with 24 hours, then it's possible a spam filter or other issue has delayed the email. Please try emailing us again from a different account or location.

Responsible disclosure policy

We ask that during your research you make every effort to maintain the integrity of our users' data, avoiding violating privacy or degrading our service. You must give us reasonable time to fix any vulnerability you find before you make it public. In return we promise to investigate reports promptly and not to take any legal action against you.

Bug bounty

As a measure of our appreciation for security researchers, we are happy to give full credit in our public postmortem after the bug has been fixed, and we offer a monetary bounty for certain qualifying bugs. To qualify for the bounty, you must:

• Follow our responsible disclosure policy (see above).
• Report the bug to us first, and give us reasonable time to fix the issue before making it public.
• Be the first person to report the issue to us.
• Use a test account (a free trial account is fine), or an account that you control. Never interact with other accounts without the owner's consent.
• Find a bug that could allow access to private user data, or enable access to a system running FastMail infrastructure.

Examples of valid vulnerability types include:

• Authentication or session management issues
• Cross-Site Scripting (XSS) (only on www.fastmail.com or beta.fastmail.com, not on user.fm or fastmailusercontent.com; see below)
• Cross-Site Request Forgery (CSRF/XSRF)
• Remote Code Execution
• Privilege Escalation

The decision of whether a bug qualifies for a bounty is solely at the discretion of FastMail. Any qualifying bug will be eligible for a bounty of a minimum of US $100 and a maximum of $5,000. The exact value will be determined by FastMail after taking into account the severity of the vulnerability, the number of users potentially affected etc. All bounties will be paid via PayPal. Any taxes or fees are the sole liability of the recipient.

Exclusions

1. Denial of Service (DOS) and social engineering attacks do not qualify and must not be attempted against FastMail or our users under any circumstances.
2. Bugs that require exceedingly unlikely user interaction or are caused by insecurities in browser extensions do not qualify.
3. Brute force log in attempts.
4. The domains user.fm and fastmailusercontent.com are used to host potentially unsafe user content. By keeping this content in completely separate domains, we avoid any security issues with our core fastmail.com domain. As such, any Cross-Site Scripting (XSS) attacks on these sites are not of interest to us. Please note that if you go to a user web site such as http://testuser.fastmail.com it immediately redirects to http://testuser.fastmail.com.user.fm and is thus in the user.fm security domain, not the fastmail.com domain.
5. Bugs on sites associated with FastMail but not run by FastMail do not qualify. This includes blog.fastmail.com and fbl.fastmail.com. We are grateful for any reports on issues with these sites, and we will pass on the bugs to the relevant company, however they do not qualify for a bounty.
6. Anything related to enumeration of usernames does not qualify.
7. Bugs related to unpatched, out of date or exceedingly rarely used browsers or other client software out of our control
8. We are public about the software we run. We are not interested in reports about "leakage" of the fact we run nginx, or the version number, or Perl module names or file paths.
9. Email spoofing bugs do not qualify. We're quite aware that users can set arbitrary From addresses on emails, that our SPF records allow arbitrary hosts to send email as our domains, and that we don't yet have a DMARC policy. These policy decisions are by design, and we track the actual sender in a separate header.

Hall of fame

Our thanks to the following security researchers for their submissions: