Koverto requirements analysis
About Kuvert
Things about Kuvert that are explained in the README and manual pages Kuvert that are important for Koverto design.
What Kuvert does not
- Does not work as mailman or schleuder, in which the final destinations are managed by aliases mailman.
- In the same way, it does not require to modify an email server setup.
What Kuvert does
- It requires to modify the configuration of the application
(from now on
client
) that send emails to be processed by Kuvert. - Only one
Kuvert
process can run in the same system, because it launches a receive-only MTA in a port. - Only one
.Kuvert
configuration file perKuvert
process. kuvert_submit
andKuvert
share the same configuration file.- Only one
.kuvert_queue
directory. - The client needs to be configured to either call
kuvert_submit
or configure the client SMTP credentials with the Kuvert's receive-only MTA. Kuvert
process *only- process emails from the.kuvert_queue
or incoming in the Kuvert's MTA.Kuvert
uses *only- one keyring (GnuPG keyring).Kuvert
delivers the final email viasendmail
or external email server found in the configuration file.Kuvert
allows per-recipient rules, but not per-sender rules- Kuvert logging in info mode does not say much, in debug mode is too verbose
- Kuvert only allows one sender email and key to sign
For better understanding, see the example Kuvert's sessions.
Differences of Sequoia store with GnuPG keyring
- Sequoia store can have different
realm
s (each of them has also an associated) label name that contain different sets of public keys. - Sequoia store does not have private/secret keys so far. Therefore, *Umschagend can not sign emails- for now.
Initial thoughts
What Koverto could do different to Kuvert
Idea 1
- Have different queue directories per configuration or cli argument.
- Have a different sequoia store realm per queue directory.
Problem:
- How would
koverto
process know on which queue directory to search for emails or which store realm to search for OpenPGP keys?. One way could be to use the email addresses from which the emails come from, but there could be several levels of local_parts and subdomains to take into account and it adds complexity. In addition we want to be able to use the same sender email address with different clients and strategies.
Idea 2
- Allow different
koverto
processes to read different configuration files and use different queues and sequoia store realms.
Problem:
- Adds complexity and can become confussing to administer.
Idea 3
- If the applications only use the receive-only MTA, there is no need for a queue directory
Idea 4
- Use an ssh tunnel, client or sendmail to put the email notifications in
a directory read by
koverto
. See the Deployment Impossible diagram.
Problem:
- The applications do not allow to run arbitrary commands for sending their notifications, they only allow an SMTP server.
Using docker volume mounts
Koverto will most likely run in docker containers using volume mounts. This way the code lives in the image and the data in volume mounts. Data notably includes:
- The sequoia store with all the public keys
- The mail queue directories
- log files
Volume mounts can be shared with the host and/or other docker containers. This way standard sequoia tools can be used to add keys to the keystore.
In addition a receive only MTA such as OpenSMTPD could run in a separate container and queue the mails to then be processed by koverto.
Minimal Koverto design
- Make
koverto
behave the same way asKuvert
, one configuration file per email submission/MTA, process, queue and store realm, to do not add complexity and be compatibly withKuvert
. - If different applications would like to have different sequoia store realms,
they would need to run
koverto
in different systems. - Use the same configuration variables as
Kuvert
, to make it easy to understand/migrate tokoverto
if the users already know/administerKuvert
. - Use the same cli arguments as Kuvert, for the same reason.
Handle multiple queue dirs with different policies
A single koverto instance could allow for handling mails according to different policies.
The configuration would set the policy based on the directory the mails are queued in.
For example koverto could watch for queued mails in
queue/must-encrypt
queue/fallback
queue/sign-only
This way the MTA could be configured to store the mails in different folders based on the requirements of the clients.
It could expose this distinction by receiving mails on different domains, ports or with different authentication credentials.
Receive mails with koverto itself.
Work has started on using Samotop as an SMTP server that hands the incoming mails to koverto.
Currently it is running as a receive only MTA that queues the mails in a directory.
However this integration would be particularly interesting if we need to couple the MTA and the koverto process closer together for some reason.
Samotop is a research project and the development seems stalled for quite a while. However we could not find a more mature rust SMTPd out there either.
For now using a different MTA to queue the mails seems to be the way to go for production environments.
Kuvert and Koverto CLI arguments
submit as kuvert_submit. See kuvert_submit for the following arguments:
-f As Kuvert.
Maybe to implement in the future
-t As Kuvert, but for koverto is the default right now.
Maybe to implement in the future.
Without submcommand, it will run the local MTA, if configured, and
it will reads the emails in the configured queue.
-c Path to the configuration file. This option is not availabe in
Kuvert.
-o As Kuvert, but for koverto it's the default right now.
-d As Kuvert. Maybe to implement in the future
-r (SIGUSR1) As Kuvert, it should be implemented.
-k (SIGTERM) As Kuvert, it needs to be implement,
to allow stop koverto cleanly and easy systemd integration
Requirements by actual Kuvert users
How they use Kuvert
- not use
kuvert_submit
command, because the applications they use do not allow to use arbitrary commands for notifications, only MTAs. - send email using the configuration of the Kuvert receive-only MTA.
- Multiple instances of Kuvert in docker containers to be able to have have different applications using different MTA credentials (ie. not having the same password to authenticate with Kuvert receive-only MTA)
- The different applications also require Kuvert do different things, eg.
- encrypt (and sign?) or drop
- encrypt opportunistically (and sign?)
- unencrypted but signed
- An script to reload Kuvert cause it does not detect when new keys are added or removed
keyring
- all Kuvert instances use the same keyring
- keys that are verified are stored in a git repository with the file named
with the email address, (eg. alice@example.example.asc?) pad L105
- if a key has multiple verified email addresses, there is one file per email address. pad L106
What they need
- have only one application running as a receive-only MTA (#24) that allows different credentials, ie. user/password per client
- allow each client to do different things, ie. encrypt and/or sign
- do not have to reload Kuvert to detect changes on the keyring
Logging
- At info level, it should log:
- email received from alice@example.example
- email sent encrypted to bob@example.example with key BBBBBBBBBBBBBBBB and signed with key CCCCCCCCCCCCCCCC
- At debug level:
- plain text when something (what) fails
- have the option to run Kuvert foreground (#21)
Sender rules
- Each application (user/password) send the email with a different
From
and therefore possibly using a different key to sign
What would be nice to have
More ideas not required for a first release in the notes we took in a pad file.