29 Nov
2023
29 Nov
'23
11:13 p.m.
On Nov 29, 2023, at 5:06 PM, John Forecast
<john(a)forecast.name> wrote:
That seems sensible; the default stuff applies when authentication data isn't present.
"Account" is an obscure authentication field that is only used in some
operating systems, but I can imagine how its presence might make a check for "there
was no authentication data" fail.
FWIW, one case it's used is in RSTS if you define a "system password"
(basically, a second password set for the whole system). If you do and you want to use
explicit access control, the system password travels in the account field.
paul
On Nov 29, 2023, at 4:16 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
Just tested from Mim. It can definitely talk MAIL11 to 41.249. No problems there.
So I guess 41.202 is your DECnet implementation under Linux.
I don't understand why the audit event talks about login. But also, why username
"DECNET"? VMS systems usually deal with MAIL running under user MAIL$SERVER.
When you try to connect from your Linux implementation, what kind of connect block and
content are you setting up?
That’s because I set it up with a default DECnet account. It’s a documented
feature during DECnet configuration depending on what level of security you want. I’ve
been building various DECnet configurations and that’s the last one I had tried.
Anyway, I’ve found the problem! sendvmsmail (the program Linux uses to send mail to VMS)
tries really hard to put something in the account field of access control. This seems to
cause login to the nonpriviledged account to fail. I don’t believe I’ve seen any
documentation about this issue. Comment out the logic which fills in the account field and
everything works OK, even the V3 protocol is almost functional.