Koverto design for Version 1.0

The main deployment scenario is having one or multiple koverto instances run in docker containers: Docker deployment

Koverto expects mails in a queue dir that is mounted as a volume mount. A separate receive only MTA queues the mails there.

Key management happens in a sequoia key store that is also mounted as a volume mount.

This way koverto runs as a single daemon in the container. All data is on volume mounts. And all interaction (sending mails, adding keys) happens via these mounts.

Based on the Requirements analysis, the following components are needed or a 1.0.0 release:

  • Configuration file. It would need to have:
    • Sequoia store configuration
    • Credentials to use an external MTA for sending email
    • Clients section. Each client:
      • A name
      • A queue directory to look for mails in
      • Actions to be run with the emails (modes in Kuvert):
        • MustEncrypt - Attempt to sign and encrypt, drop mail if encryption fails.
        • Fallback - Attempt to sign and encrypt, fall back to signing if encryption fails.
        • SignOnly - no encryption just sign.
      • There is no need to configure a signing key, since it can be found with the From email address or generated by sequoia
  • Connection to the sequoia store. The store is queried for every key lookup. This way keys added to the store will become available immediately.
  • Process the emails and keys using Sequoia:
    • Parse the emails
    • Obtain recipients (only To for now)
    • Obtain recipients' key(s) form the sequoia store
    • Sign and (optionally) encrypt body depending on configured crypto action
    • log these actions at different levels.
    • Compose encrypted/signed email
  • Send email to an external MTA.
  • A single configurable log file that logs:
    • WARN: missing or expired keys
    • WARN: failed delivery attempts
    • INFO: keys being added
    • INFO: mails being processed

Most notably the 1.0 Version will NOT :