I have contacted VSI but thought I'd ask here too. If anyone can give
this a try and let me know if they experience the problem I'd appreciate knowing.

Integrity server, VMS V8.4-2L1, TCPIP V5.7 eco 5 with any later hotfixes
as of June 2023 applied.

V8.4-2L3 is coming but I can't install it to check for a while.

We use the 'sendmail.com' freeware to send email with binary attachments (mostly PDFs) with customized SMTP headers. On this VSI system we get a
single error every time we run SFF from the command procedure.

Exact same procedure on a V8.3 Alpha and an HP V8.4 Integrity run
without error so we're tentatively calling it a VSI issue.

Every run using symbol form via

sff :== $SYS$SYSTEM:TCPIP$SMTP_SFF.EXE

(as defined within sendmail.com)

generates the following error, but also still creates the email
successfully:

%LIB-F-INVNBDS, invalid numeric byte data string

Happens with any normal or priv'd account, regardless of the body text
file, presence or absence of attachments, who the recipient is, presence
or absence of a subject line.

I don't have any other systems to test on (specifically no other VSI
systems).

Thanks for any info.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 6 Aug 2024 14:49:38 -0500, Richard Jordan wrote:

%LIB-F-INVNBDS, invalid numeric byte data string

No traceback? No source code to look at?

But then, you did say it was “freeware”, not “Free software” ...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/6/2024 8:02 PM, Lawrence D'Oliveiro wrote:

On Tue, 6 Aug 2024 14:49:38 -0500, Richard Jordan wrote:

%LIB-F-INVNBDS, invalid numeric byte data string

No traceback? No source code to look at?

But then, you did say it was “freeware”, not “Free software” ...

I am not sure that I understand what you are trying to say.

The source of SENDMAIL.COM is obviously available as it is DCL.

The source of TCPIP$SMTP_SFF.EXE is just as obviously not available
as it is closed source VSI software.

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/6/24 2:49 PM, Richard Jordan wrote:

I have contacted VSI but thought I'd ask here too.  If anyone can give
this a try and let me know if they experience the problem I'd appreciate knowing.

Integrity server, VMS V8.4-2L1, TCPIP V5.7 eco 5 with any later hotfixes
as of June 2023 applied.

V8.4-2L3 is coming but I can't install it to check for a while.

We use the 'sendmail.com' freeware to send email with binary attachments (mostly PDFs) with customized SMTP headers.  On this VSI system we get a single error every time we run SFF from the command procedure.

Exact same procedure on a V8.3 Alpha and an HP V8.4 Integrity run
without error so we're tentatively calling it a VSI issue.

Every run using symbol form via

     sff :== $SYS$SYSTEM:TCPIP$SMTP_SFF.EXE

(as defined within sendmail.com)

generates the following error, but also still creates the email
successfully:

     %LIB-F-INVNBDS, invalid numeric byte data string

Happens with any normal or priv'd account, regardless of the body text
file, presence or absence of attachments, who the recipient is, presence
or absence of a subject line.

I don't have any other systems to test on (specifically no other VSI systems).

Thanks for any info.

Do you get anything interesting from:

$ MCR TCPIP$SYSTEM:TCPIP$SMTP_SFF.EXE sys$input: -log sys$error: -loglevel 1 ...
^Z

?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-08-06, Richard Jordan <usenet@cropcircledogs.com> wrote:

I have contacted VSI but thought I'd ask here too. If anyone can give
this a try and let me know if they experience the problem I'd appreciate knowing.

Integrity server, VMS V8.4-2L1, TCPIP V5.7 eco 5 with any later hotfixes
as of June 2023 applied.

V8.4-2L3 is coming but I can't install it to check for a while.

We use the 'sendmail.com' freeware to send email with binary attachments (mostly PDFs) with customized SMTP headers. On this VSI system we get a single error every time we run SFF from the command procedure.

Exact same procedure on a V8.3 Alpha and an HP V8.4 Integrity run
without error so we're tentatively calling it a VSI issue.

Every run using symbol form via

sff :== $SYS$SYSTEM:TCPIP$SMTP_SFF.EXE

(as defined within sendmail.com)

