Need to force all SMTP mail through a mail gateway

[Jeremy Begg]

Hi,

HP TCP/IP Services for OpenVMS Alpha Version V5.4
on a AlphaServer DS15A running OpenVMS V7.3-2

I've been asked to investigate an SMTP problem on this system. There are applications on this system which generate reports and then email the results. The applications send the report using a command such as

$ mail/subj="XYX Report" report.txt "user@domain.com.au"

where 'user' is the user responsible for the application and 'domain.com.au' is the official domain name for the organisation.

We'd like these messages to be sent to the local Exchange server but the TCP/IP Services SMTP symbiont sends them to the user's local VMS MAIL account instead, without going anywhere near Exchange.

Here are some relevant parts of the SMTP configuration:

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: COLOEXCH1
General gateway: not defined

Substitute domain: DOMAIN.COM.AU
Zone: VMSBOX.DOMAIN.COM.AU

In addition, the logical name TCIP$SMTP_ALTGATE_ALWAYS is defined /SYS/EXEC with value "1", which I thought should force it to route through the specified gateway (COLOEXCH1).

Where have we gone wrong?

Thanks,
Jeremy Begg

[Joseph Huber_1]

One possibility: the destination is in the list of local aliases in
TCPIP$SMTP_COMMON:TCPIP$SMTP_LOCAL_ALIASES.TXT
Check it.

If this is not the case, the problem could be at the gateway: do the headers ("Received from ...") show if it was going through the gateway, or directly without passing the gateway ?

[marsh_1]

hi,

have you an mx entry for your exchange server in tcpip ?

hth

[Jon Pinkley]

Do you get connected to the exchange server when you enter:

$ telnet coloexch1 25

If not, you need to find out why.

Jon

[Ananth S]

Have you tried removing the zone ?

[Bill Hall]

Jeremy,

We have similar requirements as your client. Our SMTP config is as follows:

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: EXCHANGE.DOMAIN.COM
General gateway: not defined

Substitute domain: HIDDEN,CLUSTER_ALIAS.DOMAIN.COM
Zone: not defined

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

Generic queue Queues Participating nodes

The substitute domain is a valid cluster alias. IIRC, the zone entry the problem. We were able to use a zone entry when our Exchange domain was different than the VMS server/cluster domain.

Bill

[Bill Hall]

Jeremy,

I should also mention that this smtp configuration allows us to send smtp mail between VMS servers without routing through our Exchange server. After rereading your post, I wasn't sure if you wanted to route all smtp mail through the Exchange server.

Bill

[Bill Hall]

Jeremy,

I double checked my facts. The current config I listed IS IN FACT routing all VMS to VMS mail with smtp addressing through the Exchange server. We do not use the TCPOP$SMTP_ALTGATE_ALWAYS logical.

When we had the Exchange server in a different domain and all of the VMS servers were all in another domain, we were able to use a zone entry of vms_domoin.com to send smtp directly from VMS server to VMS server without routing through the Exchange server.

Sorry for the previous flawed post.

Bill

[Jeremy Begg]

Thanks for all your suggestions. Here's some feedback.

Joseph, I can confirm the TCPIP$SMTP_LOCAL_ALIASES.TXT file contains only two entries: the hostnames of the two VMScluster members. I can also confirm that the mail was delivered by the TCP/IP Services SMTP symbiont directly into the VMS MAILBOX without going through Exchange.

Mark, there are no MX entries:
$ tcpip show mx
%TCPIP-E-ROUTEERROR, error accessing routes database (TCPIP$ROUTE)
-TCPIP-W-NORECORD, information not found

I also checked the DNS and the MX record for this domain points to another server (not the Exchange server). It does not point to the VMScluster nodes.

Jon, yes the Exchange server accepts connections from the VMS systems on port 25.

Ananth, removing the Zone does not help. (I added it yesterday trying to see if it would help.)

Bill, it looks like the "substitute domain" is the culprit; removing it fixed the problem (and creates a new one, see below).

As far as I can tell, if the substitute domain is set to the same domain name as the domain you're sending to, TCP/IP Services assumes that it's OK to deliver directly to the local host -- ignoring the TCPIP$SMTP_ALTGATE_ALWAYS logical and the SMTP zone setting.

I'll need to discuss with the customer how they want to handle this. They want the VMS servers to route outgoing email via Exchange, but the VMS hostnames aren't registered in the Internet DNS and hence many external mail systems will reject mail from the VMS systems. So I think I need my customer to set up Exchange to modify the sender address on the way out (to remove the VMS hostname).

