SMTP Route Through

[RF Thomas]

All of our users need to send emails through our corporate SMTP server that is an IA64 OpenVMS system from their home computers.

We have set-up Good-Clients and placed node names/IP addresses into this list. The problem is that most ISP's do not set-up statis addresses or node names, so when these change the SMTP.CONFIG file must be edited to reflect the changes.

Does anyone have a better solution? Each user does have a unique VMS acocunt, but the SMTP server does not appear to utilize this for route through traffic.

[Hoff]

VPN or ssh into the box. This could be directly, or via an outboard firewall / VPN router? By raising a direct tunnel (and setting the client up to use it for all traffic), everything goes in and out via your mail server, too.

The TCP/IP Services package is comparatively limited in its support for modern SMTP-related features and mechanisms; I'd investigate one of the third-party IP stacks, or an alternative mail server.

[RF Thomas]

To change the TCP/IP stack is not a viable option for us. The VPN/SSH also is not a desireable option.

I omitted part of the "puzzle", we travel all over the world and many times are connecting through customer networks. The allowable protocols can be very restricted.

We have installed a web based mail server on the OpenVMS system, but web based mail message creation has limited functionality and does not integrate well with OUTLOOK.

[Hoff]

AFAIK, this case is basically deadlocked between policy restrictions and product limitations, then.

Here, I'd start to investigate alternatives to the SMTP server you're using, and I'd certainly suggest you make your product requirements known to HP here. This given that the current configuration is not meeting your requirements here, nor was your previous quest for spamassassin or analogous apparently fruitful. One of the other common pieces of this - ClamAV - is around as an add-on, however.

If you can't use a VPN or tunnel, then Gmail or other such (directly or as a route-through) might be an option, and HP often helps its customers move to Microsoft Exchange server, for instance. OpenVMS Engineering has featured the Quintara SecureServer product, and the Process IP stacks are certainly in wide use on OpenVMS.

Yes, I know, (still) not the answer you wanted... Sorry.

[RF Thomas]

Thanks for the helpful responses. We would prefer to avoid MICROSOFT Exchange.

We'll have to start looking more closely at LINUX.

[Willem Grooters]

Have you looked at Communigate-pro (http://www.communigate.com/). As far as I tested it (some years ago), it runs as "Exchange on OpenVMS", so it may well fit your needs.

[Wim Van den Wyngaert]

You could use putty (free) to tell the server in a secure way (SSH) which IP address the PC has. And then modify the SMTP config. And have some kind of timeout system to remove them again (or reset it at midnight). Of course this would require an extra action at boot or a click of the user.

fwiw

Wim

[Willem Grooters]

[quote]
Of course this would require an extra action at boot or a click of the user.
[/quote]
Not just that. You'll have to restart SMTP.

[Hoff]

If I'm going to ssh or VPN into the network, I'm going to ssh or VPN into the firewall, and connect from there through to the server. This gives me a LAN-based IP address, among other benefits.

I regularly use these tools to connect from the local Mac OS X client boxes through onto various OpenVMS boxes and onto other server boxes. These approaches can also permit DECwindows X connections and displays sent back from OpenVMS out onto the Mac client, for instance.

If you're interested in discussing a particular implementation of this approach, contact me off-line.

[RF Thomas]

We are probably mistaken in many aspects, but the following is our understanding with respect to the various responses:

1) CommunigatePRO does not seem to support OpenVMS, at least it is not mentioned as a supported system.
2) To obtain IP addresses, our users log onto the VMS server using a telnet client. They then enter $SHOW TERM and the IP address is displayed. This is then added to the Good-Clients list. We probably should automate such using a script on the PC's and a DCL command file on the VMS mail server. Maybe using PHP and APACHE?
3) SMTP does not need to be restarted when changes are made to the SMTP.CONFIG file that impact GOOD_CLIENTS. The changes are picked-up "on the fly".
4) We will look into VPN through our firewall router. As I understand VPN, each connection is a unique network, so each PC would have to map to a unique network, I suppose that the network masks could be set to minimize the number of nodes possible in each network. Since almost all of our users connect via NAT (and our router utilizes NAT), the VPN functionality needs to be in the firewall/router, or special software is required on both sides. Additionally we will have ensure that out firewall supports a large enough number of VPN's.
5) We have attempted to use X-Windows through VPN's. Unless one has local high performance connections the performance was unacceptable. To get reasonable performance LBX (Low bandwidth X) needs to be installed. HP has a kit for this for VMS. We did not have enough resources (time) to get things working acceptably.