generates the following error, but also still creates the email
successfully:

%LIB-F-INVNBDS, invalid numeric byte data string

Given that your email gets sent, I am surprised nobody has mentioned
the possibility that this is simply a bogus/uninitialised exit status.

If you get the numeric exit status and display it in hex, does the
bit pattern contain anything of interest ?

It could be something x86-64 specific or it could be something that
has always been there and on other architectures just happens to give
a success exit status.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/7/24 7:24 AM, Simon Clubley wrote:

On 2024-08-06, Richard Jordan <usenet@cropcircledogs.com> wrote:

Integrity server, VMS V8.4-2L1, TCPIP V5.7 eco 5 with any later hotfixes
as of June 2023 applied.

V8.4-2L3 is coming but I can't install it to check for a while.

It could be something x86-64 specific or it could be something that
has always been there and on other architectures just happens to give
a success exit status.

Doesn't seem likely given the system he reported.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/6/2024 3:49 PM, Richard Jordan wrote:

Integrity server, VMS V8.4-2L1, TCPIP V5.7 eco 5 with any later hotfixes
as of June 2023 applied.

V8.4-2L3 is coming but I can't install it to check for a while.

We use the 'sendmail.com' freeware to send email with binary attachments (mostly PDFs) with customized SMTP headers.  On this VSI system we get a single error every time we run SFF from the command procedure.

Exact same procedure on a V8.3 Alpha and an HP V8.4 Integrity run
without error so we're tentatively calling it a VSI issue.

Every run using symbol form via

     sff :== $SYS$SYSTEM:TCPIP$SMTP_SFF.EXE

(as defined within sendmail.com)

generates the following error, but also still creates the email
successfully:

     %LIB-F-INVNBDS, invalid numeric byte data string

Happens with any normal or priv'd account, regardless of the body text
file, presence or absence of attachments, who the recipient is, presence
or absence of a subject line.

Some LIB$ functions can return that (I looked at LIB$CVT_DX_DX).

<quote>
LIB$_INVNBDS

Invalid NBDS. There is an invalid character in the input, or the value
is outside the range that can be represented by the destination, or the
NMDS descriptor is invalid. This error is also signaled when the array
size of an NBDS is larger than 65,535 bytes or the array is
multi-dimensional.
</quote>

But the relevance for email is not obvious to me.

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/7/2024 10:06 AM, Arne Vajhøj wrote:

On 8/6/2024 3:49 PM, Richard Jordan wrote:

Integrity server, VMS V8.4-2L1, TCPIP V5.7 eco 5 with any later
hotfixes as of June 2023 applied.

V8.4-2L3 is coming but I can't install it to check for a while.

We use the 'sendmail.com' freeware to send email with binary
attachments (mostly PDFs) with customized SMTP headers.  On this VSI
system we get a single error every time we run SFF from the command
procedure.

Exact same procedure on a V8.3 Alpha and an HP V8.4 Integrity run
without error so we're tentatively calling it a VSI issue.

Every run using symbol form via

      sff :== $SYS$SYSTEM:TCPIP$SMTP_SFF.EXE

(as defined within sendmail.com)

generates the following error, but also still creates the email
successfully:

      %LIB-F-INVNBDS, invalid numeric byte data string

Happens with any normal or priv'd account, regardless of the body text
file, presence or absence of attachments, who the recipient is,
presence or absence of a subject line.

Some LIB$ functions can return that (I looked at LIB$CVT_DX_DX).

<quote>
LIB$_INVNBDS

Invalid NBDS. There is an invalid character in the input, or the value
is outside the range that can be represented by the destination, or the
NMDS descriptor is invalid. This error is also signaled when the array
size of an NBDS is larger than 65,535 bytes or the array is multi- dimensional.
</quote>

But the relevance for email is not obvious to me.

Let us assume that VSI did not make any changes to SFF between
HPE 8.4 and VSI 8.4-2L1.

Then it must be a difference in systems not in SFF.

Within the content of a SMTP email, then I think Date header
is by far the most likely to cause problem.

So are there any difference in anything time or timezone related
on the systems that works vs those that does not?

