question: DMS with Roundcube + Roundcube Password Plugin

[ValentinRgt]

Subject

I would like some feedback concerning a use case

Description

Hello,

I have setup Docker Mailserver with Roundcube on my server until now everything works fine, however I would like to use the roundcube password plugin so that my collaborators can manage their password without my intervention except that I can't get it to communicate with the dovecot server...

Could you please help me with this configuration?

[polarathene]

Could you please help me with this configuration?

I don't think this would work reliably for you.

We presently have two ways to manage passwords. Our file based postfix-accounts.cf that you use setup email add ... command to manage, and LDAP which you manage with other software and we just direct auth through that.

With LDAP, Dovecot will send password login through that, but with postfix-accounts.cf each time the container is started or the change detection service is triggered, we re-create the Dovecot accounts DB with our postfix-accounts.cf. So any modification directly to Dovecot by something else would lose it's changes at that point.

Your best bet would be use LDAP and provide some way to update passwords through that. Presently LDAP does opt-out of our change detection service. So any file support to reload services or config would require container restarts to apply.

There are others interested in a password/account API and OAUTH/OIDC support, both which might be other alternatives you could leverage but I'm not aware of anyone actively working on either right now.

[ValentinRgt]

Eventually, if you integrate Roundcube into the docker image to make this plugin functional wouldn't that be possible?

For example, a parameter in the .env like ROUNDCUBE_ENABLED=true|false ...etc behind?

[polarathene]

if you integrate Roundcube into the docker image to make this plugin functional wouldn't that be possible?

Maybe? I don't know if we'd do that though. It'd be more likely you'd run Roundcube as a separate container and we have some example in docs on how to better integrate with DMS. That requires someone to contribute such however.

Users have requested ability to not require admin to manage passwords on behalf of others, and that's not always for Roundcube, an API would better meet the needs and could be integrated into DMS image. Then someone could probably make a Roundcube plugin that uses that API, or the alternative of using LDAP/OIDC (which'd manage passwords elsewhere).

[ValentinRgt]

I agree about the LDAP, but you said that the container had to be restarted after modification, so the problem isn't solved...
You're also talking about APIs. Can I open a websocket or http server to send requests to the dovecot or dms server?

You said that in the doc there was a section talking about DMS and Roundcube? I'd like the page, but I can't find it...

[polarathene]

had to be restarted after modification

Anything that our change detector supports reloading services for to apply config changes. Anything that is managed by LDAP isn't a concern there. If you use the setup ... command and it modifies relay config, or you update cert files, that won't be detected without the change detector.

You're also talking about APIs

Not implemented. There was an attempt but it stalled. Users want it but there's been very little contribution towards making it possible.

You said that in the doc there was a section talking about DMS and Roundcube?

No, misunderstanding again. I was suggesting that we would more likely document how to setup Roundcube as a separate container to use with DMS, instead of add Roundcube into DMS image.

We have no such docs. You can find some users sharing config in our issues with search, but this does not address the request you have for password plugin integration.

[ValentinRgt]

docker-compose.yaml

version: '3'

name: mailserver-stack

services:
  mailserver:
    image: mailserver/docker-mailserver:latest
    container_name: mailserver
    hostname: mail
    domainname: DOMAIN_NAME.EXT
    env_file: /opt/docker/mailserver/mailserver/mailserver.env
    ports:
      - "25:25"
      - "587:587"
      - "465:465"
      - "110:110"
      - "995:995"
      - "143:143"
      - "993:993"
      - "4190:4190"
    volumes:
      - /opt/docker/mailserver/mailserver/mail/data/:/var/mail/
      - /opt/docker/mailserver/mailserver/mail/state/:/var/mail-state/
      - /opt/docker/mailserver/mailserver/mail/logs/:/var/log/mail/
      - /opt/docker/mailserver/mailserver/config/:/tmp/docker-mailserver/
#     - /opt/docker/mailserver/mailserver/certs/:/certs
      - /opt/docker/mailserver/mailserver/certbot/certs/:/etc/letsencrypt/
      - /opt/docker/mailserver/mailserver/certbot/logs/:/var/log/letsencrypt/
#     - /opt/docker/mailserver/mailserver/backup/:/backup/
      - /etc/localtime:/etc/localtime:ro
    restart: always
    cap_add:
      - NET_ADMIN
      - SYS_PTRACE
    networks:
      - mailserver
    healthcheck:
      test: "ss --listening --tcp | grep -P 'LISTEN.+:smtp' || exit 1"
      timeout: 3s
      retries: 0

  roundcubeemail:
    image: roundcube/roundcubemail:latest
    container_name: roundcube
    restart: always
    env_file: /opt/docker/mailserver/roundcube/roundcube.env
    volumes:
      - /opt/docker/mailserver/roundcube/www/:/var/www/html
      - /opt/docker/mailserver/roundcube/config/:/var/roundcube/config
      - /opt/docker/mailserver/roundcube/db/:/var/roundcube/db
      - /opt/docker/mailserver/roundcube/temp/:/tmp/roundcube-temp
    ports:
      - "9000:80"
    depends_on:
      - mailserver
    networks:
      - mailserver

networks:
  mailserver:
    name: mailserver_network
    driver: bridge

roundcube.env

# PostgreSQL => pgsql
# MySQL => mysql
# SQLite => sqlite
ROUNDCUBEMAIL_DB_TYPE=sqlite

# Use this parameter if you use PostgreSQL or MySQL
#ROUNDCUBEMAIL_DB_HOST=localhost

