>>>>> "JH" == Jeff Heinen <jeff.heinen@inherent.com> writes:
JH> Why would a leave fail? I thought this was one of the reasons alias
JH> existed?
If I add user1, then make user1 point to user2, the canonicalization
process turns user1 into user2, which is not subscribed to the list.
JH> Perhaps I see the resoning behind aliases differently. I've been
JH> thinking of it one step higher for the web based features. Take the
JH> 1.94.x versions. They currenly (if configures that way), will mail you
JH> back a request for conformation with what amounts to be a password. If
JH> we were to save this information, we could then have user name (email
JH> address or nickname) and password identification.
Permanent stored passwords are bad. They just don't work. We've been over
it here. That said, stored passwords are trivial to add to the code, but I
don't see their connection to aliasing at all.
Since you don't want to present a password just to post a message, you
still need aliasing for plenty of internal things.
JH> It would mean that web-based interfaces could prove who a user was.
Yes, that's a bit useful, but not really nice for the users.
JH> Oops, what I ment so say was, "I found someone willing to pay me to add
JH> mail list management to their Netscape/LDAP servers and I plan to use
JH> for some of that." And actually, I thought about it for the 1.9x
JH> versions but I needed the abstraction that is in 2.0.
So you're going to add something to 2.0? Let me know what you need and
I'll help out all I can.
JH> Unfortunally, there is no easy way to wrap another program into
JH> Netscape Yes, I have seen tons of solutions for 1.9x servers, but they
JH> don't work for me. If majordomo learnes LDAP, then the Netscape server
JH> can handle all the outgoing mail just as eaislly as the rest of its
JH> mail with out me having to do anything special to it.
You will, of course, lose the interesting delivery features of Majordomo 2,
but that probably doesn't concern you.
Majordomo 2 can use any suitable storage medium for lists. You don't have
to maintain all of the interesting subscriber flags, though I haven't
considered what to do if that information is not available.
JH> Did I answer any questions or did I just ramble on?
I'm still not crystal clear on how Majordomo 2 relates to your project. I
also don't get where the subscriber data is stored in an LDAP scheme, and
what you plan to do with the data that Majordomo keeps (like subscriber
class) which drastically influences delivery.
- J<
Follow-Ups:
References:
|
|
