✉ Inovamail
← Legal Center

Inovamail Legal

Law Enforcement Guidelines

Effective: [EFFECTIVE DATE] · Last updated: [LAST UPDATED DATE] · Version [VERSION]

These guidelines explain how law enforcement and government agencies can request data from Inovamail. We require valid legal process enforceable in Canada. Because Inovamail uses zero-knowledge, end-to-end encryption, we cannot provide the content of E2E-encrypted messages or a user's encryption keys or passphrase — we do not have them and cannot decrypt them. This summary is for convenience and does not replace the full text below.

Contents

  1. 1. Purpose & audience
  2. 2. Due process & user privacy
  3. 3. Valid legal process required
  4. 4. What zero-knowledge encryption means
  5. 5. Data we may be able to provide
  6. 6. Emergency disclosure requests
  7. 7. Data preservation requests
  8. 8. Notice to users
  9. 9. Transparency reporting
  10. 10. Cost reimbursement
  11. 11. How to serve requests
  12. 12. No waiver

1. Purpose & audience

These Law Enforcement Guidelines ("Guidelines") are intended for law enforcement agencies, government authorities, and their authorized representatives seeking information about a user of the Inovamail service (the "Service"), operated by [LEGAL ENTITY NAME], a company registered in Canada.

They describe the legal process we require, what data we may and may not be able to provide, and how to submit a request. They are provided for informational purposes, do not constitute legal advice, and do not create any right or expectation on the part of any person. They may be updated from time to time, and we may deviate from them where the law or the circumstances require.

Users seeking to understand how their personal data is handled should refer to our Privacy Policy.

2. Our commitment to due process & user privacy

Inovamail is a privacy-first service. We are committed to protecting our users' privacy and to responding to government requests consistently with due process and applicable law. We disclose user data only where we are legally compelled to do so by valid process, or where a narrow exception (such as a genuine emergency, Section 6) applies.

We review each request on its own facts. We may object to, narrow, seek to quash, or reject requests that are legally deficient, overbroad, vague, unduly burdensome, or not properly served, and we require requests to be limited to the specific data reasonably needed for the stated investigation.

3. Valid legal process required

We require lawful process that is valid and enforceable in Canada before disclosing any non-public user data. Depending on the data sought, appropriate process may include a Canadian court order, production order, warrant, or other lawful demand issued under Canadian law and sufficient in law to compel the disclosure requested.

Foreign requests

  • Requests from authorities outside Canada should ordinarily proceed through a Mutual Legal Assistance Treaty ("MLAT") or letter rogatory, or otherwise be domesticated through a Canadian court so that the resulting process is enforceable in Canada.
  • We are generally not able to act on foreign legal process directly unless it is recognized or given effect under Canadian law.

Requirements for all requests

  • Be issued by an authority with jurisdiction and be properly served (Section 11);
  • Identify the requesting agency, the responsible official, and a return contact;
  • Identify the specific account(s) with precision (for example, the exact Inovamail address) and the specific data sought;
  • State the legal authority for the request and any applicable deadline; and
  • Be as narrowly tailored as reasonably possible.

We reserve the right to require that legal process be valid, current, and served through the channels in Section 11, and to reject requests that do not meet these requirements.

4. What zero-knowledge encryption means for requests

We cannot provide what we do not have. Inovamail uses zero-knowledge, end-to-end ("E2E") encryption. The content of E2E-encrypted messages and files is encrypted on the user's device or in the user's session with keys derived from a passphrase we never receive. Accordingly, Inovamail cannot provide the plaintext content of E2E-encrypted messages, and cannot provide user encryption keys, private keys, or passphrases, because we do not possess them and are technically unable to decrypt the content. No valid legal process can compel us to produce data we do not have or to break encryption we cannot break.

  • We cannot decrypt E2E-encrypted content, and we cannot recover a lost passphrase or the data it protects — this is a property of the design, not a policy choice.
  • We do not maintain a "master key," backdoor, or escrow that would let us or anyone else decrypt user content.
  • Where content is stored by us, it is stored as ciphertext; producing it would yield only encrypted, unintelligible data.

A request that seeks decrypted content or user keys will be met with a response explaining that the data is not available to us for the reasons above.

5. Data we may be able to provide with valid process

Subject to valid legal process (Section 3) and to what actually exists and is retained at the time of the request, the categories of data we may be able to provide are limited. Depending on the account and applicable data-retention practices, these may include:

  • Basic subscriber / account information — such as an account identifier, the address(es) associated with an account, account creation date, and plan or subscription status;
  • Limited billing information — such as the existence of a subscription and non-sensitive billing records (we do not store full payment-card numbers; payment data is handled by our payment processor);
  • Certain metadata and logs, as available — such as connection/IP logs and timestamps that we retain for security and operational purposes.