How does the Date header look on the systems that works vs
those that does not?

NB: all this is pure speculation.

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/7/24 3:13 AM, Oswald Knoppers wrote:

On Tue, 6 Aug 2024 14:49:38 -0500, Richard Jordan wrote:

I have contacted VSI but thought I'd ask here too. If anyone can give
this a try and let me know if they experience the problem I'd appreciate
knowing.

Integrity server, VMS V8.4-2L1, TCPIP V5.7 eco 5 with any later hotfixes
as of June 2023 applied.

V8.4-2L3 is coming but I can't install it to check for a while.

We use the 'sendmail.com' freeware to send email with binary attachments
(mostly PDFs) with customized SMTP headers. On this VSI system we get a
single error every time we run SFF from the command procedure.

Exact same procedure on a V8.3 Alpha and an HP V8.4 Integrity run
without error so we're tentatively calling it a VSI issue.

Every run using symbol form via

sff :== $SYS$SYSTEM:TCPIP$SMTP_SFF.EXE

(as defined within sendmail.com)

generates the following error, but also still creates the email
successfully:

%LIB-F-INVNBDS, invalid numeric byte data string

Happens with any normal or priv'd account, regardless of the body text
file, presence or absence of attachments, who the recipient is, presence
or absence of a subject line.

Does sending mail to a smtp% address using the mail command work? I have
seen errors using sff caused by errors in the smtp config (tcpip show
config smtp).

Oswald

Yes, and that is done all the time for text reports and status emails.
The customer wants to both add a reply-to header and optionally handle
non-text files as attachments which sendmail is perfect for. The issue
is using SFF, not anything in the SMTP subsystem as far as we can tell.

Rich

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/7/24 6:59 AM, Craig A. Berry wrote:

On 8/6/24 2:49 PM, Richard Jordan wrote:

I have contacted VSI but thought I'd ask here too.  If anyone can give
this a try and let me know if they experience the problem I'd
appreciate knowing.

Integrity server, VMS V8.4-2L1, TCPIP V5.7 eco 5 with any later
hotfixes as of June 2023 applied.

V8.4-2L3 is coming but I can't install it to check for a while.

We use the 'sendmail.com' freeware to send email with binary
attachments (mostly PDFs) with customized SMTP headers.  On this VSI
system we get a single error every time we run SFF from the command
procedure.

Exact same procedure on a V8.3 Alpha and an HP V8.4 Integrity run
without error so we're tentatively calling it a VSI issue.

Every run using symbol form via

      sff :== $SYS$SYSTEM:TCPIP$SMTP_SFF.EXE

(as defined within sendmail.com)

generates the following error, but also still creates the email
successfully:

      %LIB-F-INVNBDS, invalid numeric byte data string

Happens with any normal or priv'd account, regardless of the body text
file, presence or absence of attachments, who the recipient is,
presence or absence of a subject line.

I don't have any other systems to test on (specifically no other VSI
systems).

Thanks for any info.

Do you get anything interesting from:

$ MCR TCPIP$SYSTEM:TCPIP$SMTP_SFF.EXE sys$input: -log sys$error:
-loglevel 1
...
^Z

?

Yes and no. Thanks for reminding that many of these utilities have
those options! I had forgotten; I rarely get to be in VMS anymore.

I ran it with one of the temp files sendmail.com created, and with the
-log and -loglevel options, as well as with SYS$INPUT.

The one run with the sendmail temp file for input placed the
%LIB-F-INVNBDS error as the first line in the error log, then a blank
line, then SMTP configuration data, then the expected text from the
input file appropriately escaped (munged).

The run with SYS$INPUT did the same. If I just hit return, SFF exits
with an error and the error log shows the %LIB-F-INVNBDS error at the
top. If I enter a valid SMTP command (MAIL FROM:) then ctrl-z errorlog
shows the same; the LIB error, followed by a blank line, the contents of
the SMTP config file, my one line and an end of input file notice. And
same if I hit ctrl-z immediately after running SFF, I get the LIB error,
a blank line, then the SMTP config dump.

