Solving the LDAP issues is quite frustrating. If someone can help, please chime in!

@polarathene I really need your help with TLS now. Please take a look at parallel set 2.

Solving the LDAP issues is quite frustrating. If someone can help, please chime in!

Sorry for the lack of response for so long.. I had some technical difficulties (as usual 😓), back on Github now. I'll build the image from this PR starting from tomorrow and sort out the remaining TLS + LDAP test failures, since those are areas I'm familiar enough with I should be able to get those tests passing and we'll finally have this upgrade resolved! 😁

Huge appreciation for all the work you've done thus far on the task! ❤️ Once I've sorted the remaining tests out I'll review the PR fully.

Regarding the TLS failure

At a glance these are all failing only on Port 25, we don't manage that list explicitly (we do have some rules to filter out cipher suites, but we do not customize the cipher list order like we do for other service ports).

We hard-code the expected list in the failing test file here:

Exclusions are handled here:

The expected vs actual results appear to only differ by sorting, so presumably Postfix adjusted this in one of it's newer releases since 3.6.

• Notably *-CCM8 was all demoted to the end of the list (this particular variant is better for some embedded clients IIRC, which if we only offer AEAD ciphers we could allow the client to choose it's preferred cipher-suite to negotiate, but for the port 25 list I don't think we do).
• It should be okay to trust Postfix here if that's the case (nothing about the changed order is too concerning), so we can just adjust the referenced .bats lines to pass those tests.

EDIT: Only *-CCM8 suites were shifted to the end of the server-side preference list, their priority amongst themselves otherwise remains intact. CCM8 is for embedded, and has reduced security due to the Message Authentication Code (MAC) tag length (8 byte / 64-bit vs 16 byte / 128-bit). Change was due to OpenSSL policy config in Debian 13 (which Postfix inherited).

LDAP isn't as obvious at a glance and I'll troubleshoot that after some rest 👍

Progress

UPDATE: I've resolved all LDAP issues too, didn't take long but energy is too low to publish details (I managed to write-up about 70% of it 😅), I'll wrap that up tomorrow and follow-up with applying the necessary changes.

• Resolve LDAP + TLS failures
• Review PR in full
• Ensure changelog updated
• Ensure docs also have any applicable migration changes applied where necessary

Likely worth adding Changelog entries about for v16:

