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.