Need to force all SMTP mail through a mail gateway

[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!