EMX Terms of Service

Version: 1.0
In effect from: 6 October 2026
Provider: Krauss Software, sole proprietorship of Samuel Krauss, Im Ländli 18, 6315 Oberägeri ZG, Switzerland, trading as Elchi Studios ("EMX by Elchi Studios")
Contact: legal@elchi.dev; support at contact@elchi.dev; reports of abuse to abuse@emxmail.ch
Applies to: EMX, the hosted business mail service: the web client and the
API at mail.emxmail.app, the mail server mx.emxmail.ch, and the use of the
service through mail apps and the programs published for EMX

The current version of these terms is published at elchi.dev/legal/emx-terms.

1. Who these terms are between

1.1 These terms govern the use of EMX, a hosted mail service operated by
Krauss Software ("we", "us"), the sole proprietorship of Samuel Krauss,
seated in Oberägeri, Canton of Zug, Switzerland. Krauss Software is not
entered in the commercial register. Samuel Krauss, as its owner, is
personally liable for its obligations. Elchi Studios is the name under which
the service is presented.

1.2 The "customer" is the business that creates an organisation in EMX: a
legal entity, or a natural person acting in their trade or profession. EMX is
offered only to businesses and only for their business purposes, on every
plan including the free one. It is not offered to consumers.

1.3 The person who creates the organisation and accepts these terms confirms
that they are authorised to bind the customer. If that authority is missing,
they are liable to us as the law provides for a person acting without
authority.

1.4 "People" are the natural persons to whom the customer gives a mailbox or
access to EMX. They use EMX on the customer's behalf, and the customer is
responsible for their use of it as for its own. People sign in through EAuth,
our sign-in service; what that involves is described in Annex A.

1.5 These terms alone govern EMX. The general terms and conditions of the
Elchi Studios agency and the EAuth Terms of Service do not apply to EMX, and
neither do terms of the customer. Where we and the customer sign a separate
written contract for EMX, such as for the Enterprise plan, that contract
prevails over these terms where it differs.

2. The service

2.1 EMX is mail on the customer's own domains: mailboxes for its people,
shared mailboxes, groups and aliases; a web client; IMAP and SMTP submission
for mail apps such as Outlook, Apple Mail and Thunderbird, including the
shared mailboxes a person is a member of; automatic replies, forwarding and
rules that file mail on the server; a filter for spam on incoming and outgoing
mail, which refuses attachments that are programs, also inside archives; an
API and webhooks; and an export of the mail. A scan for known viruses runs
only while a virus scanner is connected to EMX. At the time of this version
none is, because the platform EMX runs on does not offer one yet (Annex B,
B.6). An automatic reply goes only to a sender whose domain passes SPF or
DMARC, with the subject the person set or a fixed one, and counts against the
sending limits in 6.3. The documentation at docs.elchi.dev/emx describes the
service as it is.

2.2 EMX does not include, at the time of this version: calendar and contacts
(CalDAV and CardDAV), Exchange ActiveSync, a mobile app of its own, signed
installers for the desktop app, or an archive that meets the requirements of
the Swiss ordinance on the keeping of business records (GeBüV). We make no
promise as to whether or when any of these will be offered.

2.3 We develop EMX further and may change it. We give at least 30 days'
notice by email before we remove a feature the customer uses to a material
extent, and the customer may then end the contract with effect from the day
of the change. Changes to the API follow the versioning rule in the API
reference.

2.4 Sealed mailboxes. Where the organisation allows it, a person can seal
their own mailbox. By default only an organisation of one person allows it;
its owners can change that (Section 9.3). From then on, each message,
including its subject, its sender and its recipients, is stored encrypted to a
key of the person's. We keep that key only encrypted to the person's recovery
code and to a passkey or a passphrase of theirs, none of which we ever see.
Mail that was in the mailbox before it was sealed is not sealed and stays
readable as before. Neither the customer nor we can open a sealed message. Our
servers handle a message in clear only while it is being received or sent. A
sealed mailbox cannot be read in a mail app, its mail cannot be searched on
the server, it sends no automatic replies and forwards nothing, and of its
rules only those on the size of a message apply. If the person loses their
recovery code and every passkey and passphrase, the sealed mail cannot be
recovered by anyone. Annex B, B.1, says exactly what is encrypted and what is
not.

