mails from VMS to exchange server not going.

[shiva27]

can you pl. suggest urgently.

Recently, OLD DNS resolver server decommisioned and new DNS server configured. application team reported that after reboot system generated mails are not getting on their mail id in exchange server as they used to get 3 time in d day.

i cheked TCPIP$SMTP_LOGFILE.LOG; file
---------------------------------------
%MAIL-E-USERDSABL, user xyz_12 cannot receive new mail
%TCPIP-E-SMTP_UNKHST, remote host unknown, citi.com
-SYSTEM-F-NOSUCHNODE, remote node is unknown
-----------------------------------------


$ ucx sho name

BIND Resolver Parameters

Local domain: abc.xyz.COM

System

State: Started, Enabled

Transport: UDP
Domain: abc.xyz.COM
Retry: 4
Timeout: 4
Servers: IP address1, IPaddr2,
Path: No values defined

Process

State: Enabled

Transport:
Domain:
Retry:
Timeout:
Servers:
Path:




$tcpip show config smtp /full
---------------------------------------------
SMTP Configuration
Options
Initial interval: 0 00:30:00.00 Address_max: 16 NOEIGHT_BIT
Retry interval: 0 01:00:00.00 Hop_count_max: 16 NORELAY
Maximum interval: 3 00:00:00.00 TOP_HEADERS

Timeout Initial Mail Receipt Data Terminate
Send: 5 5 5 3 10
Receive: 5

Alternate gateway: not defined
General gateway: not defined

Substitute domain: not defined
Zone: not defined

Postmaster: TCPIP$SMTP
Log file: SYS$SPECIFIC:[TCPIP$SMTP]TCPIP$SMTP_LOGFILE.LOG

Generic queue Queues Participating nodes

TCPIP$SMTP_SVMU04_00 1 LONDON

----------------------------------------

MAIL> send
To: user@domain.com
Subj: test messages..
Enter your message below. Press CTRL/Z when complete, or CTRL/C to quit:
test messages .. Exit

mail>read/since=today
---- Transcript of session follows ----

%TCPIP-E-SMTP_UNKHST, remote host unknown, citi.com
-SYSTEM-F-NOSUCHNODE, remote node is unknown

---- Unsent message follows ----

[shiva27]

If you required more cmd output pl. let me know. Thanks.

[Joseph Huber_1]

Before going into mail, which hides or complicates the issue, I first would check if the new DNS is working with
"TCPIP SHOW HOST citi.com"
if this does not return an IP address, then talk to the DNS admin.

[Wim Van den Wyngaert]

Your alternate gateway is not filled in.

ucx set conf smtp/gat=alt=xxx

Thus it tries to access the mail server without a hostname, t.i. with the domain name citi.com. And it fails.

Tried the same thing here and I get unknown host to.

Wim

[Wim Van den Wyngaert]

BTW : on my 5.3 I had to stop/id the tcpip$smtp* process and restart the queue to make the change work again.

Wim

[Joseph Huber_1]

Wim, I don't believe the missing gateway is the problem.
It is o.k. to send mail directly without a gateway (if firewalls allow it), and since DNS is the only change made in the OP's system, I assume the SMTP setup has not changed since it was working.

citi.com is an existing domain, and should be usable. So I still suspect the DNS server in question is not getting the address.

[Wim Van den Wyngaert]

You need to comunicate with the mail server and it tries to use citi.com as a host name.
So, or citi.com is a host name and your domain is .com or the host is missing.

You can simply try it. Fill in the host name of your mail server and test it again.

BTW : how would you like that VMS contacts the mailserver without any config item ?

Wim

[Joseph Huber_1]

>>BTW : how would you like that VMS contacts the mailserver without any config item ?

The destination address is either node address or a MX record. The node address can directly be contacted and has a smtp server (port 25),
or an MX record finally is resolved to the mail server node address.

There is no need for gateways in simple systems, of course most environments do not allow each node to directly send mail through port 25, they have to go through a gateway.

I just DID test this on my system:
tcpip set config smtp /nogateway=noalt
tcpip set config smtp /nogateway=nogen
tcpip$smtp_shutdown , tcpip$smtp_startup
and still could send mail to a destination node, and to an MX address.


As I sayed, the OP problem happened after a DNS server change, not after SMTP configuration change.

citi.com translates perfectly in my systems. but not in his.

[Hoff]

Use dig and traceroute and whois and ping, and work from there. Work through the networking. With the TCP/IP mechanisms to bring dig and such online in your local process environment (TCPIP$DEFINE_COMMANDS.COM) these tools are available, and these can and do allow resolving DNS-level and SMTP-level weirdnesses. TCPIP> SHOW HOSTS can show bogus local static or cached entries, too. It's not my preferred tool for poking around in DNS. (Your networking folks will likely be more familiar with dig and friends than with the TCPIP> tools, too.)

Now is the time to learn how to run dig and such, too. This tool will tell you what the DNS response is, and which DNS server returned it. Among other details.

The DNS resolver (and I'd expect you're running a resolver and not a DNS server) is set up via TCPIP$CONFIG menu system. If you're running a full-on DNS server, you should probably stop doing that, or at least be prepared to go rummaging through that.

Then work your way up to SMTP and such.

There are many potentially interesting parts within this configuration that are well worth investigating, but I'm not going to grope blindly around here; masking of DNS and of addresses is to be expected but also makes troubleshooting these cases all the more interesting and difficult. Bogus data is very hard to use to debug DNS.

There are also some complete wildcards here, as there are active malware infestations around which seek to deliberately alter DNS resolution and that can attempt to jam up ARP traffic; that target DNS and routing.

What's also interesting are the DNS-related and network-related questions in your ITRC history; somebody's been overhauling DNS and the networking in this organization. Which can mean that any or all of the stack involved here can be a potential trigger for this.

And if this is urgent, do consider ceasing the use of ITRC here, and contact your formal support and escalation organization directly; that'll get you the fastest answer. Get some help. DNS isn't hugely difficult, but it's also not an entirely trivial area. Your local DNS environment appears particularly volatile, too.

Stephen Hoffman
HoffmanLabs LLC

[shiva27]

Mail server is pinging from our VMS server and do the traceroute w/o any issue.

New DNS implementation i've done 1 month ago and this mail receiving issue experiencing since last 2 days.

I checked with Mail server team they said "At there end VTM patching and server relocation has been done in weekend "

But our system and application side no changes.

Pl. let me know if you want see see any cmd output to figure out this issue.
Thanks.