Inventory: what we will keep about you

The inventory is printed as decisions are made: what is decided becomes its first rows.

What we will keep

What we will keep, why and for how long, and what you turn on yourself.

Account and sign-in

• Your addresses and aliases. Why: without them, mail cannot find your mailbox. How long: as long as the account exists.
• A record for signing in with your password (OPAQUE). The password itself will not reach us, not even when you sign in. Why: to check your password without learning it. How long: as long as the account exists.
• Your keys, only in wrappers that will open with your password, recovery phrase or passkey. We will not be able to open them without you. A new device will get the key from an old one in encrypted form: we won’t be able to read it on the way. Why: so that your devices get the keys and we do not. How long: as long as the account exists.
• The public keys of your addresses, in a public key log. Why: so others can encrypt email to you, and a swapped key can be detected: Methmail will check keys against the log. The log can’t rule out a swap in advance, and external PGP programs don’t check it. How long: the log will be append-only.
• An entry for your address in the key log after you delete your account. Even before that, the address will be kept there not in the clear but as an irreversible hash with a proof (VRF). After deletion, the key will be replaced with a deletion mark; the address hash and the technical data for checking the log (commitments) will remain. The address cannot be read from the hash, but we will be able to confirm or deny someone’s guess that we had such an address. Why: so the log cannot be quietly rewritten. How long: forever.
• The hash of a deleted address or alias on a Methmail domain. We will not keep the address itself. Why: so the address cannot be taken again; otherwise a new owner would get the previous owner’s mail, including password resets from other services. How long: forever.
• The public parts of your passkeys and hardware keys, and a use counter for each: that is how the standard works (WebAuthn). For passkeys that sync between devices, it is usually zero. Why: to check sign-ins. How long: until the key is removed.
• The secret for 2FA codes from an authenticator app, encrypted with our service key. The server has to know it to check the codes: that is how TOTP works. A passkey needs no such secret. Why: to check the codes. How long: while 2FA is on.
• Your sessions: a random number; the public part of the device key that will sign each request; the device name, encrypted with your key, which only you will see. We will keep session dates to the day: the day you signed in and the day the session was last used, with no time. Why: so you can see and revoke any session and tell which device you haven’t used for a while. How long: until you sign out, revoke it, or it goes unused for 30 days, and no longer than 90 days after sign-in.
• Recovery email, as a hash only. It will be optional. If you add one, we will store only its hash: to reset your password, you will type the address yourself. We won’t be able to hand over your recovery address; we will only be able to confirm or deny someone else’s guess. When you add a recovery address and when you reset your password, our server will see it, to compute the hash and to send the link. On a reset, that address’s mail provider will see an email from Methmail, but not your Methmail address. A court will be able to order us to record the address at one of those moments (exceptions: part 4). Why: so you can regain access without us holding your second address. How long: while the address is set.
• The account’s service state: the day it was created; the sending trust level, “new” or “verified”; the sending status: allowed or paused, with one reason out of four: complaints, undelivered email, a review held an email, a team decision; pending security changes and the hour they take effect: external forwarding, new recovery methods (including a passkey with account recovery turned on), a password reset or account deletion without the recovery phrase or a passkey with account recovery turned on, a change of password or second factor from a session younger than 7 days without the phrase or a passkey with account recovery turned on; delivery statuses of your mail to external addresses, with the hour until which the status is kept: it will show the hour the message was sent. Why: anti-spam limits will grow with the account’s age; these pending changes will take effect after 7 days (after 72 hours if one of your devices has been signed in for more than a week); to show whether a message arrived. How long: as long as the account exists; a sending pause until it’s lifted; once lifted, it will leave nothing in the account’s data, and the staff member’s action will stay in the staff action log (1 year); pending changes until they take effect or are cancelled; delivery statuses until your device picks them up, at most 48 hours.
• Today’s sending count: how many emails and recipients left the mailbox for other providers today. Why: daily and hourly sending limits. How long: until the end of the day in UTC, then deleted; not included in the daily copies.
• The hour of a new mailbox’s last email: for the first 7 days after the mailbox is created, we will keep the hour of the last email to other providers, for the current day only. Why: an hourly limit for new mailboxes. How long: until the end of the day; not included in the daily copies.