2.5 The customer's own Resend account. For a domain, the customer may
choose to send its outgoing mail through its own account at Resend, Inc.
instead of through EMX's own mail servers. EMX then hands that domain's
outgoing mail to Resend with the customer's key. Resend acts under the
customer's own contract with Resend, as the customer's provider and not as
ours. Otherwise EMX sends all mail through its own mail servers and uses no
third party to send it.

3. Sign-up, plans and payment

3.1 The contract is concluded when the person signing up creates the
organisation in EMX and accepts these terms. We record the version accepted
and the time. Where we create the organisation for the customer, the contract
is concluded instead by a written contract signed by both parties.

3.2 The plans are Private (free of charge, for one mailbox on one domain),
Team (charged per mailbox and month) and Enterprise (on request, under a
separate written contract). Their scope and limits are those in Section 6
and in the documentation. There is no trial period.

3.3 The Team plan is a subscription taken out through Stripe Checkout. The
price per mailbox and month, and any value added tax, are those shown at
checkout before the customer pays and on the invoice. Prices are stated in
Swiss francs.

3.4 The subscription is charged monthly in advance, to the payment method the
customer gives Stripe. The number of mailboxes charged follows the personal
mailboxes in the organisation; when it changes, Stripe charges or credits the
difference pro rata. Invoices are available in the billing portal, which
administrators open from the administration of the organisation in EMX.

3.5 If a payment fails, Stripe tries again. If the Team subscription ends,
because it was cancelled in the billing portal or because payment remains
outstanding, and the organisation has not been cancelled, EMX suspends the
organisation at the end of the billing period already paid: it can no longer
send mail, but it still receives mail, and its people can still read and
export their mail. EMX tells the organisation's owners. If within 30 days the
subscription is neither taken out again nor the organisation cancelled, EMX
cancels the organisation, and Sections 4.2 and 8.5 apply from then on.

3.6 We may change prices with 30 days' notice by email. A change applies from
the first billing period that starts after the notice period. The customer
may cancel before then under Section 4.2.

3.7 Stripe (Stripe Payments Europe, Limited, Ireland) processes the payment
data under its own terms, as an independent party. We do not receive or store
full card details.

4. Term and ending the contract

4.1 The contract runs for an indefinite period. A Team subscription renews
each month.

4.2 The customer may end the contract at any time by cancelling the
organisation in EMX, which only an owner of the organisation can do. The
contract ends at that moment: from then on the organisation sends and receives
no mail, and Section 8.5 applies. During the 30 days in Section 8.5 an owner
can undo the cancellation, and the contract then continues.

4.3 Cancelling the organisation also ends a Team subscription, at the end of
the monthly billing period already paid. Fees for a billing period that has
started are not refunded. Ending only the Team subscription, in the billing
portal, does not end the contract; Section 3.5 then applies.

4.4 We may end the contract with three months' notice to the end of a
calendar month. If we discontinue EMX as a whole, we give every customer at
least twelve months' notice.

4.5 Either party may end the contract with immediate effect for good cause,
in particular if the other party seriously or repeatedly breaches these terms
and does not remedy the breach within a reasonable period after a written
warning, unless a warning would be pointless.

4.6 Section 8.5 governs what happens to the data when the contract ends.

5. Availability and support

5.1 We give no availability commitment. There is no service level
agreement, no availability figure we promise, and no credit for downtime. We
would rather say so than publish a figure we cannot yet stand behind.

5.2 What we do instead is described in Annex B, B.5: EMX runs on two
application servers at two providers in two countries, every database write
is confirmed on three servers, and the stored messages are copied every night
to a second provider.

5.3 While EMX cannot be reached, servers sending mail to the customer
normally keep it and try again, usually for several days; how long is decided
by the sending server and not by us. EMX tries to deliver outgoing mail for
five days and then returns it to the sender as undeliverable.

5.4 We carry out maintenance so that it interrupts the service as little as
possible.

5.5 Support is given in German and English through the console at
panel.elchi.dev or at contact@elchi.dev. We aim to answer within one working
day (Monday to Friday, except public holidays in the Canton of Zug). This is
an aim, not a commitment.

6. Acceptable use and limits

6.1 The customer and its people must not use EMX to:

• send unsolicited mass advertising, or mail to addresses that were bought,
  harvested or otherwise obtained without the recipients' consent;
• send malware, or links to it;
• send phishing, or otherwise deceive recipients about who is writing, such
  as by forging senders or imitating another organisation;
