jbayer@ispi.UUCP (Jonathan Bayer) (01/18/89)
Hello netlanders, I would like to totally replace the standard Xenix mail system. Currently I have smail running, with a few kludges in order to let it work with Xenix. What I need are copies of the local-transport-agents (mail and mailx) and/or definitions of what they do. I want to get rid of the execmail program as well as all the other unexplained stuff that SCO supplies. UUCP currently calls rmail (linked to smail) which then calls lmail. lmail is the first program I want to replace. I have received a copy of an lmail replacement from Jon Zeeff. It looks good, but I do want some more input since the comments state that it has not been fully checked out. The mailx program (known as mail on SCO systems) seems to call execmail. I assume that execmail is the local transport agent. This is the second program I want to replace (mailx). I feel that mailx should call either lmail or rmail, depending on where the mail is going. This would eliminate all calls to execmail, leaving a System V equivilent system. JB -- Jonathan Bayer Beware: The light at the end of the Intelligent Software Products, Inc. tunnel may be an oncoming dragon 19 Virginia Ave. ...uunet!ispi!jbayer Rockville Centre, NY 11570 (516) 766-2867 jbayer@ispi
ccs@lazlo.UUCP (Clifford C. Skolnick) (01/18/89)
In article <417@ispi.UUCP> jbayer@ispi.UUCP (Jonathan Bayer) writes: > [Discusion of Xenix mail system and desire to replace] >...I have received a >copy of an lmail replacement from Jon Zeeff. It looks good, but I do >want some more input since the comments state that it has not been fully >checked out. I checked it out, It looked secure except for two things. I check that in order for the program to send mail to a program, two things are checked. 1) the program specified is a full path name 2) the user being mailed to owns the file directing transfer to a program. Here are the diffs to the version posted to the net: -----Cut Here----- #!/bin/sh # shar: Shell Archiver (v1.22) # # Run the following text with /bin/sh to create: # lmail.diff # sed 's/^X//' << 'SHAR_EOF' > lmail.diff && X345a346,349 X> if (statbuf.st_uid!=pwd->pw_uid) { X> fclose(in_file); X> continue; X> } X366a371,374 X> if (statbuf.st_uid!=pwd->pw_uid) { X> fclose(in_file); X> continue; X> } X480a489,492 X> if (dest[1]!='/') { X> (void) fprintf(stderr, "\nCan only pipe to a full path name.\n",dest); X> return(8); X> } SHAR_EOF chmod 0644 lmail.diff || echo "restore of lmail.diff fails" exit 0 -----cut here----- >-- >Jonathan Bayer Beware: The light at the end of the >Intelligent Software Products, Inc. tunnel may be an oncoming dragon >19 Virginia Ave. ...uunet!ispi!jbayer >Rockville Centre, NY 11570 (516) 766-2867 jbayer@ispi -- Cliff Skolnick (ccs@lazlo)| "You told me time makes it easy, but you never Phone: (716) 427-8046 | told me time stands still" - Gary Numan TCP/IP: 44.68.0.195 | ...!rutgers!rochester!ritcv!ritcsh!sabin! lazlo!ccs ccs@lazlo.n1dph.ampr.org| \!kodak!pcid!gizzmo!/
tif@cpe.UUCP (01/19/89)
Written 1:05 pm Jan 17, 1989 by ispi.UUCP!jbayer in cpe:comp.unix.xenix > I would like to totally replace the standard Xenix mail system. >Currently I have smail running, with a few kludges in order to let it >work with Xenix. What I need are copies of the local-transport-agents >(mail and mailx) and/or definitions of what they do. I want to get rid >of the execmail program as well as all the other unexplained stuff that >SCO supplies. The purpose for all the other unexplained stuff has to do with the networking implemented by Microsoft (micnet). It also allows some pretty powerful aliasing. I'm a bit defensive of anything that sounds like criticisms of micnet because it works and most people are too set in their ways to try it. There are actually no users on the machine which answers the phone as "cpe." All the users are scattered on several different machines which all talk to each other by micnet. Micnet isn't transparent or anything fancy but it works better than UUCP for tightly connected systems. (It is transparent as far as mail paths go.) Paul Chamberlain Computer Product Engineering, Tandy Corp. {killer | texbell}!cpe!tif
jtc@tessera.UUCP (J.T. Conklin) (01/19/89)
[ followups redirected to comp.unix.xenix ] In article <417@ispi.UUCP> jbayer@ispi.UUCP (Jonathan Bayer) writes: >Hello netlanders, > > I would like to totally replace the standard Xenix mail system. >Currently I have smail running, with a few kludges in order to let it >work with Xenix. What I need are copies of the local-transport-agents >(mail and mailx) and/or definitions of what they do. I want to get rid >of the execmail program as well as all the other unexplained stuff that >SCO supplies. I dumped the Xenix mail system about one year ago and never regretted the decision. Since that date, my mail system has gone through several stages. It's still not perfect, but it is much better than the stock system. This is a brief history of my mail system. It is not a "how to" guide. If anyone wants details, mail me and I'll do my best to help. 1. Replaced execmail with sendmail. Execmail is basically a non-configurable subset of sendmail. I grabbed sendmail from an archive site, whipped up a sendmail.cf file, and replaced execmail with sendmail. This change didn't add any extra functionality over SCO's mail, but I felt a bit happier that I was in control. (source code, etc) 2. Used smail as a back end to sendmail. 3. Totally removed SCO mail. I decided that _I_ was interested in SysV mail behavior even if SCO wasn't. I wrote a new mail delivery program which used /usr/mail as spool directory and SysV style locks. Because the spool directory was changed, login couldn't notify me of new mail, so I wrote my own login too! [ Bug waiting to happen department: What is bound to happen sooner or later when two Xenix machines on a network share the /usr/spool/mail directory when they don't also share /tmp? ] I now use mush and elm as my user interface. (mush is linked to mail) I am working on a port of the BSD Mail mailer, but not enough time. Moving the spool directory to /usr/mail and using SysV style locks has not been totally without problems. For example, the ELM configuration script discovered I was on a Xenix box and blindly assumed I was using that standard Xenix methodology. It didn't even ask for confirmation! Good Luck, --jtc -- J.T. Conklin ...!{ubc-cs,uunet}!van-bc!tessera!jtc
jim@tiamat.FSC.COM (Jim O'Connor) (01/22/89)
In article <6800065@cpe>, tif@cpe.UUCP writes: > > The purpose for all the other unexplained stuff has to do with > the networking implemented by Microsoft (micnet). It also allows > some pretty powerful aliasing. I'm glad to see someone else uses micnet. I was beginning to think I was the only one after receiving many "mic-what?" responses every time I mentioned it. Actaully, the aliasing is part of the mail system, which can be used independently from micnet if you want to. > I'm a bit defensive of anything that sounds like criticisms of micnet > because it works and most people are too set in their ways to try it. Amen. > There are actually no users on the machine which answers the phone as > "cpe." All the users are scattered on several different machines > which all talk to each other by micnet. Micnet isn't transparent > or anything fancy but it works better than UUCP for tightly connected > systems. (It is transparent as far as mail paths go.) It's also transparent as far as the topology of the network goes. The command $ rcp myfile siteA:/tmp/myfile will always work no matter how you've got connections made between here and siteA. Despite all the things I like about it, there are some legitimate short-falls. 1) - our systems usually report < 50% line utilization, e.g. ~ 400cps on a dedicated 9600 baud line, with out retransmissions. Apparently, there is some significant overhead. 2) - process order; i.e. jobs are not processed in the order they are received. They are not processed in any consistent order that I can detect. 3) - start up time; worst case time between when something is submited and when it starts to be transfered is two minutes. This seems high for a dedicated line connection. 4) - log messages and diagnostics; with the amount and type of traffic I've got running on micnet, I would really like to see better log messages and diagnostics. These are usually the reasons uucp proponents give for why I should use uucp instead of micnet, but I still think micnet wins in tightly coupled situations, especially when some of your machines are running Altos 3.4 Xenix, or earlier, which has one the least capable uucp's I've ever seen. Next weekend we will be completely re-wiring out micnet network to use a different machine as the center node in our star topology, and because we use micnet, the users should never notice. --jim ------------- James B. O'Connor jim@FSC.COM Filtration Sciences Corporation 615/821-4022 x. 651
tif@cpe.UUCP (01/22/89)
Written 4:39 pm Jan 20, 1989 by ateng.UUCP!chip in cpe:comp.unix.xenix >According to tif@cpe.UUCP: >>because it works and most people are too set in their ways to try it. >... >As soon as I discovered that, I switched to UUCP. If MICNET is careless in >copying files, what else is carelessly written? Best not to find out the >hard way. I rest my case. Paul Chamberlain Computer Product Engineering, Tandy Corp. {killer | texbell}!cpe!tif
jbayer@ispi.UUCP (Jonathan Bayer) (01/22/89)
In article <295@tessera.UUCP> jtc@tessera.UUCP (J.T. Conklin) writes: >[ followups redirected to comp.unix.xenix ] > > I now use mush and elm as my user interface. (mush is linked to mail) > I am working on a port of the BSD Mail mailer, but not enough time. I have been able to port the BSD Mail mailer to Xenix. I am currently testing it out, and will be able to post diffs for it in the near future. I would like a few people who would like to test it out for me. JB -- Jonathan Bayer Beware: The light at the end of the Intelligent Software Products, Inc. tunnel may be an oncoming dragon 19 Virginia Ave. ...uunet!ispi!jbayer Rockville Centre, NY 11570 (516) 766-2867 jbayer@ispi
chip@ateng.ateng.com (Chip Salzenberg) (01/24/89)
According to jbayer@ispi.UUCP (Jonathan Bayer): > I would like to totally replace the standard Xenix mail system. >Currently I have smail running [...] > > UUCP currently calls rmail (linked to smail) which then calls >lmail. lmail is the first program I want to replace. I have received a >copy of an lmail replacement from Jon Zeeff. It looks good, but I do >want some more input since the comments state that it has not been fully >checked out. Jon Zeeff's lmail program does work, but it lacks flexibility. (An aside: It is ironic that Jon denigrates Smail 3 for lack of flexibility, while he publishes a mail program with only minimal functionality.) My "deliver" program would probably be a better choice: System-wide and user-specific delivery files control the delivery of each message. Delivery files are shell scripts, so anything you can describe in a shell script can be used to control delivery. Security has been carefully addressed. Some specific applications so far: Bounce mail to work or home systems based on time of day and day of week. Allow for common misspellings of user names. Save mail in different mailboxes based on subject line, sender, etc. Toss mail from particularly irritating people. The deliver program is available in the comp.sources.unix archives. The current patchlevel is six -- be sure to get all six patches. Incidentally, it's a plug-in replacement for the /usr/lib/mail/mail.local program which is a standard part of the Xenix mail system. You Xenix users who don't wish to throw away the Xenix mail system can use deliver without disturbing your current setup. -- Chip Salzenberg <chip@ateng.com> or <uunet!ateng!chip> A T Engineering Me? Speak for my company? Surely you jest! "It's no good. They're tapping the lines."
chip@ateng.ateng.com (Chip Salzenberg) (01/24/89)
According to jtc@tessera.UUCP (J.T. Conklin): >This is a brief history of my mail system. >1. Replaced execmail with sendmail. >2. Used smail as a back end to sendmail. >3. Totally removed SCO mail. > > [ Bug waiting to happen department: What is bound to happen sooner > or later when two Xenix machines on a network share the /usr/spool/mail > directory when they don't also share /tmp? ] The "deliver" program can be configured to use *both* Xenix and Unix locking schemes. This provides maximal safety in networked environments. > The ELM configuration script discovered I was on a Xenix box > and blindly assumed I was using that standard Xenix methodology. > It didn't even ask for confirmation! If you have a non-standard system, you have to expect such problems. -- Chip Salzenberg <chip@ateng.com> or <uunet!ateng!chip> A T Engineering Me? Speak for my company? Surely you jest! "It's no good. They're tapping the lines."
chip@ateng.ateng.com (Chip Salzenberg) (01/24/89)
According to tif@cpe.UUCP: >According to chip@ateng.ateng.com: >>According to tif@cpe.UUCP: >>>because it works and most people are too set in their ways to try it. >> >>As soon as I discovered that, I switched to UUCP. If MICNET is careless in >>copying files, what else is carelessly written? Best not to find out the >>hard way. > >I rest my case. Now, wait a minute. I *tried* Micnet. I had a working Micnet network with three hosts. I then switched to UUCP because of Micnet's inferiority to UUCP in several key areas. I wasn't "set in my ways"; I simply evaluated Micnet and found it wanting. -- Chip Salzenberg <chip@ateng.com> or <uunet!ateng!chip> A T Engineering Me? Speak for my company? Surely you jest! "It's no good. They're tapping the lines."
chip@vector.UUCP (Chip Rosenthal) (01/24/89)
In article <295@tessera.UUCP> jtc@tessera.UUCP (J.T. Conklin) writes: >In article <417@ispi.UUCP> jbayer@ispi.UUCP (Jonathan Bayer) writes: >> I would like to totally replace the standard Xenix mail system. > >1. Replaced execmail with sendmail. >2. Used smail as a back end to sendmail. >3. Totally removed SCO mail. I've also been thinking about dumping SCO's mail package ... but I've been thinking about a different approach. I've heard so many horror stories about "sendmail" that I want to avoid it. Instead, I was thinking about using "smail" and Chip Salzenberg's recently posted deliver program, and do all my fromming/aliasing with smail (and possibly deliver). Therefore, I envison something like: Elm -----. .----------> uux | | uuxqt -----+-----> smail,rmail -----+ | | recmail -----' `----------> deliver Where Elm, recmail, and uuxqt are the entry points into mail for users, news, and uucp respectively; and uux and deliver are the delivery agents for uucp and local mail respectively. I've also recently brought up TCP/IP here, and would possibly like to add SMTP to this at some point. Hopefully, the coming-reeel-soon-now version of smail will support the hooks for this. Hey Chip ... what does your mail setup look like? -- Chip Rosenthal chip@vector.UUCP | Choke me in the shallow water Dallas Semiconductor 214-450-5337 | before I get too deep.
jim@tiamat.FSC.COM (Jim O'Connor) (01/26/89)
In article <694@vector.UUCP>, chip@vector.UUCP (Chip Rosenthal) writes: > > I envison something like: > > Elm -----. .----------> uux > | | > uuxqt -----+-----> smail,rmail -----+ > | | > recmail -----' `----------> deliver > > Where Elm, recmail, and uuxqt are the entry points into mail for users, > news, and uucp respectively; and uux and deliver are the delivery agents > for uucp and local mail respectively. This setup should prove to be very useful and robust, and since you would have the source for nearly all of it (probably not the uucp stuff), you would have complete control over what it does. The fact that all the behavior of the SCO mail system is not documented is my biggest problem with it. > I've also recently brought up TCP/IP here, and would possibly like to add > SMTP to this at some point. Hopefully, the coming-reeel-soon-now version > of smail will support the hooks for this. smail3 supports everthing. period. If it's not in the default configuration, you can add it using run-time configuration files. It took only five minutes to write the entries for sending mail across micnet links, which was not in the default configuration. With all of the flexibilty built-in to smail3, you can do anything you want to with your mail. > Hey Chip ... what does your mail setup look like? I would bet it either looks like the picture you drew, or something similar with smail3 in the middle. --jim ------------- James B. O'Connor jim@FSC.COM Filtration Sciences Corporation 615/821-4022 x. 651
chip@ateng.ateng.com (Chip Salzenberg) (02/01/89)
In article <694@vector.UUCP>, chip@vector.UUCP (Chip Rosenthal) writes: > Hey Chip ... what does your mail setup look like? /usr/bin/mail -----> execm ---. | Elm -----. | .----------> (user mailboxes) | v | uuxqt -----+-----> smail,rmail -----+----------> uux | | recmail -----' `----------> deliver Here, /usr/bin/mail is the standard SCO program, and execm is my replacement for /usr/lib/mail/execmail that parses options and runs Smail. (My Xenix patches include the Smail 2 version of execm. Smail 3 will be distributed with execm included. Note that execm won't help unless /usr/lib/mail/mailrc contains the command "set execmail". I configure Elm to think that it has sendmail, which Smail 3 emulates. (One of the ten (!) links to /usr/bin/smail is /usr/lib/sendmail.) Smail 3 usually writes directly to user mailboxes. I, personally, have a .forward file that says "|/usr/bin/deliver chip", so my mail is handled by deliver. I could configure Smail 3 to use deliver for all local mail, and it would take about thirty seconds; but why? Smail 3's aliasing is flexible enough for most needs (except mine :-)). -- Chip Salzenberg <chip@ateng.com> or <uunet!ateng!chip> A T Engineering Me? Speak for my company? Surely you jest! "It's no good. They're tapping the lines."
tif@cpe.UUCP (02/02/89)
Gee, it's still growing, I better send it before it gets any longer ... Written 4:04 pm Jan 31, 1989 by ateng.UUCP!chip in cpe:comp.unix.xenix >In article <694@vector.UUCP>, chip@vector.UUCP (Chip Rosenthal) writes: >> Hey Chip ... what does your mail setup look like? > >/usr/bin/mail -----> execm ---. > | > Elm -----. | .----------> (user mailboxes) > | v | > uuxqt -----+-----> smail,rmail -----+----------> uux > | | > recmail -----' `----------> deliver Hey Chip ... (Sarcasm for humor only, i.e. :-) ) (Firstly, I'm not familiar with the features of deliver) Unless deliver is real smart, that won't cover ALL the Xenix options. I realize that there are only two of us Micnet fans out here, but I thought I'd mention that Micnet adds a couple of quirks to this: There can be a machine whose only access to uucp is via Micnet. Therefore, the outgoing mail has to be sent down Micnet to get to the uucp machine where it is actually uux'ed. Also, his incoming mail has to be sent down Micnet to his machine where it actually gets stuffed in his mailbox. In essence, the right hand side of the drawing has two more branches. One which (eventually) boils down to a "remote ... uux" and another which is a "remote ... diddle-with-mailbox." I'm not sure if "deliver" can handle these possibilities or not. The biggest obstacle that I can see is that (ideally) the uucp machine on the network should be identified by the "uucp:" line in the maliases file (although I see no reason it couldn't be handled through a different RUNTIME determination method). Both of us (remember us two Micnet fans) came up with a two part solution. (Honestly, I can't remember right now why I needed a two part solution.) One for a micnet only machine, and one for a micnet/uucp machine. Anyway, for the micnet only machine, the right hand side of the diagram, in my system, is replaced by the original /usr/lib/mail/execmail (moved to execmail.x). It has the smarts to find the real uucp machine and send the mail there (it actually goes through smail again on that machine). The philosophy was to leave as much of the existing system intact as possible. It's not as elegant as I'd like but it works. A single solution that is no less efficient than the original XENIX mail system would be best. Any better ideas? (And, I'm sure you all know how it ruffles your feathers for someone to "solve" your problem by saying "Well, don't do that." i.e. DON'T tell me to trash micnet.) Now, did I just waste my time discussing a problem that deliver solves? Paul Chamberlain Computer Product Engineering, Tandy Corp. {killer | texbell}!cpe!tif (Sometimes) my writings (ASCII) resemble LISP (lots of parentheses) but at least there are no mispellings, typos, or missing words (not intended to be directed at anyone in particular, just my soapbox).
chip@vector.UUCP (Chip Rosenthal) (02/02/89)
In article <1989Jan31.170500.19635@ateng.ateng.com> chip@ateng.ateng.com (Chip Salzenberg) writes: >In article <694@vector.UUCP>, chip@vector.UUCP (Chip Rosenthal) writes: >> Hey Chip ... what does your mail setup look like? > > /usr/bin/mail -----> execm ---. > | > Elm -----. | .----------> (user mailboxes) > | v | > uuxqt -----+-----> smail,rmail -----+----------> uux > | | > recmail -----' `----------> deliver > Amazing coincidence. About 12 hours before this message appeared, I brought up the "deliver" program and replaced the SCO XENIX mail system as I had proposed in the parent article. Things work exactly as I had hoped. The difference between the above diagram and my original diagram is due to "smail". With smail 2.5, "deliver" is needed for delivery to user mailboxes and "|command" type aliases. The result is a very lean and flexible mail system. I'm very happy with it. Yes, micnet has been lost -- but no great loss as far as I'm concerned. However, you could probably hack "deliver" to recognize micnet sites and feed the message to "/usr/lib/mail/mail.mn". I did a similar thing: I hacked my deliver sys file to recognize "user%site" addresses for internal machines on our ethernet. It looks to me when the really-it-is-going-to-be-here-someday version of smail is out, "deliver" could be dropped from its primary position in the mail system. (Just as my changes dropped /usr/bin/mail -- but left it available for use.) If anybody out there wants to try it, I setup the smail 2.5 "defs.h" file as: #define DELIVER "/usr/lib/mail/deliver" #define LMAIL(frm,sys) "%s -r '%s'",DELIVER,frm Then things (Rnmail, control.c, Elm, etc.) should be setup to mail through smail rather than /usr/bin/mail. (The cost of not doing this is a couple of arg parses and fork/exec's.) I put the path "/bin/smail" into a bunch of places, but I think I'm going to go back and bring up the "svbinmail" program (which is distributed with smail 2.5) as "/bin/mail". >I configure Elm to think that it has sendmail, which Smail 3 emulates. >(One of the ten (!) links to /usr/bin/smail is /usr/lib/sendmail.) OK ... /bin/smail, /bin/rmail, /usr/lib/sendmail ... What are the rest? -- Chip Rosenthal chip@vector.UUCP | Choke me in the shallow water Dallas Semiconductor 214-450-5337 | before I get too deep.
karl@ddsw1.MCS.COM (Karl Denninger) (02/03/89)
In article <132500003@cpe> tif@cpe.UUCP writes: > >Gee, it's still growing, I better send it before it gets any longer ... >Both of us (remember us two Micnet fans) came up with a two part solution. >(Honestly, I can't remember right now why I needed a two part solution.) >One for a micnet only machine, and one for a micnet/uucp machine. .... >It's not as elegant as I'd like but it works. A single solution that >is no less efficient than the original XENIX mail system would be best. >Any better ideas? Well, having smail3 here, and LOVING it, I can say this: We modified it to handle a completely different transport mechanism AND routing requirements in about two hours. It drops right in place of "execmail" (I linked it to /bin/rmail & /bin/smail too for good measure). Now, if someone knows how micnet works internally (ie: what it delivers mail to for resolution, and how a process would go about setting up or queueing outgoing requests for it) then I'll just have to hack up another director entry for smail3 to handle that as well. Anyone want to spill the beans to my mailbox? If so, everyone can have a fully integrated solution to the problem. As it is, I've got everything except MICNET working great; micnet we don't use here internally... -- Karl Denninger (karl@ddsw1.MCS.COM, ddsw1!karl) Data: [+1 312 566-8912], Voice: [+1 312 566-8910] Macro Computer Solutions, Inc. "Quality solutions at a fair price"
jim@tiamat.fsc.com (Jim O'Connor) (02/03/89)
In article <132500003@cpe>, tif@cpe.UUCP writes: > > I realize that there are only two of us Micnet fans out here, but I > thought I'd mention that Micnet adds a couple of quirks to this: > > There can be a machine whose only access to uucp is via Micnet. > Therefore, the outgoing mail has to be sent down Micnet to get > to the uucp machine where it is actually uux'ed. Also, his > incoming mail has to be sent down Micnet to his machine where > it actually gets stuffed in his mailbox. The first part of this (i.e. non-uucp micnet machine needing to send mail to another micnet site or a remote uucp site) is most easily handled by using #define RMAIL(flags,from,sys) "remote -u %s - %s rmail",from,sys /* */ instead of #define RMAIL(flags,from,sys) "%s %s - %s!rmail",UUX,flags,sys /* */ in the "defs.h" file of smail2.5, which causes the micnet only machine to use "remote" rather than "uux" for delivering non-local mail. The only other thing you need to do is to install a minimal "paths" file which only has paths to your micnet neighbors and a "smart-host" entry to your machine that has a more complete paths file and runs uucp. The "smart-host" will then take care of figuring out an address and delivering by uucp, if necessary. This approach has (IMHO) the great advantage of only having to store and maintain the paths file on the uucp machine. Leave LMAIL defined as "execmail.x", which does a good job with local mail, unless you want to know what's going on, in which case I recommend deliver. The other part of the problem is a little more difficult (i.e. machine which uses both uucp and micnet to deliver remote mail) since smail2.5 only knows about one remote delivery command, i.e. whatever is defined by RMAIL. The situation can be handled (without getting into the smail2.5 source) by using #define RMAIL(flags,from,sys) "delagent -f%s -un%s -s%s ",from,flags,sys /* */ where delagent is a program I wrote which looks up the name "sys" in a file, and if found, uses the command listed there as the delivery method. E.g. the entries DEFAULT /usr/bin/uux - -a%F -%U %S!rmail uunet /usr/bin/uux - -a%F -r %S!rmail fsc2086 /usr/bin/remote - -u %F %S rmail fsc1086 /usr/bin/remote - -u %F %S rmail would cause mail to "fsc2086" or "fsc1086" to delivered with "remote", mail to "uunet" to be delivered via "uux" with the spool option on, and mail to any other system (the DEFAULT entry) to be delivered via "uux" with whatever options were specified as an argument to delagent. The %F, %S, and %U tokens are replaced by the strings supplied with the -f, -s, and -u arguments. This not only adds support for micnet, but adds extra flexibilty (at the price of extra complexity) to the entire system. > Both of us (remember us two Micnet fans) came up with a two part solution. > (Honestly, I can't remember right now why I needed a two part solution.) > One for a micnet only machine, and one for a micnet/uucp machine. I admit, I'm the other micnet fan. The reasoning behind a two part solution is that the micnet/uucp solution is not very pretty, and there is no need to burden the micnet only machine with it. There is no reason, howvever, why my "delagent" micnet/uucp setup could not be used on a micnet only machine (provided the micnet only machine's paths file directs all uucp mail addresses through a machine whcih can do uucp). > It's not as elegant as I'd like but it works. A single solution that > is no less efficient than the original XENIX mail system would be best. Smail3. As long as you don't define efficiency in terms of the size of the binary file, smail3 is definitely going to be (it is, here) the nicest way to replace (read "enhance") the regular Xenix mailing system. I have written the necessary entries to coax smail3 into delivery mail via the "remote" command, so micnet support for it will be available. In the meantime, though, my "delagent.c" addition to smail2.5 is available (there's one more thing it needs to be able to do, but I can fix that before I send it out), for anyone wanting to set things up as I've described. I'll admit, it's not pretty, but it has worked reliably for some time now. --jim
jim@tiamat.fsc.com (Jim O'Connor) (02/03/89)
In article <698@vector.UUCP>, chip@vector.UUCP (Chip Rosenthal) writes: > > The result is a very lean and flexible mail system. I'm very happy with > it. Yes, micnet has been lost -- but no great loss as far as I'm concerned. > However, you could probably hack "deliver" to recognize micnet sites and > feed the message to "/usr/lib/mail/mail.mn". I did a similar thing: I > hacked my deliver sys file to recognize "user%site" addresses for internal > machines on our ethernet. See my other posting for how to set up smail2.5 to delever mail over micnet and still be able to use deliver without having to hack much of anything. > It looks to me when the really-it-is-going-to-be-here-someday version > of smail is out, "deliver" could be dropped from its primary position > in the mail system. (Just as my changes dropped /usr/bin/mail -- but > left it available for use.) Smail3 will let you replace everything if you want to (except, of course, the user agents and delivery commands like "uux"). > Then things (Rnmail, control.c, Elm, etc.) should be setup to mail through > smail rather than /usr/bin/mail. Even without deliver, if you have smail, you should eb able to do this. > >I configure Elm to think that it has sendmail, which Smail 3 emulates. > >(One of the ten (!) links to /usr/bin/smail is /usr/lib/sendmail.) > > OK ... /bin/smail, /bin/rmail, /usr/lib/sendmail ... > What are the rest? -r-sr-xr-x 8 root csd 249286 Jan 27 19:20 /usr2/bin/mailq -r-sr-xr-x 8 root csd 249286 Jan 27 19:20 /usr2/bin/optto -r-sr-xr-x 8 root csd 249286 Jan 27 19:20 /usr2/bin/pathto -r-sr-xr-x 8 root csd 249286 Jan 27 19:20 /usr2/bin/rsmtp -r-sr-xr-x 8 root csd 249286 Jan 27 19:20 /usr2/bin/runq -r-sr-xr-x 8 root csd 249286 Jan 27 19:20 /usr2/bin/smail -r-sr-xr-x 8 root csd 249286 Jan 27 19:20 /usr2/bin/smtpd -r-sr-xr-x 8 root csd 249286 Jan 27 19:20 /usr2/bin/uupath /usr2 is on a different filesystem than /usr, so these are linked separately from the other three. --jim
jtc@tessera.UUCP (J.T. Conklin) (02/03/89)
In article <368@tiamat.fsc.com> jim@tiamat.fsc.com (Jim O'Connor) writes: >In article <698@vector.UUCP>, chip@vector.UUCP (Chip Rosenthal) writes: >> It looks to me when the really-it-is-going-to-be-here-someday version >> of smail is out, "deliver" could be dropped from its primary position >> in the mail system. (Just as my changes dropped /usr/bin/mail -- but >> left it available for use.) > >Smail3 will let you replace everything if you want to (except, of course, >the user agents and delivery commands like "uux"). But when will smail3 be availiable to the rest of us? I've been waiting for a long time, and am willing to wait longer -- I just want to know how long I'm going to have to wait. --jtc -- J.T. Conklin ...!{ubc-cs,uunet}!van-bc!tessera!jtc
chip@ateng.ateng.com (Chip Salzenberg) (02/12/89)
According to tif@cpe.UUCP: >According to chip@ateng.uucp (Chip Salzenberg): >>In article <694@vector.UUCP>, chip@vector.UUCP (Chip Rosenthal) writes: >>> Hey Chip ... what does your mail setup look like? >> >>/usr/bin/mail -----> execm ---. >> | >> Elm -----. | .----------> (user mailboxes) >> | v | >> uuxqt -----+-----> smail,rmail -----+----------> uux >> | | >> recmail -----' `----------> deliver > >Hey Chip ... (Sarcasm for humor only, i.e. :-) ) >(Firstly, I'm not familiar with the features of deliver) >Unless deliver is real smart, that won't cover ALL the Xenix options. [mention of Micnet deleted] Deliver can handle just about anything. This is because its "delivery files" are shell scripts. Therefore, anything you can express in a shell script can be used to control mail messages. For example, Micnet could be handled by the system delivery file. Assume that "fred" and "joe" are remote users on machines "fredmach" and "joemach" respectively: # system delivery file # Use Micnet for fred and joe for u do machine= case "$u" in fred) machine=fredmach ;; joe) machine=joemach ;; *) echo $u; continue ;; esac if [ "$machine" ] then cat $HEADER $BODY | remote - $machine rmail $u fi done The Micnet-only machines would have a similar delivery file, but with an additional case "*!*" to handle UUCP addresses. Incidentally, the hostname is available to delivery files in the environment variable $HOST (or is it $HOSTNAME?), so all machines can have identical system delivery files with behavior that varies according to the host name. >Anyway, for the micnet only machine, the right hand side of the diagram, >in my system, is replaced by the original /usr/lib/mail/execmail (moved >to execmail.x). It has the smarts to find the real uucp machine and send >the mail there (it actually goes through smail again on that machine). The >philosophy was to leave as much of the existing system intact as possible. Well, that's fine. It is not, however, necessary. Deliver is flexible enough to handle a mixed Micnet/UUCP network. Combined with Smail 3 it's just about all I can imagine needing, short of mind-reading. >Now, did I just waste my time discussing a problem that deliver solves? No waste. It's an interesting problem. Perhaps I can come up with a more elegant solution if I think about it. One thing that will help is my plan to add a second system delivery file, one that is executed after the user delivery files but before actual delivery takes place. This would permit user delivery files to output plain addresses, and then have them processed just like incoming addresses. Also, as separate programs, I'm planning to write an alias file lookup program and a message header parser. Currently I make do with grep, but it's not sufficient to handle multi-line header fields. Such is life in the big city. -- Chip Salzenberg <chip@ateng.com> or <uunet!ateng!chip> A T Engineering Me? Speak for my company? Surely you jest! "It's no good. They're tapping the lines."
chip@ateng.ateng.com (Chip Salzenberg) (02/12/89)
According to chip@vector.UUCP (Chip Rosenthal): >With smail 2.5, "deliver" is needed for delivery to >user mailboxes and "|command" type aliases. The need for "|command" processing -- with security! -- was my original excuse to begin writing deliver. The project, well, grew from there. >The result is a very lean and flexible mail system. I'm very happy with >it. Yes, micnet has been lost -- but no great loss as far as I'm concerned. >However, you could probably hack "deliver" to recognize micnet sites and >feed the message to "/usr/lib/mail/mail.mn". I did a similar thing: I >hacked my deliver sys file to recognize "user%site" addresses for internal >machines on our ethernet. An interesting approach. It could work for Micnet too. In my previous article I described another approach, one driven by username instead of by address syntax. Of course, the approaches could be combined. >It looks to me when the really-it-is-going-to-be-here-someday version >of smail is out, "deliver" could be dropped from its primary position >in the mail system. (Just as my changes dropped /usr/bin/mail -- but >left it available for use.) The only thing left for deliver to do in my mail system is to (1) vary behavior based on message *content* (as opposed to destination address), and (2) modify message contents, as when forwarding. Smail 3 does the rest. >>(One of the ten (!) links to /usr/bin/smail is /usr/lib/sendmail.) >OK ... /bin/smail, /bin/rmail, /usr/lib/sendmail ... >What are the rest? Here they are, in /usr/local/bin: -r-sr-xr-t 10 root 265702 Jan 25 11:30 mailq -r-sr-xr-t 10 root 265702 Jan 25 11:30 optto -r-sr-xr-t 10 root 265702 Jan 25 11:30 pathto -r-sr-xr-t 10 root 265702 Jan 25 11:30 rsmtp -r-sr-xr-t 10 root 265702 Jan 25 11:30 runq -r-sr-xr-t 10 root 265702 Jan 25 11:30 smail -r-sr-xr-t 10 root 265702 Jan 25 11:30 uupath Of course, /usr/local/bin/smail is redundant, given /usr/bin/smail, but it doesn't hurt anything. The "mailq" and "runq" links are for mail spooling, a feature which I won't need until I do batch SMTP over UUCP -- that will be a real time-saver for uunet, since I'll need to send only a single file for each batch of messages. The "rmstp" link is for when other people send BSMTP to me. The other links provide utility functions. Smail 3 is great... worth the wait, without a doubt. -- Chip Salzenberg <chip@ateng.com> or <uunet!ateng!chip> A T Engineering Me? Speak for my company? Surely you jest! "It's no good. They're tapping the lines."
chip@ateng.ateng.com (Chip Salzenberg) (02/12/89)
According to karl@ddsw1.MCS.COM (Karl Denninger): >Well, having smail3 here, and LOVING it, I can say this: >We modified it to handle a completely different transport mechanism AND >routing requirements in about two hours. It drops right in place of >"execmail" (I linked it to /bin/rmail & /bin/smail too for good measure). Although the options accepted by execmail and Smail3 are *very* similar -- they both seem to imitate Sendmail -- they are not identical. A version of my execm program comes with Smail3; it should be used in place of execmail when you install Smail3. BTW, a version of execm for Smail2 is included in my Smail2 Xenix patches. -- Chip Salzenberg <chip@ateng.com> or <uunet!ateng!chip> A T Engineering Me? Speak for my company? Surely you jest! "It's no good. They're tapping the lines."
chip@ateng.ateng.com (Chip Salzenberg) (02/14/89)
There is one configuration with smail 2.5, deliver and Micnet which hasn't
yet been mentioned here, so I think I'll mention it. Perhaps it will be
acceptable to those who like Micnet.
Deliver was written as a drop-in replacement for /usr/lib/mail/mail.local.
The mail.local program is called by the Xenix execmail program to deliver
local mail. So, how about this:
1. Start with smail 2.5.
2. Apply my Xenix patches and define MICNET. This causes all mail
to be delivered by execmail.x.
3. Make /usr/lib/mail/mail.local a link to /usr/bin/deliver.
This configuration uses deliver for local mail, but uses the normal SCO mail
system for UUCP and Micnet mail delivery. The SCO execmail program (named
execmail.x during the Smail install) unwittingly calls deliver for local
mail.
Incidentally, this is the configuration I used when I first wrote deliver.
(I write deliver before I had Smail 3.)
So, Micnet fans: what's the verdict?
--
Chip Salzenberg <chip@ateng.com> or <uunet!ateng!chip>
A T Engineering Me? Speak for my company? Surely you jest!
"It's no good. They're tapping the lines."tif@cpe.UUCP (02/15/89)
Written 3:42 pm Feb 13, 1989 by ateng.UUCP!chip in cpe:comp.unix.xenix > 1. Start with smail 2.5. > 2. Apply my Xenix patches and define MICNET. This causes all mail > to be delivered by execmail.x. > 3. Make /usr/lib/mail/mail.local a link to /usr/bin/deliver. Replacing mail.local with deliver seems to be an independent decision from installing smail. The goal (at least my goal) was to install smail for its routing intelligence. Although installing /usr/bin/deliver looks like a very flexible thing to do, I don't think it's related to this goal (unless mail.local does something wrong that I'm not aware of). Paul Chamberlain Computer Product Engineering, Tandy Corp. {killer | texbell}!cpe!tif