Only if you turn them on. These will be off by default:

• Server-side filter rules. They will be stored in the clear, and you will see a warning about it. Why: so a rule works while your devices are off. How long: as long as the rule exists.
• A forwarding address at another service. Only mail that arrived from other providers unencrypted will be forwarded, and it will leave in plain text; you will see a warning about it. The server won’t be able to forward mail from Methmail users or mail encrypted with PGP. Why: to forward. How long: while forwarding is on.
• A log of your sign-ins with IP addresses. It will be encrypted with your key, and only you will be able to read it. Why: so you can see where you signed in from. How long: 90 days, then it will be deleted; you will be able to delete it sooner.
• How many entries your sign-in log has per week, if you turn it on, that is, how many times a week there was a sign-in. The entries themselves (time, device, IP) will be encrypted with your key. Why: to delete entries after 90 days without reading them. How long: 90 days.

Mail

We will store content only encrypted with your keys: the text, attachments, subject, sender and recipients, the date with the time, drafts, contacts, folder and label names, filters (except the server-side rules you turn on yourself), signatures, auto-replies, settings. The search index will be built on your devices. If a copy of it is ever sent to our servers, it will be sent only encrypted with your keys. The limits of this protection are under What Methmail won’t be able to do.

Which threads you snoozed and until when will be stored only encrypted with your account key, as one object per account. The server won’t see when they’re due back: your device will bring a thread back by its own clock while Methmail is open. The server will only see that you have used Snooze: when and from which device this object changed, and its size rounded to a step.

In the clear, the server will keep:

• Message, folder and label numbers, and what is in which. The numbers will be random, with no time inside; your folder and label names will be encrypted. Why: to put incoming mail into Inbox or Spam and to sync your devices. How long: as long as the message exists.
• Which folder sits inside which, without names. Why: so all your devices show the same folder tree. How long: as long as the folder exists.
• The number of attachments we will not know: attachments will sit inside the message as one encrypted whole, and the server will know only the size step of the whole message.
• The number of contact batches. Contacts will be stored in batches of up to 250, all the same size, so we will know how many contacts you have only in steps of 250. Why: to sync contacts. How long: as long as you have contacts.
• “Read” and “important” marks. Why: so they are the same on all your devices. How long: as long as the message exists.
• Message size, rounded to a size step. Why: to count storage; the step does not give away the content. How long: as long as the message exists.
• The date received: the day only, no hours or minutes. The exact time will remain only in technical logs (7 days) and in the database change archive (24 to 48 hours). Why: to show messages in order. How long: as long as the message exists.
• The spam filter’s verdict: spam or not. Why: so the message lands in the right folder straight away. How long: as long as the message exists.
• Where a message came from: a Methmail user (end-to-end encrypted) or another service (encrypted on arrival). Why: to show you how the message is protected. How long: as long as the message exists.
• A sync counter. Why: so your devices know what changed. How long: as long as the account exists.
• Storage used. Why: your plan and its limits. How long: as long as the account exists.

On your device, in the browser database mm-core, there will be an encrypted first-contact memory: the addresses of the people you correspond with in Methmail and their key fingerprints (who you wrote to and who you received signed emails from), up to 5,000. Only your account key can open it; it isn’t sent to the server; it’s erased when you sign out.

Your device will hold a search index of your emails, encrypted with your account’s key; it will be erased when you sign out. If you don’t keep your sign-in on this device, the index will live only in the open tab’s memory.

Invitations and payment