• send, store or make available content whose sending or possession is
  unlawful, in particular depictions of sexual abuse of children, content
  that incites violence or hatred, and content that infringes the rights of
  others;
• harass or threaten people;
• relay mail for third parties, or resell EMX without a separate written
  agreement;
• circumvent the limits in 6.3, probe or test the security of EMX without
  our written permission, or impair the service for others.

6.2 Newsletters and other mail to many recipients are permitted only to
recipients who have consented, with a working way to unsubscribe, and within
the limits in 6.3. EMX is not a mass mailing service.

6.3 These limits apply:

A message that would go over a sending limit is refused. Going over a limit
only refuses that message; it does not stop the person's sending. Outgoing
mail is checked by the filter in Annex B, B.6, as incoming mail is (Section
7.5). Receiving mail is limited only by the size of a message and the storage
of the mailbox; while a mailbox is full, EMX asks the sending servers to try
again later. On the Enterprise plan the limits are those of the contract.

6.4 We may lower a limit with 30 days' notice. To stop abuse we may, at once
and for as long as needed, lower the daily limit of one person or stop their
sending (Section 7).

6.5 Abuse is reported to abuse@emxmail.ch. How we handle reports is described
at docs.elchi.dev/emx-abuse.

7. Suspension

7.1 We may suspend the sending of mail, or access to EMX, for a person, a
mailbox or the whole organisation, if:

• there are concrete indications of use contrary to 6.1;
• an account appears to be compromised;
• mail sent from the organisation endangers the delivery of other customers'
  mail, for instance by putting our servers on block lists;
• an authority or a court orders it; or
• the Team subscription has ended while the organisation has not been
  cancelled (Section 3.5).

7.2 Where the situation permits, we warn the customer first and give it
reasonable time to remedy the problem. Where it does not, we suspend first
and inform the customer's administrators within one working day, with the
reason, unless the law or an order forbids it.

7.3 We choose the least restrictive measure that is effective, such as
stopping the sending of one person, or lowering their daily limit, rather than
suspending the whole organisation, and lift it as soon as its cause has been
removed. Suspension never deletes data.

7.4 A justified suspension gives no claim to damages or to a reduction of
fees.

7.5 Automatic stop. If a person's outgoing messages are refused repeatedly
as spam or because they carry malware, EMX stops that person's sending on its
own. Only such refusals stop a person; a message refused for going over a
limit in 6.3 does not. A stopped person's mail is refused until an
administrator of the organisation, or we, lift the stop. The administrators
see the stop and its reason in the administration of the organisation, and it
is recorded in the organisation's audit log.

8. Data, export and deletion

8.1 The customer's mail and data belong to the customer. We claim no rights
to them and process them only to provide EMX, as Annex A describes.

8.2 The customer can take its mail out at any time without asking us: each
person can export their mailbox, and the shared mailboxes they may read, as
a file in the web client; mail apps read all of it over IMAP; and the API
gives access to every message.

8.3 When the customer removes a person, that person's access ends at once.
When removing them, or during the following 30 days, an administrator can turn
the person's mailbox into a shared mailbox, or hand its mail to a colleague,
who can then read and export it. Sealed messages stay unreadable to everyone
(Section 9.3). A mailbox that is not handed on in one of these ways is deleted
after 30 days. Administrators cannot export another person's mailbox directly.

8.4 When the customer removes a domain, EMX stops accepting and delivering
mail for it at once and stops signing mail with its keys. Mail already
received stays in the mailboxes.

8.5 When the contract ends (Section 4.2), the organisation sends and
receives no mail any more, and EMX keeps its data for 30 days. During that
time its people can still sign in, read their own mail and export it, and its
owners can export all mailboxes of the organisation. The billing portal is
closed while the organisation is cancelled. An owner can undo the cancellation
during the 30 days. If the Team subscription had ended by then, the undo
leaves at least 7 days to take it out again before the cancellation under
Section 3.5 starts again. After 30 days we delete the mailboxes with their
messages, the people, the domains and the rest of the organisation's data. On
request we confirm the deletion in writing.

8.6 Deleted data also disappears from the copies of the message bodies
within a few days, and from the database backups when they are replaced in
the normal backup cycle. We restore from backups only to recover the service
after a failure, never to bring back a customer's data that was deleted.
Records we must keep by law, such as invoices (Art. 958f OR), are kept for as
long as the law requires.

