On Wed, Jul 14, 2004 at 11:06:16PM -0400, Gene Heskett wrote:
> On Wednesday 14 July 2004 14:05, Alexander Dalloz wrote:
>
> [...]
> >
> >Of course, if Philippe did give his Sendmail a hostname which is not
> >resolvable, neither by the hosts file nor a DNS, his MTA will not
> > work proper.
...
> All of which makes sense (I think, I'm having trouble with he
> "internal" status of AAA yet)
I recall reading a comment that local host names for sendmail need "enough"
dots. i.e.
box.bogustopdomain # will not work for some.
box.subdomain.bogustopdomain # can work.
Since there is a AAA.com., aaa.net. and aaa.org resolver code could be
looking any of these up because you do not have enough dots.
I recommend the top two levels of a private host name be researched
for conflicts. I once found a nifty but flawed how-to for sendmail
and dns that said use "invalid.com". It turns out that there is a
registered domain by that name. Following the directions in this case
did unpredictable and possibly bad things.
http://www.interex.org/tech/9000/Tech/sun_hpux_interop/chap10_dns.html
In part the root of this is the ndots of resolver code (not really a
sendmail problem). In some cases /etc/hosts can use dots to force
termination and closure. i.e. DNS resolver code should understand
that a trailing dot terminates the fully qualified domain name.
192.188.1.5 boxa.aaa. boxa.aaa boxa
Also "Mail -v fred@xxxxxxxxx" may respond differently than
without the trailing dot "Mail -v fred@xxxxxxxx". If things are correct
they should be the same. Compare and contrast...
host boxa.aaa.
host boxa.aaa
Mail -v fred@xxxxxxxxx
Mail -v fred@xxxxxxxx
next do a reverse lookup on the host results. Forward and reverse lookup
should be consistent.
$ host boxa.aaa.
boxa.aaa. has address 192.168.0.51
$ host 192.168.0.51
51.0.168.192.in-addr.arpa domain name pointer boxa.aaa.
Since aaa is not a subdomain of a .com .net or other high level domain
this dot count thing could be important.
In addition sendmail has a need to locally resolve private network
addresses.
http://sendmail.org/tips/private-dns/
The point here is that if the reverse lookup fails for a private
network as it will without local interaction mail will queue. This
"should be OK" with hosts first in resolv.conf but I have not found it
to be satisfactory.
Also there may be issues with path MTU discovery for some ISP services.
http://sendmail.org/tips/pathmtu.html
It can be useful and diagnostic to force your outgoing MTU to be
modestly sized.
Lastly if you are on a DHCP assigned address you will find that
setting up sendmail is painful. The short TTL for the domain name is
a signature of dynamic DNS. Use the ISP's mail host as a smart host.
This may require authentication. Set 'reply to:' headers on mail to
be the ISP's assigned mail address. Collect mail from the ISP with
fetchmail/ pop/ imap for local access.
I once thought that MX records would be helpful but there is a window
when your old IP address and DNS records could point to a different
box. If that box answers then rejects mail, mail will bounce back to
the sender.
Summary:
in etc/hosts
192.168.0.10 a.aa.priv.notpublicnet a
not
192.168.0.10 a.aa a
--
T o m M i t c h e l l
/dev/dull where insight begins.
