⟦aecd15745⟧

TextFile

		Common Problems and Recommended Solutions

			Updated 12/14/86

(1) The configuration shell script smail.cf.sh insists that
I give it another domain that I'm authoritative for, but we
don't have anything to give it.

    This is a common problem for small companies that only
    have one machine, or for organizations that are originally
    registering in COM/EDU/GOV and were never known in UUCP.

    The shell script is somewhat simple - it really should let
    you just hit RETURN here.  But you can go ahead and follow
    the examples anyway, and it shouldn't hurt anything.

    For example, if you're FOOBAR.COM:
	Enter This Host's Name:
	foobar
	Enter This Host's Official Domain:
	COM
	Enter Any Equivalent Domain Classes:
	foobar
	Enter Any Domains For Which This Host Is An Authority:
	foobar.UUCP
    The first two lines mean that you are user@foobar.COM (the two
    entries strung together.)  The second one means you also
    understand what to do with user@foobar, which isn't really
    legal but may tend to crop up from time to time.  The last
    means you also understand user@foobar.UUCP, which is important
    for upward compatibility since that's commonly generated by
    other systems, by netnews software, and the like.

(2) I can send mail to others OK, but sometimes when they send mail
to me or I send mail to others on my machine, it doesn't work.
It says "couldn't resolve myhost.mydom!user".

    This is probably a configuration problem.  Look in defs.h to see
    how you have MYDOM set.  It comes distributed as ".UUCP", but
    you probably want to change this to the answer to the "Enter This
    Host's Official Domain" question above.  If you don't run sendmail,
    this is the only way smail has of knowing your host name.
    (We really should have smail read this in from a file, for future
    3rd party binary distributions, but so far we haven't.)

(3) Mail isn't getting through sometimes, and since I just installed
this new software, I suspect it.  Or, I see munged header lines, and
I don't know who is doing it.

    If you aren't sure where the mail is getting dropped (remember, UUCP
    is an unreliable transport mechanism, so lots of things could be going
    wrong) here's a trick we sometimes use to find out what's going on.
	mv /bin/rmail /bin/realrmail

	cat > /bin/rmail
	#! /bin/sh
	umask 0
	LF=/usr/spool/uucp/rmail.log
	cat > /tmp/rm$$
	echo " " >> $LF
	date >> $LF
	echo rmail $* >> $LF
	cat /tmp/rm$$ >> $LF
	realrmail $* < /tmp/rm$$
	st=$?
	rm /tmp/rm$$
	exit $st
	^D
	chmod 755 /bin/rmail
    
    This will keep a very verbose log of all incoming traffic into your
    machine in LF, including the text as it arrived on your machine, and
    the arguments to rmail.  You can tell whether it was broken when it
    arrived or if you broke it, and you can reproduce the mail by editing
    out the message (into, say, /tmp/msg) and running
	realrmail args < /tmp/msg
    using the args as they appear in the file.

    Some words of warning.  (a) These files can get big very fast if you
    process much traffic through your machine, so be sure to clean them
    out often.  (b) This saves everything, including the message body.
    It is unethical to browse such logs unless a specific problem has
    arisen which requires you to check the log.  This is one reason why
    it's kept in /usr/spool/uucp, if you have a hidden directory on your
    system that's even better.  (c) This extra set of file copies adds
    overhead to your machine, so don't run this unless you suspect you
    have a problem, and then take it out when you trust things again.

    There is a RECORD option in the code which is similar, but this
    option saves the mail at a later stage, so you lose some information
    about how it arrived on your machine.