8.7 The export of a sealed mailbox contains its messages as they are stored:
encrypted. The person can open them with their key, for instance with their
recovery code and the age tool.

8.8 EMX is not an archive. Where the customer must keep business records,
such as under Art. 958f OR and the GeBüV, it is responsible for doing so,
for example by exporting the mail it must keep.

9. The mail of people who leave, and access by the organisation

9.1 The customer is the controller of the mail in its organisation. It
decides, within the law, who may read a person's mailbox when that person
leaves or is absent. It must observe the protection of its employees'
personal data (Art. 328b OR) and the applicable data protection law, and
inform its people of its rules in advance.

9.2 EMX gives administrators no way to read or export the mailbox of a person
who is active in the organisation. One thing they do see: where the
organisation chooses to hold suspected spam in a quarantine instead of filing
it in the person's junk folder, its administrators see the sender, the
recipients and the subject of each held message, so that they can release or
delete it. When the customer removes a person, its administrators can deal
with that person's mailbox only as Section 8.3 describes. Every such step is
recorded in the organisation's audit log.

9.3 Mail in a sealed mailbox cannot be opened by anyone other than the person
who sealed it: not by the organisation and not by us. If that person leaves
without making their mail available, the organisation cannot read it, and it
is not handed on with the rest of the mailbox. The owners of the organisation
decide whether its people may seal their mailboxes; by default only an
organisation of one person allows it. Turning sealing off does not unseal a
mailbox that is already sealed. The customer should agree with its people
whether business mail may be kept in a sealed mailbox.

9.4 We do not open a person's mail on behalf of the customer. The functions
of EMX described here are the way to reach it. Section A.11 of Annex A
governs requests from authorities.

10. The customer's responsibilities

10.1 The customer keeps the details of the organisation and its billing
contact accurate.

10.2 The customer ensures that its people keep their sign-in details and app
passwords secret, and that a lost device's app password is revoked. We
recommend a second factor for every person. A suspected compromise is
reported without undue delay to security@elchi.dev.

10.3 The customer may only add domains it is entitled to use, and is
responsible for their DNS records. Mail for a domain reaches EMX only once
the domain's MX record points to it.

10.4 The customer ensures that its people comply with Section 6, informs them
about EMX and the processing of their data, and answers the requests of data
subjects whose data is in its mail, with the tools of EMX and our help under
Annex A.

11. Data protection

11.1 For the personal data in the customer's mail and in the accounts of its
people, the customer is the controller and we are its processor. Annex A is
the data processing agreement and forms part of these terms.

11.2 For our own purposes, namely concluding and performing the contract,
billing, contact with the customer, the security of the service and handling
abuse, we are the controller. For these purposes we process the details of
the organisation and its billing contact, the administrators' contact
details and the logs described in Annex B, B.7.

12. Liability

12.1 We are liable without limitation for damage caused intentionally or by
gross negligence (Art. 100 para. 1 OR), for personal injury, and wherever
else the law does not permit liability to be limited in advance. Nothing in
these terms limits that liability.

12.2 For slight negligence, our liability is limited to direct damage and, in
total for all claims arising in a calendar year, to the greater of the fees
the customer paid for EMX in the twelve months before the event causing the
damage and CHF 500. Liability for indirect and consequential damage, in
particular lost profit, is excluded for slight negligence.

12.3 If mail or data is lost for a reason for which we are responsible, we
restore it from the most recent copy available and bear the cost. Further
claims for the loss exist only under 12.1 and 12.2.

12.4 We are not liable for the content of mail sent or received by the
customer, for the loss of sealed mail whose keys were lost (Section 2.4), for
the services of the customer's own Resend account (Section 2.5), for other
servers that refuse or delay mail or file it as spam, or for events beyond our
reasonable control.

12.5 We are liable for the people we engage, including our sub-processors,
as for our own conduct.

12.6 The customer indemnifies us against claims of third parties arising from
use of EMX contrary to these terms by the customer or its people, unless we
are responsible for the claim.

13. Changes to these terms

13.1 We give at least 30 days' notice of a change to these terms by email to
the organisation's administrators and its billing contact.

13.2 If the customer does not agree, it may end the contract before the change
takes effect, under Section 4.2. Otherwise the new version applies from the
day stated. A change required by law, or needed at once to protect the
security of the service, may take effect sooner; we say so in the notice.