Fail2Ban 1.1.0 is a bit outdated and until a 1.1.1 release is published, there is an incompatibility with Dovecot 2.4 (which our tests supposedly didn't catch):

• Release 1.1.1 fail2ban/fail2ban#3939 (comment)
• add Dovecot 2.4 support fail2ban/fail2ban#4016

The Rspamd 4.0 release has breaking changes and is an implicit bump in the debian repo we pull it from (something that I recall the rspamd author said wouldn't happen, when they refused assistance to setup publishing versioned packages that we could have pinned).

Posting this a little early to avoid risk of data loss again on my end 😓

LDAP test failures

Failure 1 - SASLAuthd

LDAP test failure had simplest reproduction with this command to test auth:

$ testsaslauthd -u some.user -p secret
0: NO "authentication failed"

$ doveconf

# ...

ldap_auth_dn = cn=admin,dc=example,dc=test
ldap_auth_dn_password = # hidden, use -P to show it
ldap_base = ou=users,dc=example,dc=test
ldap_uris = ldap://ldap.example.test

# ...

passdb ldap {
  driver = ldap
  fields {
    auth_bind = no
    default_pass_scheme = SSHA
    ldap_version = 3
    pass_attrs = uniqueIdentifier=user,userPassword=password
    tls = no
    user_attrs = mailHomeDirectory=home,mailUidNumber=uid,mailGidNumber=gid,mailStorageDirectory=mail
  }
  filter = (&(userID=%{user | username})(objectClass=PostfixBookMailAccount))
}

userdb ldap {
  driver = ldap
  fields {
    auth_bind = no
    default_pass_scheme = SSHA
    ldap_version = 3
    pass_attrs = uniqueIdentifier=user,userPassword=password
    tls = no
    user_attrs = mailHomeDirectory=home,mailUidNumber=uid,mailGidNumber=gid,mailStorageDirectory=mail
  }
  filter = (&(userID=%{user | username})(objectClass=PostfixBookMailAccount))
}

$ cat /etc/saslauthd.conf

ldap_servers: ldap://ldap.example.test
ldap_auth_method: bind
ldap_bind_dn: cn=admin,dc=example,dc=test
ldap_bind_pw: admin
ldap_search_base: ou=users,dc=example,dc=test
ldap_filter: (&(userID=%U)(mailEnabled=TRUE))
ldap_start_tls: no
ldap_tls_check_peer: no
ldap_referrals: yes
log_level: 10

Failures were due to the PR likely having a find/replace operation applied carelessly for %u => %{user | username} (Dovecot 2.3 to 2.4 breaking change migration), as that replacement was also applied to %U (see upstream docs for this syntax token) that not only was a different casing, but also for an entirely different program (SASLAuthD).

Failure 2 - ENV config override

Meanwhile, this test case was failing because the override was no longer being applied (thus the "actual" output mismatch reported from the failure was the original config unmodified):

Failure 3 - LDAP UserDB + PassDB

The test-case dovecot: ldap mail delivery works was failing due to botched migration of Dovecot LDAP config, there was copy/paste of content from target/dovecot/dovecot-ldap.conf.ext as Dovecot 2.4 no longer delegates args to separate .conf.ext files the LDAP settings must be adapted accordingly (as documented upstream).

• default_pass_scheme = SSHA remains valid, but is only necessary if the password itself lacks a password scheme prefix. We do this in our examples, unclear about actual users own LDAP setups, so we should probably keep that for now given the upstream default is CRYPT.
• ldap_version = 3 is the default value already.
• tls = no maps to ldap_starttls = no (default).
  • This setting is only relevant for connecting to LDAP over port 389 instead of implicit TLS (preferred) over port 636 (which is instead handled via ldap_uris with an FQDN prefixed with ldaps://), as detailed here in upstream docs.
  • Port 389 can still use ldap:// scheme with ldap_uris and ldap_starttls will control if StartTLS is negotiated to upgrade the connection to be secured over TLS.
• auth_bind = no maps to passdb_ldap_bind = no (default).
• passdb_filter and userdb_filter are both treated in Dovecot 2.4 as a filter field in their respective passdb/userdb entries.
  • In Dovecot 2.4, we can however also add these external of the passdb/userdb objects and use the equivalent global name (that references that object type with the assigned driver name as a prefix to a field), such that passdb_ldap_filter for example is also valid, and thus easier for us to target via scripts? (this Dovecot 2.4 settings feature is documented early in the migration guide)
  • Your workaround was to insert invalid field names for scripts to target and then later use sed on the config to correct it. Going with the global setting name instead seems preferable?
• Likewise user_attrs/passdb_attrs was changed to fields (thus global setting names of userdb_ldap_fields / passdb_ldap_fields). This is notably where misconfiguration occurred, preventing successful authentication/lookup of LDAP users. EDIT: Actually this might still be supported via userdb_import but I don't see an equivalent for pass_attrs.

We'd instead want something like this:

# Replaced by ldap.sh
ldap_uris             = REPLACED
ldap_base             = REPLACED
ldap_auth_dn          = REPLACED
ldap_auth_dn_password = REPLACED

passdb ldap {
  driver = ldap
  filter = (&(objectClass=PostfixBookMailAccount)(uniqueIdentifier=%{user | username}))

  fields {
    default_pass_scheme = SSHA
    user = %{ldap:uniqueIdentifier}
    password = %{ldap:userPassword}
  }
}

userdb ldap {
  driver = ldap
  filter = (&(objectClass=PostfixBookMailAccount)(uniqueIdentifier=%{user | username}))

  fields {
    uid = %{ldap:mailUidNumber}
    gid = %{ldap:mailGidNumber}
    home = %{ldap:mailHomeDirectory}
    mail_path = %{ldap:mailStorageDirectory}
  }
}

This comment is just additional notes/insights for reference.

Failure 3 - Dovecot LDAP PassDB (no test coverage)

With our mail_with_ldap.bats test container we can do the following (applicable to earlier DMS releases):

# Requires `ENABLE_SASLAUTHD=1`:
# (this is an alternative SASL provider to Dovecot, only relevant to Postfix auth)
$ testsaslauthd -u some.user -p secret
0: OK "Success."

# Regardless of `ENABLE_SASLAUTHD`, the following tests Dovecot's `passdb` auth:
# (fails because our LDAP user has no `uniqueIdentifier` attribute to query accounts against)
$ doveadm auth test "some.other.user" "secret"
Error: cmd auth test: user some.other.user: internal auth failure
extra fields:
  user=some.other.user
  code=temp_fail

The uniqueIdentifier attribute as a default is configured in DMS for each SASL provider at these locations (DMS v15.1 / edge):

And in our mail_with_ldap.bats test file, we override those SASLAuthd and Dovecot LDAP pass filters to instead match on the LDAP accounts userID attribute configured as here:

There's no modification to Dovecot's pass_attrs (but we do support and document that), as such Dovecot passdb can find a result successfully with it's LDAP query, but we expected that response to return a uniqueIdentifier attribute to map to the Dovecot field user value... hence the failure.

NOTE:

• The user field itself however does not appear necessary, we could absolutely omit it from the config and the original username from the credential would be used.

  • It's only relevant if we need to actually adjust the value of the user attribute. PassDB supports a few other fields (username, domain) for the same purpose.
  • It can be worthwhile to normalize the login username to a canonical user in the sense of debug/verbose logs referring to the same account login regardless of the supported variations.

  For IMAP/POP3 related auth, I think it may also be relevant for a MUA to then query mailbox for that account via Dovecot's UserDB (although in the case of LDAP the same filter for userID will ensure the same account lookup occurs, unlike with our default FILE provisioner which expects ownership across different mail domains can differ, so the full address must be provided).

  For SMTP auth with Postfix delegating to Dovecot, if no domain-part is provided Postfix is configured by DMS to append one via smtpd_sasl_local_domain, which leads to a slightly inconsistent experience.

• For the LDAP accounts being tested against we could prefer mail or userID instead of uniqueIdentifier.

  This can be useful to normalize on what user should be set to, given that the %{user | username} filter will allow login with just the local-part or full mail address.

  docker-mailserver/test/config/ldap/openldap/ldifs/03_user-email-other-primary-domain.ldif

  Line 12 in e532b37

  mail: some.other.user@localhost.otherdomain

  docker-mailserver/test/config/ldap/openldap/ldifs/03_user-email-other-primary-domain.ldif

  Line 9 in e532b37

  userID: some.other.user

Example:

# `user = %{ldap:mail}` changes the `user` field to the full mail address:
# `original_user` is included in the returned fields to preserve the login username
$ doveadm auth test "some.other.user" "secret"
passdb: some.other.user auth succeeded
extra fields:
  user=some.other.user@localhost.otherdomain
  default_pass_scheme=SSHA
  original_user=some.other.user


# Since the `filter` takes the auth credential input `user` and then truncates any `@<domain-part>`
# via the syntax `%{user | username}` (Dovecot 2.4) / `%n` (Dovecot 2.3),
# we can also authenticate with the mail address as `userID` in both cases is matched to `some.other.user`.
# 
# In this scenario the login username already matches the LDAP `mail` attribute,
# thus no `original_user` field is returned.
$ doveadm auth test "some.other.user@localhost.otherdomain" "secret"
passdb: some.other.user@localhost.otherdomain auth succeeded
extra fields:
  user=some.other.user@localhost.otherdomain
  default_pass_scheme=SSHA

As mentioned earlier, PassDB will return user which in an auth flow for something like a MUA client accessing a mailbox over IMAP will be used for the UserDB lookup AFAIK to proceed. This can be tested with the following:

Failure:

# `user=%{ldap:mailAlias}` (postmaster@localhost.otherdomain):
# That `user` field is then queried to the UserDB after successful auth
# and no matching `userID` was found, so the login fails.
$ doveadm auth login "some.other.user" "secret"

passdb: some.other.user auth succeeded
extra fields:
  user=postmaster@localhost.otherdomain
  default_pass_scheme=SSHA
  original_user=some.other.user
Error: auth-master: login: request [3707109377]: Login auth request failed: Authenticated user not found from userdb, auth lookup id=3707109377 (auth connected 0 msecs ago, request took 0 msecs, client-pid=1733 client-id=1)
Error: cmd auth login: user some.other.user: userdb lookup failed: Internal error occurred. Refer to server log for more information.

Success:

# With `user=%{ldap:mail}` / `user=%{ldap:userID}` or as below no `user` field set:
# Any of these would succeed as their `user` value will match an LDAP account by `userID`.
$ doveadm auth login "some.other.user" "secret"

passdb: some.other.user auth succeeded
extra fields:
  user=some.other.user
userdb user: some.other.user
userdb extra fields:
  uid=5000
  gid=5000
  home=/var/mail/localhost.localdomain/some.other.user/
  mail_path=/var/mail/localhost.localdomain/some.other.user/
  auth_mech=PLAIN

NOTE: IIRC, there's another caveat with auth configuration (unrelated to the changes in this PR) that affected OAuth if a username / address wasn't properly canonicalized.

@georglauterbach no need to ping for review :) yes tests pass.. but there's still quite a bit of the PR itself that needs to be revised as I can see concerns there. I didn't have any spare energy to tackle that today.

Assuming my system or environment (power/internet) don't introduce interruptions again (I've had so many setbacks this year due to these problems), I'll be doing the full PR review tomorrow 👍

Due to the issues I've been having lately I'll probably reduce time spent on review feedback/discussion and push commits without detailed context until I'm happy with clicking approve. This PR has been delayed enough as it is :(

Documentation preview for this PR is ready! 🎉

Built with commit: 253e7b4

Right well... I've made a foolish mistake 😓

TL;DR: System crashed again.

• Firefox somehow got quite memory hungry and pushed memory usage up to 99% exceeding the 90GB capacity for committed memory (system memory + disk pagefile).
• In an attempt to try stay focused and keep memory usage down, I used an ephemeral session and made the poor decision to use the GH web IDE for pending changes that I didn't commit quickly. Once hitting OOM unexpectedly, uncommitted changes were lost.

Will continue with return to review again tomorrow.