Potential Security Problems Due to Mail-11 Changes
As mentioned in the OpenVMS Version 7.0 Release Notes, SYS$SYSTEM:MAIL.EXE no longer has code to properly handle image privileges. This means that if you install it with privileges, then a user can obtain those privileges by using the VMS MAIL SPAWN command or by invoking an editor reached via spawning from VMS MAIL.
So, when you upgrade to OpenVMS V7.x, and if you are using a version of pmdf older than 5.0-6, you must modify your PMDF_COM:PMDFIMAGE.DAT file to no longer install MAIL.EXE with privileges. Alternatively, you can obtain an up-to-date version of PMDF_COM:PMDFIMAGE.DAT from ftp.pmdf.process.com. You will find it in the /anon/files/pmdf_50_patches directory. Ftp it as a text file. Again, you only need the new version of the pmdfimage.dat file if you are using a version prior to PMDF v.5.0-6. PMDF itself does not need those privileges; they are only used by the stand alone DELIVER utility. If you use foreign protocol interfaces from other vendors (e.g., JNET%) then you may need to contact that vendor to see if their interface can work without MAIL.EXE being installed with privileges. You may also want to check other mail related software to ensure that it doesn't install MAIL.EXE with privileges either. A number of packages do install MAIL.EXE with privileges (e.g., Wingra Jnet).
Note that DEC's claim that VMS MAIL does not itself require image privileges to correctly function is incorrect. For example, without EXQUOTA privilege, a user who is over quota may not be able to delete mail messages in order to get back under quota. Why? The process of deleting a message involves removing a record from the .MAI ISAM file and adding a new record to the .MAI ISAM file representing the message being moved to the wastebasket folder. If the .MAI ISAM file should need to be extended to add that record, then the user will be unable to delete their messages. We've seen this come up many times. Moreover, without EXQUOTA users cannot send mail or print messages if storage of the temporary message file pushes them over quota.
It was our understanding from the 7.0 field test that DEC was going to have the new VMS MAIL image be MAILUTL.EXE and leave the old one as MAIL.EXE. That would have avoided the security pitfalls associated with sites blindly installing MAIL.EXE with privileges. It seems that DEC decided upon a different course. The final release of 7.0 has the new VMS MAIL named MAIL.EXE and the old VMS MAIL named MAIL_OLD.EXE. However, note that the old image also ignores image privileges too. That is, it's not safe to install MAIL_OLD.EXE with privileges either.
