Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!ucbcad!ucbvax!VAX1.LSE.AC.UK!SKELTON
From: SKELTON@VAX1.LSE.AC.UK
Newsgroups: comp.os.vms
Subject: Re: Synchronizing VMSMAIL.DAT with SYSUAF
Message-ID: <8712110020.AA27211@ucbvax.Berkeley.EDU>
Date: 11 Dec 87 00:21:07 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 30

> 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?

I have seen a couple of replies to this; one missed the point by supplying a
procedure to remove VMSMAIL entries that had NO forwarding address ( the
reverse of what was asked ) and the other suggested using MAILUAF.COM to go
through all registered users ( not a quick job with 2000 students around ).

My favoured method is to use the MAIL command SHOW FORWARD/USER=* which lists
out all users who have set a forwarding address. On our site there are few of
these, and most are genuine. ( In fact most do not correspond to SYSUAF
records anyway and have been added with SET FORWARD/USER=xxx yyy ). It
shouldn't take much effort to check the few oddities to see if they are still
in the UAF. Also, our de-registering procedure removes VMSMAIL.DAT records
automatically, as well as disk quotas and entries in at least three other
files used locally for system management and registration.

I don't recommend anyone with more than a few tens of users to make much use
of AUTHORIZE interactively - its a pity that DEC haven't yet provided tools
to combine management of all these files in one go.

Jeremy Skelton, London School of Economics