4:53 p.m.
Hi all,
I've attached a diff file for the debops.postldap role. It contains
CipherMail-specific changes to the role defaults that more people might be interested in.
What do you think? Should I make a PR for (some of) these changes?
The changes are:
- Use of mailRecipient object class where it makes sense, specifically in the
ldap_virtual_alias_maps, ldap_virtual_mailbox_maps and ldap_smtpd_sender_login_maps
configuration.
- 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.
- search_base of ldap_virtual_mailbox_maps.cf set to the base DN instead of ou=People. We
did this because we also have mailboxes that are accessed by services whose LDAP accounts
are under the ou=Hosts tree. An example is the system that uses IMAP to access messages in
our support(a)ciphermail.com mailbox.
- 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.
- 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.
- 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.
- We're not using postldap__domain_rev_pattern.
Personal LDAP objects look like this:
dn: uid=imre,ou=People,dc=ciphermail,dc=com
objectClass: authorizedServiceObject
objectClass: hostObject
objectClass: inetOrgPerson
objectClass: ldapPublicKey
objectClass: mailRecipient
objectClass: posixAccount
objectClass: posixGroup
objectClass: posixGroupId
objectClass: shadowAccount
objectClass: top
cn: Imre Jonk
gid: imre
gidNumber: 2002000000
homeDirectory: /home/imre
mail: imre(a)ciphermail.com
mailAddress: imre(a)ciphermail.com
sn: Jonk
uid: imre
uidNumber: 2002000000
authorizedService: all
givenName: Imre
host: posix:all
loginShell: /bin/bash
mailAlternateAddress: dev(a)ciphermail.com
mailAlternateAddress: imre(a)ciphermail.com
mailAlternateAddress: imre(a)staging.ciphermail.com
Group LDAP objects used as distribution lists look like this:
dn: cn=UNIX Administrators,ou=Groups,dc=ciphermail,dc=com
objectClass: authorizedServiceObject
objectClass: groupOfNames
objectClass: hostObject
objectClass: mailRecipient
objectClass: posixGroup
objectClass: posixGroupId
objectClass: top
cn: UNIX Administrators
gid: admins
gidNumber: 2000000000
mail: tech(a)ciphermail.com
mailAddress: tech(a)ciphermail.com
member: uid=imre,ou=People,dc=ciphermail,dc=com
member: uid=martijn,ou=People,dc=ciphermail,dc=com
authorizedService: all
description: People responsible for UNIX-like infrastructure
host: posix:all
mailAlternateAddress: abuse(a)ciphermail.com
mailAlternateAddress: abuse(a)djigzo.com
mailAlternateAddress: hostmaster(a)ciphermail.com
mailAlternateAddress: postmaster(a)ciphermail.com
mailAlternateAddress: postmaster(a)djigzo.com
mailAlternateAddress: root(a)ciphermail.com
mailAlternateAddress: security(a)ciphermail.com
mailAlternateAddress: tech(a)ciphermail.com
mailAlternateAddress: tech(a)staging.ciphermail.com
mailAlternateAddress: webmaster(a)ciphermail.com
owner: uid=imre,ou=People,dc=ciphermail,dc=com
owner: uid=martijn,ou=People,dc=ciphermail,dc=com
Hoping this is useful for someone. It took me quite a while to figure out and explain in
writing what customizations I've made to this role. It's been a while since I last
touched the mail cluster configuration...
Cheers,
Imre
9:32 p.m.
On lut 25, Imre Jonk wrote:
Hi all,
I've attached a diff file for the debops.postldap role. It contains
CipherMail-specific changes to the role defaults that more people might be
interested in. What do you think? Should I make a PR for (some of) these
changes?
Thanks for sending these! The 'postldap' role was left a bit stagnant since
I had to first develop the 'mailservice.schema' in the 'slapd' role and
then
fix some issues for it. It seems that the current schema is working so the
'postldap' role can definitely be updated to support it out of the box.
The changes are:
- Use of mailRecipient object class where it makes sense, specifically in
the ldap_virtual_alias_maps, ldap_virtual_mailbox_maps and
ldap_smtpd_sender_login_maps configuration.
Good idea. :-)
- 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 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.
- search_base of ldap_virtual_mailbox_maps.cf set to the base DN
instead of
ou=People. We did this because we also have mailboxes that are accessed by
services whose LDAP accounts are under the ou=Hosts tree. An example is the
system that uses IMAP to access messages in our support(a)ciphermail.com
mailbox.
That's a good idea as well.
- 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. :-)
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 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 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.
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.
- We're not using postldap__domain_rev_pattern.
Sure, that's also environment-dependent. It's not useful if you don't have
senders on your subdomains.
Personal LDAP objects look like this:
dn: uid=imre,ou=People,dc=ciphermail,dc=com
objectClass: authorizedServiceObject
objectClass: hostObject
objectClass: inetOrgPerson
objectClass: ldapPublicKey
objectClass: mailRecipient
objectClass: posixAccount
objectClass: posixGroup
objectClass: posixGroupId
objectClass: shadowAccount
objectClass: top
cn: Imre Jonk
gid: imre
gidNumber: 2002000000
homeDirectory: /home/imre
mail: imre(a)ciphermail.com
mailAddress: imre(a)ciphermail.com
sn: Jonk
uid: imre
uidNumber: 2002000000
authorizedService: all
givenName: Imre
host: posix:all
loginShell: /bin/bash
mailAlternateAddress: dev(a)ciphermail.com
mailAlternateAddress: imre(a)ciphermail.com
mailAlternateAddress: imre(a)staging.ciphermail.com
Group LDAP objects used as distribution lists look like this:
dn: cn=UNIX Administrators,ou=Groups,dc=ciphermail,dc=com
objectClass: authorizedServiceObject
objectClass: groupOfNames
objectClass: hostObject
objectClass: mailRecipient
objectClass: posixGroup
objectClass: posixGroupId
objectClass: top
cn: UNIX Administrators
gid: admins
gidNumber: 2000000000
mail: tech(a)ciphermail.com
mailAddress: tech(a)ciphermail.com
member: uid=imre,ou=People,dc=ciphermail,dc=com
member: uid=martijn,ou=People,dc=ciphermail,dc=com
authorizedService: all
description: People responsible for UNIX-like infrastructure
host: posix:all
mailAlternateAddress: abuse(a)ciphermail.com
mailAlternateAddress: abuse(a)djigzo.com
mailAlternateAddress: hostmaster(a)ciphermail.com
mailAlternateAddress: postmaster(a)ciphermail.com
mailAlternateAddress: postmaster(a)djigzo.com
mailAlternateAddress: root(a)ciphermail.com
mailAlternateAddress: security(a)ciphermail.com
mailAlternateAddress: tech(a)ciphermail.com
mailAlternateAddress: tech(a)staging.ciphermail.com
mailAlternateAddress: webmaster(a)ciphermail.com
owner: uid=imre,ou=People,dc=ciphermail,dc=com
owner: uid=martijn,ou=People,dc=ciphermail,dc=com
Hoping this is useful for someone. It took me quite a while to figure out
and explain in writing what customizations I've made to this role. It's been
a while since I last touched the mail cluster configuration...
Awesome guide, thanks! I think that it could be added in the 'postldap' role
documentation as an example of a production setup.
Cheers,
Maciej
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
12:11 p.m.
On Monday, 01 March, 2021 19:11 CET, Imre Jonk <imre(a)imrejonk.nl> wrote:
On Fri, 2021-02-26 at 21:32 +0100, Maciej Delmanowski wrote:
> 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 :)
The ldap_smtpd_sender_login_maps restriction indeed catches this. Here's the error
message I get from Postfix when trying to send mail from martijn(a)ciphermail.com with user
'imre':
RCPT TO <someone(a)example.com> failed: <martijn(a)ciphermail.com>: Sender address
rejected: not owned by user imre
1390
days inactive
1395
days old
3 comments
2 participants
participants (2)
-
Imre Jonk -
Maciej Delmanowski