7:11 p.m.
Hi Maciej, thanks for the thoughtful response. See my comments inline.
On Fri, 2021-02-26 at 21:32 +0100, Maciej Delmanowski wrote:
On lut 25, Imre Jonk wrote:
> - Support for virtual alias lookups for group members. This allows
> us to make a distribution list out of an LDAP group. Postfix
> resolves the distribution list members using
> special_result_attribute and leaf_result_attribute.
That's an interesting idea, although it seems that you use
'mailRecipient' as the objectClass. Wouldn't that result in such
group having its own Maildir/ as the final destination, with group
member e-mail addresses as aliases to it?
I don't believe it does. ldap_virtual_mailbox_maps returns the Maildir
path based on the uid attribute, which is not present in group objects.
Postfix would perform the following lookups when a message for a
distribution list is coming in:
1. ldap_virtual_alias_maps, for finding the mail attributes of the
member objects of the (distribution list) group object. For example:
given tech(a)ciphermail.com, this lookup would find imre(a)ciphermail.com
and martijn(a)ciphermail.com.
2. ldap_virtual_mailbox_maps, for finding the Maildirs related to the
member objects. These would be /imre/Maildir/ and /martijn/Maildir/ in
this example.
I would think that using 'mailDistributionList' instead would
be more
correct, where Postfix can lookup the members and forward the mail to
their mailboxes... Although I'm theorizing here, based on your diff,
maybe I need to see it in action.
This could very well be the preferred solution. I'll have a go at this
later this week. I think it would need some changes to other parts of
the role, like the ldap_smtpd_sender_login_maps configuration.
> - The maildir paths are /var/vmail/<uid>/Maildir instead
of
> /var/vmail/<domain>/<localpart>/Maildir. I like to associate
> mailboxes with
> the accounts in LDAP, which are primarily distinguished by uid and
> not email
> addresses.
This is probably very much environment-dependent but yes, using the
'uid' as the base seems to mesh better with current LDAP defaults in
DebOps, where 'uid' is globally unique. The LDAP schema supports the
'mailHomeDirectory' attribute which could also be useful to augment
the location in combination with Dovecot, but again - specific to an
environment. Thankfully, 'postldap' is pretty malleable as is. :-)
This can also be easily made user-configurable with a separate
inventory variable. I'll have a go at this.
I wonder if you support changing the 'uid' attribute in your
organization (it is done frequently at my workplace) and what is your
solution for moving the Maildirs around in this case. Seems that
Dovecot might have some mechanism for that via 'doveadm', although I
haven't investigated that yet. The 'dovecot' role still needs to be
refactored, and perhaps at that time somethin for moving Maildirs
around could also be added to it.
We haven't yet needed to do something like this, nor can I quickly come
up with a valid reason for it. Would you care to share why this is done
frequently at your workplace?
I imagine that changing a uid would require me to visit every service
that was used by the person behind that uid in order to correctly tie
the new uid to their existing accounts. Some services might use the
entryUUID attribute to identify a user account, but others (I think
GitLab) just use the uid.
> - We are using mailAlternateAddress attributes (mailRecipient
> objectClass) instead of mailAlias objects. This allows us to add
> email aliases directly to the existing people and group objects.
> The filters have been updated for this.
Good, good. As I said before, 'postldap' role was designed before the
'mailservice.schema' was introduced, that's why the current filters
used in the role might seem inadequate. Since you already battle-
tested the new LDAP schema in the field (I haven't yet, so huge
thanks for this!), it might be a good idea to update the 'postldap'
configuration.
I see that tblein has already created a PR for this. Nice!
> - I have removed the ldap_unauth_sender_access sender
restriction.
> This
> restriction forces SMTP clients to authenticate before sending mail
> when the
> sender address exists in LDAP. This is nice, but the
> ldap_unauth_domain_access sender restriction already forces
> authentication
> when an SMTP client tries to send mail from one of the domains in
> LDAP,
> which should be enough. Removing this restriction reduces the
> complexity of
> the whole system a little and saves some LDAP lookups.
First of all, if you really want to remove it, it might be easier to
just change its state to 'absent' in the inventory; no need to remove
the configuration entirely from the role.
That's a good idea.
I think that you missed a crucial function of this lookup though -
it
forces the mail clients to authenticate with the e-mail addresses
they own in the directory. It's essentially an anti-spoofing measure,
so that some user on your domain is not able to send an e-mail with
From: Imre Jonk <imre(a)ciphermail.com>
set as the mail header. Better check if that's possible with another
account ASAP.
I did test this, and if I remember correctly, this evil plan is foiled
by the ldap_smtpd_sender_login_maps restriction. I'll test it again
tomorrow though :)
Awesome guide, thanks! I think that it could be added in the
'postldap' role documentation as an example of a production setup.
Definitely. I'll put some effort in.
Cheers,
Imre