• How many invitations you have left: a number, without who you gave them to. Why: a limit of 5 invitations a year on paid plans. How long: as long as the account exists.
• Hashes of used codes. Who issued them and who used them will not be recorded. Why: so a code can’t be used twice. How long: while the batch of codes is valid, then we will delete them. How invitations work: below.
• Your plan, the day it’s paid until, and how much storage was added. During the alpha, the Methmail founder will be able to change your plan and storage by hand; why it was changed, and whether it was paid for, won’t be recorded. Why: so your plan works. How long: while you have an account.
• Hashes of used payment confirmations. Who paid and for which mailbox will not be recorded. Why: so one confirmation can’t be used twice. How long: for the quarter the key issues confirmations, and one more quarter.
• In the payment service, for each order: the order number, the denomination, the payment method and the month. No mailbox, no confirmation. Why: accounting and refunds. How long: as long as the law requires.
• On our crypto payment server (BTCPay), for each invoice: the order number, the amount and the exchange rate, the Bitcoin address or Lightning invoice, the transactions, and the exact time of the invoice and of the payment. No mailbox, no account. Why: to accept the payment and reconcile it. How long: as long as the law requires.
• In the payment service, if you ask for a crypto refund: the refund address, next to the order. Why: to send the money back. How long: until the refund is decided, then the address will be erased.
• In the payment service, for each subscription: the Stripe subscription number, a hash of the subscription secret, and confirmations for future periods until your device collects them. No mailbox, no account. Why: to renew without linking the subscription to your mailbox. How long: while the subscription is active; ready confirmations: until collected, but no longer than the grace period and 30 more days.

There will be no payments during the beta.

Technical logs

Terms differ by row: 7 days, 30 days and 1 year.

• The log of mail arriving at Methmail: the minute; the domain and a hash of the rest of the address, under a key that will change every day and be destroyed after 7 days; the server’s reply code; the TLS version; the size step; the spam verdict, with no detail about the content. While the key exists, a hash could be checked against a guess, including our own users’ addresses. Why: to work out why a message did not arrive. How long: 7 days.
• The log of email sent to other providers, one line per recipient and attempt: the minute; pseudonyms of the mailbox and the recipient, under a key that will change every day; the outcome and the recipient server’s reply code; the TLS policy; the attempt number; the size rounded to a step. No addresses, domains or IPs. Why: to find out why an email didn’t go out. How long: 7 days.
• The IP addresses of other providers’ mail servers that send mail to Methmail. Not your IP. Why: sender reputation and spam protection. How long: up to 30 days.
• The log of web app requests to the server: the minute, which request, the result, how long it took. The account number will go in only when a failure cannot be worked out without it, and then as a hash under a daily key. No IP. Why: to fix failures. How long: 7 days.
• Sign-in attempts: success or failure, and the type of factor. No IP. Why: to see attacks on sign-in. How long: 7 days.
• The staff action log: who did what to the infrastructure, and when. Why: so every action on the system is visible and cannot be altered. How long: 1 year.

We will publish the list of log fields. No new field will be added without a security review.

Backups

• Daily copies of all the data from “Account and sign-in”, “Mail” and “Invitations and payment”: the ciphertext and the fields kept in the clear, encrypted once more with our key on top. They will be kept at a second provider in another country. Technical logs will not go into the copies: they will stay only on their own nodes, within their own terms. Why: so your mail is not lost in an outage. How long: 30 days; anything you delete will physically disappear from the copies within 30 days.
• The database change archive for recovery to a point in time. It will contain the exact time of each write. Why: to roll back after a failure. How long: 24 to 48 hours.

If you delete your account, we will remove the live data and all the wrappers of your keys from our servers as soon as the deletion takes effect: after 72 hours if you have a device you signed in on more than a week ago, and after 7 days if you don’t. It will take effect at once only if you confirm it with your recovery phrase or a passkey with account recovery turned on. Until then you will be able to cancel it, the account and its addresses will stay yours, and mail will keep arriving. Deleting your account won’t wipe the copies on your devices by itself: Methmail will offer to wipe the copies in the browser too, and the choice will be yours. In the backups, the wrappers will stay for up to 30 more days, then they will be physically gone too. The backups will be unreadable without you: that will take your password, recovery phrase, passkey or a device you have signed in on. Addresses on a Methmail domain, aliases included, will stay taken forever, including for you: that way they will not go to a new owner. Addresses on your own domain will be controlled by whoever owns the domain.

What you send us yourselves

