Jens Vagelpohl wrote:
>
> > Have the authentication bit working at the moment. Having a think about
> > how to store the mailman subscription information still. Whether to store
> > the attributes (subscription type, nomail option, etc) as a sub-object of
> > the person object or to have lots of atrributes named in such a way that
> > they are unique to their list, but easily searchable and don't add a lot
> > of load to the LDAP protocol. Any suggestions or preferences from a
> > general POV??
>
> i personally would define an object class that has all the mailman-specific
> attributes as "MAY"-attributes. then you simply add this object class into
> the object class statements for your user records. all mailman-specific
> records are then simply stored on your user record along with the rest of
> the information.
>
> you could also create separate records that carry the email address and
> mailman-specific stuff (or better, that carry anything needed by mailman),
> but then you'd have to make sure that info is in sync with your "normal"
> user records in case someone is defined as a normal user record and has a
> separate mailman record as well.
I'm sure whether to have something like a sub-object with something like:
dn: cn=myname, ou=dept, o=company
|
----------------------------------------------------
| |
dn: [EMAIL PROTECTED], cn=myname, ou=dept, o=company
another maillist dn
| |
|-nomail: yes
|-nomail: no
|-digest: no |- etc
|-etc
or
dn: cn=myname, ou=dept, o=company
|
|- some attribute combinations...
|- nomail: yes
|- digest: yes
|- etc
the top way of organising things is more scalable and easier to manage (i
think). but the second one only allows for one option for all your mailing
lists - ie you have digest enabled for all or non e of your mailing list
subscriptions. Or maybe i list the mailing list names in the nomail
attribute and parse it on the mailman side to see if nomail is set for the
particular list.
eg:
nomail-yes: [EMAIL PROTECTED], [EMAIL PROTECTED]
nomail-no: [EMAIL PROTECTED], [EMAIL PROTECTED]
or something along those lines...
Hmm... think i should cc this onto Mailman-dev actually...
> > As regards code, I'll be releasing it to the Mailman developers and anyone
> > who wants it once it's working...
>
> barry warsaw is working for my company ;)
I'm cc-ing this to the Mailman-dev mailing list - I'm subscribed to it, but
slightly behind in reading the digests (only by some 75 days!! hehe) - just
so they know someone is playing with it. I know it's on the WishList for
Mailman 3.x, but no harm in seeing what's involved and exploring the
unknown...
Regards
Donal
_______________________________________________
Mailman-Developers mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-developers