We collect and retain only limited data, and we do not have data we never collected or that we no longer retain. Metadata that exists is described in general terms above; the specifics available in any case depend on what was collected and retained. This section does not create any obligation to collect, generate, or retain data we would not otherwise hold.

See our Privacy Policy for a fuller description of the categories of data we process and our retention approach.

6. Emergency disclosure requests

In narrow circumstances, we may voluntarily disclose limited information to a government authority without legal process where we have a good-faith belief that an emergency involving a risk of death or serious physical harm to a person is imminent and that disclosing information without delay may prevent or mitigate that harm.

  • Emergency disclosure is at our discretion and is limited to information reasonably necessary to address the emergency;
  • An emergency request must be submitted by an authorized official, on official channels, and must document the nature of the emergency, the specific danger, why it is imminent, and how the requested information relates to it;
  • We may require the request to be made on our emergency-request form or to include sufficient detail for us to assess it in good faith; and
  • Our zero-knowledge limits (Section 4) apply in an emergency exactly as they do otherwise — an emergency does not enable us to decrypt E2E-encrypted content.

7. Data preservation requests

We will consider properly submitted requests to preserve data that is within our possession and control and that we are able to preserve, pending the service of valid legal process, as required or permitted by applicable law.

  • A preservation request should identify the specific account(s) and the data to be preserved, and identify the requesting agency and official;
  • Unless applicable law provides otherwise, we will preserve responsive data for the period required by law or, absent a specified period, for a reasonable period (for example, up to ninety (90) days), which may be extended once on a further request;
  • A preservation request does not compel disclosure; disclosure still requires valid legal process (Section 3); and
  • We can only preserve data that exists and that we retain — a preservation request does not require us to create, decrypt, or begin collecting data.

8. Notice to users

Our policy is to notify affected users of a request for their data before disclosure, so that they may seek to protect their rights, unless:

  • We are legally prohibited from doing so (for example, by a valid non-disclosure order, sealing order, or statute);
  • Notice is prohibited or would be counterproductive in a genuine emergency (Section 6); or
  • We reasonably believe notice would be futile, or would risk harm to an individual, to the integrity of an investigation, or to the safety of others.

Where we are temporarily barred from giving notice, we may provide notice after the prohibition lapses. Requesting agencies that seek to prevent notice should provide an appropriate legal basis (such as a non-disclosure order); a bare request not to notify, without legal basis, may not be sufficient.

9. Transparency reporting

Consistent with our commitment to transparency, Inovamail intends to publish periodic transparency reports containing aggregate information about the government and law-enforcement requests we receive and how we respond, to the extent permitted by law. Nothing in these Guidelines requires us to disclose information whose disclosure is prohibited by law or by a specific order.

10. Cost reimbursement

Responding to legal process can require significant time and resources. Where permitted by applicable law, we may charge and seek reimbursement of the reasonable costs we incur in searching for, retrieving, and producing data in response to legal process. We will inform the requesting agency of any applicable cost recovery in advance where practicable.

11. How to serve requests

Legal process, emergency requests, and preservation requests should be directed to:

Legal — Law Enforcement Response, Inovamail
Email: [LEGAL EMAIL]
Mail: [LEGAL ENTITY NAME], [NOTICE ADDRESS]

  • Please include a return email and telephone contact for the responsible official, a clear statement of the legal authority relied on, and any deadline;
  • Identify the account with precision (for example, the exact Inovamail address); requests that do not identify a specific account may be rejected;
  • Mark genuine time-sensitive matters clearly (for example, "Emergency Request" or "Preservation Request") in the subject line; and
  • Our acceptance of a request through these channels is not an admission that the request is valid or that we possess responsive data, and does not waive any objection or requirement of proper service.

12. No waiver of rights or of user protections

Nothing in these Guidelines constitutes a waiver of any right, defense, objection, or privilege of Inovamail or of any user, including the right to challenge, narrow, or seek to quash any request, or to require valid legal process. Our provision of these Guidelines, our response to any request, or our voluntary provision of information in an emergency does not (a) admit the validity or enforceability of any request, (b) waive any objection or immunity, (c) create any obligation to collect, generate, retain, or decrypt data, or (d) diminish the privacy protections we provide to users. These Guidelines may be changed at any time without notice and are subject to applicable law.

Inovamail is operated by [LEGAL ENTITY NAME], a company registered in Canada (Business No. [BUSINESS NUMBER]), [REGISTERED ADDRESS].

Terms of Service Privacy Policy Acceptable Use Anti-Spam Cookies DPA Subprocessors Refunds Copyright/DMCA Law Enforcement SLA Security

© [EFFECTIVE DATE] [LEGAL ENTITY NAME]. Inovamail and the Inovamail logo are trademarks of their owner. Contact: [SUPPORT EMAIL].