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.

[Wim Van den Wyngaert]

ucx show mx ?

Can you at teast try to fill the mail server info ? Wouldn't be the first time config data is lost.

Wim

[Joseph Huber_1]

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

Which is rather irrelevant, since You showed us the TCPIP SMTP configuration does not use a gateway.
If You have an SMTP server/gateway in the organization, then use it, define it as gateway for VMS SMTP as Wim suggested, and see what happens.
Then If the mail sending again fails with a DNS error, then it is a general problem in Your organization, not VMS specific.

But of course the underlying DNS problem is another issue to be resolved, and should be checked first.

[shiva27]

Joseph,

Right from begining we've not define gateway. So do you thing if i define the gateway this issue will resolve.

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_LONDON_00 1 LONDON

[Wim Van den Wyngaert]

TRY IT PLEASE !!!

Wim

[Joseph Huber_1]

As Wim said, try it, i.e. set the mail gateway to the mail server node (the one managed by the mentioned mail server team).
At least it will show if the DNS problem is local to the VMS system or also present in wider local net.

Read the help in TCPIP:
"help set config smtp".
and in particular the /GATEWAY and /ZONE, and /SUBSTUTE_DOMAIN options.

I don't know what the policy in Your organization is for mail, in mine it is simply not possible to send smtp mail to the outside directly by an individual node, and mail can only be received/addressed to the mail domain, not an individual node inside the domain.

How does the VMS system RECEIVE mail ? Also directly addressed, or through the incoming mail server ?

But even if the mail via gateway will work, there might still be the original DNS (bind resolver) problem.
If the mail destination citi.com in Your first posting was not just an example, then try if "TCPIP SHOW HOST citi.com" is resolved. It should return the address of citibank.com if the bind resolver is working correctly.