# Security policy

We believe in transparency to mitigate security risks. All known vulnerabilities are available on 
our [security page](docs/modules/ROOT/pages/security.adoc).

We disclose such security issues only once a released version addressing the issue is available.

We use automated tools to review our docker images and dependencies.

# Reporting security vulnerabilities

To ensure safety of our users, security process needs to happen privately.

Here are the steps:

 - 1. Reporter email the issues privately to `openpaas-james[AT]linagora.com`.
 - 2. We will then evaluate the validity of your report, and write back to you within two weeks. This response time 
 accounts for vacation and will generally be quicker.
 - 3. We will propose a fix that we will review with you. This can take up to two weeks. 
 - 4. We will propose a draft for the announcement that we will review with you. 
 - 5. We will propose you a schedule for the release and the announcements.
 - 6. One week after the release we will disclose the vulnerability.
 
You will be credited in the vulnerability report for your findings.

# Threat model

The following threats are generic points of attention for email softwares:

 - Virusses: Emails are one of the vector for spreading virusses. We recommend administrators to set up virus scans
as part of their email infrastructure. We recommend user to be cautious opening attachments of unknown senders or
suspicious emails. We recommend users to have an anti-virus installed. For instance [TeamMail backend](https://github.com/linagora/tmail-backend/) is integrated with 
[ClamAV](https://www.clamav.net/) solution.
 - Fishing: Attackers can try trick users on their identity and try to make them believe they are a legitimate sender and try to use
this to either make user conduct actions or leak information. We recommend administrator to run an anti-Spam software, to verify SPF and DKIM
records. For instance [TeamMail backend](https://github.com/linagora/tmail-backend/) is integrated with [RSpamD](https://rspamd.com/) solution.
 - `Authentication`. We recommend administrator to set up strong authentication with an OIDC provider. This avoids TeamMail frontend to store directly user credentials,
enable configuring handy features like two factor authentication and the like. For instance [TeamMail backend](https://github.com/linagora/tmail-backend/) is integrated
with [LemonLDAP](https://lemonldap-ng.org/) identity provider using the [Apisix](https://apisix.apache.org/) API gateway. We also recommend users to logout once they finished using TeamMail.
 - HTML rendering. By design, email embeds HTML generated by non trusted sources. TeamMail do sanitize HTML prior displays. The use of the canvas also limits the 
impact of HTML rendering related vulnerabilities. Loading of remote resources like images can also be used for tracking purposes. As off today, TeamMail do not allow 
blocking such tracking attempts.

TeamMail today relies on [Firebase Cloud Messaging](https://firebase.google.com/docs/cloud-messaging) for its push architecture. 
Only StateChanges are transiting though a third party, which to not include presonnal data.
