topic Re: Disabling VMS mail in Operating System - OpenVMS

Disabling VMS mail

John A. Beard — Tue, 06 Feb 2007 09:18:32 GMT

I need to find out what steps I need to take in order to disable VMS mail from a particular node (7.3-2).

I do not want to set the "/dismail" flag on user accounts, but rather disable it altogether for everyone (both on the fly and for a ny future reboot)

Re: Disabling VMS mail

Wim Van den Wyngaert — Tue, 06 Feb 2007 09:47:51 GMT

Don't forget that mail is used by many tools to notify SYSTEM.
E.g. dfg, sched, DTSS, CA, ...

Wim

Re: Disabling VMS mail

John A. Beard — Tue, 06 Feb 2007 09:54:34 GMT

Hi Wim,

I didn't think there would be an easy answer. Is there any way of making VMS mail inaccessible to certain groups, or perhaps only available to holders of a particular identifier

Re: Disabling VMS mail

Hoff — Tue, 06 Feb 2007 10:16:32 GMT

What are you seeking to avoid here? (Pointed questions are somewhat difficult for options and alternatives.) Can you provide some background on the problem and the proposed solution?

DISMAIL and DISNEWMAIL are the usual approaches toward locking out MAIL. (Removing NETMBX privilege may or may not be feasible. It usually isn't, but sometimes it is.)

Further along is CAPTIVE or RESTRICTED command procedures, and simply keeping the user out of MAIL. MAIL is one of a class of utilities with a couple of interesting features, so I tend to avoid permitting a completely untrusted user access into the MAIL command prompt.

If you are specifically targeting remote IP mail access, you can disable SMTP.

There are parts of OpenVMS itself that use MAIL for various purposes, and many command procedures around can expect access to MAIL, so removing it isn't necessarily something I would recommend.

In any case, it would be useful to know some background around why you're locking out MAIL.

Re: Disabling VMS mail

Peter Zeiszler — Tue, 06 Feb 2007 10:20:39 GMT

The only times I have ever disabled mail was on account or group basis. That was done modifying the UAF entry.

To disable mail for group 300
mc authorize mod [300,*]/flags=dismail

I don't know if you can set an identifier to remove access to mail. You might be able to do it through ACLs on the SYS$COMMON:[SYSEXE]MAIL.EXE file.

I personally would stick with UAF modifications.

Re: Disabling VMS mail

John Abbott_2 — Tue, 06 Feb 2007 10:39:52 GMT

For one-off's... (although discouraged), if it's something you control and the users cannot override you could try $ MAI*L=="!" "do-what-you-want-to-do" and then delete the symbol afterwards.

... or set-up an identifier access ACL on sys$system:mail.exe (note that it's an installed image) but this would return a rather ugly nopriv error and the user could of course have their own mail.exe

I suspect you can't remove NETMBX.

J.

Re: Disabling VMS mail

John A. Beard — Tue, 06 Feb 2007 10:46:19 GMT

Thanks to all for your suggestions.

I think for now I will simply set the /dismail flag on selected accounts.

I cannot remove NETMBX, not can I make the accounts in question captive or restricted.... over a 1000 users with all kinds of different access requirements.

I will dig deeper into what you have all suggested and see what I can come up with. Thanks again for your time

Re: Disabling VMS mail

Hoff — Tue, 06 Feb 2007 11:41:44 GMT

There are DCL procedures around that can send VMS MAIL quite nicely. Without using MAIL utility. I wrote one that lets me send mail from anyone to anyone. This is similar to what is now called relay spam, but from a previous era.

As for locking out the utility via the command line, that's a fairly soft protection. It'll certainly slow down some of the script kiddies, but it won't but momentarily delay an experienced user. And I'd not recommend removing the command verb, but that too has been tried.

FWIW, Whether you're defending against script kiddies or experienced users or complying with corporate auditing requirements isn't yet known, which is why I was looking for some background around the question.

Re: Disabling VMS mail

Ian Miller. — Tue, 06 Feb 2007 16:51:38 GMT

you could block access to SYS$SHARE:MAILSHR.EXE with an ACL along the lines of

((ID=MAILUSER,ACCESS=EXECUTE),ID=[*,*],ACCESS=NONE))

sort of thing. This allows chatting to the MAIL DECnet object using MAIL11 protocol for the terminally curious.

Security is often a people problem.