13.3 Every version of these terms remains published, with its date, so that
it can be seen what applied when.

14. Final provisions

14.1 Swiss law applies, excluding its conflict of laws rules and the United
Nations Convention on Contracts for the International Sale of Goods.

14.2 The exclusive place of jurisdiction is Zug, Switzerland. We may also
bring proceedings at the customer's seat.

14.3 If a provision of these terms is invalid, the rest remains in force, and
the invalid provision is replaced by a valid one that comes as close as
possible to what it intended.

14.4 These terms are published in German and in English with the same
content. If the two versions differ, the German version prevails.

14.5 Notices to the customer go by email to the addresses in the
organisation's administration. Notices to us go to legal@elchi.dev.

14.6 The customer may transfer the contract only with our written consent.
We may transfer it to a company that continues the business of Krauss
Software, with notice by email; the customer may then end the contract with
effect from the transfer.

Annex A: Data Processing Agreement

This annex is the agreement on the processing of personal data on behalf of
the customer required by Art. 9 of the Swiss Federal Act on Data Protection
(revDSG) and by Art. 28 of the General Data Protection Regulation (GDPR),
where that applies. It forms part of these terms and needs no separate
signature. Terms not defined here have the meaning given in the revDSG and
the GDPR.

A.1 Subject matter and duration

We process personal data for the customer in order to provide EMX, for as
long as the contract runs and until the deletion described in A.15.

A.2 Nature and purpose

Receiving, filtering incoming and outgoing mail for spam and harmful
attachments, storing, indexing for search, displaying, synchronising, sending
and exporting mail; managing the organisation's people, mailboxes, domains and
rights; recording security and access events; and making the backups and
copies described in Annex B.

A.3 Data subjects

The customer's people; the people who write to them or receive mail from
them; and the people named in that mail.

A.4 Categories of personal data

• Account data: names, addresses, roles, the identifier of the person's
  sign-in, preferences, signatures, and digests of app passwords and tokens.
• The content of messages and attachments, of any kind.
• Message data: sender, recipients, subject, times, size, flags and folder.
• The full-text search index of mailboxes that are not sealed.
• The senders a person has allowed or blocked.
• Logs: sign-ins, administrative actions and IP addresses, as described in
  Annex B, B.7.
• Push subscriptions of browsers in which a person has turned on
  notifications.

Mail can contain sensitive personal data in the sense of Art. 5 lit. c
revDSG and Art. 9 and 10 GDPR, such as health data. EMX processes such data
like any other mail. Whether the customer may send and keep it by mail is the
customer's decision and responsibility.

A.5 Instructions

We process the data only on the customer's documented instructions. These
terms and the customer's settings in EMX are those instructions. If we
consider that an instruction infringes data protection law, we tell the
customer and may suspend carrying it out until it is clarified. We process
the data for other purposes only where the law obliges us to, as described
in A.11.

A.6 Confidentiality

Everyone we authorise to process the data is bound by a written duty of
confidentiality that continues after their engagement ends. We do not read
the customer's mail. Where looking at a message is unavoidable, such as for
a message a person sends us to resolve a problem, we look at it only as far
as necessary.

A.7 Security

We take the technical and organisational measures in Annex B. We may change
a measure, but not in a way that lowers the overall level of protection.

A.8 Sub-processors

The customer gives general authorisation for the sub-processors listed here:

Resend does not send the customer's mail. EMX sends it through its own mail
servers, except for a domain for which the customer has chosen its own Resend
account (Section 2.5).

These are not sub-processors and receive no content of mail: Stripe, which
processes payment data as an independent party (Section 3.7); Cloudflare,
which holds the DNS zones of our domains; and the push services of browser
makers, which carry a notification, encrypted end to end to the browser, only
to a browser in which a person has turned notifications on.

We give at least 30 days' notice by email before adding or replacing a
sub-processor. If the customer objects on reasonable data protection grounds
within that period and we cannot accommodate the objection, the customer may
end the contract with effect from the change. Every sub-processor is bound
by data protection obligations no weaker than this annex, and we remain
liable to the customer for them.

A.9 Transfers abroad

