Conference iosg::all-in-1_v30

    Hi 'Chele,
    
    I don't know if this is possible I am sure someone will correct me if I
    am wrong.  What you could do is the following:
    
    1. Create a shared mail area for this group
    2. Create a oa$data directory structure for this group
    3. Ensure the profile and network data files for this group only
       have their names
    4. Ensure that these users profiles are updated so they can only write
       to the shared area created in 1
    5. When users login define a logical to point to their copy of oa$data
    
    Regards,
    
    Sunil

    OA$DATA must be defined /EXEC or we won't turn on image privs, which
    would break most of mail unless the users are privileged, which I
    presume they aren't or all bets are off.
    
    Graham
    
    PS Re .0 - Use the salary continuation method? The advantage of
    Electronic Mail is that there is evidence available to show their
    managers....

    A number of years ago, when I was in Ed. Services, I separated the
    students from the rest of the group by setting up a separate OA$DATA
    area.  It got a little involved, because I had to have several PROFIL
    forms to update different profiles and other relevant data files.  We
    actually had three sets: the normal users, the stored student accounts,
    and the active "normal" accounts. At the end of a class, I just copied
    the stored student profile.dat over to the active area.  I guess we had
    a special SDAF and shared areas as well.  Again, three sets, and the
    student stuff got wiped out after each class.
    
    We had /GROUP logicals pointing the students at the correct
    directories. Actually, this kind of scenario is supposedly the reason
    for the EXECUTIVE mode logicals.  It allows you to have non-privileged
    users access the files because ALL-IN-1 will raise its privs to access
    the files.  The user can't do a DEFINE/EXEC without SYSNAM privilege. 
    So, now you just define all the /GROUP logicals with /EXEC and it
    should work fine.
    
    I don't think I ever prevented them from sending remote mail.  But the
    big problems were people changing their names or adding an ALL-IN-1
    password, or sending a ton of mail to the first user in the profile. 
    It sure solved all those problems. 
    
    I don't know if anyone is still available on the node named for fast
    food who could check if this was ever upgraded for ALL-IN-1 V2.3 and
    beyond.  
    
    BTW, my setup was the cause of all those security messages in pre V2.3. 
    
    Ben

Hi again,

These beastly people are still causing problems - unfortunately the policy for 
these bods is that they use generic VMS & ALL-IN-1 accounts. There are only 2 
terminals they access, and they are available to any of the 50 people in the 
room, so accounting to track the culprits isn't likely to be useful. They only 
use ALL-IN-1 a couple of times a year (in order to get through their job 
reviews), hence the decision to go for generic accounts.

The problem with the earlier suggestions is that although a FIND fails if an 
addressee is outside the rudegroup, if a rudegroup member KNOWS the correct 
address for a non-rudegroup ALL-IN-1 user, mail will still go to that person.

I never COULD get the hang of Thursdays.

Any other ideas?


Thanks & regards

Chele

    I believe ALL-IN-1 still checks the value of MR$NODE to see if MR is
    available.  If you could make it null for the rudegroup, you could stop
    them from doing it.  Also, you could customize the Send option on the
    menu to ignore remote mail addresses or whatever.  In the scenario I
    described, there were separate PENDING files, so no mail could be
    exchanged without MR.  Perhaps you were referring to different
    suggestions.  
    
    Of course, I'm very disappointed about BIGMAC.  We had started this
    scenario under V1.3, I believe.  We started with V1.2.  One of the
    managers told me back then that ALL-IN-1 had a limited life and would
    never be a big revenue generator, and he's still there, more or less.
    
    Ben