Alternative (DIY without landing the PR)

Usually when I demonstrate (like below) how to approach without upstreaming via PR a user is happy with that as it's much less burden for both parties involved 😅

You would have your typical DMS compose.yaml:

services:
  dms:
    image: ghcr.io/docker-mailserver/docker-mailserver:latest # :15.0
    hostname: mail.example.test
    # ... Any other DMS related config ...

You can then append/merge this additional config, or layer it on with:

• CLI flags: docker compose -f compose.yaml -f <filename> up
• Implicitly via compose.override.yaml
• Docker Compose includes feature.

Here is roughly the same functionality as your PR, but as a single file you can carry/reference that doesn't require upstreaming into DMS with docs + tests.

services:
  dms:
    # You'd normally use `volumes` here but for simplicity of the example, all config is contained within `compose.yaml`:
    configs:
      - source: dovecot-custom
        target: /tmp/docker-mailserver/dovecot.cf
      - source: dovecot-gssapi-auth
        target: /etc/dovecot/conf.d/auth-kerberos.inc
      - source: dovecot-gssapi-passdb
        target: /etc/dovecot/conf.d/auth-kerberos.conf.ext

# Using the Docker Compose `configs.content` feature instead of volume mounting separate files.
# NOTE: This feature requires Docker Compose v2.23.1 (Nov 2023) or newer:
# https://github.com/compose-spec/compose-spec/pull/446
configs:
  # Enable Kerberos PassDB (Authentication):
  dovecot-custom:
    content: |
      auth_gssapi_hostname = "$ALL"
      !include auth-kerberos.inc
      !include auth-kerberos.conf.ext

  dovecot-gssapi-auth:
    content: |
      auth_gssapi_hostname = mail.example.com
      auth_krb5_keytab = /etc/dovecot/krb5.keytab
      auth_realms = example.com
      auth_default_realm = example.com

  dovecot-gssapi-passdb:
    content: |
      passdb {
        driver = ldap
        args = /etc/dovecot/dovecot-ldap.conf.ext
        mechanisms = gssapi
        default_fields = nopassword=y
      }

  dms-user-patches:
    content: |
      #!/bin/bash
      
      # Ensure custom CA certificates are recognized:
      update-ca-certificates

      # Add GSSAPI support:
      apt-get update && apt-get install dovecot-gssapi

      # Append `,krbPrincipalName=k5principals` to end of `pass_attrs`
      # if the line appears unmodified:
      sed -i -r -e \
        '|^(pass_attrs.*userPassword=password)$|\1,krbPrincipalName=k5principals|' \
        /etc/dovecot/dovecot-ldap-conf.ext

If you still needed to use this helper function for ENV based overrides, that would still be possible in user-patches.sh, you'd just need to import (source) our utils.sh scripts first like this:

source /usr/local/bin/helpers/index.sh

_replace_by_env_in_file 'KERBEROS_' '/etc/dovecot/conf.d/auth-kerberos.inc'

NOTE: The package install in user-patches.sh will add a startup delay. We document similar advice for users interested in Apache SOLR for FTS functionality. If you need to minimize the delay you can easily extend DMS locally instead like this:

services:
  dms:
    hostname: mail.example.com
    # The `image` setting now represents the tag for the local build configured below:
    image: localhost/dms:${DMS_TAG?Must set DMS image tag}
    # Local build (no need to try pull `image` remotely):
    pull_policy: build
    # `Dockerfile` to build is embedded into the Docker Compose config:
    build:
      dockerfile_inline: |
        FROM docker.io/mailserver/docker-mailserver:${DMS_TAG?Must set DMS image tag}
        RUN apt-get update && apt-get install dovecot-gssapi

Likewise the configs section for Kerberos additions could be added into that image as separate files via COPY if you prefer that instead of additional volumes/configs entries. The related user-patches.sh could be a separate script that you have a simpler user-patches.sh call too.

The main caveat apart from carrying all that yourself instead of offloading it to the project is potential maintenance burden when upgrading if anything changes internally within DMS that'd affect those configs.

This project tends to be reluctant towards new features without prior discussion/approval, especially when there is low demand from users.

Yes. I saw that but wanted to contribute either way, I already have a working setup with kerberos.

