On 2013-03-21, at 2:08 PM, Jo Shields <[email protected]> wrote:
> On Thu, 2013-03-21 at 13:24 -0400, Francis Lachapelle wrote: >> Hi Jo >> >> On 2013-03-21, at 12:53 PM, Jo Shields <[email protected]> wrote: >> >>> 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? >> >> >> SOGo won't decompose the group members when sending an email. > > Is that an intended exclusive design choice, or is it something where > patches would be accepted (assuming I can scrounge up an ObjC > developer)? > > If SOGo *requires* a matching mail: attribute for any groupOfNames, and > Evolution screws up on a mail: attribute for any groupOfNames, then, > well, we have an issue. We chose to not decompose the LDAP group because the decomposition process would usually be performed by the MTA or a mailing list manager. Also, the group may refer to thousands of entries which would considerably increase the message size as well as slow down the Web interface if we decide to decompose and display the entries "live". That said, you could still provide a patch but with a domain defaults to control whether or not the groups should be decomposed when used as a mail recipient. Francis -- [email protected] :: +1.514.755.3640 :: http://www.inverse.ca Inverse :: Leaders behind SOGo (http://sogo.nu) and PacketFence (http://packetfence.org) -- [email protected] https://inverse.ca/sogo/lists
