Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!ucsd!sdd.hp.com!zaphod.mps.ohio-state.edu!ncar!ico!rcd
From: rcd@ico.isc.com (Dick Dunn)
Newsgroups: comp.unix.sysv386
Subject: Re: Getting smail with ISC 2.2 to work
Summary: it can be made to work
Message-ID: <1990Oct23.212357.7968@ico.isc.com>
Date: 23 Oct 90 21:23:57 GMT
References: <34877@cup.portal.com> <105@w3vh.UUCP> <289@cadlab.sublink.ORG> <32@opel.COM>
Organization: Interactive Systems Corporation, Boulder, CO
Lines: 51

johnk@opel.COM (John Kennedy) writes:

> I had given up on getting smail from ISC or smail 2.5 from uunet to
> work with smartmail.  It's encouraging to see so many other failures :-).

> Has anyone actually got this combination to work under ISC 2.2?  Maybe
> we could use some clues.

I played around with smail2.5 straight from uunet to get it to work in
no-sendmail mode on ISC 2.2, which is a V.3.2.  The uunet-distributed
version supports it on V.2, but some conventions have changed between R2
and R3.  Here's how it goes:

    Under V.2, prior to installing smail, rmail and mail were the same
    program, with the rmail invocation used to restrict to delivery.  The
    internal check was for "rmail" or not.  When installing smail, it took
    over the role of rmail, and the old rmail became lmail (local mail).
    The little svbinmail took over the role of old /bin/mail, directing
    to either lmail (the old mail/rmail, to read) or rmail (now nee smail,
    to send).

    Under V.3, rmail is a separate program.  mail and lmail are the same,
    with lmail being the delivery agent, and the internal check is now for
    "lmail" or not.  Thus the svbinmail trick doesn't quite work; it can
    deliver OK, but trying to read, it invokes lmail which complains that
    it wants to send mail.

(Got it?:-)

So I used a slight variant on the hack--svbinmail now invokes either rmail
to send or rdmail (my invented name) to receive.  The new rdmail is a link
to lmail.  This is a one-line change to svbinmail plus some tweaks to the
installation instructions.

You do want to check that you've got things plugged in right before you
turn 'em on--permissions and all.  These guys are a little feisty and they
pass the buck a lot...if somebody passes the buck to the wrong guy, or to
himself, you get much commotion and spraying-about of processes, with very
little actual mail delivered.

While I was at it, I also tweaked the Makefile to strip files and use the
shared C library.

I have seen one bizarre event, though:  Sometimes sending one mail message
to both a local user and a remote user causes a failure message about being
unable to deliver to the local user.  In spite of that, the mail is still
delivered both places correctly (which is why I haven't bashed around
enough to fix it yet).  Anyone seen this?  got a fix?
-- 
Dick Dunn     rcd@ico.isc.com -or- ico!rcd       Boulder, CO   (303)449-2870
   ...Never offend with style when you can offend with substance.