Article 161520 of comp.os.vms: After checking the FAQ and getting an example from DECUS (dispatch.zip) I put together a callable mail image as a shared image. It has a dispatcher and a vector transfer setup and is linked together and placed in sys$share. If a privileged users runs the program that calls this as an external function it works to any and all E-mail addresses. A regular user causes the calling program (a 4GL - Gembase) to bug dump on address going to an Internet address. It reports an exception trying to send to a person, but it looks like a blank address. We use UUCP to move our mail, real internet is coming.... In researching DSIN there is an article that closely matches my problem. It explains the problem with using Callable mail and message routers. It indicates that the calling utility should have sysprv Note! ******* ability. In installing my image I added this privilege along with bypass, tmpbmx, netmbx, sysnam and setprv. Within the shareable image I try to set these using $setprv, but it reports back that nothing has changed. The program that calls the sharable image is installed as shared but has no special privileges. Installing a shareable image with privileges has *absolutely no effect*. VMS lets you do it, but the privileges will never get used: The Image Activator only looks at image privileges when it is loading the main program, not when it is merging in shareable images. My question is how would I properly set the privileges to allow a less privileged user/program to execute the callable mail shared image to internet addresses? This is actually quite difficult to do. The only mechanism VMS provides by which the privileges can be determined by the *called* image is the user- written system service (aka protected shareable image). A USS running in either executive or kernel mode can either ignore the process's privileges, or change them. The difficulty has always been that *anyone* could link to the protected shareable image and invoke the USS. The USS had to have its own logic to make sure that it wasn't being called inappropriately. This is extremely difficult to get right, and can blow a hole through VMS security if you get it wrong. Usually, the way it's done is to provide a very narrow interface that will do something very specific with privileges. The MAIL Callable Interface is an example. If you send mail to a local receiver, it has to be written to his mail file and directory. That requires SYSPRV. The implemen- tation of the mail shareable image (MAILSHR) includes a protected shareable image (MAILSHRP) that gets around the SYSPRV limitation. It's "safe" in that the only interface it provides requires you to pass in things like the user- name of the recipient and the data for the message. *It* locates and opens the user's mail file; it doesn't trust you to tell it what file to use, or let you actually write to the file - *it* does all the writing, then closes the file before returning to you. The problem you're having with sending Internet mail is that the sending code - invoked as a foreign transport - generally writes the outgoing message to a file in some spool directory. To keep mail private and keep people from interfering with others's mail, the spool directory is protected - you need SYSPRV to access it at all. So ... same problem as for local VMSMAIL delivery. The foreign transport *could* be written to use a protected shareable image organized the way MAILSHRP is, but historically it hasn't been done that way. It's difficult, and originally wasn't necessary: At one time, there was no Callable MAIL, no MAILSHRP, and MAIL.EXE itself was installed with SYSPRV. Then, when the mailer was re-organized and the privileged stuff moved to MAILSHRP, it was still possible - and safe - to simply install MAIL.EXE with SYSPRV, because it retained its old logic for manipulating privileges to prevent misuse. (Obviously, you don't want to install a random application with SYSPRV!) Unfortunately, that no longer works. In any case, it would not have helped in your situation, which uses Callable Mail, and not the MAIL.EXE image. These days, you could probably do this safely by building a protected subsys- tem: You need to hold some special identifier to access the protected shareable image, and that identifier is granted by running the approved applications. I haven't gone through a complete analysis, so don't know for sure if that would work in this situation. Anyone? The program follows very closely the example in the Callable mail utility manual and takes an address, subject line and the name of a file and sends it out. The shareable image is a user mode system service. I'm not sure why you did it this way. I have some of the code below... Not relevant. -- Jerry