[postfix] Can't get LDAP mailAlias to work
Nobody has claimed this yet.
- Dominant language
- Jinja
- Stars
- 1.4k
- Forks
- 379
- Avg merge
- 4d 18h
- Merged PRs (30d)
- 8
Description
results in a /etc/postfix/ldap_virtual_forward_maps.cf file which looks something like this:
# This file is managed remotely, all changes will be lost
# The virtual_forward_maps setting is used to find the final delivery address,
# given a distribution list.
server_host = ldaps://ldap.example.com/
search_base = dc=example,dc=com
query_filter = (& (| (objectClass=mailAlias) (objectClass=mailDistributionList) ) (mailAddress=%s) (| (authorizedService=all) (authorizedService=mail:receive) ) )
result_attribute = mailForwardTo
special_result_attribute = member
leaf_result_attribute = mailAddress
scope = sub
bind = yes
bind_dn = uid=postfix,cn=smtp.example.com,ou=Hosts,dc=example,dc=com
bind_pw = <something>
version = 3
start_tls = no
tls_ca_cert_dir = /etc/ssl/certs/
If I create a mailAlias LDAP entry like this (the authorizedService seems a bit like overkill but probably necessary given the query filter above?):
dn: mail=alias@example.com,ou=Groups,uid=postfix,cn=smtp.example.com,ou=Hosts,dc=example,dc=com
objectClass: mailAlias
objectClass: authorizedServiceObject
mail: alias@example.com
mailAddress: alias@example.com
mailForwardTo: bob@example.com
authorizedService : all
Then the alias lookup will expand to both the alias and the mailForwardTo address:
root@smtp:~# postmap -q alias@example.com ldap:/etc/postfix/ldap_virtual_forward_maps.cf
alias@example.com,bob@example.com
root@smtp:~# postmap -vq alias@example.com ldap:/etc/postfix/ldap_virtual_forward_maps.cf
...
postmap: dict_ldap_lookup: /etc/postfix/ldap_virtual_forward_maps.cf: Searching with filter (& (| (objectClass=mailAlias) (objectClass=mailDistributionList) ) (mailAddress=alias@example.com) (| (authorizedService=all) (authorizedService=mail:receive) ) )
postmap: dict_ldap_get_values[1]: Search found 1 match(es)
postmap: dict_ldap_get_values[1]: search returned 1 value(s) for requested result attribute mailAddress
postmap: dict_ldap_get_values[1]: search returned 1 value(s) for requested result attribute mailForwardTo
postmap: dict_ldap_get_values[1]: Leaving dict_ldap_get_values
postmap: dict_ldap_lookup: Search returned alias@example.com,bob@example.com
...
While I'd expect only the mailForwardTo address to be returned (i.e. bob@example.com).
I'm guessing one reason could be that the Postfix LDAP docs, section leaf_result_attribute says:
When one or more special result attributes are found in a
non-terminal (see above) LDAP entry, leaf result attributes are
excluded from the expansion of that entry
(note the leading when).
One alternative would be to change the mailAlias entry so that it contains members attributes pointing to the DN corresponding to "Bob", but I can't really figure out how to do so. mailAlias is structural and I can't find a suitable auxiliary objectClass which permits member attributes (and also, the above LDAP entry should work, shouldn't it?).
So, suggestions on what to do? Have I misunderstood how a mailAlias entry should be configured....or have I hit a bug in Postfix? (this was all tested using Bullseye).
Also, @drybjed - the mailservice.schema seems a bit....underdocumented at the moment? Any chance of adding some more documentation about it to one of the appropriate roles?
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with ansible/roles/postldap/defaults/main.yml at lines 341-362 and reproduce the lookup using postmap with ldap_virtual_forward_maps.cf. Compare the configured query_filter, result_attribute, special_result_attribute, and leaf_result_attribute with the Postfix LDAP behavior described in the issue. Done means the mailAlias lookup returns only mailForwardTo, or the issue documents the required LDAP entry configuration and schema guidance.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- ansible
- Domain
- infrastructure
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100