(4) I don't understand how to set up subdomain of my domain.

    There are two ways to do this.  The easiest is just by recognizing
    the subdomain host by their UUCP name.  If you are the gateway for
    domain FOO.COM, then any mail through your sendmail to bar.FOO.COM
    or to bar.myname.FOO.COM (where "myname" is your hosts's name) will
    be treated as if it were bar.UUCP, so if the name "bar" is in your
    path file, you're all set.  The disadvantage to this is that if you
    want to create a subdomain whose name conflicts with a public name,
    it won't work.  If you want to disable this code, look for "mydom"
    in the sendmail.cf.

    A perhaps cleaner way is to explicitly put the subdomains into the
    pathalias database.  Thus, if you have a.FOO.COM, b.FOO.COM, p.b.FOO.COM,
    x.myname.FOO.COM, and y.myname.FOO.COM, you could include this in
    your local pathalias input:
	aname	.a.FOO.COM
	bname	.b.FOO.COM
	pname	.p.b.FOO.COM
	xname	.x.myname.FOO.COM
	yname	.y.myname.FOO.COM
    In each case, "aname" is the UUCP name for host "a", etc.  This
    sort of says "aname and a.FOO.COM are the same host."  This
    description says that you have subdomains x and y under your host,
    that there are peer subdomains a and b, and that you know about
    a subdomain of b called p.  Other subdomains of a and b that
    are not mentioned here will be routed through aname or bname as
    gateways.  The only reason to mention p here would be if we have
    a direct link and want to avoid routing through bname.  If you
    do this, you have less strict requirements about name uniqueness:
    aname, bname, pname, xname, and yname must still be unique, and
    a.FOO.COM, b.FOO.COM, p.b.FOO.COM, x.myname.FOO.COM, and
    y.myname.FOO.COM must also be unique (ignoring case, so that
    two different hosts a.foo.com and A.FOO.COM conflict.)  In
    particular, this means that if you have a local host with a name
    that isn't unique, say "bilbo", you can safely create a subdomain
    "bilbo.myname.FOO.COM", but you'll still have a problem if the
    UUCP name of the host is "bilbo".  You may be able to make this
    partly work using the pathalias "private" notation, but we advise
    you to change the UUCP name to something unique.

(5) When another host in my domain sends mail to a third host in my
    domain, it seems to get routed through the gateway even though
    my host knows how to route directly.

    For example, suppose you have gateway cbosgd.att.com, and other
    machines foo.att.com and bar.att.com.  Smail is installed on all
    three machines.  But when a user on foo sends to user@bar.att.com,
    the mail is routed via cbosgd.  Sometimes, you may even see this
    happen for mail on foo to foo.

    There are two solutions.  The first is to make sure that foo knows
    that bar.att.com is the same as bar (where "bar" is the uucp name.)
    Include lines in the local pathalias input files like
	foo	.foo.att.com
	bar	.bar.att.com
	cbosgd	.cbosgd.att.com
    
    The second solution is to declare foo to be a gateway for your
    subdomain, e.g.
	foo	.att.com
    This will handle all mail to att.com locally on foo instead of
    routing it through cbosgd.  (It also means you'd better be sure
    to keep the routing tables on foo as up to date as on cbosgd.)

    The first method is strongly recommended for everyone.  The second
    is appropriate only for well maintained and supported hosts.
    Either should handle the problem.

(6) Mail to some domains isn't working.  For example, if I type

	smail -d USER@LLL-MFE.ARPA
    
    It says:

	resolve: parse address 'USER@LLL-MFE.ARPA' = 'USER' @ 'LLL-MFE.ARPA' (DOMAIN)
	getpath: looking for '.LLL-MFE.ARPA'
	getpath: looking for 'LLL-MFE.ARPA'
	getpath: looking for '.ARPA'
	getpath: looking for 'ARPA'
	route 'LLL-MFE.ARPA' failed
	resolve failed 'USER@LLL-MFE.ARPA' = 'USER' @ 'LLL-MFE.ARPA' (DOMAIN)

    There is a .arpa line in the pathalias database that looks like:

	.arpa	ihnp4!akgua!gatech!seismo!%s

    Chances are the pathalias database is out of order.  Remember
    to run it through "sort -f" before storing it.

(7) People on the ARPANET are complaining about us sending them mail
    from FOO.COM when we aren't on the ARPANET.

    Politely ask them to upgrade their mail system to support MX
    records, as required by RFC's 973 and 974.

    If you have a COM, EDU, or GOV name confirmed by the UUCP Zone, and
    you have a working forwarder, you have an officially allocated name
    which you are entitled to use.

    However, do understand that the old way of handling things on the
    ARPANET was to open a connection directly to the destination host
    and send the mail via SMTP.  Many hosts assume that a name ending
    in ARPA, COM, etc implies being on the ARPANET, and handle mail
    this way.  (4.3BSD still does this.)  The above RFC's, approved in
    January 1986, say that mailers are supposed to check for an MX
    record, which says that mail for one domain should be delivered to
    a different host to be forwarded.  As of December, 1986, many
    ARPANET hosts still have mailers that understand MX, and the
    standard UNIX and TOPS 20 mailers don't support it.  So politely
    urge them to find whoever supports their mailer and get it upgraded
    to support MX.  (Berkeley has a version of sendmail that supports
    it, but it isn't in 4.3BSD.  An MX supporting sendmail can be found
    on ucbarpa.Berkeley.EDU by logging in as anonymous and retrieving
    pub/4.3/sendmail.MX.tar.  The file is 1.26MB.  The latest MMDF also
    supports it.)  In the meantime, tell whoever is trying to send you
    mail that mail to user@foo.COM (for example) can be sent to
    foo.COM!user@seismo.CSS.GOV.

(8) My System V machine with sendmail produces the error message
    "No ! in UUCP!" when I send local mail.

    This is a bug in older versions of sendmail.  If you have the
    source to sendmail, make the following change to deliver.c to
    fix the problem:


    *** deliver.c.stock
    --- deliver.c
    ***************
    *** 1016,1022
      		expand("$g", buf, &buf[sizeof buf - 1], CurEnv);
      		bang = index(buf, '!');
      		if (bang == NULL)
    ! 			syserr("No ! in UUCP! (%s)", buf);
      		else
      		{
      			*bang++ = '\0';

    --- 1016,1022 -----
      		expand("$g", buf, &buf[sizeof buf - 1], CurEnv);
      		bang = index(buf, '!');
      		if (bang == NULL)
    ! 			return;
      		else
      		{
      			*bang++ = '\0';

    If you do not have source to sendmail, a workaround is to edit
    /usr/lib/sendmail.cf (or template.cf before you run make.cf.sh.)
    Find the line beginning "Mlocal", and remove the "U" on that line.
    This has an undesirable side effect, in that the From_ line will
    be in a format not understood by mailx, but since most mailx replies
    use the From: line, this should be a minor problem.

#
# @(#)Trouble	2.1 smail 12/16/86
# [Edited by MRH 12/14/86]
#
DataMuseum.dk

DKUUG/EUUG Conference tapes

⟦aecd15745⟧ TextFile

Derivation

TextFile
