"Privilege Error" on when invoking VMS MAIL Send

[IFX_1]

I'm getting this error when sending mail to recipients like "name@company.com".

Any idea which file I should set accordingly?

I already tried setting protection on mail.mai and vmsmail_profile.data but to no avail.


************************************
$ mail

You have 71 new messages.

MAIL> send
To: email@company.com
%RMS-E-PRV, insufficient privilege or file protection violation
%RMS-E-PRV, insufficient privilege or file protection violation

MAIL>

[Wim Van den Wyngaert]

If audit is enabled :
$ anal/aud/fu/sin=xxx audit_file
where audit file is found in show audit/all

To enable file access violation auditing :
set aud/aud/ena=(access=(failure:(read,write,execute,delete,control))

(but save your settings based upon show aud/all)

Wim

[Wim Van den Wyngaert · Accepted solution]

Easier but cryptical :
before starting mail
set watch file/class=all (or replace all by major if too many output)

Wim

[Jan van den Ende]

IFX,

perhaps you will fare better if you use

MAIL> send
To: "email@company.com"

As it is, you are using a DCL indirection feature which (tries to) activate a file COMPANY.COM in your current default directory.
Atmittedly, the error message could have been more informative :-)

Proost.

Have one on me.

jpe

[Wim Van den Wyngaert]

Jan,

DCL within mail ?

I just used the same syntax without quotes. Works fine.

Wim

[Steven Schweda]

> I just used the same syntax without quotes.
> Works fine.

I do it all the time, too, but for some
pretty old VMS versions, more work was
needed. As usual, more info about the
environment (VMS version, TCPIP (or whatever)
version, ...) might be useful. I can imagine
something like this happening if some obscure
SMTP-related image is over-protected.



> "Privilege Error" [...]

Just curious: What were you quoting?

[IFX_1]

Thank you guys for the feedback.

We are using this syntax on other cluster nodes without problems.

We are running on OpenVMS 8.3, TCPIP V5.6-9ECO2.

I tried adding READALL privilege to the VMS account and I can run the same syntax (no quotes) without problem.

Which file is MAIL trying to open?

[Wim Van den Wyngaert]

With my set watch command you could find that.

in my version (5.3) :

tcpip$service.dat
tcpip$configuration.dat
tcpip$host.dat
and a temp file I will not quote (in login directory)

Wim

[IFX_1]

Wim,

Great help. Right away I found which file it has no access to by using "set watch". It's TCPIP$CONFIGURATION.DAT.

Thank you Wim and to the rest who responded to my query.

[Hoff]

Jan's reply is incorrect on two counts: the parenthesis are not required for specifications within mail (that's a DCL-level bit of "fun"), and the @ processing only happens when DCL is accepting and processing the input and not another utility (such as mail in this case).

@ doesn't have an unexpected side-effect inside MAIL for the same reason you can't perform ' ampersand substitution at this same juncture within MAIL or inside ftp or other such; it's not DCL that's reading and processing the input. It's (in this case) MAIL doing that. And if it's not DCL, there's no DCL processing.

[Wim Van den Wyngaert]

But I vaguely remeber that the quotes were required in early ucx versions and that a logical had to be defined to bypass that. But never ran into that so not sure.

Wim

[Hoff]

Prior to V6.2, yes.

Otherwise, you'll want to use the transparent SMTP% support for MAIL and the DCL tools such as COPY /FTP and such; OpenVMS V6.2 provided major improvements in the integration of IP into OpenVMS and into DCL and such.

Given the number of times I see folks fighting with DCL symbol substitution within the classic ftp utility -- COPY /FTP and DIRECTORY /FTP and such are vast improvements in integration -- knowledge of these 1995-era changes to OpenVMS and to DCL haven't been fully disseminated.

[Wim Van den Wyngaert]

Major improvement, yes. Integration : poor.

Try copy/ftp with
/since/before/conf/contig/prot/read .. .
None of them are supported (7.3).

And (tcp) proxies : idem. Even when proxy flag added to service ftp.

And I also remeber that file name parsing is not as good as it should be (not identical to normal copy), but have no details on that by hand.

Wished I could blindly add /ftp to all remote copies (and why not backup/ftp).

Wim

[IFX_1]

Got another problem. Our mails sent to external receipts (e.g. yahoo, gmail) can't see to be receieved (or sent). Emails sent internally are sent and recieved successfully.

[Wim Van den Wyngaert]

Very often the origin of the mail ("from")is validated. If it doesn't exist, the mail is ignored (after being accepted by the mailserver !).

Try setting the logical TCPIP$SMTP_FROM to you personnal mail address on PC. This also has the advantage that any problems with the mail are reported there (in outlook in my case).

It could also be that the size exceeds company standards.

Wim

[Hoff]

More often than not, one or more aspects of the mail message shipped out by OpenVMS itself are assumed to indicate it's spam.

TCPIP$SMTP_FROM can itself potentially cause problems here, too, as the various network addresses embedded in the mail message might not line up.

Start by declaring your mail servers via DNS, for instance, and have all your OpenVMS email routed through your designated mail server(s). If the OpenVMS box(es) here comprise your core mail servers, then declare them in your DNS per SPF, as a start.

Work with the folks that are running the target mail servers to see why your mail is being rejected, or to get your mail messages whitelisted with your recipients.

Also see if some or all of your IP addresses are in the typical DNSBL black hole lists.

There are add-on packages from Process Software (PreciseMail), Brilliant Systems (Quintara) and other folks that provide much more modern mail servers on OpenVMS, too. These deal with "correct" outbound mail and with filtering your inbound mail, for instance.

And at a minimum, head over to www.spamhaus.org or similar resources and start reading.

[WWarren]

As Wim wrote and I found out a long time ago (for VMS v8.2, TCPIP V5.5-1):
If you want a non-privileged (TMPMBX, NETMBX only) user to be able to send SMTP mail, then the TCPIP$SERVICE (TCPIP$SERVICE.DAT) and TCPIP$CONFIGURATION (TCPIP$CONFIGURATION.DAT) files must be readable by MAIL.EXE. [If you have authorized (but not process) privileges that allow you to access TCPIP$CONFIGURATION, MAIL will access this file (but not TCPIP$SERVICES.]

What I wish to contribute to this discussion is:
1) Why isn't this documented? [If it is, I wasn't able to find it.]
2) Isn't this a security hole? Why should you have to open up your configuration files? For one, TCPIP$CONFIGURATION contains your SNMP community strings!

[Wim Van den Wyngaert]

You don't have to open the security on the files. You can also install mail with privs.
But indeed not documented IMO.

Also ucx ping required privs (4.x, now installed with privs by default).

Wim