The data is processed in Switzerland and in Germany, the Netherlands, France
and Bulgaria, and Spamhaus Technology Ltd is in the United Kingdom. These
states, the United Kingdom included, provide adequate protection under Annex 1
of the Swiss Data Protection Ordinance (DSV), and the European Commission has
found Switzerland and the United Kingdom adequate (Art. 45 GDPR). The name
servers through which Spamhaus answers the questions in A.8 can also be in
other states; a question carries only the IP address of a sending server or a
domain a message links to, and no content of mail.

One transfer goes outside both: Resend, Inc. stores the mails of the sign-in
service in the United States. For data from Switzerland it rests on the
standard contractual clauses in Resend's data processing agreement, as
adapted for Swiss law (Art. 16 para. 2 lit. d revDSG). For data subject to
the GDPR it rests on Resend's certification under the EU-U.S. Data Privacy
Framework (Art. 45 GDPR), with those clauses in addition (Art. 46 para. 2
lit. c GDPR).

Data held by a provider in another state can be reached by that state's
authorities under its law, through the provider. Message bodies held by our
providers are encrypted with a key that is not kept with the stored data; the
database is not encrypted in that way (Annex B, B.1).

If the customer sends through its own Resend account (Section 2.5), that
transfer is the customer's.

A.10 Data subject rights

If a data subject asks us to exercise their rights, we forward the request
to the customer without undue delay and do not answer it ourselves. EMX
gives the customer the tools to answer: export, correction and deletion.
Where these are not enough, we help the customer at no charge.

A.11 Requests from authorities

We disclose the customer's data to an authority only where Swiss law
obliges us to, on an order of a competent Swiss authority. Requests from
foreign authorities must go through Swiss mutual legal assistance. We tell
the customer about a request without delay, unless the law or the order
forbids it. How we handle requests, and what data exists, is described at
docs.elchi.dev/emx-authorities.

A.12 Assistance

We help the customer, taking into account the nature of the processing and
the information available to us, with the security of the processing, with
notifying breaches of data security, and with data protection impact
assessments and prior consultations (Art. 22 to 24 revDSG, Art. 32 to 36
GDPR).

A.13 Breaches of data security

We notify the customer of a breach of data security that affects its data
without undue delay, and in any case within 72 hours of becoming aware of
it. The notice describes the nature of the breach, as far as known the
categories and approximate number of data subjects and records concerned,
the likely consequences, and the measures taken or proposed. We notify the
customer even where we are not certain that the breach affects it, because
that judgement is the customer's.

A.14 Audits

The customer may request the information needed to show that this annex is
complied with once per calendar year, and after a breach affecting its data.
No certification or independent audit of EMX exists; we say so rather than
let the customer assume otherwise. An audit on site requires 30 days'
notice, must not disrupt the service or disclose other customers' data, and
is at the customer's cost.

A.15 Deletion and return

When the contract ends, the customer can make a final export for 30 days, as
Section 8.5 describes. We then delete the data, as Sections 8.5 and 8.6
describe, unless the law requires us to keep it. On request we confirm the
deletion in writing.

Annex B: Technical and organisational measures

These are the measures in place, not a general list. Where something is not
protected, this annex says so.

B.1 Encryption

• Message bodies. Every message, with its attachments, is compressed and
  encrypted with AES-256-GCM under a master key before it is stored in the
  object storage. The object storage and its nightly copy hold only
  ciphertext.
• The master key is held in the platform's secret store and in the
  operator's password manager, and is not part of any backup.
• What is not encrypted in this way: the database. It holds, for
  mailboxes that are not sealed, the sender, recipients, subject, times,
  flags and folder of each message, a short preview, and the full-text index
  for search built from the subject, the people and the text. It also holds
  the account data of Annex A, A.4.
• Secrets are encrypted with the master key: the private keys for DKIM,
  the stored tokens of the sign-in service, the keys of the customer's own
  Resend accounts, the secrets of webhooks, the passwords given for importing
  mail, and the account and keys for the certificate of the mail server.
• App passwords, API tokens and session tokens are stored only as SHA-256
  digests. An app password is 100 random bits and is shown once.
• Sealed mailboxes. Each message, including its subject, sender and
  recipients, is encrypted with age (X25519) to the mailbox's public key as
  soon as it is received or sent. The private key is kept on the server only
  encrypted to the person's recovery code and to a passkey or a passphrase,
  none of which the server sees. Mail that was in the mailbox before it was
  sealed is not encrypted in this way. What stays readable to the server is
  the time a message arrived, its size, its folder and its flags, and for mail
  sent to other servers the delivery record in B.7. Sealed messages are not
  indexed for search on the server, and IMAP is not available for them. While
  a message is being received or sent, the server handles it in clear.
