Xref: utzoo comp.mail.sendmail:2731 comp.protocols.tcp-ip.domains:632
Path: utzoo!attcan!uunet!ispd-newsserver!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!ncar!gatech!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!mucs!cns!jf
From: jf@ap.co.umist.ac.uk (John Forrest)
Newsgroups: aus.mail,aus.aarnet,comp.mail.sendmail,comp.protocols.tcp-ip.domains
Subject: Re: Strange behaviour with MX record lookups, mailers, ...
Message-ID: <1991Jan31.211658.26804@cns.umist.ac.uk>
Date: 31 Jan 91 21:16:58 GMT
References: <6587@munnari.oz.au>
Sender: usenet@cns.umist.ac.uk (News System)
Organization: comp
Lines: 30

I have to admit this was too long to read through quickly.
However, a couple of points:

My gut reaction is that this is a wildcard MX problem - it you
have a wildcard MX for *.dom1.dom2 and you are in ...dom1.dom2,
then sendmail will often throw the wildcard on during lookup.
To get around this, you either:

1) Get rid of the wildcard. (best in my opinion, but subject to
   admin problems).
2) Get hold of a sendmail binary that does not do domain
   resolution - you have to give it the full name. (less
   useful, but some people prefer the certainty).

This is worth checking first - although it is difficult since
lookups using host(1) for T_ALL or T_MX will return with the
wildcard bit filled in. Still worth trying with the names you
intend though.

Second point. If you want to stop name resolution, the best way
is via the binary - there is a resolver flag to stop it. You
have to be careful putting '.' on the end, since a bad lookup
might leave it there. Having said this, I wish we had a global
convention that '.' on the end indicates a fully resolved
address - having to choose between fully and partially resolved
addresses can be tricky.

John Forrest
Dept of Computation
UMIST