Lacre frontend (the interface used to upload, verify and delete keys) communicates with the backend (the job actually importing keys and encrypting messages with them) via database.
This could be changed by moving all database accessing-code to the backend and exposing a simple API for the frontend to call. This API could be a Unix or TCP socket, or maybe some queue to send messages to.
We could use gettext to translate Lacre messages to different languages (for example Spanish).
See Python Packaging User Guide.
There's a very well documented setup.py example.
See Alembic
Instead of using our own wrapper for GnuPG we should consider using something more thorough, like pretty-bad-protocol. (However, this project seems to be inactive since 2018…)
We could use context variables and logging.LoggerAdapter or logging.Filter to log more contextual information, like Message-Id of the message processed. That would make it easier to debug if something went wrong.
Read more in Logging Cookbook - Use of contextvars and documentation of contextvars module.
Instead of using after-queue mail filters, we could use Sendmail 8's Milter API. They can be written in Python too (see Python milters).
With Lacre being a Milter, it would become available for a wider audience (i.e. for Postfix and Sendmail admins).
Since Python has some limitations (e.g. its email module makes it hard to process messages without modifying their contents), I'm considering rewriting Lacre in Rust.
Crates I consider using:
asyncio;