VSI OpenVMS Forum

--- Observation ---
It is getting more and more difficult these days to send email from OpenVMS. TCP/IP Services V5.7 sends mail by connecting to a distant server, determined from the MX record for the destination domain, on port 25. It appears that the service cannot send mail through an SMTP server that requires either encryption or authentication. If I am wrong about any of that, please correct me.

How does TCP/IP Services V6.0 address those issues?
---

TCP/IP V6.0 does not include features to support sending mail through SMTP servers requiring authentication and encryption. Please reply to this topic if your application or product requires extending OpenVMS to support sending mail through SMTP servers requiring authentication and encryption.

My main concern is that SMTP lacks the ability for TLS when requested by the receiver. Receiving is less of a problem, I'm using Process PreciseMail AntiSpam frontend and that has served me well for several years. I have been thinking of PMDF as well but it was my thought at the time it would be too much (given my environment: 1 domain,. 2 users). I might rethink the idea

To echo Tom's comment, Process Software PMDF is the ultimate solution for all things email on VMS. It's not free, although I do think they have a "hobbyist" license if that suits your needs.

There is a TLS option for PMDF called, naturally, PMDF-TLS, which is an added cost for non-hobbyist use.

Rather than install PMDF-TLS, I configured WASD on the PMDF server machine to accept a TLS session from the client and pass it through to PMDF. WASD listens on ports 465 and 993 and forwards them through to ports 587 (SMTP) and 143 (IMAP), respectively, where PMDF accepts the connection. (Note this "raw" TLS, not START-TLS.)

I've never had a requirement for being able to send mail from VMS to another server using SMTP with authentication. The configuration for PMDF to act as an SMTP client, sending a username and password to the remote SMTP server, is described in section 21.5 "SASL Authentication for the TCP/IP Channel Client" of the PMDF System Manager's Guide. It would not be difficult to configure WASD to tunnel a non-TLS connection from PMDF to a TLS session on a remote SMTP server, for specific remote servers.

Jeremy Begg

within my employers internal corporate network authentication and ssl is required to send email so internal VMS servers can no longer send emails to me warning of batch job failures and so on.

On customer networks this requirement is becoming more common.

Support for these features within VMS TCPIP would be welcome.

imiller wrote: ↑

Tue Dec 19, 2023 5:50 am

within my employers internal corporate network authentication and ssl is required to send email so internal VMS servers can no longer send emails to me warning of batch job failures and so on.

On customer networks this requirement is becoming more common.

Support for these features within VMS TCPIP would be welcome.

If they do get around to overhauling SMTP in TCP/IP Services, they'll really need to implement Sender Policy Framework and DomainKeys Identified Mail. SPF and/or DKIM are generally required these days for operating any kind of mail service.

I definitely think VMS should have an SMTP server that supports all of todays protocols.

But from a practical perspective needing to send email from from VMS as part of operations then I would think that:
* applications could use a SMTP client library to talk to some non-VMS SMTP server (rewriting from VMS callable mail to a SMTP client library is obviously effort, but I consider it a general improvement making it possible to use new features)
* DCL scipts are slightly more tricky, but it should not be that hard to write a little mailer based on a SMTP client library in Python or Groovy or whatever one prefer

Sorry Arne, but I have to disagree with you there. Pretty much every other O/S has a workable SMTP setup. If nothing than other than being to email log fles, errors etc to a sysadmin team that is surely a must.

On our late ERP-ish system, we used to script running reports that were emailed to either customers or suppliers

It surely isn't rocket science...

Chris

VMS should have a working SMTP server - working as in working with current standards. For those that want to run the SMTP server on VMS.

Other server OS can do that. So VMS should too.

But SMTP servers are typical a centralized function today. If you have 500 Linux servers, then there are not 500 SMTP servers running - there are probably just 2 SMTP servers running (dedicated SMTP server with redundancy).

VMS applications should not require a local SMTP server, because other platforms do not.

So moving VMS applications to a model of external SMTP server makes sense to me.

And then it works with a Linux SMTP server today and with a VMS SMTP server in the future when VSI get the VMS SMTP server updated.

I agree - the SMTP client option in VSI TCPIP should enable a client capable of emailing modern SMTP servers including the facility to email a file. Often I email a backup report or similar using VMSMAIL.
This is a separate but related facility to running a SMTP Server on OpenVMS.

Something callable via VMS calling convention and something for DCL would be very nice.

But solutions exist.

I would expect:

https://docs.python.org/3/library/email.examples.html

to work on VMS too.

(obviously with SMTP_SSL class instead of SMTP class to meet original requirement)

That would work but would require python on the VMS server which something I'd like but it's not always easy getting customers to agree. For older systems [ I look after too many of those ] I would use VMSMAIL over DECnet to a more up to date node as that is what is done now.