SIBLOCK@MCMASTER.BITNET (12/08/87)
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?
--------
Stephen J. Siblock
Bitnet: SIBLOCK@mcmaster <VAX 8600, VMS v4>
SIBLOCK@mcmvm1 <IBM 4381, CMS r4>
VMS: SSCVAX::SIBLOCK
profs%"SIBLOCK@mcmvm1.profs" <VMS to IBM PROFS>
CoSy: siblock
--------
Computing Services Coordinator, Faculty of Science
Computing and Information Services
McMaster University, ABB-149
Hamilton, Ontario, Canada L8S 4M1
(416) 525-9140, x4157.
--------carl@CITHEX.CALTECH.EDU (Carl J Lydick) (12/09/87)
> 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? You're correct in your presumption as to why this happens. I take it that your use of apologetic quotes implies that you consider this a bug. Well, this just goes to show that one man's bug is another man's feature. Here on CITHEX, I use this feature (actually, the fact that you can have a record in VMSMAIL.DAT that doesn't correspond to any record in SYSUAF.DAT) for three purposes: 1) We have some users who, for historical reasons, have on username on CITHEX but another username on many other machines. In these cases, I've entered a record in VMSMAIL.DAT that takes mail addressed to the user by the username he has on other systems and forwards it to his real account on CITHEX (I know, I know: this is a pernicious practice and should be avoided, but some of these users have a lot of influence in the hiring and firing of system managers :-(); 2) There are some users who used to have accounts on CITHEX but who have migrated to other machines; rather than bouncing their mail, we've chosen to forward it to their accounts on the other machines (wouldn't it be nice if VMSmail had a feature that would let you forward the message AND send a warning message back to the sender, including the user's new address?); and 3) There are some address that are commonly used (well, at least I use them a lot), that are cumbersome to type. For example, ST%"""info-vax@kl.sri.com""". On CITHEX, VMSMAIL.DAT has a record that forwards mail sent to INFOVAX to that address. The following procedure does what you want, if I understand your complaint correctly. It searches VMSMAIL.DAT (being careful not to lock records or the file against changes) for records with usernames that don't correspond to records in SYSUAF.DAT (again, while being careful not to lock records or the file, and opening SYSUAF.DAT for read access only). It keeps the usernames so found in a series of DCL variables. It then goes back through VMSMAIL.DAT and deletes the offending records. You can easily delete the code to ask before deleting the records, if you so desire. The process running the procedure must have READ access to SYS$SYSTEM:SYSUAF.DAT, and WRITE access to SYS$SYSTEM:VMSMAIL.DAT. ******************************************************************************** $! Command procedure to conform VMSMAIL.DAT to SYSUAF.DAT $! Copyright (C) 1987, Caltech Odd Hack Committee, no rights reserved. $ ON WARNING THEN GOTO DONE $ ON CONTROL_Y THEN GOTO DONE $ OPEN/READ/SHARE=WRITE UAF SYS$SYSTEM:SYSUAF.DAT $ OPEN/READ/WRITE/SHARE=WRITE MAIL SYS$SYSTEM:VMSMAIL.DAT $ N = 0 $ LBL0: READ/END=LBL1/NOLOCK MAIL RECORD $ USERNAME = F$ELEMENT(0," ",RECORD) $ READ/KEY="''USERNAME'"/IND=0/ERR=OOPS/NOLOCK UAF RECORD $ GOTO LBL0 $ OOPS: N = N + 1 $ USERNAME_'N' = USERNAME $ GOTO LBL0 $ LBL1: CLOSE UAF $ LBL2: IF N .LT. 1 THEN GOTO DONE $ USERNAME = USERNAME_'N' $ READ/ERR=LBL3/PROM="Delete record for ''username' [N]? " SYS$COMMAND X $ X = F$EXTRACT(0,1,F$EDIT(X+"N", "TRIM,UPCASE")) $ IF X .NES. "Y" THEN GOTO LBL3 $ READ/DELETE/IND=0/KEY="''USERNAME'"/ERR=LBL4 MAIL RECORD $ LBL3: N = N - 1 $ GOTO LBL2 $ LBL4: Write sys$output "Failed to delete record for ",username $ GOTO LBL3 $ DONE: ON CONTROL_Y THEN GOTO DONE $ SET NOON $ IF F$TRNLNM("MAIL") .NES. "" THEN CLOSE MAIL $ IF F$TRNLNM("UAF") .NES. "" THEN CLOSE UAF
DSTEVENS@VAXC.STEVENS-TECH.EDU (David L. Stevens) (12/09/87)
I found this neet little procedure called MAILUAF.COM in SYS$EXAMPLES ( I think) that will allow you to go playing around with the VMSMAIL.DAT file's forwarding addresses. You would still need to list out all the users and go thru the VMSMAIL.DAT file one by one, but this procedure is very easy to use, and has a list option to list out all the forwarding addresses that currently exist. If you can't find it on your system let me know, and I'll send you a copy. Dave Stevens Senior Systems Programmer Stevens Institute of Technology BITnet: DSTEVENS@SITVXA INTERnet: DSTEVENS@VAXC.STEVENS-TECH.EDU "Who am I ? Where am I ? Why am I ? And why am I asking you ??? " ------------
mpr@nancy (Mike Russell (CSC)) (12/11/87)
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
jdc@beach.cis.ufl.edu (Jeff Capehart) (12/11/87)
It is interesting that you can put in "dummy" records in VMSMAIL.DAT and let
userA receive mail that was intended for unknown userB. However, it was also
mentioned that whoever sent the mail should be notified of new forwarding
address. Here is a way that might work. If you set the forwarding address
of unknown userB to userA, set it to a list so that is goes to something like:
userA,"please send mail to userA" This is a nifty feature in mail. You can
set an invalid forwarding address and it will let you do it. However, when
someone tries to send to you, it will say unknown user "whatever garbage"
and spit back the text that was invalid in the forwarding address. I use
this to "turn off my mail" .. set forw "I dont want mail today." then when
someone tries to send mail to me, they get this message. Try that.
Also, here is a spiffy little program that will check to see if there is
new mail, and also go right into mail so that you can read it (put this
in your login if you like AUTO_MAIL !)
-----
$AUTO_MAIL: ON CONTROL_Y THEN GOTO MAIL_ABORT
$if f$search("SYS$LOGIN:MAIL.MAI").eqs."" then exit
$def/user sys$output nl:
$def/user sys$error nl:
$search sys$login:mail.mai NEWMAIL
$if $status .eq. 148340819 then exit !no strings found (matched)
$def/user sys$input sys$command
$mail
$exit
$mail_abort: exit !or some other optional error message
-----
--
Jeff Capehart Internet: micronaut%oak.decnet@pine.circa.ufl.edu
University of Florida UUCP: ..!ihnp4!codas!ufcsv!beach.cis.ufl.edu!jdc IMHW400@INDYVAX.BITNET (12/13/87)
Well, the trivial solution to this problem is to establish a user removal procedure that always smashes the removed user's VMSMAIL.DAT record. I realize that some sites may be managed in such a way that enforcing such a procedure is difficult or cumbersome. Here, we use a highly automated user account management system, and I am seriously considering the addition of such code. This has the advantage that bogus users used to implement mailing-list catchers and suchlike, don't get zapped by accident.
carl@CitHex.Caltech.EDU (Carl J Lydick) (12/14/87)
> It is interesting that you can put in "dummy" records in VMSMAIL.DAT and > let userA receive mail that was intended for unknown userB. However, it > was also mentioned that whoever sent the mail should be notified of new > forwarding address. Here is a way that might work. It's a nice first try, but it only does what you want it to if userA and userB are on the same machine (or, maybe, on the same homogenous cluster). > If you set the forwarding address of unknown userB to userA, set it to a > list so that is goes to something like: userA,"please send mail to userA" > This is a nifty feature in mail. You can set an invalid forwarding address > and it will let you do it. Right. MAIL has a tendency not to complain when you do something wrong. In some cases, this might be useful, but in others it's a nuisance. > However, when someone tries to send to you, it will say unknown user > "whatever garbage" and spit back the text that was invalid in the > forwarding address. I use this to "turn off my mail" .. set forw "I dont > want mail today." then when someone tries to send mail to me, they get this > message. Try that. This works as long as: 1) The entity trying to mail to you is logged in on the same machine you use; and 2) The process sending the mail has a terminal associated with SYS$INPUT. If SYS$INPUT is not a terminal, the mailer will complain about the invalid address and will also fail to deliver the message to the valid address. If the mail is coming from another node, it will have the same problem. > Also, here is a spiffy little program that will check to see if there is > new mail, and also go right into mail so that you can read it (put this in > your login if you like AUTOMAIL !) > > ----- > $AUTO_MAIL: ON CONTROL_Y THEN GOTO MAIL_ABORT > $if f$search("SYS$LOGIN:MAIL.MAI").eqs."" then exit > $def/user sys$output nl: > $def/user sys$error nl: > $search sys$login:mail.mai NEWMAIL > $if $status .eq. 148340819 then exit !no strings found (matched) > $def/user sys$input sys$command > $mail > $exit > $mail_abort: exit !or some other optional error message The program makes the unsupported assumptions that you're storing all your mail in your login directory, and that any message in the NEWMAIL folder is actually new. Neither of these need be true, and it's easy to do it right: $ FILE = "SYS$SCRATCH:" + F$GETJ("00000000","PID") + ".TMP" $ ON CONTROL_Y THEN GOTO DONE $ ON WARNING THEN GOTO DONE $ DEFINE/USER SYS$OUTPUT 'FILE' $ MAIL SELECT/NEW $ DEFINE/USER SYS$OUTPUT NL: $ DEFINE/USER SYS$ERROR NL: $ SEARCH/NOOUTPUT/EXACT 'FILE' "%MAIL-W-NONEWMAIL, no new messages" $ SEVERITY = $SEVERITY $ DELETE 'FILE'; $ IF SEVERITY .EQ. 1 THEN EXIT $ DEFINE/USER SYS$INPUT SYS$COMMAND $ MAIL $ DONE: IF F$SEARCH(FILE) .NES. "" THEN DELETE 'FILE';*