[prev in list] [next in list] [prev in thread] [next in thread] 

List:       majordomo-workers
Subject:    Re: How do I explain aliases?
From:       Jason L Tibbitts III <tibbs () hpc ! uh ! edu>
Date:       1997-10-20 20:13:42
[Download RAW message or body]

>>>>> "JH" == Jeff Heinen <jeff.heinen@inherent.com> writes:

JH> How do you avoid this problem with closed lists? If user2 is not on the
JH> list, the canoniclaization from user1 to user2 would disallow him from
JH> posting? I guess I really need to look over the code better before I
JH> confuse myself too much.

I think you have confused yourself.  Canonicalization works like this:

take address, strip comments
take stripped address, apply all transforms
take transformed address, apply alias (if any)

So if I alias user1@a.com to user2@b.com and have a mungedomain-type
transform applied, user1@machine.a.com turns into user1@a.com which turns
into user2@b.com.

This does not hurt closed lists because you cannot alias away from a
subscribed address, you cannot alias to an unsubscribed address and you
cannot create circular aliases.  So if user2@b.com is subscribed,
user1@a.com simply cannot subscribe because they're already on the list (as
user2@b.com).  If user1@a.com tries to post, they are allowed because they
are aliased to user2@b.com who is subscribed.

The problem comes when you don't worry about things like subscribedness
when you do aliasing, because since the aliasing transformation is
unconditional the alias lookup can turn a subscribed address into an
unsubscribed one.  I solved this by making the aliases per-list and doing
all of the subscribedness checks, so you can't get into these confusing
situations.

It's always possible that I missed something, of course.  The interaction
of auxiliary lists with aliases isn't well defined right now.  There are
probably other interesting issues.  But if you want to see how it works,
why not just try it?  The shell interface makes this relatively easy.

[big snip; not much time to reply right now]

JH> 3) Currenly, I dont know. I have been thinking of adding code to the
JH> server to

JH> look up the subscriber information, and deal with the message
JH> approiatally. Unfortunally, the more I look at it, the harder and more
JH> complex it seems.

It's not that bad, really.  Every call that retrieves subscriber data goes
through SubscriberList.pm, which is currently just a wrapper around
SimpleDB.pm but doesn't have to be.  You can extend things here to do
whatever lookups you need, or to use a completely separate backend for some
of the storage.  SimpleDB doesn't have that many functions you need to deal
with.  (The mogrify function is the hardest, I think.)

One problem you might run into is that Majordomo keys all of its databases
by the canonical address (i.e. after transformations and aliases); LDAP
probably doesn't.

 - J<

[prev in list] [next in list] [prev in thread] [next in thread]