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