Create a Delta Chat bot as an additional admin interface

[missytake]

We want users to be able to run mailadm commands out of Delta Chat. The bot creates a verified group - to make someone an admin, you can just invite them to the group. This interface can expose pretty much all of the command line commands.

A first try to implement this was in #23, but it's pretty outdated as it was before the switch to mailcow. Not sure if it can be re-used.

usage flow

• during setup (after mailadm init) run mailadm setup-bot to create a bot account and admin group. it shows an invite QR code for the admin group.
  • this can be re-run later if you lose access to the admin group, to create a new admin group. This ensures that SSH admins can always regain control over the setup.
  • if you don't specify --email and --password, mailadm creates a [email protected] email address in the mailcow instance.
• whoever is sitting in front of the command line can scan the QR code with Delta Chat to become the first admin. They can invite others to the group to make them admins, too.
• any command in the group is accepted by the bot, but also seen by anyone else. (alternative: allow anyone in the admin group to send commands to the bot privately per DM)

to do

• write a Delta Chat bot to listen to commands: DeltaChat bot as additional command interface #46
• write tests: First working bot tests #54
• make the rest of the CLI commands available through the bot interface
• document mailadm setup-bot
• document all mailadm commands
• make bot replies In-Reply-To the command which triggered them: bot method to reply to user's command #53

[missytake]

In the discussion with the mailcow folks we came to the conclusion that it makes sense to run the flask HTTP API, the prune commands, and the bot all in the same process/container.

Open questions:

• Right now the HTTP API is run with a gunicorn command (in the docker container). How can we start the prune loop and the deltachat bot from there?
• How can we kill the whole process if one of the children tasks dies? (I'm probably using wrong terminology here, I never really worked with threading)

[missytake]

Right now the HTTP API is run with a gunicorn command (in the docker container). How can we start the prune loop and the deltachat bot from there?

the easiest way to do this seems to be starting the prune and bot threads from src/mailadm/app.py.

How can we kill the whole process if one of the children tasks dies? (I'm probably using wrong terminology here, I never really worked with threading)

Could the bot and prune threads be daemons, which kill the main process if they die? This way the whole process would die if any thread dies, causing the docker container to restart.

[dumblob]

Related: #101 (I wanted to keep security issues separate).

[dumblob]

Any plans for this bot to notify about important behavior of the server?

1. warning about an ongoing attack (ddos, ...)
2. periodical warning about attack statistics (e.g. list of attacks during the last 7 days with countries listed, type of attack, intensity in whatever measure best suits it, etc.)
3. warning about low disk space (periodically until it gets solved)
4. warning about certificates which are about to expire (periodically until it gets solved - i.e. continue notifying even after the certificate expired if it was not exchanged yet)
5. warning about domain expiration (dtto)
6. ... lots of other monitoring events

Each such notification should have 2 parts:

a. Concise description what happened.
b. List of possible solutions with command examples to "copy & paste".

[missytake]

Those are cool ideas :) I think they are far in the future, but yes, this bot interface could one day be used for many server/admin interactions beyond user management.

[missytake]

oops, misclick.

If you want to contribute on features like this, I suggest you open an issue about them, we discuss a bit about what makes sense considering the different use cases of mailadm, and then you can start implementing :)