Jason L Tibbitts III wrote:
> >>>>> "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 canonicalizationprocess
> turns user1 into user2, which is not subscribed to the list.
How do you avoid this problem with closed lists? If user2 is not on the list,
the canoniclaization from user1 to user2 would disallow him from posting? I
guess I really need to look over the code better before I confuse myself too
much.
>
>
> 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.
No, I was not planning on using the password for any email stuff execpt for
things like the currenly confirmitations. I was mainly thinking of using it
for the web side, where you could type _any_ emailaddress in at the prompt. So
something else is needed to prove identity.
I do not beleive passwords are part of aliasing at all. We have gotten
sidetracked from aliaes, to what should be stored about the person and where.
I do aggree that passwords do pose a lot of problems, that with them being
lost etc. (Between then and the list intro files that people can never keep,
nor read! :_( ), but I dont see another way for the web side.
>
>
> 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.
You don't have my users. :_) One of the most inportant things for my users are
web-based archive/discussion areas, and web admin areas. My users are not the
most um.. "technically savvy". They would really benifit from a better
interface then the email commands. But yes, I doubt many others would even
care. Most of the stuff I've been doing is only really needed for my users
with strange demands which is why I tend not to bother you all. :_)
> 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.
Actually, My adding to Majordomo would only be along the line nessary to
"support my MTA".I actually do care about the delivery features, which is why
I'm trying to find a
good way to intergrate the two. The reason I was considering allowing the
MTA&LDAP to handle all
the list mail was that way, the message only ran through one program, and not
having to call
perl/Majordomo for each message. The latter tends to load a very active
server.
>
>
> 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.
1) I need a List Management Program. I want to use Majordomo 2 because I like
it.
2) Subscriber data is stored wherever/however We decide. We get to make it up.
3) Currenly, I dont know. I have been thinking of adding code to the server to
look up the subscriber information, and deal with the message
approiatally.
Unfortunally, the more I look at it, the harder and more complex it seems.
-Jeff
Follow-Ups:
References:
|
|
