Maykel Moya writes:

I had created a custom attribute sldMailForwardTo describe mail recipients for a given alias. As sldMailForwardTo is just an email address I made it inherits from mail.

The problem is that now, whenever I do a search on mail=foo, entries having foo on sldMailForwardTo are matched too.

That is how the LDAP standard says it should work. Also if the client includes mail in the list of attributes to return, the server will return sldMailForwardTo attributes too.

I suggest you (1) stop slapd, (2) dump your database with slapcat, (3) remove the inheritance and copy the meat of 'mail's definition into 'sldMailForwardTo' instead, (4) slapadd the database back, and (5) restart slapd. Or if you don't want slapd to be down that long, you can rebuild the database in a separate directory - and change the database directory on the fly too, if you are using the config backend.

It might be sufficient to run slapindex instead of slapcat-slapadd in this case, I don't know. The simplest rule to remember is that if you mess with the definition of attributes that already exist in your database, you need to dump first and reload afterwards.

Do exists a way to avoid that? If no, what are the effective benefits then of having inherited attributes?

That _is_ one of the benefits of inheritance. Except RFC 4519 says "Client implementations MUST NOT assume that LDAP servers are capable of performing attribute subtyping", so you are still limiting yourself to implementations that do support it. Anyway:

It rarely makes sense to inherit from an attribute which is itself intended to be used in directory entries, because of the problem you've just encountered.

You can define an attribute which is _only_ intended as a supertype of other attributes. That gives you a group of attributes with the same properties (syntaxes, matching rules) unless you override those, and you can search for them all at once by searching for the supertype. Examples in the standard are 'name' (supertype of 'cn', 'o', 'ou', 'title' and some more standard attributes), and 'distinguishedName'. See RFC 4519.