Operating System - OpenVMS
Showing results for 
Search instead for 
Did you mean: 

random loss of email delivery to outside client

Go to solution
Kelly Cox
Frequent Advisor

random loss of email delivery to outside client

I have a random problem with smtp mail delivery.
Alpha DS10
VMS 8.2, latest ECO's and latest TCP.
Using apache 2.1 with latest patches.

A web client logs in daily to look at reports/data that is run via a cgi program looking RMS data. The cgi program logs the selected data to a .txt file and emails log to myself and the client.
My email and the clients are both pop3 accounts on very different domains, neither on the same domain as the vms/axp/apache server.

The client just notified me that they are only getting about 2/3's of the emails, i am getting all daily emails. If I go back to the same server and manually email the text file to the client they get it. The manual command is the same as spawned from the program.
$mail/subj=daily report.txt "client@client.edu"

I've looked in the forums and smpt manual for reference to some smtp logs that may prove the email was sent, but cannot find any 'sent' log.

No patches or updates in the past 3 weeks. Most days the client gets the email.
It sure looks like a random error on the client mail server, but I'd like to find a log that may show the bounce or delivery error.

I suspect that the client mail server logs could probably show the problem, so I would like to show them a log of the email leaving.
I may have to increase the level of my local vms smtp logs. ??

I know VERY little about smtp or mx or related issues. VMS mail has always worked, so any suggestions would be appreciated.
Honored Contributor

Re: random loss of email delivery to outside client

I'll assume this VMS mail server is operating with a public static IP and public DNS, and is the mail server of record for the domain; that there are not other mail servers involved here within your configuration.

The usual triggers for failed SMTP connections are bad MX records and bad host configuration and bad reverse DNS, though these triggers will usually cause a receiving mail server to presume the sending server is a spam engine nuke all arriving mail messages.

This sort of indeterminate behavior can also be triggered by issues within pools of receiving mail servers.

To see the outbound SMTP traffic, use the ACCOUNTING tool. The outbound traffic departs via the SMTP queues, and you'll see queue-related records there. You can add additional diagnostics and snapshot diagnostics and additional logging via:


These sorts of cases are usually resolved with a look at the sending mail server DNS (to confirm no mistakes) and with a look at the receiving mail server and its logs, and in the junk folders or the transmitting mail server based on whatever is (or is not) found in the remote mail server.
Kelly Cox
Frequent Advisor

Re: random loss of email delivery to outside client

Thanks Hoff,
This is not the listed mail server for the domain, and i believe that smtp traffic is only allowed out from this vms server.

This unit is basically a black box data server and email is only sent from this box, nobody receives mail to this unit.

I am waiting to hear from the mail server manager of the client to see what type of errors if any they see coming from the vms server as the client is getting 70 out of 100 emails per week from the vms process.

It seems to really be an issue at the client side as I get 100 or 100 of the same messages. I was just trying to learn a little more about smtp especially as relates to logging so I can be more definitive when i tell a client to check their own smtp logs and clean up their smtp routing rules.

This management and verification used to be easier when there were not so many middleware issues...but that is today's world.

Thanks again Hoff, i'll read that link and check the accounting logs and learn more.
Craig A Berry
Honored Contributor

Re: random loss of email delivery to outside client

Your log files would typically be in SYS$SPECIFIC:[TCPIP$SMTP], and I think TCPIP$SMTP_RECV_RUN.LOG is the one most likely to have logs of what's been sent.

There are a *lot* of logical names at the link Hoff pointed you to. I think TCPIP$SMTP_RECV_TRACE is the one most likely to be relevant to what you're interested in, though if in fact mail is not getting sent then various other debugging options might be relevant.

If by any chance your domain has a dynamic IP, then one possibility is that the receiving MTA does a reverse lookup that fails during a switchover but otherwise succeeds.

Don't overlook silly things like having the end user check in her junk or spam folder. Automated messages, however legit, sometimes get a high spam score.
Honored Contributor

Re: random loss of email delivery to outside client

This could well be the client, but it's also possible that if a mail server box is not the listed mail server for the domain, then weirdnesses can arise when this "rogue" mail server lights up within the domain. Receiving SMTP servers can get cranky.

See this thread:


and see the TCPIP$SMTP_ALTGATE_ALWAYS settings.

And if you're working on VMS on your receiving mail server, then the mail can be far more tolerant of inbound mail than many (other) serves are configured.

Reposting. Porque esto es ITRC

Bob Blunt
Respected Contributor

Re: random loss of email delivery to outside client

My application had this sort of problem incessantly. The problems almost always turned out to be related to gateway definition issues and intermediate servers. The logfiles and the email headers are the keys to use. Just when we'd find and fix a problem then the email infrastructure dictators would change some definitions underneath us and we'd have to find the source(s) of the problems again.

In all honesty the application I was managing worked *perfectly* within a DECnet-based network. When we were moved to a mostly simple IP-based network it still worked pretty well. But as the network got more complicated and the new ideas and solutions moved further and further from our direct control the problems got much worse. Every time the network types redesigned the layout or moved systems, hubs and hosts to new datacenters it was a mess.

Even if your applications just get mail "one way" make sure you test end-to-end in both "directions" so you can see if there are any differences in the intervening nodes between your end points. That can help let you know if you've got some DNS naming issue that isn't always evident.

Honored Contributor

Re: random loss of email delivery to outside client

You're undoubtedly not looking for more work here, but this is VMS and...

The VMS IP stack is certainly functional and sufficient for internal operations, though many (most?) sites have now moved mail to Microsoft Exchange, or Postfix on Unix, or otherwise, and for various reasons.

If you have the option, then using an SMTP client tool and entirely bypassing the VMS pieces might help get the bulk of the stack out of the way. That'll likely make it easier to configure into a target environment, too; it'll work like a traditional mail client, rather than a server.

There's the BSD-license source code of a C mail client here:


For php, there's the phpmailer package here:


There are certainly others, though I don't immediately see ports of libsmtp or libmail or such around for VMS.
Robert Gezelter
Honored Contributor

Re: random loss of email delivery to outside client


I have seen many cases of bounced messages and messages relegated to SPAM traps of various kinds. Some of this can be traced from the OpenVMS end, in other cases, there is no feedback to the sender, the message is acknowledged to OpenVMS and then mis-handled further on down the line.

Thus, it is possible that the OpenVMS-resident logs may not be of use. They are worth checking for obvious error indications, but a more interesting monitoring would be to use WireShark (or similar tool) to monitor the relevant outgoing connections from the OpenVMS system to the outside. Then one could go back to the message that disappeared and precisely trace where it went. In effect, following the breadcrumbs through the forest.

On several occasions, what then comes into view is unexpected. For example, if a domain has a series of SMTP servers (which is common), the round-robin DNS results (or traffic managers) will route incoming mail to different systems. If some of those systems are configured differently, interesting things can happen.

The key is finding out precisely what is happening. Otherwise, there is no assurance that a solution is truly a solution, and not just an experimental artifact.

- Bob Gezelter,
Author, "Internet E-Mail Architecture", Chapter 56, Handbook of Information Security
Jeremy Begg
Trusted Contributor

Re: random loss of email delivery to outside client

Hi Kelly,

If 2/3 of the messages make it through to your client's server and 1/3 don't, I'd be checking how many mail gateways the client is running.

The mail gateways might be identified by multiple MX records and/or multiple A records for the client's domain.

If that's the case, it's likely that one of those mailservers is refusing to process the mail messages being sent from VMS. You will have to work with the client to resolve that issue, e.g. "fixing" their mailserver or taking any possible actions at your end to convince their mailserver that your mail is legitimate.

Jeremy Begg
Kelly Cox
Frequent Advisor

Re: random loss of email delivery to outside client

Thanks for all the input. I finally received an ip address of the clients primary mail server and put that address as the general and alternate gateway. Now i get 100% of emails and the client gets 100% of emails...this from a vms server on their own network.

I warned them that when they change rules or boxes or ip's then this will break again. I also asked them to clean up their rules for all their smtp incoming to allow smtp from the vms box.

For now, automated reports are showing up in the clients BOSSES emails again and they are happy. It is hard sometimes NOT to tell the boss I TOLD YOU. That box has run for years without needing a smtp gateway entered.

Thanks again for the pointers, thankfully i did not have to learn too much more about vms smtp as i am already behind on my task list.