From: kevin@cfctech.cfc.com (Kevin Darcy)
Newsgroups: comp.sys.3b1,comp.mail.misc
Subject: Re: Sendmail problem on AT&T unix 7300 (3b1).
Date: 8 Jan 93 22:55:14 GMT
Organization: Chrysler Financial Corp., Southfield, MI

In article <1993Jan7.014459.14742@blilly.uucp> lilb@sony.compuserve.com (Bruce Lilly) writes:
>In article <1993Jan6.051545.3526@gagme.chi.il.us>,
> posted to comp.sys.3b1,comp.mail.misc,
> wdp@gagme.chi.il.us (Bill Pfeiffer) wrote:
>>
>>Interesting thing is, that I DO NOT have a smail binary on the system!
>
>$ ls -li /bin/cp /bin/ln
>    71 -rwxr-xr-x   2 bin      bin          4812 Jan  1  1970 /bin/cp
>    71 -rwxr-xr-x   2 bin      bin          4812 Jan  1  1970 /bin/ln
>$
>
>If you execute "rm -f /bin/cp" (and you have sufficient permission for it to
>succeed), do you still have the "cp" program? Yes, you do; it's also called
>"ln"-- if you then execute "/bin/ln /bin/ln /bin/cp" everything will be back
>to normal.  Similarly, if you execute "mv /bin/cp /usr/lib/sendmail", you
>haven't created sendmail.
>
>Just because the authors of smail elected to call a link to their program by
>the name "sendmail", doesn't make it become sendmail. It's still smail.
>It's fine to aspire to greatness, but aspirations and reality aren't
>necessarily the same.

Hmmmm... And here I was thinking that the smail3 implementors offered the 
option (note: option) of linking their program to the name "sendmail" just
to humor crufty scripts, mailreaders, newsreaders, etc. that have the name
hard-coded from the days of the dinosaur which once went by the name.

Of course, once all the hard-coded cruft goes away, the link can be severed,
and the name "sendmail" will just pass away into an unpleasant memory...

>>I DO have a /usr/spool/smail directory AND a /usr/lib/smail directory,
>                        ^^^^^                          ^^^^^
>These are dead giveaways that you have smail and not sendmail.
>
>>but my binary is sendmail which lives in /usr/bin/sendmail.  In the
>
>sendmail is usually installed as /usr/lib/sendmail or /usr/sbin/sendmail
>(it's unlikely that you have a /usr/sbin on a 3B1, unless somebody made one;
>it's not standard under SVR2.2). sendmail usually uses /usr/spool/mqueue
>for queued mail files (/var/spool/mqueue recently). sendmail is also
>usually linked to programs named newaliases and mailq (and possibly
>others). sendmail requires a configuration file, usually located in
>/etc/sendmail.cf (possibly /usr/lib/sendmail.cf for old versions).
>If none of this sounds familiar, you almost certainly don't have sendmail.
>
>The other dead giveaway was your reference to ``version 3.1''. It is
>*extremely* unlikely that you have version 3.1 of sendmail, since a) it
>would be horribly ancient, and b) it was probably never released outside of
>UCB (the earliest one I've seen on a 3B1 was version 4.12). Current releases
>of sendmail are 5.67 (production version) and 6.5 (now in alpha test (may
>well be 6.6 or later by the time you read this)).
>
>On the other hand there have been several versions of smail. smail 3 was
>also known as smail 2.5. There is also a completely different smail 3.x
>which is currently somewhere around 3.1.27.1 (no doubt several smail fans
>which rush to provide different numbers). The latest version of smail, still
>in development is, paradoxically, smail 2.7.  

Oh, really? Has the smail3.1 dev team recently been kidnapped by sendmail 
terrorists while working on 3.1.29?

Smail2.7 and smail3.1 have nothing to do with each other, Mr. Lilly, and I've
seen no indication that smail3.1 development has stopped.

>Don't try to make sense of any
>of the version numbers in this paragraph; it could be hazardous to your
>mental health.

That's a laugh. Let's see, sendmail is either /usr/lib/sendmail or 
/usr/sbin/sendmail, spools files in either /usr/spool/mqueue or 
/var/spool/mqueue, has a config file either in /etc/sendmail.cf or
/usr/lib/sendmail.cf, and its current version number is 5.67, 6.5 or 6.6
(take your pick) -- unless it's IDA or KJS or Sun's port for SunOS 4.1, 
which has also been picked up by many SysVr4 ports, and announces itself as 
version "SMI-4.1" -- and yet you have the chutzpah to claim that trying to 
make sense of smail3's version numbering (which you didn't even get right) is 
hazardous to one's mental health? Talk about a double standard...

>I still stand by my original advice: get the sendmail binary for the 3b1
>which is available from the osu-cis or uunet archives (and other places) or
>get the UIUC/IDA sendmail sources and compile them.  What you have now
>(regardless of what it is called) is clearly not working satisfactorily for
>you, else you would not have posted. 

Care to estimate the ratio of "I can't get sendmail to work properly" versus 
"I can't get smail3 to work properly" posts to the Net, Mr. Lilly? By your 
own highly-questionable measure -- calls for net.help -- I'd be willing to bet 
that smail3 is clearly a superior package. 

>It's time to junk it and put something
>useful in its place (unless you enjoy the challenge of dealing with your
>ongoing mail problems). Of course, you're free to do as you please, but you
>asked for advice, and I've given mine, along with justification for my
>position. Good luck to you, whatever you choose to do.

The poster asked for advice on a package that was quite clearly smail3, Mr.
Lilly, as you yourself acknowledged early on in the exchange. The poster's 
initial confusion over whether the program was "sendmail" or "smail", and if 
the latter, which of the multiple "smail" packages, does not, IMHO, warrant 
the instigation of a religious war by such a biased sendmail partisan.

However, if you actually WANT a religious war, I'm sure there are plenty here 
who are more than willing to oblige you...

Note: I've had smail3 running on my 3B1 for about two years, doing SMTP just
fine with my Sun (also running smail3), after "junking" (to use your charming
term) the non-functional sendmail that came with the 3B1's TCP/IP package. So 
I know from firsthand experience that smail3 runs fine on the box, if ported 
and configured properly.

------------------------------------------------------------------------------
kevin@cfc.com 		  	  | Kevin Darcy, Unix Systems Administrator
...heifetz!cfctech!kevin 	  | Technical Services (CFC)
Voice: (313) 759-7140 		  | Chrysler Corporation
Fax:   (313) 758-8173 		  | 25999 Lawrence Ave, Center Line, MI 48015
------------------------------------------------------------------------------
Newsgroups: comp.sys.3b1,comp.mail.misc