• If you report a swapped key (the “Tell us” button): the other person’s address, both fingerprints, the key log’s proof, the Methmail version number and the time to the minute. Without your account or IP address. The report will have no message text, subject or other recipients, and you will see everything that goes before you send it. Why: to work out whether it was an attack. How long: until it has been looked into, at most 90 days.

The rest is printing.

What will not be on this list

Message text and attachments, subjects, senders and recipients, contacts, folder names, in the clear. A search index in the clear: if a copy of it is ever sent to our servers, it will be sent only encrypted with your keys. The exact time of messages: it will remain only in technical logs (7 days), in the database change archive (24 to 48 hours) and in the send queue while a message to an external address waits for delivery (up to 48 hours). The hour a message to an external address was sent will be visible in its delivery status until your device fetches it, for no more than 48 hours. Your IP, except in the sign-in log that you turn on yourself and only you will be able to read. A phone number. A recovery address: only its hash. The addresses of a deleted account: only their hashes. Who invited whom (how invitations work). Card details.

What a court can require: part 4.

What we will see but not keep

What will pass through the server at delivery and will be kept nowhere, except in the send queue and in certain fields of technical logs, for a limited time.

• A message from another service: the text, subject and addresses. At the moment it arrives, in memory, while we check it for spam and viruses. Then we will encrypt it with your key right away, and only after that confirm receipt. It will not reach disk in plain text.
• A message you send to another service without PGP. It will wait in the send queue for up to 48 hours, on a volume encrypted with our key, and will be deleted right after delivery or rejection. The copy in your Sent folder will be ciphertext created by your device.
• Who writes to whom. We will not keep a record of who writes to whom: senders and recipients will be stored encrypted along with the message. Logs of incoming mail will keep the minute, the domain and a hash of the rest of the address for 7 days, under a key that will be destroyed after 7 days. The sending log will keep, for 7 days, the minute and pseudonyms instead of the mailbox and the recipient, under a key that will change every day and never be written down: within a day they will show that one mailbox wrote to one address several times, but not who. While the key exists, a hash could be checked against a guess, including our own users’ addresses. Mail to an external address will wait in the send queue for up to 48 hours, and the database change archive will keep the exact time messages were written for 24 to 48 hours. At the moment of delivery the server will see who is writing to whom; a court will be able to order us to start recording it and to hand over the last 7 days of logs (exceptions: part 4).
• Your IP when you connect. By default, we will not record it. In memory, it will feed counters against password guessing and spam, under a key that changes: up to 24 hours for sign-in, up to 7 days for reputation. Exceptions: part 4.
• Images in emails. We’ll show images from emails sent by other services right away, through our server: the sender won’t learn your IP address or device, but will be able to tell that the email was opened, and when. We won’t load known tracking pixels. We won’t record the image address. If showing images is on (it will be by default), when you open an email our server will learn the addresses of its images, including in an encrypted email, but not the text. You’ll be able to turn showing them right away off in settings (“Show images in emails right away”): then images will show only when you click the button. In Spam, images will always show only when you click the button.
• Changing a plan by hand during the alpha. When the founder changes a plan by hand, they will see the address of the mailbox they’re changing it for.
• Invitations. When you take an invite, the server will see that your account took one, but not the code itself: your device will create it and the server will certify it blindly. When someone signs up with a code, the server will see the code but won’t learn who issued it. The server will see when an account takes an invite and when someone uses one: if hardly anyone else takes or uses invites around that time, the link could be guessed from timing.
• Emails to other providers. Emails to other providers leave unencrypted. To keep our addresses from being used for spam, we count how many emails each mailbox sends and watch complaints and bounces. The text of emails to other providers is automatically checked for patterns of mass hoax threats (such as bomb threats); if it matches, the email is held until a person reviews it. We don’t check the content of emails within Methmail.
• A recipient’s address at another service, when we look up their PGP key. The request will go through our proxy, and only once the complete address is typed; it will not be recorded or cached.
• Your IP address when you send a report about a swapped key. At the moment you send the report; we won’t record it.
• Payment. At the moment you pay, the server will see the order, the time and the IP address. The payment service will keep only the month of the order, our crypto payment server also the exact time of the invoice and of the payment, and your account will record the day your plan is paid until. The IP will be kept nowhere.
• Turning on a paid plan. The server will see which account turns on a plan of which denomination. It will keep only the new end date, and hold the confirmation’s hash apart from the account.
• Renewing a subscription. When you open Methmail around the renewal date, your device will collect a confirmation from the payment service; at that moment, the link could also be seen from the time and address.
• What Stripe or BTCPay send us about a purchase. We will keep the order number, the amount, the status and the month, and nothing else.
• Your recovery address, when you add it and when you reset your password: to compute the hash and to send the link. We will not record it. Exceptions: part 4.