Could you please add context to why Kerberos would be beneficial? (I'm not familiar with it beyond name, nor do I recall any users requesting it over the past 5 years) I am interested to know why it may be preferred over existing auth support.

Kerberos enables no-password logins to imap, pop and smtp, by using the user's sessions TGT (Ticket Granting Ticket), It's more of a complement to regular ldap login that is pretty well deployed in the enterprise space (ex. Windows Single Sign On).

There have been some issues regarding this, namely #1024 and #1021

If it were to be approved documentation would need to be added, along with tests. Often that is more effort than just adding a docs example for the benefits of other interested users.

Yes, of course, I sent the PR to gather feedback regarding my changes, and will be documenting everything accordingly.

The LDAP auth has tests and docs but lacks proper maintainer support over the years, yet has much more demand/adoption from users than Kerberos. So while I appreciate the PR I'm not sure if we want to take this feature on. It'll likely have some breaking changes that'd need to be changed for the Dovecot 2.4 upgrade too 😅

The upgrade of these changes to 2.4 shouldn't really be such a burden given that Kerberos auth didn't change

I've provided an example compose.yaml below that might work well enough for you?

Thanks! But I already have a setup of my own ^^"

I still have several things in my todo for this PR:

• Add SASLAUTHD support
• Enable the use of the keytab for ldap - not possible due to dovecot limitations
• Figure out a test plan (by changing the date-time during tests ? Kerberos is time sensitive)

This project tends to be reluctant towards new features without prior discussion/approval, especially when there is low demand from users.

Yes. I saw that but wanted to contribute either way, I already have a working setup with kerberos.

That's nice, but not the point. You opening the issue is not for you, but for us. I am not against adding this functionality, but we need to make sure we can maintain it and we need to make sure there is enough need to justify maintenance.

This project tends to be reluctant towards new features without prior discussion/approval, especially when there is low demand from users.

Yes. I saw that but wanted to contribute either way, I already have a working setup with kerberos.

That's nice, but not the point. You opening the issue is not for you, but for us.

I have a working setup. This is not for me, I want my work to benefit the community - hence my contribution.

I am not against adding this functionality, but we need to make sure we can maintain it and we need to make sure there is enough need to justify maintenance.

Maintaining this shouldn't be and issue given that the configuration in dovecot do not seems to have went through major changes in the last few years.

Regarding usage, I do agree that Kerberos is not well-known and is rather niche. His usage is mainly in Microsoft Windows Active Directory and FreeIPA (the one I tested with) and allows the single sign-on using clients like Thunderbird ref.

This is mostly used in enterprise environments, but some people (like me) like to run it for their own infrastructure and such.

I pointed out an issue requesting Kerberos / GSSAPI authentication in my earlier messages.

I do not mind my PR being rejected, I offer my contribution, and it's not my project at the end.

I want my work to benefit the community - hence my contribution.

Appreciated, but there has been no one else engaging in this community requesting GSSAPI support for a long time (your references are from 2018, with one comment in 2020, nothing else for 5+ years).

Hence maintainers are understandably reluctant to have the burden of looking after the feature as it can add friction for us to support when there's only 1 (or few) users interested in the feature.

This is why we have a process to defer to a docs contribution first when viable (I already demonstrated how this feature could be supported easily that way).

Maintaining this shouldn't be and issue given that the configuration in dovecot do not seems to have went through major changes in the last few years.

There's been a notable change between Dovecot 2.3 and Dovecot 2.4.

The burden is usually on support from users seeking help, or if we do run into any issues like we have with LDAP.

Beyond support requests and docs not being in good shape for LDAP, we've not been able to as easily offer feature parity as it's slightly out of sync with the file based provisioning and some differences. Additionally the tests could fail (we've gone through refactoring in the past where the lack of LDAP knowledge added friction, and the external deps like an LDAP container has required maintenance due to upstreams dropping maintenance support of their images).

We've also had issues with other features that had been contributed previously such as Dovecot FTS with Xapian (where we ended up needing to compile the plugin support ourselves) and Solr (we carried a package with docs that had become stale/unmaintained, the package lacked ARM64 support requiring extra support on our end_).

Your PR already adds to the burden of LDAP support with the changes this PR proposes as it adds additional complexity (not for you but for us). Once we officially support a feature, user support and maintenance is offloaded onto us.

As we will require tests like we do with LDAP, this does add extra burden when maintainers need to interact with the related feature support. A similar feature for SQL DB support offers a bit more value but would also have similar costs for maintainers, along with adding friction to refactoring to some degree in my experience 😓

I do not mind my PR being rejected, I offer my contribution, and it's not my project at the end.

It's small enough that I might be ok with it, but I'm also wanting to step down from my maintainer status at some point, thus the other maintainers would need to approve.

You'd still have docs (for which I tend to be a bit strict on for quality), and tests (that you've already raised is a bit tricky to approach)... Are you sure you want to push for upstreaming this into DMS straight away vs the much simpler documentation contribution? (I'm more lax on review when it's an unofficial guide)

Docs would still be discoverable and benefit any interested users. It can also be as simple as a small FAQ entry (or similar location) to reference a link to the PR here (or my compose.yaml override comment).

A reference compose.override.yaml (similar to what I already demonstrated), should make it rather simple to add that support?

You could almost avoid the user-patches.sh:

• The dovecot-gssapi package could potentially be included in our build by default (on the basis it causes us no burden, otherwise we're free to drop it).
• update-ca-certificates could rather easily get in through a separate PR (it would still require some mention in docs + test to verify).

I have a working setup. This is not for me, I want my work to benefit the community - hence my contribution.

Definitely appreciated!

I am not against adding this functionality, but we need to make sure we can maintain it and we need to make sure there is enough need to justify maintenance.

Maintaining this shouldn't be and issue given that the configuration in dovecot do not seems to have went through major changes in the last few years.

Whether this is the case is up to us - not to you. This project mandates holding the discussion beforehand in an issue.

I do not mind my PR being rejected, I offer my contribution, and it's not my project at the end.

I'd like to see this become an additional page in the documentation, as @polarathene has pointed out. Can you do that @MatthieuCoder?

I have a working setup. This is not for me, I want my work to benefit the community - hence my contribution.

Definitely appreciated!

I am not against adding this functionality, but we need to make sure we can maintain it and we need to make sure there is enough need to justify maintenance.

Maintaining this shouldn't be and issue given that the configuration in dovecot do not seems to have went through major changes in the last few years.

Whether this is the case is up to us - not to you. This project mandates holding the discussion beforehand in an issue.

I do not mind my PR being rejected, I offer my contribution, and it's not my project at the end.

I'd like to see this become an additional page in the documentation, as @polarathene has pointed out. Can you do that @MatthieuCoder?

Yes I can do that. Sorry I'm a bit busy currently, I'll get to it in a few weeks

@MatthieuCoder is this still something you want to tackle and will find time for at some point?

@MatthieuCoder is this still something you want to tackle and will find time for at some point?

Yes. Might be better to move this to an issue