On Thu, 2003-01-09 at 07:38, Tony Earnshaw wrote: > tor, 2003-01-09 kl. 00:54 skrev Chris Toshok: > > > The only present issue with just using lachman/laser (or rather what the > > example in the lachman/laser draft shows) is that the mailGroup > > definition contains "MUST (cn $ mail)".. Not sure what to do wrt the > > 'mail' attribute when creating a MUA mailing list, as the members of the > > list are represented as mgrpRFC822MailMember attributes. > > > > We could create another mailGroup-esque objectClass.. maybe like the > > following: > > > > objectclass ( x.x.x.xxxx.xxxx.xx.x.x.x > > NAME 'muaMailGroup' > > SUP top AUXILIARY > > DESC 'MUA Friendly Mail Group' > > MUST ( cn ) > > MAY ( mgrpRFC822MailMember ) ) > > > > That can be used in conjunction with mailGroups.. Not sure yet. > > Hmmm ... the only Lachmann-Laser I have is from Jan 2001, is included > with the Openldap tarball distro. At the end, is the following: > > (ii) Removed references to mailGroup document which has expired. > > There's no definition of a mailGroup objectclass, only a dif file > example with one in it.
Yeah... all these drafts have long since expired :) mailGroup is defined in this draft (expired 1998): http://www.globecom.net/ietf/draft/draft-steinback-ldap-mailgroups-00.html mailGroup and the lachman/laser stuff seem more geared toward mail delivery, letting you specify which mailHost to use for a particular address, which addresses are local, etc. There's another draft, from which rfc822MailMember seems to originate (expired 1999): http://www.globecom.net/ietf/draft/draft-srivastava-ldap-mail-00.html > A test example I use doesn't have a mailGroup objectclass: > > dn: cn=localmailgroup,ou=people,ou=groups,dc=billy,dc=demon,dc=nl > objectClass: top > objectClass: nisMailAlias > structuralObjectClass: nisMailAlias > cn: [EMAIL PROTECTED] > rfc822MailMember: [EMAIL PROTECTED] > rfc822MailMember: [EMAIL PROTECTED] > rfc822MailMember: [EMAIL PROTECTED] > rfc822MailMember: evy > rfc822MailMember: tonye > rfc822MailMember: torgeir > > That's all it needs. My mailserver parses [EMAIL PROTECTED] > and removes the realm, if necessary. > Yeah, nisMailAlias is another alternative, but for some reason (I don't really understand it myself, possibly because of my tour as a sysadmin) I find myself wanting to steer clear of anything with "NIS" in its name :) > But, it's not in an rfc or anything and as I said, what guarantee would > there be that it would correspond to something on a MS Exchange or > eDirectory group? Well the only thing we really need to decide upon is the attribute that'll be used to hold raw email addresses, since that basically dictates what structural classes we'll be able to interoperate with. Whatever objectclass mozilla/evolution ends up using should be auxiliary - We'll need another objectClass anyway to store mua specific things, like "hide the email addresses when i send email to this list", that sorta thing.. Not sure what mozilla requires in this regard. MS likes to store filters in their active directory stuff (at least I've seen a few in my dealings with it), so it wouldn't suprise me if they support something like membershipFilter (from the srivastava draft).. And that might be a good feature to add to evolution, but I'm loathe to fire off nested queries to fully resolve an object (which is the reason I hate groupOf{Unique}Names). Chris _______________________________________________ evolution maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution
