Rework skeleton
|
@ -16,7 +16,8 @@ However, as Aerogramme is a distributed-first server,
|
||||||
you will not benefit from all of its nice properties, and many manual
|
you will not benefit from all of its nice properties, and many manual
|
||||||
work will be required.
|
work will be required.
|
||||||
|
|
||||||
- [Static user management](@/documentation/cookbook/static-user-management.md)
|
- [Configuration file](@/documentation/cookbook/config.md)
|
||||||
|
- [User management](@/documentation/cookbook/static-user-management.md)
|
||||||
- [Local storage](@/documentation/cookbook/single-node-garage-storage.md)
|
- [Local storage](@/documentation/cookbook/single-node-garage-storage.md)
|
||||||
- [TLS encryption](@/documentation/cookbook/tls-encryption.md)
|
- [TLS encryption](@/documentation/cookbook/tls-encryption.md)
|
||||||
- [Integration with a service manager](@/documentation/cookbook/service-manager.md) (systemd or docker)
|
- [Integration with a service manager](@/documentation/cookbook/service-manager.md) (systemd or docker)
|
||||||
|
|
35
content/documentation/cookbook/config.md
Normal file
|
@ -0,0 +1,35 @@
|
||||||
|
+++
|
||||||
|
title = "Configuration file"
|
||||||
|
weight = 5
|
||||||
|
+++
|
||||||
|
|
||||||
|
In the [quickstart](@/documentation/quick-start/_index.md), you launched Aerogramme in "development mode", that do not require a configuration file. But for a real-world usage, you will need to specificy many things: how your users are managed, which port to use, how and where data is stored, etc.
|
||||||
|
|
||||||
|
## A first configuration file
|
||||||
|
|
||||||
|
Let's start with the following configuration file:
|
||||||
|
|
||||||
|
```toml
|
||||||
|
role = "Provider"
|
||||||
|
pid = "aerogramme.pid"
|
||||||
|
|
||||||
|
[imap]
|
||||||
|
bind_addr = "[::]:1143"
|
||||||
|
|
||||||
|
[lmtp]
|
||||||
|
bind_addr = "[::1]:1025"
|
||||||
|
hostname = "example.tld"
|
||||||
|
|
||||||
|
[users]
|
||||||
|
user_driver = "Static"
|
||||||
|
user_list = "users.toml"
|
||||||
|
```
|
||||||
|
|
||||||
|
Copy this content in a file named `aerogramme.toml`.
|
||||||
|
Also create an empty file named `users.toml` (Aerogramme does not know how to create it automatically yet).
|
||||||
|
|
||||||
|
And then you can start Aerogramme with the following configuration file:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
aerogramme -c aerogramme.toml provider daemon
|
||||||
|
```
|
|
@ -1,7 +1,6 @@
|
||||||
+++
|
+++
|
||||||
title = "Static User Management"
|
title = "User Management"
|
||||||
weight = 10
|
weight = 10
|
||||||
+++
|
+++
|
||||||
|
|
||||||
Todo
|
Aerogramme can externalize its user management through [LDAP](@/documentation/cookbook/ldap.md), but if you target a simple deployment, it has also an internal user management system that will be covered here.
|
||||||
|
|
||||||
|
|
|
@ -1,8 +1,12 @@
|
||||||
+++
|
+++
|
||||||
title = "Design"
|
title = "Concepts"
|
||||||
weight = 40
|
weight = 40
|
||||||
sort_by = "weight"
|
sort_by = "weight"
|
||||||
template = "documentation.html"
|
template = "documentation.html"
|
||||||
+++
|
+++
|
||||||
|
|
||||||
Test
|
[Per-user encryption](@/documentation/design/per-user-encryption.md) - TODO
|
||||||
|
|
||||||
|
[Unbreakable mailboxes](@/documentation/design/unbreakable-mailboxes.md) - TODO
|
||||||
|
|
||||||
|
**Stateless** - 12 factor app.
|
||||||
|
|
31
content/documentation/design/per-user-encryption.md
Normal file
|
@ -0,0 +1,31 @@
|
||||||
|
+++
|
||||||
|
title = "Per-user encryption"
|
||||||
|
weight = 10
|
||||||
|
+++
|
||||||
|
|
||||||
|
|
||||||
|
Aerogramme can't store plaintext data, instead all users data must be encrypted with a per-user key on the storage target.
|
||||||
|
Of course, cryptography is always a tradeoff with other properties (usability, compatibility, features, etc.),
|
||||||
|
so the way the key is derived and where the encryption/decryption can take place can be configured.
|
||||||
|
|
||||||
|
## Security flavors
|
||||||
|
|
||||||
|
These different configurations are identified as flavors:
|
||||||
|
|
||||||
|
**Transparent Flavor** - Users' data are decrypted in the server's RAM. The key is derived from the user's password upon IMAP login.
|
||||||
|
It's completely transparent to end users. While an attacker having full access to the server can still compromise users' data, it reduces the attack surface.
|
||||||
|
In term of security, it's similar to [TREES](https://0xacab.org/liberate/trees) (from [RiseUp](https://riseup.net)) or [scrambler](https://github.com/posteo/scrambler-plugin) (from [Posteo](https://posteo.de/)).
|
||||||
|
|
||||||
|
|
||||||
|
**Hardened Flavor** - Users' data are decrypted on the user's device. The private key is only stored on the user's device.
|
||||||
|
The server knows only users' public keys. When an email is received by the server, it is directly encrypted and stored by the server.
|
||||||
|
The user must run Aerogramme locally as a proxy that will manipulate the encrypted blobs stored in the server
|
||||||
|
and decrypt them locally, exposing an IMAP proxy interface. An attacker having full access to the server at a point in time
|
||||||
|
will not be able to compromise your already received data (but can intercept new emails). It's similar to [Proton Mail Bridge](https://proton.me/fr/mail/bridge),
|
||||||
|
but keep in mind that Aerogramme does not support (yet) end-to-end email encryption like Proton Mail or Tutanota, *so Aerogramme is less secure*.
|
||||||
|
|
||||||
|
When run on server (both for the transparent and hardened flavor), Aerogramme must be started in the "provider mode", as in "email service provider".
|
||||||
|
When run on the end-user device (only the hardened flavor require that), Aerogramme must be started in the "companion mode", as in "a companion process of your email client".
|
||||||
|
These 2 words are materialized as 2 subcommands on the Aerogramme binary: `aerogramme provider` and `aerogramme companion`.
|
||||||
|
|
||||||
|
## Aerogramme "role"
|
6
content/documentation/design/unbreakable-mailboxes.md
Normal file
|
@ -0,0 +1,6 @@
|
||||||
|
+++
|
||||||
|
title = "Unbreakable mailboxes"
|
||||||
|
weight = 20
|
||||||
|
+++
|
||||||
|
|
||||||
|
Test
|
Before Width: | Height: | Size: 26 KiB After Width: | Height: | Size: 26 KiB |
Before Width: | Height: | Size: 27 KiB After Width: | Height: | Size: 27 KiB |
Before Width: | Height: | Size: 73 KiB After Width: | Height: | Size: 73 KiB |
Before Width: | Height: | Size: 8.9 KiB After Width: | Height: | Size: 8.9 KiB |
Before Width: | Height: | Size: 18 KiB After Width: | Height: | Size: 18 KiB |
Before Width: | Height: | Size: 11 KiB After Width: | Height: | Size: 11 KiB |
|
@ -1,5 +1,5 @@
|
||||||
+++
|
+++
|
||||||
title = "Overview"
|
title = "Architecture"
|
||||||
weight = 10
|
weight = 10
|
||||||
+++
|
+++
|
||||||
|
|
|
@ -8,7 +8,7 @@ template = "documentation.html"
|
||||||
This quickstart guide will teach you how to run an in-memory instance of Aerogramme,
|
This quickstart guide will teach you how to run an in-memory instance of Aerogramme,
|
||||||
because it is easier to run than a distributed real-world deployment. The goal here
|
because it is easier to run than a distributed real-world deployment. The goal here
|
||||||
is that you get familiar with the software, you understand what it does and what it does not,
|
is that you get familiar with the software, you understand what it does and what it does not,
|
||||||
so you can evaluate it. Once ready for a real deployment, you will find all the information you need in the cookbook.
|
so you can evaluate it. Once ready for a real deployment, you will find all the information you need in the [cookbook](@/documentation/cookbook/_index.md).
|
||||||
|
|
||||||
*Enjoy your reading!*
|
*Enjoy your reading!*
|
||||||
|
|
||||||
|
@ -120,7 +120,7 @@ Remember, Aerogramme is about managing your mailbox, not managing mail transfer.
|
||||||
As this is an Aerogramme specific, the goal here is not to deploy Postfix, opensmtpd or any other MTA software.
|
As this is an Aerogramme specific, the goal here is not to deploy Postfix, opensmtpd or any other MTA software.
|
||||||
|
|
||||||
Instead we will emulate their action: forwarding the messages they received to Aerogramme through the LMTP protocol.
|
Instead we will emulate their action: forwarding the messages they received to Aerogramme through the LMTP protocol.
|
||||||
Python natively supports the LMTP protocol, the following command this capability to deliver a fake email:
|
Python natively supports the LMTP protocol: the following command uses Python to deliver a fake email:
|
||||||
|
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
|
@ -158,29 +158,6 @@ user management, auto-discovery, persistent storage, high-availability design, o
|
||||||
All these points will be covered in the [Cookbook](@/documentation/cookbook/_index.md), it should be your next stop!
|
All these points will be covered in the [Cookbook](@/documentation/cookbook/_index.md), it should be your next stop!
|
||||||
|
|
||||||
<!--
|
<!--
|
||||||
## Aerogramme's little secret: per-user mailbox encryption
|
|
||||||
|
|
||||||
Aerogramme can't store plaintext data, instead all users data must be encrypted with a per-user key on the storage target.
|
|
||||||
Of course, cryptography is always a tradeoff with other properties (usability, compatibility, features, etc.),
|
|
||||||
so the way the key is derived and where the encryption/decryption can take place can be configured.
|
|
||||||
These different configurations are identified as flavors:
|
|
||||||
|
|
||||||
**Transparent Flavor** - Users' data are decrypted in the server's RAM. The key is derived from the user's password upon IMAP login.
|
|
||||||
It's completely transparent to end users. While an attacker having full access to the server can still compromise users' data, it reduces the attack surface.
|
|
||||||
In term of security, it's similar to [TREES](https://0xacab.org/liberate/trees) (from [RiseUp](https://riseup.net)) or [scrambler](https://github.com/posteo/scrambler-plugin) (from [Posteo](https://posteo.de/)).
|
|
||||||
|
|
||||||
|
|
||||||
**Hardened Flavor** - Users' data are decrypted on the user's device. The private key is only stored on the user's device.
|
|
||||||
The server knows only users' public keys. When an email is received by the server, it is directly encrypted and stored by the server.
|
|
||||||
The user must run Aerogramme locally as a proxy that will manipulate the encrypted blobs stored in the server
|
|
||||||
and decrypt them locally, exposing an IMAP proxy interface. An attacker having full access to the server at a point in time
|
|
||||||
will not be able to compromise your already received data (but can intercept new emails). It's similar to [Proton Mail Bridge](https://proton.me/fr/mail/bridge),
|
|
||||||
but keep in mind that Aerogramme does not support (yet) end-to-end email encryption like Proton Mail or Tutanota, *so Aerogramme is less secure*.
|
|
||||||
|
|
||||||
When run on server (both for the transparent and hardened flavor), Aerogramme must be started in the "provider mode", as in "email service provider".
|
|
||||||
When run on the end-user device (only the hardened flavor require that), Aerogramme must be started in the "companion mode", as in "a companion process of your email client".
|
|
||||||
These 2 words are materialized as 2 subcommands on the Aerogramme binary: `aerogramme provider` and `aerogramme companion`.
|
|
||||||
|
|
||||||
*Earlier, we started Aerogramme in the provider mode with a test account configured with the transparent flavor.*
|
*Earlier, we started Aerogramme in the provider mode with a test account configured with the transparent flavor.*
|
||||||
|
|
||||||
-->
|
-->
|
||||||
|
|