• In transit. The web client and the API are served over HTTPS only.
  HTTPS ends at our edge proxies, and from there requests travel over our own
  encrypted network between the servers. The mail ports use TLS 1.2 or newer;
  passwords are accepted only after TLS has been established. Outgoing mail
  is sent with TLS whenever the receiving server offers it, and only with TLS
  where the receiving domain requires it through MTA-STS. Whether mail
  travels encrypted between other servers and EMX also depends on the other
  side.

B.2 Access control

• People sign in through EAuth, with OpenID Connect; a second factor is
  available. Mail apps use one app password per device, which can be revoked
  on its own.
• Rights are set per mailbox (read, write, delete, send as, send on behalf,
  manage) and checked on every request. A token never has more rights than the
  person it belongs to. EMX has no function by which an administrator reads or
  exports the mailbox of an active person. Where the organisation holds
  suspected spam in a quarantine, its administrators see the sender, the
  recipients and the subject of each held message, and why it was held, but
  not its content.
• A removed person's mail reaches a colleague only when an administrator turns
  the mailbox into a shared mailbox or hands it on (Section 8.3); both are
  recorded in the audit log.
• Failed sign-ins are counted per IP address and per account; too many lock
  further attempts for a period.
• Access to the servers, the database and the master key is limited to the
  people who operate EMX and the platform it runs on. With that access, mail
  that is not sealed could technically be read; it is used only as Annex A,
  A.6, allows.

B.3 Separation

Every record belongs to one organisation, and each request is checked
against the rights of the person making it. Organisations share servers and
the database; the separation is logical.

B.4 Integrity

• Incoming mail is checked with SPF, DKIM and DMARC; outgoing mail is signed
  with DKIM.
• Administrative actions are recorded in the organisation's audit log, with
  the person, the action and the time.
• A message is stored in the object storage before the database refers to
  it, so an interruption cannot leave a reference to half a message.

B.5 Availability and resilience

• Two application servers, at two providers in two countries, each accept
  mail and serve the web client and the API.
• Every database write is confirmed on three servers at three providers in
  two countries. The database is backed up weekly in full, daily by
  difference and continuously by its write-ahead log, which allows a restore
  to a point in time; an encrypted copy of the backups is kept at a second
  provider.
• The message bodies are copied every night to a second provider, from which
  they are read if the first fails.
• Connections and sign-ins to the mail ports are limited per address and in
  total, and sending is limited as Section 6.3 states.

B.6 Filtering

• Incoming and outgoing mail is checked for spam before it is filed or sent,
  using the checks in B.4, the sending server's name and address, the content,
  block lists, and a classifier per organisation that learns from what its
  people file as junk.
• The block lists of Spamhaus, through its Data Query Service, are asked about
  the IP address of the sending server and about the domains a message links
  to. They receive no content of mail.
• Attachments that are programs are refused, also when they are inside an
  archive.
• A scan for known viruses runs only while a virus scanner is connected to
  EMX. At the time of this version none is, because the platform EMX runs on
  does not offer one yet; until then mail is not scanned for known viruses.
• Mail filed as junk, or held in quarantine where the organisation chose that,
  is deleted after the organisation's retention period, 30 days unless it set
  another.

B.7 Logs

• The security and access logs record sign-ins, administrative actions and the
  IP address they came from. After 90 days, IP addresses in these logs are
  shortened to their network: an IPv4 address to its first 24 bits, an IPv6
  address to its first 48.
• The operating logs of the servers record connections to the mail ports with
  their IP address, and the sender of each message sent; they are used only
  to run the service and to handle abuse.
• The delivery record of each outgoing message (sender, recipient, time and
  outcome) is kept for a week after delivery, so that a person can see where
  their mail went.
• Counters of failed sign-ins are kept in memory for the length of their
  window only.

B.8 Organisational measures

• Secrets are given to the service through the platform's environment and are
  never committed to source control.
• Every release is built from a reviewed commit and passes the automated
  tests first.
• No independent security audit of EMX has been performed. When one is, we
  will publish the result regardless of its outcome.

Annex C: Version history