phil@wubios.wustl.edu (J. Philip Miller) (07/11/89)
we ran into a "administration" problem, rather than a bug, and wonder how others have solved it. In our public alias file, we have a list for all of the users of the system, so notices can be made to everyone, etc. Because elm requies that these group lists be composed of only aliases, we also defined an alias for each user and we used their first name for that alias. The problem occurs if an individual user has an alias defined for that same name, the then group list goes to the wrong person, e.g. I as a user may have an alias for john that is defined as johna@elsewhere, where the system alias file has john defined as john@myhost. Now these are not only different accounts, they may be different folk. Have we set things up wrong? How do others avoid this type of namespace problem? -- -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* J. Philip Miller - Div of Biostat - Washington Univ Medical School phil@wubios.WUstl.edu - Internet phil@wubios.wustl - bitnet (314) 362-3617 c90562jm@wuvmd - alternate bitnet
skl@van-bc.UUCP (Samuel Lam) (07/11/89)
In article <509@wubios.wustl.edu>, phil@wubios.UUCP (J. Philip Miller) wrote: >In our public alias file, we have a list for all of >the users of the system, ... Because elm requies that these >group lists be composed of only aliases, we also defined an >alias for each user and we used their first name for that alias. That shouldn't be necessary, since page 3 of the Elm Alias System Users Guide says "The major limitation with group aliases is that each of the people in the list must be a previously defined alias or a valid mail address on the current machine". >**< Listing each local user's mailbox's name in the group's membership list should do the job. ...Sam -- Samuel Lam {alberta,watmath,uw-beaver,cs.ubc.ca}!ubc-cs!van-bc!skl
rob@PacBell.COM (Rob Bernardo) (07/11/89)
In article <509@wubios.wustl.edu> phil@wubios.UUCP (J. Philip Miller) writes:
+we ran into a "administration" problem, rather than a bug, and wonder how
+others have solved it. ...
+The problem occurs if an individual user has an alias defined for that same
+name, the then group list goes to the wrong person, e.g. I as a user may have
+an alias for john that is defined as johna@elsewhere, where the system alias
+file has john defined as john@myhost. Now these are not only different
+accounts, they may be different folk.
+
+Have we set things up wrong?
Yes, you should have never hired two people with the same first name.
I surprised your payroll people didn't complain about this situation when
the second John was first hired. :-) :-)
+How do others avoid this type of namespace problem?
I use surnames. And if there's a conflict, I don't use the surname alone
for any sharing it (lest I mistakenly use the alias for the wrong person)
but rather first initial+surname. In one case I had to use the first
two letters of the first name + surname.
--
Rob Bernardo ...![backbone]!pacbell!pbhyf!rob -or- rob@pbhyf.PacBell.COM
Product engineer, UNIX/C Reusable Code Library Editor, "Go `C' UNIX"
Office: (415) 823-2417 Pacific * Bell, San Ramon, California
Residence: (415) 827-4301 R BAR JB, Concord, Californiawoerz%isaak@isaak.uucp (Dieter Woerz) (07/28/89)
In article <177@van-bc.UUCP> skl@van-bc.UUCP (Samuel Lam) writes: >In article <509@wubios.wustl.edu>, phil@wubios.UUCP (J. Philip Miller) wrote: >>[about system aliases being replaced by the senders's personal >> aliases with the same name] >That shouldn't be necessary, since page 3 of the Elm Alias System Users >Guide says "The major limitation with group aliases is that each of the >people in the list must be a previously defined alias or a valid mail >address on the current machine". >**< > >Listing each local user's mailbox's name in the group's membership >list should do the job. There is still a problem. Asume you have the following system alias file: ... allusers = All users of this host = a, b, c, d, e, f .... and the sender of the message has the following in his personal aliases file: ... c = ... = c@x.y.z Then the c@x.y.z get the message that should have reached c on the local machine. I don't know about other possible solutions except using some other alias mechanism (e.g. within sendmail). >...Sam >-- >Samuel Lam {alberta,watmath,uw-beaver,cs.ubc.ca}!ubc-cs!van-bc!skl Dieter Woerz ISA GmbH, Azenbergstr. 35 D-7000 Stuttgart-1 W-Germany UUCP: {pyramid!iaoobel,uunet!unido}!isaak!woerz BITNET/EARN: woerz@ds0iff5
skl@van-bc.UUCP (Samuel Lam) (07/29/89)
In article <1023@isaak.UUCP>, woerz@isaak.UUCP (Dieter Woerz) wrote: >In article <177@van-bc.UUCP> I wrote: >>In article <509@wubios.wustl.edu>, phil@wubios.UUCP (J. Philip Miller) wrote: >>>[about system aliases being replaced by the senders's personal >>> aliases with the same name] > >>Listing each local user's mailbox's name in the group's membership >>list should do the job. > >There is still a problem. Asume you have the following system alias >file: > allusers = All users of this host = a, b, c, d, e, f >and the sender of the message has the following in his personal >aliases file: > c = ... = c@x.y.z >Then the c@x.y.z get the message that should have reached c on the >local machine. If that's the case, then shouldn't the current behaviour of this be consider broken? My argument here is that when the system administrator makes up the system aliases file, there would be no way for him to predict how the system aliases would later expand IF each user's private aliases file is also taken into consideration during the later expansion. If there is no way to predict how a system alias is going to expand, then what good is it to have system aliases (that's unpredictable). (Under what circumstances would the current behaviour be actually considered useful?) On the other hand, if system aliases expansions only use aliases in the system aliases file, then it would indeed provide the "pre-defined names" facility which (I think) it was originally intended for. Thus, I propose: 1) When expanding a user alias, make use of other aliases from the same user and the system aliases, as necessary. 2) When expanding a system alias, only make use of the other system aliases. Does this approach make sense? -- Samuel Lam {alberta,watmath,uw-beaver,cs.ubc.ca}!ubc-cs!van-bc!skl
scs@lokkur.dexter.mi.us (Steve Simmons) (07/30/89)
skl@van-bc.UUCP (Samuel Lam) writes: >In article <1023@isaak.UUCP>, woerz@isaak.UUCP (Dieter Woerz) wrote: >>In article <177@van-bc.UUCP> I wrote: >>>In article <509@wubios.wustl.edu>, phil@wubios.UUCP (J. Philip Miller) wrote: >>>>[about system aliases being replaced by the senders's personal >>>> aliases with the same name] >>>[response] >>There is still a problem. Asume you have the following system alias >>file: >> allusers = All users of this host = a, b, c, d, e, f >>and the sender of the message has the following in his personal >>aliases file: >> c = ... = c@x.y.z >>Then the c@x.y.z get the message that should have reached c on the >>local machine. >If that's the case, then shouldn't the current behaviour of this be >consider broken? My argument here is that when the system administrator >makes up the system aliases file, there would be no way for him to >predict how the system aliases would later expand IF each user's private >aliases file is also taken into consideration during the later expansion. >If there is no way to predict how a system alias is going to expand, then >what good is it to have system aliases (that's unpredictable). (Under >what circumstances would the current behaviour be actually considered >useful?) Glad I didn't jump into the discussion earlier -- the above paragraph lays most of the goundwork. The issue is much broader than elm. Exactly the same problems occur with any mail user agent which allows the user to define his own aliases. Any time there is a heirarchy of aliases, it is possible for lower level aliases to "mask off" upper level ones. Pretty similar to programming languages which allow nesting. This is a general and unsolvable problem with aliases. Speaking as a member of the development group (but not for it), I would not change the feature. -- : Steve Simmons ...sharkey!lokkur!scs scs@lokkur.dexter.mi.us : : UNIX -- The OS/360 of the 21st Century :
skl@van-bc.UUCP (Samuel Lam) (07/31/89)
In article <1989Jul30.013125.7407@lokkur.dexter.mi.us>, scs@lokkur.dexter.mi.us (Steve Simmons) wrote: >In article <203@van-bc.UUCP>, I wrote: >>In article <1023@isaak.UUCP>, woerz@isaak.UUCP (Dieter Woerz) wrote: >>>There is still a problem. Asume you have the following system alias >>>file: >>> allusers = All users of this host = a, b, c, d, e, f >>>and the sender of the message has the following in his personal >>>aliases file: >>> c = ... = c@x.y.z >>>Then the c@x.y.z get the message that should have reached c on the >>>local machine. > >>If that's the case, then shouldn't the current behaviour of this be >>consider broken? My argument here is that when the system administrator >>makes up the system aliases file, there would be no way for him to >>predict how the system aliases would later expand IF each user's private >>aliases file is also taken into consideration during the later expansion. >>If there is no way to predict how a system alias is going to expand, then >>what good is it to have system aliases (that's unpredictable). > >... Any time there is a heirarchy of aliases, it is possible for >lower level aliases to "mask off" upper level ones. Pretty similar to >programming languages which allow nesting. It would actually be reasonable for an higher (user) level alias to mask out a lower (system) level one when trying to match an alias which the user had entered interactively, since the interactive user is considered to be at the inner most scope (in the programming language sense). However, when expanding system aliases, we should consider the context in which they are created it. Since system aliases is created at the outer scope, it has no user alises to bind to at the time of its creation, and thus should only use other system aliases when it is being expanded. Otherwise it would render the run-time expansions of system aliases to be random and unpredictable, and thus making the system aliases feature rather undependable. -- Samuel Lam {alberta,watmath,uw-beaver,cs.ubc.ca}!ubc-cs!van-bc!skl
ske@pkmab.se (Kristoffer Eriksson) (08/01/89)
In article <1989Jul30.013125.7407@lokkur.dexter.mi.us> scs@lokkur.dexter.mi.us (Steve Simmons) writes: >skl@van-bc.UUCP (Samuel Lam) writes: >>In article <1023@isaak.UUCP>, woerz@isaak.UUCP (Dieter Woerz) wrote: >>>In article <177@van-bc.UUCP> I wrote: >>>>In article <509@wubios.wustl.edu>, phil@wubios.UUCP (J. Philip Miller) wrote: >>>There is still a problem. Asume you have the following system alias file: >>> allusers = All users of this host = a, b, c, d, e, f >>>and the sender of the message has the following in his personal >>>aliases file: >>> c = ... = c@x.y.z >>>Then the c@x.y.z get the message that should have reached c on the >>>local machine. > >This is a general and unsolvable problem with aliases. Speaking as a >member of the development group (but not for it), I would not change >the feature. Unsolvable? If there was (I don't know if there is, just speaking theoretically) a way to specify how the names in the alias list should be interpreted, you could get whatever behavior you'd like. In stead of writing allusers = All users of this host = a, b, c you could write something like allusers = All users of this host = a@local, b@local, c@local or even demoalias = Demo people = a@local, b@systemalias, c@useralias -- Kristoffer Eriksson, Peridot Konsult AB, Hagagatan 6, S-703 40 Oerebro, Sweden Phone: +46 19-13 03 60 ! e-mail: ske@pkmab.se Fax: +46 19-11 51 03 ! or ...!{uunet,mcvax}!sunic.sunet.se!kullmar!pkmab!ske
steve@vlink01.UUCP (1770 MCI) (02/26/90)
I have a couple of questions about elm's aliases. I know how to set them up in each individual user's box, however, is there a way of setting up a "system aliases" which could be accessed by anyone? Is there a limite of how many users could be in such a "System Aliases" Also, is there a way of taking "text list of aliases" and having elm munch and crunch them so they are useable by elm. Reason being, it takes a lot of time to o o punch in a very big list. I already have them in text form. Thanks in advance. Please send email to me and if anyone is interested I shall post my responses I get, I am sure that this question has been asked a couple of hunhund of hundred times, but I am new to the system. Thanks. again. -- Vlink | Steven E Frazier 1828 Darrow Drive |--------------------------------------- Powell, Oh 43065-9261 | Local : steve 614-755-3772 | Remote: steve@vlink01.UUCP