The SOGo docs say that an LDAP group of the format: dn: cn=management,ou=groups,dc=inverse,dc=ca objectClass: top objectClass: groupOfNames cn: management mail: [email protected] member: cn=bob,ou=people,dc=inverse,dc=ca member: cn=alice,ou=people,dc=inverse,dc=ca
Should be parsed & dealt with as individual users, i.e. if I try to send a mail to management, it gets sent instead to the mail: attributes of cn=bob,ou=people,dc=inverse,dc=ca and cn=alice,ou=people,dc=inverse,dc=ca This is *almost* but not entirely the same way that Evolution handles it - however, if Evolution sees a mail: attribute on the groupOfNames, then it adds that address to the decomposed list of final recipient addresses (which in some cases causes users to receive mail once - first via the decomposed DN and a second time via a mailing list address in the mail: attribute) However, this is merely the theory. The practice is, at least here, that SOGo doesn't decompose the member: values at all, and tries to simply send an email to the cn= - i.e. the mail server sees RCPT TO:<Sysadmins Group> if I try to send a mail to "Sysadmins Group", whereas Evolution expands that to four individual addresses. I don't see any obvious reason for this - the LDAP server logs show that the member: attributes are received, and as far as I can comprehend the SOGo source it's definitely got methods in there to parse member: DNs. I don't see any lookups on those DNs though, i.e. I can't see any attempt to work out the members:' mail: attributes. So is this some configuration error at our end? Or is it a case of overly optimistic documentation of missing features?
smime.p7s
Description: S/MIME cryptographic signature
