Jason L Tibbitts III wrote:
> >>>>> "JH" == Jeff Heinen <jeff.heinen@inherent.com> writes:
>
> JH> It depends on how you are storing list/user information. Unfortunally,
> JH> I havent been able to check into that was well as I want. The only way
> JH> I could think of presently is to save user-specific information in a
> JH> seperate db somewhere.
>
> The more I think about it, the more I think it has to be list specific, or
> you get into really weird situations. Say I subscribe to one list as user1
> and another as user2. Then I globally alias user1 to user2. Then an
> attempt to leave the first list fails, because user2 is not a member. To
> circumvent this, the aliasing function has to check memberships in every
> list and report some bizarre failure mode which users are probably not
> going to figure out.
Why would a leave fail? I thought this was one of the reasons alias existed?
ie. Moving companies and you not longer have access to user1 email address.
A message from an alias account should prove who you are and allow you
to change/remove other addresses.
Perhaps I see the resoning behind aliases differently. I've been thinking of
it
one step higher for the web based features. Take the 1.94.x versions. They
currenly (if configures that way), will mail you back a request for
conformation
with what amounts to be a password. If we were to save this information,
we could then have user name (email address or nickname) and password
identification.
It would mean that web-based interfaces could prove who a user was. A big
step up for lists that are currenly heavilly restricted. Yes, overkill for
some
lists, but it would come in very handy.
> JH> But Im not sure how well that would work for you. I plan to really get
> JH> into the info storeing scripts soon as I work on my Majordomo LDAP
> JH> project, so if someone can come up with a better idea, let me know.
>
> Are you going to start up a separate project? I would certainly hope
> that's not the case; it's hard enough getting people to work on one project
> and it's much worse for the users. (Plus, trust me, you don't want to
> spend too much time in the 1.9x code base.) There is ample room to
> integrate LDAP into the framework of 2.0, I just can't do it myself and
> I've been unsuccessful at getting anyone to explain to me what exactly LDAP
> would be used for in such a scheme.
Oops, what I ment so say was, "I found someone willing to pay me to add
mail list management to their Netscape/LDAP servers and I plan to use
2.0 for some of that." And actually, I thought about it for the 1.9x versions
but I needed the abstraction that is in 2.0.
LDAP is used in the Netscape servers to store and distribute user information.
It comes in very handy to set up a user in the LDAP server and have his
group membership information available to the Web server for access
authentication.
Unfortunally, there is no easy way to wrap another program into Netscape
Yes, I have seen tons of solutions for 1.9x servers, but they don't work
for me. If majordomo learnes LDAP, then the Netscape server can handle
all the outgoing mail just as eaislly as the rest of its mail with out me
having to do anything special to it. Another bonus is what I was heading
toward before. If I save information about the listmember, I can restrict
portions of the web-site to an email list membership. Perfect for web
archives for members only, or even a place to read and post from the web.
I don't know how handy it would be for the world in general, but it makes
things simpler for me.
Did I answer any questions or did I just ramble on?
-Jeff
Follow-Ups:
References:
|
|
