Path: utzoo!mnetor!uunet!husc6!cca!mirror!rayssd!brunix!nancy!mpr From: mpr@nancy (Mike Russell (CSC)) Newsgroups: comp.os.vms Subject: Re: Synchronizing VMSMAIL.DAT with SYSUAF file Message-ID: <21324@brunix.UUCP> Date: 10 Dec 87 19:25:26 GMT References: <8712090222.AA03747@ucbvax.Berkeley.EDU> Sender: root@brunix.UUCP Reply-To: mpr@nancy.UUCP (Mike Russell (CSC)) Organization: Brown University Computer Science Dept. Lines: 25 In article <8712090222.AA03747@ucbvax.Berkeley.EDU> SIBLOCK@MCMASTER.BITNET writes: > >We found an interesting little 'feature' of VMS Mail yesterday: >User "AAA" had his mail forwarded (using SET FORWARD) to user >"BBB". Well, last week we removed user AAA from the SYSUAF file, >only to discover we could still send mail to AAA, and it >did in fact end up in BBB's mailbox. Presuming >this is because running AUTHORIZE to remove a user does *not* >update the VMSMAIL.DAT file, we would like to know if someone can >suggest a procedure which will get our VMSMAIL.DAT file in >synch with our current SYSUAF file. I wonder how many 'ghost' >usernames are still receiving mail this way? We had a similar problem. User JONES left the system in April of 1986. All files and UAF entry were deleted. In July of 1987, we had a new user to add with the same name. But the previous user had specified his mail directory to be [JONES.MAIL], which now didn't exist, and it was therefor impossible to send them mail. This was confusing at the time. Clearly the VMSMAIL.DAT file was a DEC "oh, let's add that feature without thinking about it" feature. Similar to DISKQUOTAS which should be part of the UAF, or at least controlled by a top-level program which would allow complete control of a user without jumping around between too-specific system utilities. I'd also like to know if anyone has a work-around for this. -Mike Russell