The docs are a bit obtuse on the subject; by implication this might be
possible but so far testing has been unsuccessful.

The specific environment is OpenVMS Alpha V8.2, TCPIP Services V5.5,
both at current ECO levels.  No BIND server is running, just a
resolver using ISP provided public DNS servers.  The Alpha and the
email smarthost (a windows server running SMTP mail program,
identified as "Microsoft ESMTP MAIL Service V6.0.3790.4675") are on a
NAT subnet behind a firewall.  We do not have access to or control
over the firewall or the smarthost at this site, ONLY the alphaserver.

The Alpha currently sends all mail to the internal smarthost defined
as an alternate gateway; the local zone is set to 'alpha.customer.dom'
so mail intended for user@customer.dom as well as all other domains is
sent to the smarthost.

Our problem is the MS smarthost is a piece of crap.  Mail sent to many
outside domains can be delayed for hours or even a day or two after
the message was confirmed received by the smarthost.  We can't do
anything about that system or the firewall; the vendor responsible
won't change anything and the customer who owns the site won't force
the issue.  So I'm looking for an alternative.

If we don't route mail for customer.dom to the smarthost private IP
address, it fails; using public MX records from the external DNS
server has the alpha trying to send mail to the 'public' IP address,
and the firewall won't route internal SMTP connections properly to
that public IP (certainly a configuration problem); mail going to
'user@customer.dom' _has_ to go to the internal private IP if sent
from an internal source, but mail going anywhere else could be sent
directly by the alpha instead of via the smarthost; in testing by
removing the alternate gateway and zone definition, this eliminated
all the delays, but of course prevented delivery of mail to the local
domain.

My understanding: if an alternate gateway is defined as a host name or
FQDN, then the local MX record for that name provides one or more IP
addresses, in priority defined order, that can be used as that gateway
even if there is no host or 'A' record for the gateway name.  We tried
adding additional MX records for external domains pointing to their
mail server IPs (read from those domain's public MX records) but all
mail to those domains still routed through the smarthost. Yes, the
SMTP service and queues were restarted when changes were made.

In my testing, if NO alternate gateway is defined, then the MX record
for 'customer.dom' pointing to the internal smarthost had no effect.
All mail to customer.dom tried to use the public IP and failed, but
mail to anywhere else worked properly.  Putting in a local MX record
for an external domain (pointing to an incorrect IP address, or a
secondary MX for the domain) also made no difference; the mail was
sent to the primary MX for that domain as retrieved via DNS.  As far
as I can tell the local MX records are not used if the alternate
gateway is not defined.

In testing we also made the following change to get mail received by
some outside domains (I do not believe it is related to the routing
issue but included for completeness):  when the alternate gateway was
removed, substitute domain set to 'customer.dom' so the
'alpha.customer.dom' of the zone isn't sent; that allowed sites doing
DNS lookups of the 'from' address domain to let the connections stay;
there is no public A or CNAME record for 'alpha.hostname.dom' so some
sites rejected it out of hand.  The logical TCPIP
$SMTP_NO_SUBS_DOMAIN_INBOUND was set so mail sent to 'customer.dom'
addresses was not delivered locally via VMS Mail.

So is there any way to do what we need here using basic TCPIP Services
SMTP?  All mail for 'users@customer.dom' goes to the smarthost private
IP address, all mail for anywhere else gets sent directly using public
DNS MX records, using only configuration changes done on the
Alphaserver?

Thanks for any info

One way to do this, not sure if the best or not:

Run your own bind server on the alpha.

created a zone for "mydomain.dom" and say that the authoritative server
for that zone is that local dns server on the microsoft machine.

(or you could create your own zone file and manage it yourself, but not
sure if appropriate within your organisation).


Your SMTP server would then automatically resolve hosts in mydomain.dom
to the local IP address and thus connect to the local microsoft SMTP
server for local mail. For outside mail, it would forward DNS queries to
your ISP's DNS server to obtain public IP address and delivery directly.


Perhaps a simpler way:

For the public DNS server, lookup the MX record for mydomain.dom  , say
it is smtp.mydomain.dom

You then include a local entry in the hosts file

(TCPIP> SET HOST smtp.mydomain.com 10.2.3.4  ) which means that the
alpha will find the translation in its local hosts file instead of going
to your ISP to resolve it.

On Apr 22, 3:20=A0pm, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
> One way to do this, not sure if the best or not:
>
> Run your own bind server on the alpha.
>
> created a zone for "mydomain.dom" and say that the authoritative server
> for that zone is that local dns server on the microsoft machine.
>
> (or you could create your own zone file and manage it yourself, but not
> sure if appropriate within your organisation).
>
> Your SMTP server would then automatically resolve hosts in mydomain.dom
> to the local IP address and thus connect to the local microsoft SMTP
> server for local mail. For outside mail, it would forward DNS queries to
> your ISP's DNS server to obtain public IP address and delivery directly.
>
> Perhaps a simpler way:
>
> For the public DNS server, lookup the MX record for mydomain.dom =A0, say
> it is smtp.mydomain.dom
>
> You then include a local entry in the hosts file
>
> (TCPIP> SET HOST smtp.mydomain.com 10.2.3.4 =A0) which means that the
> alpha will find the translation in its local hosts file instead of going
> to your ISP to resolve it.

I'm not certain that the latter will work; the docs state the
following order of lookup when routing mail:

   1. Local MX database
   2. BIND MX records
   3. BIND A records
   4. Local hosts database

Easy enough to test though so I'll give it a try and report back.

Its a shame the local MX stuff doesn't seem to work; that would be a
very consistent and logical way to do this.  That or installing CGPro
or another properly capable mail server...

On Apr 22, 3:35=A0pm, Rich Jordan <jor...@ccs4vms.com> wrote:
> On Apr 22, 3:20=A0pm, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
>
>
>
> > One way to do this, not sure if the best or not:
>
> > Run your own bind server on the alpha.
>
> > created a zone for "mydomain.dom" and say that the authoritative server
> > for that zone is that local dns server on the microsoft machine.
>
> > (or you could create your own zone file and manage it yourself, but not
> > sure if appropriate within your organisation).
>
> > Your SMTP server would then automatically resolve hosts in mydomain.dom
> > to the local IP address and thus connect to the local microsoft SMTP
> > server for local mail. For outside mail, it would forward DNS queries t=
o
> > your ISP's DNS server to obtain public IP address and delivery directly=
..
>
> > Perhaps a simpler way:
>
> > For the public DNS server, lookup the MX record for mydomain.dom =A0, s=
ay
> > it is smtp.mydomain.dom
>
> > You then include a local entry in the hosts file
>
> > (TCPIP> SET HOST smtp.mydomain.com 10.2.3.4 =A0) which means that the
> > alpha will find the translation in its local hosts file instead of goin=
g
> > to your ISP to resolve it.
>
> I'm not certain that the latter will work; the docs state the
> following order of lookup when routing mail:
>
> =A0 =A01. Local MX database
> =A0 =A02. BIND MX records
> =A0 =A03. BIND A records
> =A0 =A04. Local hosts database
>
> Easy enough to test though so I'll give it a try and report back.
>
> Its a shame the local MX stuff doesn't seem to work; that would be a
> very consistent and logical way to do this. =A0That or installing CGPro
> or another properly capable mail server...

Heh!  Seems to work after all.  We'll test on the production box on
Monday (the site is closed).  Thanks, JF!