The rest is printing.

What others will get

Who outside Methmail will see something about you, and what exactly.

• Your recipient’s email service, if it is another provider. Email sent without PGP will leave unencrypted, and that provider will be able to read it. The subject and addresses will always be visible to it.
• Your old mail provider, if you move your mail. It will see that you requested an export of all your email, or, if a mail app downloads your email, the app signing in with an app password, the IP address your device connects from, and the app downloading your email. From these traces, it may be able to tell that you’re moving. If you turn on forwarding, it will know your new address.
• Stripe, if you pay by card. Your name, card, country, IP and device data, for fraud protection. Stripe won’t know which mailbox was paid for, unless the subscription is linked to the mailbox.
• Anyone, if you pay in Bitcoin. Anyone can see a Bitcoin payment on the public blockchain.
• Lightning nodes and your wallet service, if you pay via Lightning. The nodes along the payment’s route will see the amount and the time, and your wallet service may be able to tell that you’re paying Methmail.
• The mail provider of your recovery address. When you reset your password, it will get an email from Methmail with the link. Your Methmail address will not be in it.
• Anyone who queries the key directory. They will learn whether an address exists at Methmail and get its public key. That is how public keys work: otherwise people could not send you encrypted email. Queries will be rate-limited. The directory will show a deleted address as nonexistent.
• The providers that will host our servers and backups. They will hold our disks: ciphertext and the fields from “What we will keep”; the copies will be encrypted once more with our key.
• Sender reputation services. They will get the IP addresses of other providers’ mail servers that send mail to Methmail. Your data will not be there.

The rest is printing.

What we can be ordered to do

What a court can require of us, and what it cannot.

• What we can be ordered to do. A court or authority in the USA, where the company is registered, in the country where our servers are, or where members of our team live, will be able to order us to start recording the IP addresses of a specific account; to keep its future incoming email from other providers before it is encrypted; to copy its future email to other providers sent without PGP; to record the recovery address at the moment it is added or typed in for a password reset; to hand over what is listed under “What we will keep” (technical logs are there too, within their retention periods), and mail to external addresses that is still waiting to be sent (up to 48 hours, while it sits in the queue).
• The web app. The Methmail web app will load its code from our servers every time you sign in. So it will be impossible to fully rule out a modified version being served to one person, if our servers are hacked or we are forced to do it. Methmail won’t have apps at launch: if you face someone who could make us do this, take this risk into account.
• What cannot be ordered. To hand over, retroactively, what we won’t have kept. Or to hand over stored emails and keys: we won’t have them in readable form. Or to learn who invited whom: even under an order, we won’t learn the link between a code and the inviter, because the server won’t see the code. Only a guess from timing will remain.
• Payment. If ordered, we will be able to hand over only the day a mailbox is paid until: how and by whom, we won’t know. Together with Stripe’s records or the crypto payment server’s, that day could point to the payer if few people paid for that plan that day.
• What protects you from us too. By launch, the Methmail web app will be available over Tor, in Tor Browser on desktop at the Standard security level. Tor hides your IP even from us. We will not be able to read email that the sender encrypted to the recipient’s real key (PGP or Methmail), even as it arrives. Methmail will be able to detect a swapped key through the key log, but not rule it out in advance; external PGP programs don’t check the log (see What Methmail won’t be able to do).
• How we will respond to requests. We will check that each request is lawful, challenge it when in doubt, hand over the minimum, and notify you unless that is prohibited. Every six months we will publish a transparency report: how many requests we received from authorities, how many we complied with, and what we handed over.

The rest is printing.