So the error is occurring 'early' and the cause is not logged. Feels
like a bug in the program. Despite the fact that its listed as a
'fatal' error, the exit status from SFF on all of these tests was the same: %0x00000001

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/7/24 11:21 AM, Richard Jordan wrote:

On 8/7/24 6:59 AM, Craig A. Berry wrote:

Do you get anything interesting from:

$ MCR TCPIP$SYSTEM:TCPIP$SMTP_SFF.EXE sys$input: -log sys$error:
-loglevel 1
...
^Z

?

Yes and no.  Thanks for reminding that many of these utilities have
those options!  I had forgotten; I rarely get to be in VMS anymore.

I ran it with one of the temp files sendmail.com created, and with the
-log and -loglevel options, as well as with SYS$INPUT.

The one run with the sendmail temp file for input placed the
%LIB-F-INVNBDS error as the first line in the error log, then a blank
line, then SMTP configuration data, then the expected text from the
input file appropriately escaped (munged).

The run with SYS$INPUT did the same.  If I just hit return, SFF exits
with an error and the error log shows the %LIB-F-INVNBDS error at the
top.  If I enter a valid SMTP command (MAIL FROM:) then ctrl-z errorlog shows the same; the LIB error, followed by a blank line, the contents of
the SMTP config file, my one line and an end of input file notice.  And
same if I hit ctrl-z immediately after running SFF, I get the LIB error,
a blank line, then the SMTP config dump.

So the error is occurring 'early' and the cause is not logged.  Feels
like a bug in the program.  Despite the fact that its listed as a
'fatal' error, the exit status from SFF on all of these tests was the same: %0x00000001

I can't reproduce the INVNBDS error with TCP/IP Services 5.7 ECO 5 on
8.4-2L3 or 6.0 on 9.2-2. So I don't think it is a simple HPE/VSI
difference that you're seeing. I wouldn't rule out the possibility you
have bad data somewhere. Based on SET WATCH FILE, the following data
files are accessed early by SFF, so something could be off in one of those:

TCPIP$SERVICE.DAT
TCPIP$HOST.DAT
VMSMAIL_PROFILE.DATA

and your timezone file. I would check VMSMAIL_PROFILE.DATA first. What
to check for? Dunno, really. Maybe a multibyte character in a personal
name or columns that don't line up because somebody edited the file or something. I don't think that the columns are documented anywhere, so a
robust validator for that file might be hard to come by.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/7/24 2:31 PM, Craig A. Berry wrote:

On 8/7/24 11:21 AM, Richard Jordan wrote:

On 8/7/24 6:59 AM, Craig A. Berry wrote:

Do you get anything interesting from:

$ MCR TCPIP$SYSTEM:TCPIP$SMTP_SFF.EXE sys$input: -log sys$error:
-loglevel 1
...
^Z

?

Yes and no.  Thanks for reminding that many of these utilities have
those options!  I had forgotten; I rarely get to be in VMS anymore.

I ran it with one of the temp files sendmail.com created, and with the
-log and -loglevel options, as well as with SYS$INPUT.

The one run with the sendmail temp file for input placed the
%LIB-F-INVNBDS error as the first line in the error log, then a blank
line, then SMTP configuration data, then the expected text from the
input file appropriately escaped (munged).

The run with SYS$INPUT did the same.  If I just hit return, SFF exits
with an error and the error log shows the %LIB-F-INVNBDS error at the
top.  If I enter a valid SMTP command (MAIL FROM:) then ctrl-z
errorlog shows the same; the LIB error, followed by a blank line, the
contents of the SMTP config file, my one line and an end of input file
notice.  And same if I hit ctrl-z immediately after running SFF, I get
the LIB error, a blank line, then the SMTP config dump.

So the error is occurring 'early' and the cause is not logged.  Feels
like a bug in the program.  Despite the fact that its listed as a
'fatal' error, the exit status from SFF on all of these tests was the
same:
%0x00000001

I can't reproduce the INVNBDS error with TCP/IP Services 5.7 ECO 5 on
8.4-2L3 or 6.0 on 9.2-2.  So I don't think it is a simple HPE/VSI
difference that you're seeing.  I wouldn't rule out the possibility you
have bad data somewhere.  Based on SET WATCH FILE, the following data
files are accessed early by SFF, so something could be off in one of those:

