pat@seradg.Dayton.NCR.COM (Patrick Pesch) (10/14/87)
I have just got "smail up on my SCO Xenix system and have a question that somebody out there has probably encounterd. Smail replaces /bin/mail with a small front end called svbinmail (for systems that do not have sendmail). It moves the existing /bin/mail to /bin/lmail, and uses it only when READING mail. /bin/smail and /bin/rmail (linked together) are used when sending mail. My problem is that the smail interface seems pretty primitive, compared to the Xenix mail that was there (mailx derivative). Can smail prompt for "Subject:, CC:", etc... as mailx does? Does anyone know how this could be done without actually adding the features to smail (maybe using the existing mailer as a front end)? Would having "sendmail" help? Thanks in Advance, *** *** ******* ********* **** *** ********* *********** Patrick Pesch ***** *** *** ** *** **** NCR Corporation ****** *** *** *** *** Systems Engineering Retail *** ****** *** ********* Dayton OH *** ***** *** ** *********** *** **** ********* *** **** pat@seradg.Dayton.NCR.COM *** *** ******* *** **** "Standard Employee Disclaimer Applies" - Plato
lyndon@ncc.UUCP (Lyndon Nerenberg) (10/15/87)
I always thought the svbinmail interface was a bit of a crock. Here's what I came up with... 1) Compile smail as per usual, but change defs.h to reflect the paths indicated below. 2) Move /bin/rmail somewhere (we use /etc/local/rmail). 3) Remove /bin/mail and /bin/rmail. 4) Link mailx to /bin/mail 5) Move smail to /bin/rmail This has the effect of making mailx the default UA, and installs smail in it's proper function as the MTA. Note that on most systems mailx uses /bin/rmail for delivery. Make sure your mailx does so also or you'll wonder where your mail is going... Here are the relevent parts of defs.h: #define SMAIL "/bin/rmail" /* location of smail command */ #define HANDLE ALL #define ROUTING ALWAYS /* The above combination is necessary to keep uux from bitching when mail for an alias arrives... */ #define LMAIL(frm,sys) "/etc/local/rmail" /* SV local delivery agent */
billw@killer.UUCP (Bill Wisner) (10/16/87)
pat@seradg.Dayton.NCR.COM (Patrick Pesch): > I have just got "smail up on my SCO Xenix system and have a question > that somebody out there has probably encounterd. Smail replaces > /bin/mail with a small front end called svbinmail (for systems > that do not have sendmail). It moves the existing /bin/mail to > /bin/lmail, and uses it only when READING mail. /bin/smail and > /bin/rmail (linked together) are used when sending mail. > > My problem is that the smail interface seems pretty primitive [...] It's been a while since I've used SCO, so I'm a bit hazy on the exact mail situation there. Try the following, though. Restore the system to its normal setup -- mail in /bin/mail, the original rmail in /bin/rmail. Remove links to smail, leaving only /bin/smail behind. Forget svbinmail exists for now. Use the 'standard' mail program to send a long message to someone. Maybe something from comp.sources.unix. From another terminal (one of those virtual consoles will do fine) keep a close eye on your processes with ps -f -u foo. If a process called "rmail" pops up, it's your lucky day. If no rmail appears, ignore the rest of this article. Simply move /bin/rmail back to its backup position -- /bin/OLDrmail or whatever -- and link smail to /bin/rmail. Do nothing else! This way, typing mail will call up your real mail program, which can be used to send mail with subject lines et al. Do nothing else! Forget svbinmail ever existed, it won't be needed. See, if I remember right (probably not) the SCO mailer lets /bin/rmail do all of its delivery. Putting smail in its place will allow you to retain the full smail functionality (domain addresses, etc.) while using mail to actually compose your messages. Hope it works. -- Bill Wisner, HASA 'A' Division ..ihnp4!killer!billw "It's the coarse feel of the rope that I don't like."
billw@killer.UUCP (Bill Wisner) (10/16/87)
lyndon@ncc.UUCP (Lyndon Nerenberg): > I always thought the svbinmail interface was a bit of a crock. Here's > what I came up with... I always thought the System V /bin/mail interfact was a bit of a crock. svbinmail is a nice, if kludgy, way around it. > [...] > This has the effect of making mailx the default UA, and installs smail > in it's proper function as the MTA. Note that on most systems mailx > uses /bin/rmail for delivery. Make sure your mailx does so also or > you'll wonder where your mail is going... On killer (a 3B2, System V r2.0.5) mailx uses /bin/mail for delivery. Because of this, svbinmail is quite necessary. If yours uses /bin/rmail, then by all means go right ahead and replace /bin/mail. But be careful; some things may use /bin/mail that you don't know about, and who knows how the prompt for Subject: may futz things up? cron, for example, uses /bin/mail, or at least it does here.. -- Bill Wisner, HASA 'A' Division ..ihnp4!killer!billw "It's the coarse feel of the rope that I don't like."
kdb@ncsuvx.ncsu.edu (Kevin D. Bond) (10/16/87)
I replied by mail to this request, but have seen enough response that I thought I might help everyone out here... First, since I am a rather paranoid sort, and have been bitten before I NEVER substitute a smart mailer for /bin/mail, lots more things use /bin/mail than you might think, and they assume it is dumb. Second, so far you had to invoke mailx by saying mailx anyway, so why change? As for the problem of what mail agent mailx uses to deliver, who really cares what it uses by default, unless you try to make it into /bin/mail (which I obvious don't think you should my opinion only). You can change the delivery agent mailx uses by putting a line: set sendmail=smail in your $HOME/.mailrc, or in the global mailx setup file /usr/lib/mailx/mailrc, I think, can't remeber off the toip of my head. If you make this change, then everything works as before, program that expect /bin/mail to be dumb get what they expect, and users that want the extra features of a smart front end and smail can get them by making a simple change to their .mailrc file, of is the SA is inclined, he/she can make that the default. -- Kevin D. Bond kdb@ncsuvx.ncsu.edu kdb@cscosl.ncsu.edu kdb%katylied@mcnc.org
chip@ateng.UUCP (Chip Salzenberg) (10/16/87)
[Since this is a Xenix-specific question, followups have been directed to comp.unix.xenix.] In article <838@seradg.Dayton.NCR.COM> pat@seradg.Dayton.NCR.COM (Patrick Pesch) writes: > > I have just got "smail up on my SCO Xenix system and have a question > that somebody out there has probably encounterd. Smail replaces > /bin/mail with a small front end called svbinmail (for systems > that do not have sendmail). It moves the existing /bin/mail to > /bin/lmail, and uses it only when READING mail. /bin/smail and > /bin/rmail (linked together) are used when sending mail. > > My problem is that the smail interface seems pretty primitive, > compared to the Xenix mail that was there (mailx derivative). I've installed smail here on an SCO Xenix 2.2 system. I did _not_ rename /bin/mail to /bin/lmail. Instead, I installed a replacement for the /usr/lib/mail/execmail program. (Execmail is Xenix's answer to sendmail). This replacement program parses execmail's arguments and executes smail. The arguments that execmail (and its replacement) understand are: -f user This mail is from "user" -n Perform no alias substitution -m Mail to "me" too, if requested -r Remote [host!user instead of host:user?] -h count Specify max hop count in bang path (default is 20) (Perhaps some SCO wizards would care to clarify the usage of these options. Specifically, I haven't been able to discern any actual affect from the use of the "-m" and "-r" options.) Xenix's /bin/mail, when it finally wants to deliver mail, calls execmail, which on my system is actually smail in disguise. And smail uses the old execmail, which I've renamed to execmail.x, to deliver local mail. About configuring smail for this setup: I compiled smail without defining SENDMAIL, and I defined ALIASES as "/usr/lib/mail/r_aliases". All aliases that go to remote users are in this file; all aliases to local users are (still) in /usr/lib/mail/aliases. (Postmaster, usenet, network, Micnet aliases, etc.) I'd have let smail do _all_ alias processing, except that it doesn't understand "|pipeline" aliases. (i.e. rnews: "|/bin/rnews") The fly in the ointment is /bin/mail, which seems to consider itself lord and master of all it surveys. When it sees a name like "larry@moe.curly", it says "hey, there's no local user named `larry@moe.curly', and I don't see a bang, so I'm not going to bother execmail with this one." As someone wrote to me recently, /bin/mail is a hunk of junk. So we don't use it -- we use mush and/or elm. But if /bin/mail must be used, you can still mail to `moe.curly!larry' and it works. Barely. Anyway, now that I can change routing at whim, I'll never go back to manual bang paths. Not willingly, anyway. -- Chip Salzenberg "chip@ateng.UUCP" or "{uunet,usfvax2}!ateng!chip" A.T. Engineering My employer's opinions are not mine, but these are. "Gentlemen, your work today has been outstanding. I intend to recommend you all for promotion -- in whatever fleet we end up serving." - JTK
root@uwspan.UUCP (John Plocher) (10/16/87)
+---- In <127@ncc.UUCP> Lyndon Nerenberg writes: | I always thought the svbinmail interface was a bit of a crock. Here's | what I came up with... | ... | This has the effect of making mailx the default UA, and installs smail | in it's proper function as the MTA. +---- Except that mailx does NOT handle RFC822 addresses correctly! Try sending something to me at To: John Plocher <plocher@uwspan.UUCP> or To: plocher@uwspan.UUCP (John Plocher) mailx barfs on both of these! "Can't mail to John, can't mail to Plocher, can't mail to <plocher@uwspan.UUCP> ..." If you stick to "bang" paths everything sort of works, but isn't the reason for using smail specifically to *allow* you to use RFC822 style mail? In my book, elm + smail + John Zeeff's lmail.c which allows mail to be sent to a program is a *very good* replacement for mailx + /bin/mail. Plus, it works well with RFC822.
lyndon@ncc.UUCP (Lyndon Nerenberg) (10/17/87)
In article <1829@killer.UUCP>, billw@killer.UUCP (Bill Wisner) writes: > > On killer (a 3B2, System V r2.0.5) mailx uses /bin/mail for delivery. Because > of this, svbinmail is quite necessary. If yours uses /bin/rmail, then by all > means go right ahead and replace /bin/mail. But be careful; some things may > use /bin/mail that you don't know about, and who knows how the prompt for > Subject: may futz things up? cron, for example, uses /bin/mail, or at > least it does here.. On most System V boxes I've worked with, mailx has a global startup file (/usr/lib/mailx/mailx.rc). Try adding the following line to it: set sendmail=/bin/rmail I have had NO problems with cron (or anything else) using this setup.
paul@devon.UUCP (Paul Sutcliffe Jr.) (10/17/87)
[ This was originally posted in comp.mail.uucp. I've cross-posted it to comp.unix.xenix, but have directed followups to comp.mail.uucp. ] In the referenced article, pat@seradg.Dayton.NCR.COM (Patrick Pesch) writes: > I have just got "smail" up on my SCO Xenix system and have a question > that somebody out there has probably encounterd. Smail replaces > /bin/mail with a small front end called svbinmail (for systems > that do not have sendmail). It moves the existing /bin/mail to > /bin/lmail, and uses it only when READING mail. /bin/smail and > /bin/rmail (linked together) are used when sending mail. > > My problem is that the smail interface seems pretty primitive, > compared to the Xenix mail that was there (mailx derivative). > Can smail prompt for "Subject:, CC:", etc... as mailx does? Does > anyone know how this could be done without actually adding the > features to smail (maybe using the existing mailer as a front end)? You appear to have installed SMAIL in (what the author refers to as) the "SYSV without SENDMAIL" configuration. The problem with doing this on Xenix (SCO or Microsoft) is that, as you pointed out, SMAIL assumes that /bin/mail is a very dumb mailer, and replaces it. In fact, the Xenix /bin/mail is very intelligent (sic), and very closely resembles the UCB "Mail" package. But to address your problem. Take a close look at the contents of the /usr/lib/mail directory. Therein you will find an executable called "execmail". This is roughly the equivilent (albeit a slimmed down version) of sendmail. Execmail is the delivery agent for /bin/mail. It decides if the message is for UUCP, MICNET or local delivery and invokes /bin/rmail, /usr/lib/mail/mail.mn or /usr/lib/mail/mail.local respectively. The solution, then, is to inform SMAIL that the local delivery agent is /usr/lib/mail/mail.local instead of /bin/mail. Do this in SMAIL's defs.h file. This allows you to retain /bin/mail (and its improved features over svbinmail) while allowing SMAIL access to a local delivery agent. - paul -- Paul Sutcliffe, Jr. UUCP (smart): paul@devon.UUCP UUCP (dumb): ...{rutgers,ihnp4,cbosgd}!bpa!vu-vlsi!devon!paul
billw@killer.UUCP (Bill Wisner) (10/18/87)
And speaking of which, how do I get John Zeeff's lmail.c? -- Bill Wisner, HASA 'A' Division ..ihnp4!killer!billw "It's the coarse feel of the rope that I don't like."
billw@killer.UUCP (Bill Wisner) (10/18/87)
In article <128@ncc.UUCP> lyndon@ncc.UUCP (Lyndon Nerenberg) writes: >>On killer (a 3B2, System V r2.0.5) mailx uses /bin/mail for delivery. Because >>of this, svbinmail is quite necessary. If yours uses /bin/rmail, then by all >>means go right ahead and replace /bin/mail. But be careful; some things may >>use /bin/mail that you don't know about, and who knows how the prompt for >>Subject: may futz things up? cron, for example, uses /bin/mail, or at >>least it does here.. > >On most System V boxes I've worked with, mailx has a global startup >file (/usr/lib/mailx/mailx.rc). Try adding the following line to it: > >set sendmail=/bin/rmail > >I have had NO problems with cron (or anything else) using this setup. We want smail to handle delivery of EVERYTHING. With svbinmail installed as /bin/mail, this happens: even those people (shudder) who insist on using /bin/mail to send mail can still reap the benefits of smail. /bin/mail now resides in /bin/lmail, but this is completely transparent to the user; he need only type mail like he always did. Yes, we could simply set the DA in mailx's global rc file, but then vanilla mail would choke on domain addresses. The person I was responding to said he had replaced /bin/mail with /bin/mailx or some such; I don't remember which. My point with cron was that is the program in /bin/maiil starts prompting for a Subject, you never know in what wierd ways things might begin to act differently. Best not to tempt the fates, I say. -- Bill Wisner, HASA 'A' Division ..ihnp4!killer!billw "It's the coarse feel of the rope that I don't like."
jpp@slxsys.co.uk (John Pettitt) (10/21/87)
In article <838@seradg.Dayton.NCR.COM>, pat@seradg.Dayton.NCR.COM (Patrick Pesch) writes: > [ stuff about standard smail install deleted ] > My problem is that the smail interface seems pretty primitive, > compared to the Xenix mail that was there (mailx derivative). > Can smail prompt for "Subject:, CC:", etc... as mailx does? Does > anyone know how this could be done without actually adding the > features to smail (maybe using the existing mailer as a front end)? > Would having "sendmail" help? > I just got this to work ! Xenix mail (at least sco 2.2.1) uses several programs in /usr/lib/mail to deliver mail. If you install smail as follows then all should be fine. 1) Compile smail (remeber to edit defs.h so that the local mailer is /usr/lib/mail/mail.local.old and smail now lives in /usr/bin not /bin 2) in /usr/lib/mail mv mail.local mail.local.old mv execmail execmail.old ln /usr/bin/smail mail.local ln /usr/bin/smail execmail 3) in /usr/bin mv rmail OLDrmail ln smail rmail 4) set up an alias file as needed. This seems to work just fine. The mail command still gives all the prompts and ~ escapes and then uses smail to deliver the mail. The only problem to date is that xenix mail thinks that user@site is just a user name and so complains about not finding a passwd entry. The temporary fix is to just use ! addresses, but now with the help (?) of smail routing. How this will stand up in a xenix micnet system is anybodys guess ! -- John Pettitt G6KCQ, CIX jpettitt, Voice +44 1 398 9422 UUCP: ...uunet!mcvax!ukc!pyrltd!slxsys!jpp (jpp@slxsys.co.uk) Disclaimer: I don't even own a cat to share my views !
lyndon@ncc.UUCP (Lyndon Nerenberg) (10/21/87)
In article <1854@killer.UUCP>, billw@killer.UUCP (Bill Wisner) writes: > We want smail to handle delivery of EVERYTHING. With svbinmail installed > as /bin/mail, this happens: even those people (shudder) who insist on using > /bin/mail to send mail can still reap the benefits of smail. /bin/mail now > resides in /bin/lmail, but this is completely transparent to the user; he > need only type mail like he always did. My experience was that most users didn't even notice the changeover! Basically, the smart users already had mail aliased to mailx. The not-so-smart users couldn't care less, as long as the mail gets delivered. By making mailx the default (and only) UA, a user can mail to a@b.c and not have binmail choke. The is much nicer than a cryptic binmail error message. > The person I was responding to said he had replaced /bin/mail with /bin/mailx > or some such; I don't remember which. My point with cron was that is the > program in /bin/maiil starts prompting for a Subject, you never know in what > wierd ways things might begin to act differently. Best not to tempt the fates, > I say. Mailx only prompts for a Subject: line if stdin is attached to a terminal. As I indicated in a previous posting, I maintain five systems, all of which use the above mailer setup. Each of these systems mails a series of daily and weekly summaries from cron jobs. No problem at all. What's *really* nice about this setup is that I can do things like: /usr/adm/nitecheck | mail[x] -s "Nightly accounting check" lyndon@ncc.uucp This gives me a subject header on output from cron jobs. If one of the scripts finds something particulary nasty, the subject line can be changed to start with "WARNING!" to flag it as important. When you get 70 - 100 pieces of mail/day this is quite helpful.
chip@ateng.UUCP (Chip Salzenberg) (10/22/87)
Followups have been directed to comp.unix.xenix. [Again. *sigh*] In article <477@devon.UUCP> paul@devon.UUCP (Paul Sutcliffe Jr.) writes: >In the referenced article, pat@seradg.Dayton.NCR.COM (Patrick Pesch) writes: > >[/usr/lib/mail/execmail] is roughly the equivalent ... of sendmail. >It decides if the message is for UUCP, MICNET or local delivery and >invokes /bin/rmail, /usr/lib/mail/mail.mn or /usr/lib/mail/mail.local >respectively. This is all true. But then Mr. Pesch writes: >The solution, then, is to inform SMAIL that the local delivery agent >is /usr/lib/mail/mail.local instead of /bin/mail. Do this in SMAIL's >defs.h file. This is false! The mail.local program is _not_ a suitable delivery agent: 1. Mail.local doesn't understand Micnet addresses ("machine:user") so when you set up Xenix-net your mailer will break. 2. Mail.local doesn't do aliasing. If you therefore let smail do your aliasing since execmail is out of the picture, you lose pipe aliases (e.g. rnews: "|rnews"). Compile smail with SENDMAIL undefined, but use execmail as the local delivery agent. Just because you _can_ give UUCP mail to execmail doesn't mean that you _have_ to. Smail will siphon off all messages to other machines and invoke "uux" directly, and execmail will only see local mail. And it's a good idea to change the aliases file from "/usr/lib/aliases" to something like "/usr/lib/mail/raliases". There's no reason to start putting mail files in /usr/lib. -- Chip Salzenberg "chip@ateng.UUCP" or "{uunet,usfvax2}!ateng!chip" A.T. Engineering My employer's opinions are not mine, but these are. "Gentlemen, your work today has been outstanding. I intend to recommend you all for promotion -- in whatever fleet we end up serving." - JTK
zeeff@b-tech.UUCP (Jon Zeeff) (10/22/87)
In article <1844@killer.UUCP> billw@killer.UUCP (Bill Wisner) writes: >And speaking of which, how do I get John Zeeff's lmail.c? It's quite small, so I'll send it via email to a limited number of people. It's just a local delivery agent that also handles aliasing to files and programs. It works for me, but no guarantees for anyone else. -- Jon Zeeff Branch Technology, uunet!umix!b-tech!zeeff zeeff%b-tech.uucp@umix.cc.umich.edu
stuart@bms-at.UUCP (Stuart D. Gathman) (10/30/87)
In article <1828@killer.UUCP>, billw@killer.UUCP (Bill Wisner) writes: > See, if I remember right (probably not) the SCO mailer lets /bin/rmail do all > of its delivery. Putting smail in its place will allow you to retain the > full smail functionality (domain addresses, etc.) while using mail to actually > compose your messages. Unfortunately, SCO mail screens addresses for garbage characters (e.g. '@' & '.') before passing mail to /bin/rmail. As I say on many occasions, "Gee, they sure went to a lot of trouble to make it not work!" -- Stuart D. Gathman <stuart@bms-at.uucp> <..!{vrdxhq|dgis}!bms-at!stuart>
chip@ateng.UUCP (Chip Salzenberg) (11/02/87)
In article <536@bms-at.UUCP> stuart@bms-at.UUCP (Stuart D. Gathman) writes: > >Unfortunately, SCO mail screens addresses for garbage characters >(e.g. '@' & '.') before passing mail to /bin/rmail. As I say on >many occasions, "Gee, they sure went to a lot of trouble to make >it not work!" This `feature' is easy to defeat. In the /usr/lib/news/mailrc file, add this line: set execmail This causes the mail program to hand all mail to /usr/lib/mail/execmail. (This gem is courtesy of Tom Walsh <uunet!foobar!tw> -- thanks, Tom.) It is then necessary to rename the existing /usr/lib/mail/execmail to something else, say execmail.x, and then have smail use execmail.x as the local delivery agent. And of course, you need to install a replacement for execmail. This is my execmail replacement: #! /bin/sh # This is a shell archive, meaning: # 1. Remove everything above the "#! /bin/sh" line. # 2. Save the resulting text in a file. # 3. Execute the file with /bin/sh (not csh) to create the files: # execm.c # This archive created: Mon Nov 2 11:13:58 1987 export PATH; PATH=/bin:$PATH : echo 'shar: extracting "execm.c" (523 characters) ' if test -f 'execm.c' then echo 'shar: will not overwrite existing file "execm.c" ' else sed 's/^X//' << \SHAR_EOF > 'execm.c' X/* X * execm.c X * X * This program is a substitute for Xenix's /usr/lib/mail/execmail. X */ X X#include <stdio.h> X Xmain(argc, argv) Xint argc; Xchar **argv; X{ X char *progname = argv[0]; X X /* X * Drop the execmail options. X */ X while (argv[1][0] == '-') X { X switch (argv[1][1]) X { X case 'f': X case 'h': X argv += 2; X break; X default: X ++argv; X break; X } X } X X argv[0] = progname; X execv("/usr/bin/smail", argv); X execv("/bin/smail", argv); X X fprintf(stderr, "%s: can't execute smail!\n", progname); X exit(1); X} SHAR_EOF if test 523 -ne `wc -c < 'execm.c'` then echo 'shar: error transmitting "execm.c" (should have been 523 characters) ' fi chmod 664 'execm.c' fi # end of overwriting check # End of shell archive exit 0 -- Chip Salzenberg "chip@ateng.UUCP" or "{uunet,usfvax2}!ateng!chip" A.T. Engineering My employer's opinions are not mine, but these are. "Gentlemen, your work today has been outstanding. I intend to recommend you all for promotion -- in whatever fleet we end up serving." - JTK