Preventing VAX running VMS / Multinet from being used as SMTP relay

[Peter Coghlan]

On 11/30/17, 9:26 PM, "cctech on behalf of william degnan via cctech"
<cctech-bounces at classiccmp.org on behalf of cctech at classiccmp.org> wrote:

>
> >I have a microvax set up with VMS 5, running MULTINET (and decnet
> >locally).   The server has a FQDN and after a while being exposed to the
> >WWW someone out there started using the server as an SMTP relay.  I can
> >disable and clear the queue, but I'd like to block entirely this from
> >happening in the first place.  I'd like to learn more about how this
> >happens in VMS.
> >
> >Anyone have had this same problem before?  I realize back when VMS 5 was
> >current it was not so much of an issue, but today it is.  I am working on
> >a
> >solution.  I can envision a few ways including blocking the smtp relay
> >port
> >from the firewall, but if possible I'd like to set up a VMS Multinet
> >solution as a learning exercise.
> >
> >I am open to suggestions, and once I find the solution I'll post it.
> >
> >I understand that this kind of thing is not cookie cutter, there are
> >different levels one could address something like this.  I have a comcast
> >business router, and one of the 5 IPs I have is NAT assigned to the
> >internal 10.1.10 port of the microvax.
> >
> >This is the same machine I wrote about previously as with then, thanks for
> >your help.  I find the best way to learn is on the actual hardware warts
> >and all.
> >
> >Bill
>
> Look at the SMTP_SERVER_REJECT file example here:
> http://www.process.com/docs/multinet5_4/admin_guide/Ch15.htm.
> It¹s a set of rules that decide whether a message gets rejected (rule
> ending in ³y²) or let through (rule ending in ³n²). You¹d normally set
> this up to first let through those emails you want, then reject everything
> else at the end of the rules file.
>

I am not sure whether this method will work on the clearly elderly but
unspecified version of Multinet in use here.

I should also have suggested checking whether there are other TCP/IP services
running that may have issues.  DNS in particular would be open to very serious
abuse affecting lots of innocent third parties on the internet if not brought
up to current patchlevels.  NTP also springs to mind.

The easiest way to deal with all these issues comprehensively would probably
be to update the machine to the current version of Multinet (5.5).  This is
not hard to do and is covered by the Multinet hobbyist license.

Regards,
Peter Coghlan.