# Use this parameter if you use PostgreSQL or MySQL
# PostgreSQL => 5432
# MySQL => 3306
#ROUNDCUBEMAIL_DB_PORT=3306

# Use this parameter if you use PostgreSQL or MySQL
#ROUNDCUBEMAIL_DB_NAME=roundcube

# Use this parameter if you use PostgreSQL or MySQL
#ROUNDCUBEMAIL_DB_USER=roundcube

# Use this parameter if you use PostgreSQL or MySQL
#ROUNDCUBEMAIL_DB_PASSWORD=roundcube

# Roundcube Skin
ROUNDCUBEMAIL_SKIN=elastic

# Doc : https://github.com/roundcube/google-spell-pspell
#ROUNDCUBEMAIL_SPELLCHECK_URI

# Roundcube languages
ROUNDCUBEMAIL_ASPELL_DICTS=fr,en

# Roundcube max upload file size
ROUNDCUBEMAIL_UPLOAD_MAX_FILESIZE=5M

# Roundcube plugins
ROUNDCUBEMAIL_PLUGINS=archive,zipdownload,enigma,password,emoticons,identicon

ROUNDCUBEMAIL_DEFAULT_HOST=tls://mail.DOMAIN_NAME.EXT
ROUNDCUBEMAIL_DEFAULT_PORT=143

ROUNDCUBEMAIL_SMTP_SERVER=tls://mail.DOMAIN_NAME.EXT
ROUNDCUBEMAIL_SMTP_PORT=587

[ValentinRgt]

Here is an example configuration :)

Anything that our change detector supports reloading services for to apply config changes. Anything that is managed by LDAP isn't a concern there. If you use the setup ... command and it modifies relay config, or you update cert files, that won't be detected without the change detector.

Okay...

Not implemented. There was an attempt but it stalled. Users want it but there's been very little contribution towards making it possible.

How can we help you?

[polarathene]

Here is an example configuration :)

Thanks! Like I said there is a few in issues already. It's not for me, but a suggestion for users interested in DMS and Roundcube that someone might contribute documentation on setting up Roundcube with DMS and potentially mentioning any gotchas like the password changing.

Not too helpful for you since you've already gone through that, and usually why we don't get contributions for such as it benefits those that come after you instead of yourself 😅

How can we help you?

With an API? That is up for discussion.

Right now we rely on shell scripts, and have our setup ... commands. So an API service could run over HTTP or unix socket and run those commands. In the past we've discussed OpenAPI 3 schema/API as that is a nice standard with some perks.

I've proposed keeping it simple, allowing for a 2nd container to build a public API around, which can handle approaching security (authentication/RBAC, TLS, rate limiting, etc) as that can all vary by need it's simpler to keep out of the core of DMS. The original effort was opting to do all of it in a single API service that extended our DMS image release as a base layer.

Once that is sorted, users may make their own frontend UIs for users to manage accounts via that API under the hood. In your case perhaps a roundcube plugin instead.

It's a fair amount of work to do however, and I am not sure if the other maintainers are that familiar with this type of work to give it a fair review / maintenance, thus it may be difficult to upstream into DMS directly. Hence the separate project. I'm also slowly exiting as a maintainer of DMS (probably my last year).

If this is something you'd like, and you're able to build it out I'd say go for it. You can ask me or the other maintainers any questions that we could be helpful with, such as where logic in DMS is handled. When you have something ready, we can pin an issue or discussion topic for better visibility and include a mention in our docs, if enough users are interested and have a good experience with it, it can probably transition from third-party if you like, or just be endorsed.

If you're unable to contribute the feature, but have funds, you can try supporting a bounty and someone with the time might be willing to work on it.

[ValentinRgt]

Hello,

Yes, I don't mind contributing to the development of this API, but we need to see the specs you've already done to improve them and see if we need to modify too much of the original dms config....

[polarathene]

we need to see the specs you've already done

I only know of this attempt which was made with Python. Two maintainers would prefer implementation with Rust, but whatever gets the job done is better than nothing :)

There is an old issue on the API topic for changing passwords in this repo, it is referenced in the README of the admin repo I linked. There you'll also find a comment that might interest you, someone implemented an HTTP API with Roundcube plugin in Ruby Rails (see roundcube integration here) although that doesn't use our setup CLI and produces the postfix-accounts.cf file itself instead.

I have some feedback in a design discussion here, which is mostly what I've covered to you above already.

As for specs, there is an open issue with some discussion here: docker-mailserver/docker-mailserver-admin#1 (comment)

You'll also find it a bit confusing, but there is a closed PR on that admin repo, where the contributor opted to have review on their own fork, I provided a review: LukeMarlin/docker-mailserver-admin#2 (review)

There is another closed PR with a bit more discussion / insights there too if helpful.

---

Our shell scripts for modifying the account files isn't too great, there has been talk to write that in rust instead and expose an API service on top of that but I've not had the time. There's also been talk of postfix-accounts.cf changing format at some point in the future too, so ideally you'd build an API around the setup CLI commands rather than directly editing / replacing postfix-accounts.cf. In the links I also raise some other concerns you may want to account for.

[github-actions]

This issue has become stale because it has been open for 20 days without activity.
This issue will be closed in 10 days automatically unless:

• a maintainer removes the meta/stale label or adds the stale-bot/ignore label
• new activity occurs, such as a new comment

[github-actions]

This issue was closed due to inactivity.