art@MITRE.ARPA (Art McClinton) (04/13/88)
SEND is not a DEC VMS command. Noting your return address I am going to assume that your VMS system is on bitnet and is probably using the Joiner Associates package (Jnet). SEND is a command within the Jnet product. It does require certain privileges to be able to send messages to users that are logged in. It appears to turn on/off privileges as necessary. It does not perform the actions the Bucknell students attribute to the command. VMS security bugs have been tightly held secrets in recent times. I do not know of anyway that you will be able to prove/disprove that any one program caused a particular problem. I suggest that you determine what image is invoked by your SEND command. If you have a question about it, go to the source of that program. If the source is not a reputable one, then determine why you want to keep the program. * *---Art * *Arthur T. McClinton Jr. ARPA: ART@MITRE.ARPA *Mitre Corporation MS-Z305 Phone: 703-883-6356 *1820 Dolley Madison Blvd Internal Mitre: ART@MWVMS or M10319@MWVM *McLean, Va. 22102 DECUS DCS: MCCLINTON *
carl@CITHEX.CALTECH.EDU (Carl J Lydick) (04/14/88)
> My questions is this: could anyone tell me ("yes" or "no" would be fine) > whether the latest bug (the one just patched) involved the SEND command? > I want to know because I'd like to be able to argue for the return of > SEND privileges, but I first need to know if there is a reason other > than harassment for their suspension. If the patch was received here and > installed, there should be no exceptionally strong argument against the > return of privileges. Since the bugfix is being distributed by DEC, and not by Joiner Associates, the answer to your question is obviously NO. SEND is NOT a part of vanilla VMS. It is part of JNET. A description of the patches follows: 1) $VWS (miscellaneous fix) ! $VWS.VUG ! ! ECO01 DMC 15-Feb-1988 ! MODULE: VWS ! Check for the existence of two VWS images. If they ! exist, ANALYZE to determine the VWS version from which ! they were built. If they are not V3.1 or V3.2 images, ! delete the .VUI and .EXE files which will otherwise ! be invoked later to provide the updated images. ! 2) DBGSSISHR (new image) ! DBGSSISHR.EXE ! ! ECO01 KNM0001 17-Feb-1988 ! MODULE: DBGSSISHR ! Update the image with some fixes. ! 3) SYS (patch image) ! SYS.EXE ! ! ! Define the following symbols so that the patches can be reapplied. 4) TTDRIVER (miscellaneous fix) ! TTDRIVER.VUG ! ! ECO01 FAK 18-FEB-1988 ! MODULE: TTDRIVER ! Set up to use the appropriate TTDRIVER file based on ! which version of VMS is running. 5) TTDRIVER (new image) ! TTDRIVER.EXE ! ! FAK 16-Feb-1988 ! ! New TTDRIVER image. This TTDRIVER has changes for VWS, ! 8NN console problems, and some miscellaneous fixes. !