Debian bug report logs - #1799, boring messages

Message sent to debian-devel@pixar.com:

Subject: Bug#1799: smail nameresloving problems
Reply-To: jlarkin@aij.st.hmc.edu (John T. Larkin), debian-bugs@pixar.com
Resent-From: jlarkin@aij.st.hmc.edu (John T. Larkin)
Resent-To: debian-devel@pixar.com
Resent-Date: Sat, 04 Nov 1995 01:03:01 GMT
Resent-Message-ID: <debian-bugs-handler.1799.B11040054400@pixar.com>
Resent-Sender: iwj10@cus.cam.ac.uk
Message-Id: <m0tBWrc-0005f9C@aij.st.hmc.edu>
From: jlarkin@aij.st.hmc.edu (John T. Larkin)
To: debian-bugs@pixar.com
Date: Fri, 3 Nov 1995 16:53:40 -0800 (PST)
Content-Type: text
Content-Length: 5227

smail: 3.1.29.1 rev 13.
I'm having a problem with smail.  It was recently working just fine.  But
for some reason unknown to me, it has stopped working.
Here is a summary of the problem:

My fdqn is aij.st.hmc.edu.  Foo.st.hmc.edu is a another member of the domain
st.hmc.edu.  I have no problems using 'host' or nslookup to discover the
ip address of 'foo.st.hmc.edu', nor do I have a problem using nslookup or
host to find the ip address of 'foo', the short hostname by itself.

Sending mail to user@foo results in a returned message from the mailer-
daemon, host unknown.  Mail to user@foo.st gives the same error.
Sending mail to user@foo.st.hmc.edu (the fdqn) is ok.
Here's  my /etc/resolv.conf:
  domain st.hmc.edu
  search st.hmc.edu hmc.edu
  nameserver 134.173.53.8
  nameserver 134.173.32.20
  nameserver 134.173.42.2
The nameservers all work correctly.
Here is /etc/host.conf
  order hosts,bind
  multi on
Here is /etc/smail/routers
# This is the Smail routers file, which says what to do with mail destined for
# remote hosts.  This configuration is for Internet and satellite systems.
# It was originally generated by `smailconfig', part of the Smail package
# distributed with Debian, but it may edited by the mail system administrator.
# This file originally generated by smailconfig at Tue Oct 31 23:49:46 PST 1995
# See smail(5) for details of the things that can be configured here.

inet_addrs:
	driver=gethostbyaddr, transport=smtp;
	check_for_local, fail_if_error

inet_hosts:
	driver=bind, transport=smtp;
	defer_no_connect, -local_mx_okay, +defnames, +dns_search,
	gateways=hmc.edu:uucp:bitnet
Using any options of +/-defnames and +/-dns_search do not change the
behavior in any way.
Removing the file '/etc/smail/routers' fixes the problem.  However, as I'd
like to use a smarthost for uucp and bitnet mail, this is very inconvient.

All operations involving doing something with 'foo' work correctly, for
instance 'telnet foo' works fine, so does something like 'finger @foo'.

Here is an included message from another debian smail user with the
same problem.
-----------------------------------------------------------------------

 Ack, I have been at this an hour, and I have come to the conclusion
 that I am missing something -- probably something completely obvious.

 Ok, the situation is as follows.

	 I have a new nameserver set up at 198.112.200.8
	 This nameserver has an "MX" record for our domain
	 This nameserver has "A" records for _all_ hosts
	 Using the new nameserver:
	  I can nslookup any short hostname, fqdn, or MX record.
	  I can telnet to any host, using the short hostname or fqdn.
	  I can mail to any fqdn or MX alias.
 =======> I _can't_ *mail* to any short hostname except the localhost's
	   (it says "host unknown" when I do a "smail -bt" test)

 Can somebody help me figure out what it is trying to do?  Smail seems
 to be failing to figure out that it needs to tack on .simons-rock.edu
 to the name.  As I said above, I can nslookup short hostnames and fqdn
 just fine (e.g. plato and plato.simons-rock.edu).

 My DNS records are set up in the following format :
 ; MX Mail routing ("A" records are for broken mailers which require IPs.)
 simons-rock.edu.                IN MX 0         plato.simons-rock.edu.
 simons-rock.edu.                IN A            198.112.200.2
 abel.simons-rock.edu.           IN MX 0	        plato.simons-rock.edu.

 ; Networking Office                                             1 - 30
 plato.simons-rock.edu.          IN A            198.112.200.2
 www.simons-rock.edu.            IN CNAME        plato.simons-rock.edu.
 gopher.simons-rock.edu.         IN CNAME        plato.simons-rock.edu.

 My /etc/resolv.conf:
 domain simons-rock.edu
 search simons-rock.edu
 nameserver 198.112.200.8

 My relevant /etc/smail/transports entry:
 smtp:   driver=tcpsmtp, max_addrs=100, -max_chars, inet;
	 use_bind, defer_no_connect, -local_mx_okay, defnames

 My /etc/smail/routers:
 inet_addrs:
	 driver=gethostbyaddr, transport=smtp;
	 check_for_local, fail_if_error

 inet_hosts:
	 driver=bind, transport=smtp;
	 defer_no_connect, -local_mx_okay, defnames,
	 gateways=uu.net:uucp:+:cunyvm.cuny.edu:bitnet

---------------------------------------------------------------------
  Here's some help from Ian Jackson
---------------------------------------------------------------------
 Hmm.  Can you try adding

	dns_search
	       type: boolean
	       If set allow the resolver to search its domain list
	       for  matches.  This experimental and might not have
	       the effect you expect depending  on  your  resolver
	       search capabilities.

 to your bind router and see what the effect is ?

 If you could try it with all of
  -defnames, -dns_search
  -defnames, +dns_search
  +defnames, -dns_search
  +defnames, +dns_search
 that would be excellent ...

----------------------------------------------------------------------
All of the options described by Ian do not work.  I am quite baffled by
the performance of smail, and have no idea how to fix the problem.

Any help at all would be greatly apprectiated.

--
				- John Larkin
				- jlarkin@hmc.edu
		- <A HREF=http://aij.st.hmc.edu/~jlarkin>My home page.</A>

Message sent:

From: iwj10@thor.cam.ac.uk (Ian Jackson)
To: jlarkin@aij.st.hmc.edu (John T. Larkin)
Subject: Bug#1799: Acknowledgement (was: smail nameresloving problems)
In-Reply-To: <m0tBWrc-0005f9C@aij.st.hmc.edu>
References: <m0tBWrc-0005f9C@aij.st.hmc.edu>

Thank you for the problem report you have sent regarding Debian GNU/Linux.
This is an automatically generated reply, to let you know your message has
been received.  It is being forwarded to the developers' mailing list for
their attention; they will reply in due course.

If you wish to submit further information on your problem, please send
it to debian-bugs@pixar.com, but please ensure that the Subject
line of your message starts with "Bug#1799" or "Re: Bug#1799" so that
we can identify it as relating to the same problem.

Please do not reply to the address at the top of this message,
unless you wish to report a problem with the bug-tracking system.

Your message didn't have a Package: line at the start (in the
pseudo-header following the real mail header), or didn't have a
psuedo-header at all.

This makes it much harder for us to categorise and deal with your
problem report; please ensure that you say which package(s) and
version(s) the problem is with next time.  Some time in the future the
problem reports system may start rejecting such messages.

Ian Jackson
(maintainer, debian-bugs)

Ian Jackson / iwj10@thor.cam.ac.uk, with the debian-bugs tracking mechanism

This page last modified 01:13:02 GMT Sat 04 Nov