Thanks,
Jeremy Begg

[Steve Reece_3]

Hi Jeremy,

Before reading your last post, I concluded that the substitute domain was the culprit.
The Alternate Gateway is used for mail that's not deliverable locally. If you're sending mail to the same domain as the VMS system is in then I would expect that mail to be delivered locally. If it's outside then it will be delivered to the alternate gateway and then leaves that alternate gateway to do what it wants with the mail.

Options may include putting the COLOEXCH1 name in the General gateway too so that everything gets directed in the same way. I've not tried that though and don't have a VMS box handy to test it.

[Joseph Huber_1]

Jeremy:
>>
As far as I can tell, if the substitute domain is set to the same domain name as the domain you're sending to, TCP/IP Services assumes that it's OK to deliver directly to the local host -- ignoring the TCPIP$SMTP_ALTGATE_ALWAYS logical and the SMTP zone setting.
>>

I have the same TCPIP 5.4 version, and the setup is

Alternate gateway: SMTP.MPPMU.MPG.DE
General gateway: SMTP.MPPMU.MPG.DE

Substitute domain: HIDDEN, MPPMU.MPG.DE
Zone: MPPMU.MPG.DE

We have no problem to send to the substitute domain addresses, and it goes through the gateway.

Could it be the HIDDEN tag makes a difference ?
And also I wonder if the zone shouldn't be DOMAIN.COM.AU instead of VMSBOX.DOMAIN.COM.AU,
i.e. one level above the local VMS subdomain ?

[Ananth S]

When you define an alternate gateway, any mail destined for a domain outside the zone entry will be sent to the alternate
gateway. If an alternate gateway is defined and no zone is defined then the local domain (value of the TCPIP$INET_DOMAIN logical) is used as the zone.

[Bill Hall]

Jeremy,

We also lack DNS MX records for our VMS servers and started to get a lot of external recipients rejecting mail generated by the apps we run. Our suggestion to add MX records fell on deaf ears and we didn't get any offers of assistance from our Exchange administrators.

We recommended to our application support folks that they use the TCPIP$SMTP_FROM logical, defined to a legitimate smtp address on our Exchange servrs, as a work around to the problem.

Bill

[Hoff]

There's a Process IP stack feature that might be of interest here; Process implemented a client capability that allows SMTP traffic originating on OpenVMS to connect to (here) Exchange as the mail server.

With this feature, you can use local mail and DECnet mail, but your OpenVMS box otherwise looks like a giant SMTP client as far as your Exchange server is concerned.

Whether the customer might be interested in migrating IP stacks is another discussion. Probably not, but...

[Jeremy Begg]

Hi all,

I believe I found the cure for my problem:

$ define/system tcpip$smtp_no_subs_domain_inbound 1

I discovered this logical name on the 3rd or 4th reading of the TCP/IP Services Management Guide.

The description of this logical confirms that if the substitute domain matches the destination domain, mail will be delivered to the local host. Defining the logical name disables this behaviour.

I am waiting for my customer to confirm that their application mail messages are now going to the right place.

Bill and/or Joseph - how did you get the "Hidden" attribute set in your substitute domain setting -- and what does it do? I can't find this documented in the manual or online help.

Thanks,
Jeremy Begg

[Thomas Ritter]

Jeremy

"Bill and/or Joseph - how did you get the "Hidden" attribute set in your substitute domain setting -- and what does it do? I can't find this documented in the manual or online help."

$ ucx set configuration smtp /substitute_domain=(hidden,name="SECRET")

[Joseph Huber_1]

Well the HIDDEN attribute is not only no longer documented, I have the impression it also has no effect. I just removed it on my system without any effect on the headers sent.

It's such a long time I did the setup, so I don't remember the reason.

[Bill Hall]

Jeremy,

As Joseph stated, "It's such a long time I did the setup, so I don't remember the reason."

My intention at the time, was to hide the fact the mail was coming from host.domain.com and substitute the cluster alias, alias.domain.com. This was an attempt to approximate DECnet mail incoming/outgoing alias functionality.

Bill

[Jeremy Begg]

My customer has confirmed that after defining the TCPIP$SMTP_NO_SUBS_DOMAIN_INBOUND logical name, SMTP is behaving as desired.

So I am closing this thread now.

Thanks for all your help!