Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!caen!ox.com!mudos!mju
From: mju@mudos.ann-arbor.mi.us (Marc Unangst)
Newsgroups: comp.mail.uucp
Subject: Re: Problems with MMDF and UUCP mail
Message-ID: <0F7PP1w163w@mudos.ann-arbor.mi.us>
Date: 19 Sep 90 04:05:44 GMT
References: <7950@gollum.twg.com>
Organization: The Programmers' Pit Stop, Ann Arbor MI
Lines: 67

david@twg.com (David S. Herron) writes:
> er.. ah.. the Received: header lists both the sending and receiving
> host, so therefore the `local' host is appearing in the header somewhere.

I'm probably not being too clear here, so I'll try to elaborate on
what exactly I mean.

On most of the other MTA systems I've worked with (which includes
sendmail, smail 3.1.19, smail 2.5, "dumb UUCP", and various MS-DOS
packages), mail that originates on the local host and is delivered
elsewhere is given a Received: header by the local host.  MMDF doesn't
do this.  For example, let's say that I have two hosts: tech.dsc.com
and mudos.ann-arbor.mi.us.  I send mail from mudos, which runs Waffle
v1.63 under MS-DOS, to tech, which runs MMDF under SCO ODT.  When the
mail arrives on tech and is delivered to the user there, it will have
two Received: headers; one that was put in by mudos that just says
"Received: by mudos.ann-arbor.mi.us ...", and one that was put in by
tech that says "Received: from mudos.UUCP by tech.dsc.com ...".  This
is the way, IMHO, things should work.  However, if you try sending
mail the other way around -- from tech to mudos -- the mail arrives on
mudos and is delivered to the user there with only ONE Received:
header, which reads "Received: from tech.UUCP by mudos.ann-arbor.mi.us
...".

What I'm wondering is why, in the second case (tech->mudos), tech
isn't adding a Received: header for itself.

> If SCO's version of MMDF was compiled with NAMESERVER undefined then
> there's no-way-no-how you can do nameserver queries.  NAMESERVER was
> there in the version SCO used (update 32).

That's strange, because I talked to SCO technical support and they
said that the version of MMDF that was shipping with the current
version of ODT was not capable of nameserver queries.  They did say
that when the next release of ODT comes out, it will include a
nameserver-capable MMDF.  Perhaps this is what you're talking about?

> the /usr/lib/sendmail that MMDF installs *is* command-line-compatible
> with Berzerkeley sendmail.  At least enough-compatible to do the job
> of posting mail, and possibly a couplea other things.  (Starting up
> an smtpd for instance..)

Try, for example, "/usr/lib/sendmail -bt".  Under Berkeley sendmail,
as well as smail 3.1.19 (which installs itself as /usr/lib/sendmail,
among other things), this will get you an "address test mode" where
you can type in an address and it will show you the motions it goes
through to figure out what to do with mail to that address.  It's very
useful for debugging routing files without sending a lot of test
messages.

Under MMDF, that yields an "unknown option" error message from MMDF.
IMHO, if you're going to install something called /usr/lib/sendmail,
make sure everything about the interface with other programs is
exactly the same as the de facto standard sendmail.  Otherwise, please
don't call your program "sendmail", because it isn't.

One note that may have some effect here -- we are a SCO dealer and are
setting up this ODT network partially to help support customers who
purchase SCO ODT products.  Therefore, we are attempting to stay as
close as possible to the stock SCO distribution, and suggestions such
as "junk MMDF and go with {smail 3.1.19, IDA Sendmail, pick a favorite
MTA}" will probably be politely declined.

--
Marc Unangst               | "da-DE-DA: I am sorry, the country you have
mju@mudos.ann-arbor.mi.us  | dialed is not in service.  Please check the
...!umich!leebai!mudos!mju | number and try again."  -- Telecom Kuwait