A VAX with VMS 5 that uses the MULTINET TCP/IP stack is vulnerable to third-party SMTP relay hijacks by any Tom-BOT-and-Harry probing around for a port 25 SMTP server. Case in point, my MicroVAX 3100 exposed to the outside Internet would clog up with queued relay messages in a matter of hours putting me at risk of being flagged by my ISP (Comcast). As a result I could not keep the machine online for an extended period. I decided to see if I could solve the problem at the VMS or MULTINET stack level. Yes it would be easier to simply install a modern router or firewall solution but what fun would that be?
Here is an example message from the queue:
$ show queue /full
10 SMTP-RETURN SYSTEM 19 Holding until 2-DEC-2017 12:49
Submitted 2-DEC-2017 12:18 /FORM=DEFAULT
/PARAM=("yahoo.com.hk; Error sending MAIL command to yahoo.com.hk")
Leaving the VAX exposed to the Internet would cause hundreds of these to queue up. The relaying takes CPU and disk space.
I sent a message to cctech to see if anyone had any experience with this problem. I got a useful tip how to disable SMTP altogether:
> > $ MULTINET CONFIGURE /SERVERS
> > SERVER-CONFIG> DISABLE SMTP
> > SERVER-CONFIG> RESTART
> > Configuration modified, do you want to save it first ? [YES]
> > Regards,
> > Peter Coghlan
OK. I can at least turn off the spigot.
Using the commands listed above I disabled the SMTP service. I also cleared the message queue. I was glad to find that no new messages were being relayed. Good, but would disabling SMTP effect legitimate email routing? I ran a test to see if I could send an email out/from the VAX server to one of my email accounts elsewhere (gmail.com). That worked, but when I replied to the VAX's message (from gmail) the VAX blocked it.
Conclusion - I can't leave SMTP disabled entirely or legit inbound emails will be blocked. Initially I guessed out-bound mail would be blocked but I was wrong. MULTINET uses SMTP to route email traffic to VMS mail internally.
I found a MULTINET user group thread from 1997 that seemingly applied to my case:
>>Is there an safe and effective method for preventing third-party
>>relaying mail through the MULTINET SMTP server, while still allowing
>>local deliver of mail and local sending of mail to other hosts.
>>Reject-nets, reject-hosts doesn't really work well because the
>>abusers keep switching origins and it also blocks legitimate mail.
>Yes, there is, and it'll be in the version after V4.0 rev B. We have a
kit available for V3.5 (any revision) and V4.0 (any revision) if you'd
like to install it.
>Please contact me directly if you're interested (dwing-at-cisco.com).
Thanks Dan Wing wherever you are. OK..Let's see what version of MULTINET I have running...the command:
$ multinet show/version
Process Software MultiNet V4.1 Rev A, MicroVAX 3100, VAX/VMS V5.5-2
Good. I bet I already have the upgrade Dan was referring to. Searching through MULTINET's ansi-style menu:
$ multinet config /menu
The controls exist. The location is called "SMTP Security Parameters" and one gets there from the main menu via:
->Configure Multinet Server
-->View/Modify an Existing Service
---->Set Security Options
I set Reject by Default = TRUE (it was FALSE). I also added my mail server IP in the hosts allowed field. Note that more than one IP is allowed if your separate each IP with a comma.
I returned to the "configure multinet server" menu and restarted the multinet_server process to cause the changes to take effect.
To verify this all worked I sent an email message to the VAX from my mail server. The VAX received it. Success.
It is thus possible to have a MicroVAX running MULTINET facing the external WWW with SMTP enabled that will not also be used as an SMTP relay. Limitation - one has to add the IP(s) of the inbound email server(s) allowed given SMTP traffic is disabled by default.
I created an alias MV3100@buzz1-dot-calm on my modern mail server to route Internet messages .. That's the only "modern" cheat I used. I did not need to block port 25 at any point, set up a fire wall nor do NAT translation.
Testing the alias worked (to from gmail). I replied to the message and that worked too, the cycle is complete.
After many hours of uptime, zero messages became stuck in the mail queue from third-party SMTP relay hijackers. YAY.