TCPIP$SERVICE.DAT
TCPIP$HOST.DAT
VMSMAIL_PROFILE.DATA

and your timezone file.  I would check VMSMAIL_PROFILE.DATA first.  What
to check for?  Dunno, really.  Maybe a multibyte character in a personal name or columns that don't line up because somebody edited the file or something.  I don't think that the columns are documented anywhere, so a robust validator for that file might be hard to come by.

Thanks for following up; I didn't have time at work to do that but we
have determined its not an SFF issue after all. It might be related to
the VSI upgrade (from HP) done last year. I reviewed a system startup
log from last year then the most recent one, and when the TCPIP START
MAIL command is executed, the same error showed up in the log, followed
by normal continuation messages.

I then stopped SMTP and got the same error (that was not verified so not
sure which command tripped it), then ran the SMTP startup again with verification on and it produced the error in the same place.

So its definitely an issue in the configuration, either a DAT file or
the SMTP config file. Since the error did not cause any performance
issues we didn't realize it was in the log or happening. SFF popped it
up in our faces.

We did not change anything in the mail config when VMS was upgraded so
its still tied to the VSI installation somehow. I updated the VSI
ticket with the info and will try to do some more testing like yours
tomorrow (tonight their batches are running and pumping out emails so I
can't).

Thanks again.
Rich

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/6/24 2:49 PM, Richard Jordan wrote:

I have contacted VSI but thought I'd ask here too.  If anyone can give
this a try and let me know if they experience the problem I'd appreciate knowing.

Integrity server, VMS V8.4-2L1, TCPIP V5.7 eco 5 with any later hotfixes
as of June 2023 applied.

V8.4-2L3 is coming but I can't install it to check for a while.

We use the 'sendmail.com' freeware to send email with binary attachments (mostly PDFs) with customized SMTP headers.  On this VSI system we get a single error every time we run SFF from the command procedure.

Exact same procedure on a V8.3 Alpha and an HP V8.4 Integrity run
without error so we're tentatively calling it a VSI issue.

Every run using symbol form via

     sff :== $SYS$SYSTEM:TCPIP$SMTP_SFF.EXE

(as defined within sendmail.com)

generates the following error, but also still creates the email
successfully:

     %LIB-F-INVNBDS, invalid numeric byte data string

Happens with any normal or priv'd account, regardless of the body text
file, presence or absence of attachments, who the recipient is, presence
or absence of a subject line.

I don't have any other systems to test on (specifically no other VSI systems).

Thanks for any info.

Problem identified. There was an incorrect parameter in the
TCPIP$SMTP.CONF file. At some point in the past year someone had turned
on SMTP debugging, including adding a SYMBIONT-DEBUG. When they
finished, instead of deleting or commenting that line out they set the parameter to FALSE. But its supposed to be a bit map with a value of
0 through 8.

That generated the error but without useful context. We found it when
booting their disaster recovery server with 6 month old system disk copy
didn't produce the error until we specifically updated that .conf file
to current.

VSI may take a look at the issue (of error message context) in their 6.0
stack.

Thanks to all who replied.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-08-13 14:54:42 +0000, Richard Jordan said:

Problem identified. There was an incorrect parameter in the
TCPIP$SMTP.CONF file.

That TCPIP$SMTP.CONF file is all too reminiscent of the recent
CrowdStrike mess.

If that configuration file is missing or empty, OpenVMS SMTP turns into
an open relay, too. No errors.


--
Pure Personal Opinion | HoffmanLabs LLC

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/13/24 6:28 PM, Stephen Hoffman wrote:

On 2024-08-13 14:54:42 +0000, Richard Jordan said:

Problem identified.  There was an incorrect parameter in the
TCPIP$SMTP.CONF file.

That TCPIP$SMTP.CONF file is all too reminiscent of the recent
CrowdStrike mess.

If that configuration file is missing or empty, OpenVMS SMTP turns into
an open relay, too. No errors.

Yes. It was unfortunate that drastic SMTP config changes were made in
an ECO to 5.7 that were never really followed up on too. Or
documented... Hopefully 6.0 will be better.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/14/2024 8:17 AM, Craig A. Berry wrote:

On 8/13/24 8:25 PM, Richard Jordan wrote:

On 8/13/24 6:28 PM, Stephen Hoffman wrote:

On 2024-08-13 14:54:42 +0000, Richard Jordan said:

Problem identified.  There was an incorrect parameter in the
TCPIP$SMTP.CONF file.

That TCPIP$SMTP.CONF file is all too reminiscent of the recent
CrowdStrike mess.

If that configuration file is missing or empty, OpenVMS SMTP turns
into an open relay, too. No errors.

Yes.  It was unfortunate that drastic SMTP config changes were made in
an ECO to 5.7 that were never really followed up on too.  Or
documented...  Hopefully 6.0 will be better.

6.0 creates the configuration file for you when you enable the SMTP
service and sets relay to false.  I guess that's something. But under
the help for SET CONFIGURATION SMTP I see no mention of SMTPS,[1] SPF,
DKIM, or DMARC,[2] all of which are now necessary to send mail with a reasonable chance of getting through.

[1] https://www.cloudflare.com/learning/email-security/smtp-port-25-587/

[2] https://www.cloudflare.com/learning/email-security/dmarc-dkim-spf/

VMS has definitely been lacking in this area for years.

But maybe it is not so important any more.

My impression is that email in general is becoming outsourced
as default. Companies outsource all their email. Even many
ISP's outsource all their email.

inbound email - external service

outbound email - external service /
local server forwarding to external service /
specialized bulk email service that expose web service
API and handle all the legal requirements for unsubscribe etc.

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/13/24 8:25 PM, Richard Jordan wrote:

On 8/13/24 6:28 PM, Stephen Hoffman wrote:

On 2024-08-13 14:54:42 +0000, Richard Jordan said:

Problem identified.  There was an incorrect parameter in the
TCPIP$SMTP.CONF file.

That TCPIP$SMTP.CONF file is all too reminiscent of the recent
CrowdStrike mess.

If that configuration file is missing or empty, OpenVMS SMTP turns
into an open relay, too. No errors.

Yes.  It was unfortunate that drastic SMTP config changes were made in
an ECO to 5.7 that were never really followed up on too.  Or
documented...  Hopefully 6.0 will be better.

6.0 creates the configuration file for you when you enable the SMTP
service and sets relay to false. I guess that's something. But under
the help for SET CONFIGURATION SMTP I see no mention of SMTPS,[1] SPF,
DKIM, or DMARC,[2] all of which are now necessary to send mail with a reasonable chance of getting through.

[1] https://www.cloudflare.com/learning/email-security/smtp-port-25-587/

[2] https://www.cloudflare.com/learning/email-security/dmarc-dkim-spf/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-08-14 01:25:48 +0000, Richard Jordan said:

On 8/13/24 6:28 PM, Stephen Hoffman wrote:

On 2024-08-13 14:54:42 +0000, Richard Jordan said:

Problem identified.� There was an incorrect parameter in the
TCPIP$SMTP.CONF file.

That TCPIP$SMTP.CONF file is all too reminiscent of the recent
CrowdStrike mess.

If that configuration file is missing or empty, OpenVMS SMTP turns into
an open relay, too. No errors.

Yes. It was unfortunate that drastic SMTP config changes were made in
an ECO to 5.7 that were never really followed up on too. Or
documented... Hopefully 6.0 will be better.

Or tested, seemingly. Defaulting to an open relay is just spectacularly
stupid. Default an unconfigured mail server startup to a safe
configuration (e.g. local only), and generate appropriate log chatter.

I've cobbled together mail relaying for some installation requirements,
but it's likely safer to disable the SMTP giblets within the grafted-on
IP stack entirely, and modify the apps to access a remote mail server
using either direct or indirect ESMTP access.



--
Pure Personal Opinion | HoffmanLabs LLC

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 14 Aug 2024 19:58:16 -0400, Stephen Hoffman wrote:

Defaulting to an open relay is just spectacularly stupid.

Back in the 1990s, as the spam problem was just gathering steam, there
were some old-school sysadmins who vehemently insisted on their right to continue maintaining open mail relays.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/14/24 6:58 PM, Stephen Hoffman wrote:

On 2024-08-14 01:25:48 +0000, Richard Jordan said:

On 8/13/24 6:28 PM, Stephen Hoffman wrote:

On 2024-08-13 14:54:42 +0000, Richard Jordan said:

Problem identified.  There was an incorrect parameter in the
TCPIP$SMTP.CONF file.

That TCPIP$SMTP.CONF file is all too reminiscent of the recent
CrowdStrike mess.

If that configuration file is missing or empty, OpenVMS SMTP turns
into an open relay, too. No errors.

Yes.  It was unfortunate that drastic SMTP config changes were made in
an ECO to 5.7 that were never really followed up on too.  Or
documented...  Hopefully 6.0 will be better.

Or tested, seemingly. Defaulting to an open relay is just spectacularly stupid. Default an unconfigured mail server startup to a safe
configuration (e.g. local only), and generate appropriate log chatter.

I've cobbled together mail relaying for some installation requirements,
but it's likely safer to disable the SMTP giblets within the grafted-on
IP stack entirely, and modify the apps to access a remote mail server
using either direct or indirect ESMTP access.

In this case the VMS system receives no email and has no public
exposure. It can send email 'anywhere' but relays through the company's primary SMTP server. It works fine for current needs; using SENDMAIL
(and TCPIP$SFF) to add the Reply-To header option is a new request, and
led to the discovery of this problem.

Thanks again to those who responded to the initial query; I really
thought a new bug had been exposed, not just a bad config entry.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-08-14, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:

Or tested, seemingly. Defaulting to an open relay is just spectacularly stupid. Default an unconfigured mail server startup to a safe
configuration (e.g. local only), and generate appropriate log chatter.

At least adding support for actually turning off the open relay was an improvement over what came previously.

I've cobbled together mail relaying for some installation requirements,
but it's likely safer to disable the SMTP giblets within the grafted-on
IP stack entirely, and modify the apps to access a remote mail server
using either direct or indirect ESMTP access.

I was one of the people 20+ years ago trying to get HP to actually give
us an option to turn off the open relay. I think I've talked about this
before, but I got a support person who simply didn't understand the issue
and I had to spend time teaching him about the issue and the implications.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On Wed, 14 Aug 2024 19:58:16 -0400, Stephen Hoffman wrote:

Defaulting to an open relay is just spectacularly stupid.

Back in the 1990s, as the spam problem was just gathering steam, there
were some old-school sysadmins who vehemently insisted on their right to >continue maintaining open mail relays.

I was one of them, making the argument that abusers should be dealt with
rather than just hiding the problem. Unfortunately the makeup of the
internet was changing at the time and things were growing to the point
where admins were no longer able to keep track of their users and I think
a lot of us didn't see the impending train wreck and destruction of the community we knew and loved coming.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

kludge@panix.com (Scott Dorsey) writes:

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On Wed, 14 Aug 2024 19:58:16 -0400, Stephen Hoffman wrote:

Defaulting to an open relay is just spectacularly stupid.

Back in the 1990s, as the spam problem was just gathering steam, there
were some old-school sysadmins who vehemently insisted on their right to
continue maintaining open mail relays.

I was one of them, making the argument that abusers should be dealt with rather than just hiding the problem. Unfortunately the makeup of the internet was changing at the time and things were growing to the point
where admins were no longer able to keep track of their users and I think
a lot of us didn't see the impending train wreck and destruction of the community we knew and loved coming.

+1

My second major project as a systems programmer (the first being a JCL translator from SVS on an Amdahl 470/v7 to MVS on an IBM 3081) was an e-mail system upgrade to allow the University of Chicago to use network mail. This was a project sponsored by Educom, a network called Edunet, and explicitly utilized the open relay syntax specified in RFC 822. (This was 1983-84.)

10 years later, as the mail administrator at our startup, I had to swallow the bitter draft that was turning off the open relay in the later release of the very same e-mail system I had a hand in at Chicago.

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)