Table of Contents............................................................................................................... i

Tables............................................................................................................................... vii

Licensing, Redistribution, and Warranty....................................................................... ix

Terms and Conditions for Copying, Distribution, and Modification.......................... ix

NO WARRANTY............................................................................................................ xi

Revision.......................................................................................................................... xiii

Viewing this document.................................................................................................. xiii

Viewing on a Terminal............................................................................................. xiii

Viewing on a Under Windows................................................................................... xiii

Viewing using a Web Browser.................................................................................. xiii

Special Note for the 1.12u Edition............................................................................... xiii

Part 1: General Information............................................................................................. 1

Introduction.................................................................................................................. 1

Version Numbers............................................................................................. 1

Who Should Use This Program.................................................................................... 2

System Requirements................................................................................................. 3

Required Reading......................................................................................................... 3

Resolving Problems and Other Support....................................................................... 3

Registering for Support.................................................................................... 3

Support Via Electronic Mail............................................................................. 4

Support Via US Mail......................................................................................... 4

Support via Telephone..................................................................................... 5

Support via Mailing Lists................................................................................. 5

Frequently Asked Questions (and Answers)................................................................ 6

Part 2: Basic UUCP Installation..................................................................................... 11

New UUPC/extended Installations............................................................................ 11

Ingredients..................................................................................................... 11

Before You Begin Installing........................................................................... 13

Copying UUPC/extended files onto your system.......................................... 14

Configuring After Installation....................................................................... 16

Testing........................................................................................................... 23

All Dressed Up and No Where to Go?............................................................. 25

Upgrading an Existing Installation............................................................................ 25

Configuring Usenet News Support............................................................................ 26

Selecting a news reader................................................................................ 27

Arranging a News feed................................................................................... 27

Configuring for News..................................................................................... 27

Permissions (PERMISSN) Files.................................................................................. 29

Part 3: Advanced Mail Installation and Configuration............................................... 31

Changing How Mail is Addressed and Delivered Locally.......................................... 31

An Overview of RMAIL..................................................................................... 31

Using Nickname Files, Alias Files, Forward Files, and the HOSTPATH file 32

Implicit Nickname Processing, (or, What Your Bear Never Told You about Aliases) 33

Controlling Mail Routing for Entire Systems and Subdomains................................ 33

Overview of Mail Routing............................................................................... 33

Routing Mail Via Non-Default Mail Servers.................................................. 34

Routing Mail for SMTP Delivery.................................................................... 34

Keeping Local Mail on the Local System....................................................... 34

Aliasing Systems Via The HOSTPATH File................................................... 35

The Ever So English Sport of Site Hiding...................................................... 35

UUPC/extended as a Mail Gateway............................................................... 36

UUPC/extended and Simple Mail Transport Protocol (SMTP)................................... 37

Receiving Mail via the UUSMTPD Server...................................................... 37

UUPC/extended and POP3 clients............................................................................. 38

UUPC/extended in Multi-tasking and Multi-user Environments............................ 38

Using UUPC/extended Under Windows 3.x................................................... 38

Using UUPC/extended Under OS/2, Windows 95, and Windows NT............ 40

Using UUPC/extended On a LAN................................................................... 40

Configuring Universal Naming Convention (UNC) Names...................................... 41

Specialized Communications Drivers....................................................................... 41

Drivers Available Under Different Environments......................................... 41

Using with TCP/IP based hosts..................................................................... 42

Using FOSSIL communications drivers with UUPC/extended.................... 43

General Advice on Multitasking Environments....................................................... 45

Passive Polling: Letting Other Systems Call You...................................................... 45

Modifying your SYSTEMS, PASSWD, and PERMISSN files............................ 46

Test your machine's new configuration....................................................... 47

Test having their machine call yours........................................................... 47

Interfacing With Other Programs.............................................................................. 47

Types of Support............................................................................................. 47

Using V-mail and Other Third Party Mailers................................................ 48

Invoking uucico From External Programs................................................... 49

Having uucico Invoke External Programs.................................................... 49

Part 4: Command Reference........................................................................................... 51

Overview..................................................................................................................... 51

Command Syntax....................................................................................................... 51

COMM34...................................................................................................................... 52

EXPIRE........................................................................................................................ 53

FMT............................................................................................................................. 54

FROMWHO.................................................................................................................. 56

GENHIST...................................................................................................................... 57

GENSIG....................................................................................................................... 58

GETUUPC.................................................................................................................... 59

INEWS......................................................................................................................... 60

MAIL............................................................................................................................ 61

MAILCHEK................................................................................................................... 68

NEWSRUN................................................................................................................... 69

NOVRSTRK.................................................................................................................. 71

PNEWS........................................................................................................................ 72

REGSETUP.................................................................................................................. 73

RMAIL.......................................................................................................................... 75

RNEWS........................................................................................................................ 78

SENDBATS.................................................................................................................. 80

SU............................................................................................................................... 81

uucico........................................................................................................................ 82

uucicon..................................................................................................................... 87

UUCLEAN..................................................................................................................... 88

UUIO............................................................................................................................ 89

UUCP........................................................................................................................... 90

UUCPD......................................................................................................................... 92

UUHOUR...................................................................................................................... 93

UUNAME...................................................................................................................... 94

uupoll....................................................................................................................... 95

UUPOPD...................................................................................................................... 98

UUPORT..................................................................................................................... 100

UUSMTPD.................................................................................................................. 102

UUSTAT..................................................................................................................... 104

UUSUB....................................................................................................................... 107

UUTRAF..................................................................................................................... 108

uux............................................................................................................................ 110

uuxqt....................................................................................................................... 112

WAITING.................................................................................................................... 113

Part 5: Configuration Files........................................................................................... 115

Overview................................................................................................................... 115

The UUPC.RC and [userid].RC files.......................................................................... 115

Introduction.................................................................................................. 115

Keywords Valid in Individual or System Configuration Files..................... 116

Keywords Valid Only in System Configuration Files.................................. 119

Boolean Options Valid in Either UUPC.RC or [userid].RC............................ 122

Modem ([modem].MDM) Files..................................................................................... 128

Introduction.................................................................................................. 128

Modem File Guidelines................................................................................ 128

Valid Fields in Modem Files......................................................................... 129

Boolean Options In Modem Files................................................................. 133

Supplied Modem files................................................................................... 134

The PASSWD file...................................................................................................... 136

The SYSTEMS file.................................................................................................... 137

Introduction.................................................................................................. 137

Time............................................................................................................. 138

Call grades.................................................................................................... 140

Protocols....................................................................................................... 140

Scripts.......................................................................................................... 142

The Fine Art of Chat Scripts........................................................................ 143

Multiple entries in the SYSTEMS file......................................................... 145

System Mail ALIASES File....................................................................................... 146

User Mail FORWARD File......................................................................................... 148

User Mail Nickname File........................................................................................ 148

HOSTPATH routing file............................................................................................ 151

Synopsis....................................................................................................... 151

Description................................................................................................... 151

usenet News ACTIVE Groups File........................................................................... 153

Format.......................................................................................................... 153

Special News Groups.................................................................................... 153

Other Considerations.................................................................................. 154

Usenet news SYS (neighbours) file......................................................................... 155

Appendix 1: Additional Copyrights and Related Credits........................................... 161

Appendix 2: Working With UUPC/extended Source.................................................. 163

Appendix 3: How UUCP File Transfers Work............................................................... 165

Overview................................................................................................................... 165

What’s in a Name?................................................................................................... 165

Files in the UUCP spool directory............................................................................ 165

Basic UUCP Processing............................................................................................ 166

Sample UUCP Job..................................................................................................... 167

Appendix 4: How to Get UUPC/extended..................................................................... 168

Introduction.............................................................................................................. 168

Supported Methods....................................................................................... 168

Obsolete Methods......................................................................................... 168

Sources for UUPC/extended.................................................................................... 168

Anonymous FTP........................................................................................... 168

World Wide Web............................................................................................ 168

Anonymous UUCP......................................................................................... 168

Registering Your Current Copy............................................................................... 169

About the Files......................................................................................................... 169

General Description of the Files................................................................. 169

Summary of Archive Contents.................................................................... 171

Other Trivia............................................................................................................. 172

Questions and Comments........................................................................... 172

Appendix 5: How to Register......................................................................................... 173

Why You Should Register......................................................................................... 173

And as an Added Bonus............................................................................................ 174

Disclaimer of Warranty............................................................................................ 174

Instructions.............................................................................................................. 175

The Form.................................................................................................................. 176

User Information.......................................................................................... 176

System Information..................................................................................... 176

Items Ordered.............................................................................................. 179

Appendix 6: Changes From Previous Versions........................................................... 180

Introduction.............................................................................................................. 180

Version 1.13f – 1.13j Revision Summary................................................................ 180

Bug Fixes...................................................................................................... 180

Enhancements............................................................................................. 180

Version 1.13e Revision Summary........................................................................... 181

Bug Fixes...................................................................................................... 181

Version 1.13d Revision Summary........................................................................... 181

Bug Fixes...................................................................................................... 181

Enhancements............................................................................................. 182

Version 1.13c Revision Summary........................................................................... 182

Bug Fixes...................................................................................................... 182

Enhancements............................................................................................. 182

Version 1.13b Revision Summary........................................................................... 183

Bug Fixes...................................................................................................... 183

Enhancements............................................................................................. 183

Version 1.12w - Version 1.13a Revision Summary................................................ 184

Bug Fixes...................................................................................................... 184

Enhancements............................................................................................. 185

Version 1.12v - Version 1.12w Revision Summary................................................ 185

Bug Fixes...................................................................................................... 185

Enhancements............................................................................................. 186

Version 1.12t - Version 1.12u Revision Summary................................................. 186

Bug Fixes...................................................................................................... 186

Enhancements............................................................................................. 188

Version 1.12s Revision Summary........................................................................... 189

Bug Fixes...................................................................................................... 189

Enhancements............................................................................................. 190

Version 1.12r Revision Summary........................................................................... 192

Bug Fixes...................................................................................................... 192

Enhancements............................................................................................. 193

Version 1.12p Revision Summary........................................................................... 193

Bug Fixes...................................................................................................... 193

Version 1.12o Revision Summary........................................................................... 194

Enhancements............................................................................................. 194

Bug fixes....................................................................................................... 194

Other Changes............................................................................................. 196

Version 1.12j Through Version 1.12n Revision Summary..................................... 196

Enhancements............................................................................................. 196

Bug fixes....................................................................................................... 198

Other changes.............................................................................................. 200

Versions 1.12h through 1.12i Revision Summary................................................. 200

Enhancements............................................................................................. 200

Bug Fixes...................................................................................................... 201

Versions 1.12c through 1.12g Revision Summary................................................. 202

Bug Fixes...................................................................................................... 202

Enhancements and Other Hacks................................................................ 205

Index............................................................................................................................... 207

”The Hitchhikers Guide to The Galaxy is a very unevenly edited book and contains many passages that simply seemed to its editors like a good idea at the time.”

- Douglas Adams

Part 1: General Information

Introduction

This document provides information on UUPC/extended version 1.13j, produced by Kendra Electronic Wonderworks with contributions from around the globe.

UUPC/extended is a PC based version (and pun of) UUCP (UNIX-to-UNIX copy). UUPC/extended implements peer-to-peer networking using the UNIX UUCP protocols. MS-DOS, OS/2, Windows 3.x, Windows NT, or Windows 95-based personal computers using these protocols can exchange mail, Usenet news, and files with a UNIX system, another UUPC/extended system, or other UUCP systems. It supports serial ports and (except in DOS environments) TCP/IP connections.

UUPC/extended is based on the free widely distributed 1987 interim version of UUPC, version 1.05, written by Stuart Lynne, Richard H. Lamb, and Samuel Lam, in Vancouver, BC. The MS-DOS version of UUPC is no longer maintained in Vancouver; UUPC/extended 1.13j is the official current release of UUPC. The differences between UUPC/extended and UUPC version 1.05 include user aliases, routing to multiple hosts, dial in support, limited domain address parsing and routing, support for the OS/2 and Windows operating environments, and various improvements in the user interface. Because of these changes, much of what is contained in this document does not apply to the original UUPC 1.05 package.

This documentation is written using Microsoft Word for Windows 97.

Version Numbers

Minor revisions to UUPC/extended are denoted by changes to the letter suffix on the version number. Minor revisions include only those changes, no matter how great, that allow the user to return to a previous release by at most updating the configuration file. Major revisions are denoted by a change in the number of the version; a major revision has changes in it which introduce a permanent incompatibility with the previous release.

Beginning with version 1.12, major revisions are those which supposed are distributed to the registered user base, whether they introduce a permanent incompatibility or not. See How to Register, page 173, for details on how to register your copy of UUPC/extended. (In practice, both 1.12a and 1.13a were created because the previous versions were 1.11z and 1.12z, which is to say we ran out of letters.)

If you need to communicate with us regarding UUPC/extended, please be sure to include the full version number you are referring to, including the letter suffix.

For a full description of the changes to UUPC/extended and how they affect upgrading from one release to the next, see Changes From Previous Versions, page 180. It should be duly noted that there is no version 1.24b at this time. A user was having nightmares in which she didn't have version 1.24b and everyone else did . . .

Who Should Use This Program

As mentioned above, UUPC/extended is a peer-to-peer networking program. Your local system and systems with which it communicates are on an equal footing in that the capabilities and access of the systems are generally symmetrical. You have complete control over and must be responsible for your own system. Compare this to a client-server set-up, such as when you dial in to a central mainframe or bulletin board system on which the system operator handles the administration (and restricts your access).

One application for UUPC/extended is providing remote access to a private system or small network, for example allowing a laptop machine access a single remote PC or UNIX system. This application requires little overhead, and may be used for connections needed for just a few days.

A more common use for UUPC/extended is providing dial-up e-mail and batch news access to public networks such as Usenet and/or the Internet. When UUPC/extended is used for this purpose, you, as the system administrator, are responsible for maintaining your own system as a member of the global network community. Related duties include making sure your system calls other systems regularly (including when you are not around), monitoring your links to other systems, registering your system with a central authority such as the UUCP Project and/or the Internet Network Information Center, and other long term tasks.

Because of these responsibilities, not all people should use a program such as UUPC/extended for general e-mail access. As a rule of thumb, if you do not receive more than one e-mail message a week or do not require e-mail access for more than six months, then you should consider a commercial service such as CompuServe, America Online, MCI Mail, ATT Mail, or others over setting up UUPC/extended. This reduces the set-up work required on your part and avoids problems associated with registering and de-registering your system, leaving the system running during absences, and the like.

UUPC/extended is not intended for interactive logins; it does not present user prompt on login to allow user commands. Nor the UUCP protocols are not compatible with the protocols (Xmodem, Kermit, etc.) included with most PC terminal emulators, and UUPC/extended security is oriented towards a pre-defined list of known systems calling in regularly.

UUPC/extended should also be avoided if your primary interest is:

· A server which allows downloading files to other personal computers which do not have UUPC/extended or some other UUCP program. Use a BBS program instead for generic download functions and/or interactive access to your system.

· Interactive access to the Internet for World Wide Web surfing or FTP. Use a dial-up TCP/IP package instead.

Finally, UUPC/extended should be avoided if you lack the resources, financial or otherwise, to support the program. Installing the program does require either experience in setting up complex systems or a willingness to learn via associates or books. Trying to set up UUPC/extended without experience and resources (such as the Nutshell handbooks discussed below) can cause pain and suffering for a very important person-- you.

System Requirements

For the system requirements needed install UUPC/extended, see the equipment list that’s part of the Ingredients on page 11.

Required Reading

Read Part 2: Basic UUCP Installation, page 11, now for installation and upgrade instructions. Users of previous versions of UUPC/extended should also read Changes From Previous Versions, page 180, for a summary of changes in the current release. Instructions on using the programs are in Part 4: Command Reference, page 51.

This document and its companions only provide an overview of UUCP connections. The average person wishing to set up UUPC/extended will require a reference such as Using & Managing UUCP, part of the Nutshell Handbook series by O'Reilly and Associates.^{^[1]}^,^{^[2]}^,^{^[3]} This book, while not specifically addressing UUPC/extended, includes detailed information on:

· Format of the SYSTEMS file

· Format of the PERMISSN (Permissions) file

· Information on debugging login scripts

· Information on registering your site with various networks

· Use of the various UUCP commands under UNIX and other systems

Resolving Problems and Other Support

Note: Please read all of the documentation (especially the following section with answers to common questions) and the Nutshell handbooks before sending mail. Yes, we know this manual runs 243 pages, we had to write all 66242 words of it.

Registering for Support

See How to Register, page 173, for the cost and benefits of registering for telephone support and other goodies.

Unregistered users are supported via e-mail only.

Support Via Electronic Mail

Please report problems with this version of UUPC/extended via electronic mail to help@kew.com. Please be precise in your description and include all applicable information such as the operating system in use and its release, the release of UUPC/extended and any unique configuration aspects.

Note: If you are not using the current version, please upgrade before sending mail. Old versions are obsolete for a reason, and your problem may have been fixed already.

Note: Please don’t send us all your configuration files and logs in your initial mail. If you have a problem with a particular program you should include its log, but don’t turn the debugging volume all the way up. E-mail is wonderful -- we can always ask for more information.

Note: Do not send UUENCODEd files or MIME mail. If you need to do either, you’re sending too much information! Files which are not human readable will be discarded.

Support Via US Mail

If you are unable to reach Kendra Electronic Wonderworks via electronic mail, mail your problem report to:

UUPC/extended Help Desk
Kendra Electronic Wonderworks
Post Office Box 80144
Stoneham, MA 02180-0002 USA

If and only if you are sending us paper mail, please include with your problem description listings of the files which apply, including:

· UUPC.RC

· [userid].RC

· SYSTEMS

Note: Passwords and userids can and should be changed in the SYSTEMS file.

· Directory listing for your configuration directory.

· A log of the applicable program execution, if any. Both uucico and RMAIL automatically write logs into the spool directory. Debug level 4 (-x 4 on the command line) will provide the needed level of detail.

No claim is made that the problem will be corrected, or that the person reporting the problem will be supplied a copy of the corrected code^{^[4]}, but reasonable efforts will be made to correct the program.

Note: Don’t uuencode your log files or use MIME mail to send them.

Support via Telephone

E-mail is the fastest and most reliable way to contact us. Please try it before calling.

Our telephone number is 781-279-9812. However, we do not support unregistered users via telephone. If you are a registered user or making a general query, and you must call rather then using e-mail, the best time to call is between 6 PM and 10 PM Eastern Time (GMT -5).

Support via Mailing Lists

UUPC-Info

An electronic mailing list, uupc‑info@kew.com, is open to those interested in UUPC/extended. This list includes messages from users asking questions and responses from Kendra Electronic Wonderworks, and announcements of general interest to users such as new features going into UUPC/extended.

Note: This list is for questions or suggestions of general interest. If you have a particular question, send mail to help@kew.com directly.

To join it, send a command of the following format in the body of a e‑mail message to listserv@kew.com:

subscribe uupc‑info

The list server also accepts the command:

help

To resign from the mailing list, send mail to the list server of the following format:

unsubscribe uupc‑info

Note: DO NOT send requests to be added or deleted to uupc-info@kew.com. Mail sent to this address is automatically forwarded to all users on the list. Questions of an administrative nature which require human attention should be directed to uupc-info-request@kew.com.

Since undeliverable addresses cause mail to be bounced to the list administrator, the administrator reserves the right to drop from the list any user for whom mail is rejected. In many cases, the user will not be notified, since the mail to notify the user will bounce for the same reason the address was deleted in the first place.

UUPC-Info-Digest

This is a digest form of the UUPC-Info mailing list above. Messages from UUPC-Info are collected into a single mail message and sent out weekly or when about 30 kilobytes of messages accumulate, whichever is more often. We only do trivial editing, mostly to purge administrative requests (i.e. subscribe). The digest is useful to people who don’t want to be bothered by messages often but still want full information about UUPC/extended.

To subscribe to and signoff from this mail list, the procedure is the same as the procedure listed above for UUPC-Info, but the list name sent in the commands is UUPC-Info-Digest.

UUPC-Announce

This list is restricted to major announcements from the staff of Kendra Electronic Wonderworks, primarily new releases; users are not allowed to post to this list. Subscribing to this list allows users who do not want continuous updates about UUPC/extended to be notified when new releases are available. Registered users are automatically added to this list.

To subscribe to and signoff from this mail list, the procedure is the same as listed above in UUPC-Info, but the list name sent in the commands is UUPC-Announce.

Frequently Asked Questions (and Answers)

The following section answers common questions about UUPC/extended. The first questions are general, the latter section deals with specific problems you may see and what to do about them.

Q. Does UUPC/extended support news?

A. In part. The RNEWS command distributed with UUPC/extended now correctly decompresses and delivers local news to directories based on the news group name, and we are in the process of assembling other news handling tools, but the news reader (a port of the UNIX program RN) is still in development.^{^[5]}

Q. The uupoll command takes over my entire DOS system when it runs. Can I run it under DOS and still use the system?

A. No, but you can run it under OS/2 or under Windows NT or Windows 95. DESQView should also work. At Kendra Electronic Wonderworks, kendra uses OS/2 Warp, and electra uses Windows 95.

Note: If you run UUPC/extended in the background, be sure to enable multitasking support in your UUPC.RC file with the Boolean option multitask.

Q. It takes forever for the system to recognize a busy signal on the other end. What can I do?

A. Make sure your modem file includes the configuration variable NoConnect to document the strings your modem uses to report failures in the dialing sequence. Also, consider enabling the Boolean option CarrierDetect in your modem file.

Q. Can UUPC/extended support multiple users on one system?

A. Yes. Each user should have an entry in the PASSWD file and a copy of [userid].RC under a unique name in the UUPC/extended configuration directory. A short command file similar to the sample SU.BAT file provided can be used to change the active user. UUPC/extended cannot prevent users from reading other users' mail or mail queued for another system. This is an MS-DOS restriction.

Q. UUPC/extended is wonderful, but it doesn't run on my (insert non-IBM or NT-compatible platform here).

A. While the original UUPC was targeted for both the Mac and Atari-ST in addition to the IBM, Kendra Electronic Wonderworks only supports the MS-DOS, Windows 3.x, OS/2, and Windows NT or Windows 95 environments. Contact Dave Platt <dplatt@snulbug.mtview.ca.us>, on where to find his version of UUPC for the Macintosh. For Amiga systems, try anonymous FTP to wuarchive.wust1.edu. There are no known reliable sources for UUPC for the Atari-ST.

Q. Who is kendra?

A. Actually, that is correctly "What is kendra?" Kendra means "womanly knowledge" in Old English.

kendra was originally an 80286 based Epson Equity III+ running MS-DOS 3.3 that used a second 8088 based system as a communications front end. She has since had multiple upgrades, and as of this writing is actually three physical machines:

pandora, an IBM PS/1 486DX2/66 running FreeBSD and Taylor UUCP; this is our external Internet gateway.

athena, a Northgate 386/33 DX running OS/2 Warp.^{^[6]}

sonata, a NEC Ready 150Mhz Pentium running Windows NT 4.0

Their sibling, our documentation system electra, is a Toshiba 405CS notebook with Windows 95.

Q. You mean you don’t use UUPC/extended to talk to the outside world?

A. Not at this time. UUPC/extended is not designed for use as a dedicated gateway machine, but rather to fit in to an existing PC environment. With the rise of excellent free UNIX clones with containing the original UNIX programs such as Taylor UUCP and sendmail that we are trying to emulate, our focus is to talk to such UNIX machines, not replace them.

Q. I want users to be able to login and read their mail on my system. Since I can't use COMMAND.COM, what shell should I specify for them?

A. Right idea, wrong question. UUPC/extended is not designed for remote user login. Rather, it allows routing mail among multiple peer sites. Set up each user as his/her own node. This arrangement gives each user all the tools of his/her own system when composing mail, and keeps the time spent on-line to a minimum.

Q. Why does Snuffles want chocolate?

A. Because Chocolate is happy food. Snuffles is a very happy bear. However, ever since someone sent her 18 pounds of chocolate, she now looks for donations to the Chocolate Ice Cream Fund instead. This leaves us room in the freezer for more mundane groceries.

Note: Snuffles does still accept^{^[7]} Girl Scout Thin Mints.

Q. Could you define a [common printer type] connected to FILE and print the docks to FILE? This would let me do a "copy /b filename LPT1:" and get a nice printed copy without Word for Windows (which I don't have) or a PostScript printer (which I also don't have).

A. In theory we could. In practice, it's the path to madness. We'd soon find ourselves doing that for LaserJets, Epsons, Proprinters, Applewriters, and every other brand of printer you can think of (and none of which we have, so testing would be impossible). Local copy shops often have PostScript printers, the *.PRN files should be printable by most printers, and registered users will receive a printed copy of the documents.

Q. When I start a UUPC/extended application, it displays a message like "environment variable UUPCSYSRC must be specified," or "User configuration parameter "mailbox" must be set, "then exits.

A. You need to set the UUPCSYSRC, UUPCUSRRC, and TZ environment variables. See step 8., page 22, under Configuring After Installation.

Q. When I start up the uucico command, it displays a message like: "Invalid host id in c:/permissn, MACHINE=[name]; Unable to initialize security," then exits.

A. The PERMISSN file and your SYSTEMS file are inconsistent. There is an entry in your PERMISSN file which does not match a corresponding system in the SYSTEMS file; a userid which does not appear in PASSWD; or a needed directory does not exist. See steps 4., The PASSWD file, and step 6. in Configuring After Installation, on page 16.

Q. When I start up the uucico command, it displays a message like: wanted "OK" got ??? "ERROR????" then exits.

A. You have a problem with your [modem].MDM file. Check your UUPC.RC file (for incoming calls) or SYSTEMS file (for outgoing calls) to make sure you're using the .MDM file you think you are, then check the lines in the file to find the one that gives your modem problems. Try "uucico -x 4" to see more information as uucico processes the script. Also, try using a FOSSIL driver to reduce the chance of lost connections. See also The Fine Art of Chat Scripts, page 143.

Q. When I try to connect to the remote machine, it refuses the connection, even though I was able to dial in with another telecommunications program.

A. This could be one of several things, most of which could be due to errors in the entry in your SYSTEMS file for your mail server. See part 4. in Configuring After Installation, page 20. Or, you could have given your system a different name in your UUPC.RC file than the mail server expected. See part 1. in Configuring After Installation, page 17.

Q. UUPC/extended will connect but will not exchange data with another system, What's wrong?

A. Any number of things, which is why you should seek additional information from either a UNIX guru or the Nutshell Handbooks. However, one hint is that any programs communicating via the UUCP "g" protocol must have a clean eight bit connection. A seven bit even parity connection or a connection with software (X-ON/X-OFF) flow control will ruin your whole day. If you can login as a normal user to the remote system, you can use the STTY command to determine the parity and flow control settings. Also, make sure the Boolean option variablePacket does not appear in your modem file.

Q. When UUPC/extended logins to the remote system, the remote delivers Shere as the first message and then RLOGIN as the second message. Why doesn't UUPC/extended like this second message?

A. The full answer (or at least the full list of the possible error responses to the second message sent to the remote host) is listed in Using & Managing UUCP. Suffice to say the RLOGIN means that the remote system does not know your system. Your system is missing from the remote's USERFILE, L.sys, Systems, or Permissions^{^[8]} files.

Q. After UUPC/extended picks up my mail, uuxqt tries to deliver it and fails with the message, "PERMISSION DENIED". What's wrong?

A. Look for additional information before the "PERMISSION DENIED" error message. A good chance is that uuxqt cannot find the RMAIL command. Any program invoked by uuxqt must be in the path. Placing a command in the directory uuxqt is invoked from is not enough, because uuxqt changes directories as it runs.

Q. A mail message created in the editor is sent, but the signature is not appended.

A. Your editor is appending a Ctrl-Z to the file before the signature is appended. Disable that "feature," or use a different editor.

Q. UUCP on your remote host keeps sending you messages about RNEWS exiting normally, and you want the messages to go away.

A. The sending host should set the -n flag for the uux command which generates the RNEWS command for you.

Q. I get dropped characters in the login script when running the DOS version of UUPC/extended under OS/2. How can I fix that?

A. Run the OS/2 uucico or use an OS/2 FOSSIL driver. The DOS version doesn't handle it well when a multi-tasking operating system steals its time slice. The problem also occurs when running the DOS versions under Windows, and can be corrected by using the Windows version of UUPC/extended instead.

Note: The spool directory formats used by all versions of UUPC/extended are compatible, allowing a user to use the OS/2 or NT versions of uucico in conjunction with the DOS versions of other programs. This allows interfacing to DOS-only third party programs

Q. Why are the names in the spool directory so strange?

A. Because DOS FAT file systems only use about 50 unique characters for file names, while UNIX supports about 80 unique characters. In addition, UNIX names can be longer. A mapping routine is used to compress 14 character UNIX names into 11 character DOS names. Part of this conversion involves removing the first two characters (such as X.) and the system name from the front of the file name (the entire system name is encoded as 6 bits, or about a single character), and the rest involves base 80 arithmetic. Neat, huh?

Q. Okay, DOS is brain dead, but why use strange names in the spool directory for my system, which supports mixed-case and long names? I enabled the Boolean option longname and the Boolean option monocase, but they had no effect on the names in the spool directory.

A. First, using the standard mapping routine for the more advanced file systems makes the DOS FAT based spool directories compatible with other versions. This means other DOS programs can interface with DOS UUPC/extended programs while the native versions of other UUPC/extended programs (like UUCICO) are used.

Second, it means less code to maintain. The same routine is upwardly compatible even if the names are ugly.

Most importantly, while some file systems retain the case of characters in the directory listing, names in the DOS-derived file systems (VFAT, HPFS, NTFS) are still case-insensitive when it comes to actually creating or search for files. That is, long.file.name, Long.File.Name and LONG.FILE.NAME are all the same name to the PC operating systems, but they are unique to UNIX. The option monocase prevents UUPC/extended from generating mixed case names, but it cannot prevent a remote UNIX system from sending a mixed case name. Accepting UNIX-generated files and not honoring the case will result in file name collisions sooner or later.

"OS/2, the system so good you can't install it just once."

-- Dave Gomberg

Part 2: Basic UUCP Installation

New UUPC/extended Installations

Ingredients

The following assumes that you have never installed UUPC/extended before. If you are upgrading an existing UUPC/extended installation, skip to Upgrading an Existing Installation, beginning on page 25.

Note: If installing for Windows 3.x, first install the native DOS version and then add the Windows versions of the uucico and associated programs. This both allows initial debugging in a simpler environment and provides the needed foundation for running under Windows. See Using UUPC/extended Under Windows 3.x on page 38.

Many thanks to David Watt and his sidekick Frederick Bear Watt for assisting with this section and providing the examples, and to Snuffles for reminding us to change the system names to protect the guilty.

To start sending and receiving mail on your system you'll need the following equipment and knowledge:

Equipment:

* A computer running MS-DOS, OS/2, Windows NT, or Windows 95. Under DOS, you need at least 512 kilobytes of RAM and 2 megabytes of hard disk space (for executables, configuration files, documentation, and mail received). For OS/2, Windows 3.x, Windows NT, or Windows 95 you need the minimum configuration for the operating system plus 2 megabytes of free hard disk space.

* A modem.

* The manual for the modem.

* A text editor. The MS-DOS editor, Windows Notepad, or OS/2 editor will work fine.

* A copy of PKUNZIP.EXE, version 2.04g or later, or a compatible utility such as the Info-ZIP UNZIP utility. PKUNZIP is a shareware utility, UNZIP is freeware, and both can be found at almost all archive sites. Consult your local BBS, or get one of the two programs from wuarchive.wustl.edu.

* A friend or commercial UUCP provider with a machine that does UUCP. This can be a UNIX system, a PC running UUPC/extended or another UUCP clone, or a VMS system running DECUS UUCP.

Knowledge:

How to copy files.

How to edit a text file.

Once you've got all of that, follow these steps to prepare for, install, configure, and test UUPC/extended.

Preparing for installation:

1. Review Who Should Use This Program, page 2, to make sure UUPC/extended is right for you.

2. Read these instructions.

3. Name your system.

4. Find a UUCP neighbor.

5. Choose your user name.

6. Backup your system.

Installing UUPC/extended on your system:

1. Get the UUPC/extended archives needed for your operating system.

2. Make any required directories.

3. Copy the UUPC/extended files onto your system.

4. Create the on-line help files for MAIL.

Configuring UUPC/extended to process mail and call other systems:

1. Find your modem among the .MDM files.

2. Configure several files:

1. UUPC.RC

2. [userid].RC

3. [modem].MDM

4. SYSTEMS

5. PASSWD

6. PERMISSN

7. CONFIG.SYS

8. AUTOEXEC.BAT

9. [userid].SIG

3. Reboot your system.

Testing the new installation:

1. Check your configuration with UUNAME.

2. Check your PERMISSN file with uuxqt.

3. Send mail to yourself.

4. Check the PC <--> modem connection.

5. Check the PC <--> modem <--> modem <--> mail server connection.

6. Send remote UUCP mail.

Then you'll be up and running! Each of the steps is discussed in more detail below.

Before You Begin Installing

1. Who Should Use This Program, page 2, contains important information explaining what UUPC/extended will and will not do. It also discusses the responsibilities inherent in running a UUCP site. Please read it before proceeding further.

2. Read all of these instructions before doing anything. Trust us, you'll be glad you did.

3. Your machine needs a name. The name should be all lowercase, since many operating systems are not case-sensitive. If you plan to connect to the outside world, the first six characters of the name need to be unique over all of Usenet. This isn't precisely true, but it's close enough, and the truth is more complicated -- if you're interested in the details, buy a copy of Using & Managing UUCP, published by O'Reilly and Associates. Actually, go buy it anyway, and please read it before asking questions. Required Reading, page 3, has some suggestions on where to find this and other useful books. See RFC1178.TXT in the upc13jad.zip archive for some considerations to keep in mind when choosing a system name.^{^[9]}

Example: Fred chose the name "toscis" for his machine, in honor of Snuffles' favorite ice cream.

4. Find a friend or commercial service provider with a machine which supports sending and receiving UUCP news and mail to provide you with a link. Your contact must also be pals with the system administrator of the machine, or someone else who has the power to add accounts to the remote system.^{^[10]} They will have to add an account for your system and configure the remote UUCP to acknowledge its existence and permit your system to log in and exchange mail.

Example: Fred uses a feed from Kendra Electronic Wonderworks, which is known in the UUCP world as kewgate. Snuffles assigned toscis an account on kewgate called "Utoscis". The name is conventional -- Ukewgate, Uflopsie, and Uzzyzyx are several accounts on Fred's machine, for some of his neighbors to log onto his system.

Some Internet Service Providers (ISP’s, whose main business is dial-up TCP/IP access for Web Surfing and the like) also provide UUCP access, although many only grudgingly. If you're looking for a UUCP system to connect your machine to, you might try local universities and local software companies for friendly volunteers. The backup connection at the Wonderworks, for instance, is provided courtesy of a machine belonging to the EE department at a local university. If you have Usenet access, you might peruse comp.mail.maps for the names of local systems and their administrators who might be willing to give you a feed.

If you are willing to pay money to get to the Internet, there are a variety of network providers, ranging from small public service-oriented providers to large commercial companies with national coverage. We can’t provide a specific list because the players keep changing.

5. You need to choose a user name for yourself. This name does not have to be unique or anything, but you will need it for some of the configuration of UUPC/extended yet to come. It should be composed only of valid DOS file name characters and should have eight characters or less.

Example: Fred's user name on toscis is fbwatt. Our resident Plump Plush Platinum Programming Polar Bear's^{^[11]} user name on kewgate is Snuffles.

6. Backup your system. If you do not regularly backup your system, this is an excellent time to start. Again, trust us.

Copying UUPC/extended files onto your system.

1. To install UUPC/extended, you need to get the specific archives needed for your system, as outlined in the table below.

UUPC/extended includes nearly two dozen executable files for each operating system. The executable files should be placed in their own directory to allow easy upgrades. This directory should then be added to your MS-DOS, OS/2, Windows NT, or Windows 95 PATH variable. The program will assume that you have used the following standard directories for the binaries:

Table 1 - Archive Files Needed for Various Operating Systems

Operating System	Directory for executable files.	Archives Needed To Install
DOS	\UUPC\BIN	upc13jd1.zip upc13jd2.zip upc13jd3.zip upc13jad.zip
Windows 3.x^{^[12]}	\UUPC\WINBIN3	upc13jd1.zip upc13jd2.zip upc13jd3.zip upc13jw1.zip upc13jw2.zip upc13jw3.zip upc13jad.zip
OS/2 16 bit (for OS/2 1.x or OS/2 2.x)	\UUPC\OS2BIN16	upc13j11.zip upc13j12.zip upc13j13.zip upc13jad.zip
OS/2 32 bit (for OS/2 2.x only)	\UUPC\OS2BIN	upc13j21.zip upc13j22.zip upc13j23.zip upc13jad.zip
Windows 95 Windows NT	\UUPC\NTBIN	upc13jn1.zip upc13jn2.zip upc13jn3.zip upc13jad.zip

2. Make directories for the UUPC/extended files. You need to make the base directory (\UUPC)^{^[13]}, a directory for the sample files (\UUPC\SAMPLES), if you have not unpacked them elsewhere already, a directory for the binary files, and a public directory (\UUPC\PUBLIC)^{^[14]}.

Example: kewgate has both OS/2 (16 or 32 bit) and DOS versions of UUPC/extended installed. The DOS files are in E:\UUPC\BIN and the OS/2 files are in E:\UUPC\OS2BIN.

Example: toscis runs the MS-DOS and Windows NT operating systems. Fred put the UUPC/extended DOS executables in C:\UUPC\BIN, the Windows NT executables in C:\UUPC\NTBIN and the documentation in C:\UUPC\SAMPLES. He built the directories at the C:\> prompt this way:

C:\> mkdir \uupc

C:\> mkdir \uupc\bin

C:\> mkdir \uupc\ntbin

C:\> mkdir \uupc\samples
C:\> mkdir \uupc\public

3. Unzip the archives. (Type "PKUNZIP" at the DOS prompt for instructions on how to unzip files.)

Example: To uncompress the documentation archive and program archives for MS-DOS and Windows NT, here's what Fred did:

C:\> PKUNZIP upc13jad.zip \uupc\samples *.*

C:\> PKUNZIP upc13jd1.zip \uupc\bin *.*

C:\> PKUNZIP upc13jd2.zip \uupc\bin *.*

C:\> PKUNZIP upc13jd3.zip \uupc\bin *.*

C:\> PKUNZIP upc13jn1.zip \uupc\ntbin *.*

C:\> PKUNZIP upc13jn2.zip \uupc\ntbin *.*

C:\> PKUNZIP upc13jn3.zip \uupc\ntbin *.*

4. Convert the printed formatted documentation for mail to on-line help files by running the program NOVRSTRK on MAIL.PRN and TILDE.PRN.

Example: Fred ran NOVRSTRK on both of the files:

C:\> \uupc\bin\novrstrk \uupc\samples\mail.prn \uupc\mail.hlp
C:\> \uupc\bin\novrstrk \uupc\samples\tilde.prn \uupc\tilde.hlp

All the files you need are now on your system.

Configuring After Installation

Here's where you earn your daily chocolate by configuring the system for basic local mail and dialing out to other systems.^{^[15]} Table 2 - Files to Update for Basic Installation, below, summarizes the files to be updated and their functions. All of the files must be copied from the samples directory (\UUPC\SAMPLES) to their permanent home in the UUPC/extended configuration directory (\UUPC) except as noted.

Table 2 - Files to Update for Basic Installation

File name	Function
UUPC.RC	System wide UUPC/extended configuration file. It defines both required and optional information which is the same for all users of the local system, and default values for individual users. This information includes the local system name, the name of its mail server, directory names (if you are not using the defaults), and selected performance parameters.
[userid].RC	User-specific UUPC/extended configuration file. It defines both required and optional information for one user. A customized copy of this file with a unique name exists for each user of the system. This file is sometimes referred to as the PERSONAL.RC file.
[modem].MDM	Defines the command strings required to initialize, dial, and answer with your modem. It also contains selected protocol information for UUCP connections made using the modem. The file is referenced by entries in the SYSTEMS file. Note: You may need more than one modem file if you use your modem to connect to more than one type of remote modem.
SYSTEMS	Defines the system names, times to call, devices (modem files) to call with, phone numbers, and login scripts to use when calling other systems.
PASSWD	Defines the user ids, names, and home directories of the users of your system.
PERMISSN	Defines the access remote systems have to your disk and what programs a remote system may direct uuxqt to run on its behalf.
AUTOEXEC.BAT	Under DOS and Windows NT, this file sets environment variables for your PATH (where to find programs), the location of the UUPC.RC file, the location of the [userid].RC file, and the local time zone. Note: This file resides in the root directory of your hard drive.
CONFIG.SYS	Under DOS, defines how many files can be open at once; under OS/2, is used in place of AUTOEXEC.BAT to define the environment information listed above. Note: This file resides in the root directory of your hard drive.
[userid].SIG	Included automatically at the end of each piece of mail you send to provide return address information. Note: This file resides in your home directory, defined by the variable Home in your [userid].RC file. See step 2., page 18, for further information.

1. The first file to copy and edit is UUPC.RC, the system configuration file. This file defines the system name and other parameters which make your system unique.

The fields are described in The UUPC.RC and [userid].RC files, on page 115, and in the sample UUPC.RC file itself.^{^[16]} You must set the fields described in Table 3 - Minimum Fields to Update in UUPC.RC for New Installation, below. All other fields in the sample UUPC.RC file, such as the options= lines, can be left alone.

Table 3 - Minimum Fields to Update in UUPC.RC for New Installation

Field name	Description	Example
Nodename	The simple nodename you chose for your machine.	toscis
Domain	The fully qualified domain name for your machine. If you are just starting out, this will be your machine name, with the suffix ".UUCP".	toscis.cambridge.ma.us^{^[17]}
Mailserv	The name of the machine to which your outbound mail is sent. This will be the name of the machine belonging to the provider you found up in step 4 of Before You Begin Installing, page 13.	kewgate

Here is toscis's completed UUPC.RC file, provided as an example.

Nodename=toscis

Domain=toscis.cambridge.ma.us

postmaster=fbwatt

Mailserv=kewgate

MailExt=SPB

InModem=TB2500

options=displaycopyright

Note: toscis has some additional fields defined in its UUPC.RC. We left them in this example to remind you that more complicated configurations are possible if you choose.

2. The second file to edit is the [userid].RC file, defining personal configuration options.

The [userid].RC files configure UUPC/extended for individual users. To configure your own [userid].RC file, copy the file \UUPC\SAMPLES\PERSONAL.RC to \UUPC\[userid].RC, where [userid] is your user name. Edit the [userid].RC file fields listed Table 4 - Minimum [userid].RC fields to Update for New Installation, below.

Example: Fred's personal configuration file is called FBWATT.RC, and is located in C:/UUPC on toscis.

Table 4 - Minimum [userid].RC fields to Update for New Installation

Field name	Description	Example
Mailbox	Your user id.	fbwatt
Name	Your real name	Frederick B. Watt
FileSent	Name of a file to which all outgoing mail is saved. Omit this field entirely (delete the line) if you don’t want to save outgoing mail.	Outgoing
Signature	Name of a file which will be appended to each message sent.	fbwatt.sig
Home	The default directory UUPC/extended uses to find files (including the FileSent and Signature Files) for your user id.	C:\fbwatt

The UUPC.RC and [userid].RC files on page 115 and the descriptions in the sample PERSONAL.RC file explain these fields. If you include a Signature (highly recommended) and an Alias file, you will need to create these files as well. See step 9. on page 23 of this section for information on creating a signature file. See User Mail Nickname File, page 148, for a discussion of nickname files.

If multiple users are to share the same system, create multiple customized copies of the [userid].RC in \UUPC, each with a unique name such as "TOM.RC", "DICK.RC" or "HARRY.RC".

Example: Fred's completed FBWATT.RC file looks like this:

editor=emacs %s

FileSent=Outgoing

Home=c:/fbwatt

Mailbox=fbwatt

Name=Frederick B. Watt

options=noautoedit

Signature=fbwatt.sig

3. You must next decide which existing modem configuration file ([modem].MDM file) best describes your modem, or write a new one. See Modem ([modem].MDM) Files, page 128, for a complete list of supplied modem files.

Copy the modem file for your modem from the \UUPC\SAMPLES directory to the \UUPC directory.

Note: If none of the supplied samples is appropriate, then you will have to start with one of them, or with the sample modem configuration file (SAMPLE.MDM), and customize it for your modem. We explain how to customize modem files in Modem ([modem].MDM) Files, page 128, and in The Fine Art of Chat Scripts, on page 143.

Once you copy the [modem].MDM file, replace the port listed on the "Device=" with the communications port to which you connected your modem.

Note: If using a modem on DOS and your modem is on port COM3 or COM4, you may need to run the COMM34 utility. Refer to COMM34, page 52, for details.

4. You must copy and edit the sample SYSTEMS file, which defines the system names to call and when to call them. Copy it from \UUPC\SAMPLES directory to the \UUPC directory. Delete all the entries you do not need.

Note: The SYSTEMS file and its contents are described in detail in The SYSTEMS file on page 137.

A typical line in the SYSTEMS file contains these fields, defined in more detail by Table 5 - Contents of a Simple SYSTEMS File, below:

system Time MODEM speed telephone protocol script

Table 5 - Contents of a Simple SYSTEMS File

Field name	Description	Example
system	Name of the system. Any system you call or are called by must be listed at least once in this file. You may include the same system more than once if you have multiple phone numbers for it.	kewgate
Time	When to call. "Any" is what it says, "Night" and "Evening" refer to night and evening phone rates respectively. "Never" is used for a system which only calls you.	Any
MODEM	Name of the modem file (without the .MDM extension) used to call this system.	TB2500
Telephone	Telephone number to call	781-279-9816
p (protocol)	Protocol to use when calling. If you don't know what these are, then leave the "vg" alone-- this tells the remote system to use "v" if supported, otherwise to use "g". The "g" protocol is widely supported, "v" is faster but is only supported by newer UUPC/extended systems and Taylor UUCP systems.	vg
script	Login script for the system.	gin:--gin: Utoscis ssword:--ssword: AppleJuice

Example: Toscis's SYSTEMS file entry for kewgate looks like this:

kewgate Any TB2500 19200 781-279-9816 vg gin:--gin: Utoscis ssword:--ssword: AppleJuice

Copy this line into your SYSTEMS file, and do the following:

Replace "kewgate" with the name of your mail server.

* Replace "Any" with the time to call.

Replace "TB2500" with the name of the modem configuration file (.MDM file) you are using.

Replace "781-279-9816" with the phone number of the mail server you arranged a feed from in step 4 of Before You Begin Installing, page 13.

Replace "Utoscis" with the name your provider gave you in step 4 of Before You Begin Installing, page 13, for use on their system. Replace "AppleJuice" with the password your provider gave you.

For simple connections, these should be all of the changes you need to make to this file. For more complex connections, refer to The Fine Art of Chat Scripts, on page 143.

5. You must also create a \UUPC\PASSWD file, which defines the local users. This file is nearly identical in format to the /etc/passwd file used on UNIX systems.

At first, you should need only two lines in your PASSWD file. The following example can serve as models.

Example: tosci's PASSWD file looks like this, with entries for Fred himself and the postmaster:

fbwatt:*:::Frederick Watt:c:/u/fbwatt
postmast:*:::Postmaster:c:/u/postmast

Replace fbwatt with your user name, and "Frederick Watt" with your name. Replace "c:/u/fbwatt" with the Home directory given in your [userid].RC file. Leave the postmaster entry in the file (you can choose a new home directory); it exists to catch any failed mail.

Note: For a full description of the PASSWD file, see The PASSWD file on page 136.

6. The \UUPC\PERMISSN file is identical in format to a file called Permissions available on newer UNIX UUCP systems. The file format is explained in detail in Using & Managing UUCP.

The PERMISSN file is used to control where remote systems are permitted to read and write files on your system. For a simple configuration where you call only a mail server and no machines call your system, your PERMISSN file should look like this:

MACHINE=kewgate SENDFILES=yes REQUEST=yes

Replace "kewgate" with the name of your mail server, managed by your provider in step 4 of Before You Begin Installing, page 13.

For more complex configurations refer to the section Permissions (PERMISSN) Files, on page 29.

7. Under DOS, you need only update CONFIG.SYS if it does not exist, exists but does not have a FILES= line in it, or the FILES= value is less than 20. In any of these cases, add or replace the following line to your CONFIG.SYS, or create a CONFIG.SYS in the root directory of your boot disk or diskette if you currently do not have one:

FILES=20

Note: If you already have a FILES= line in your CONFIG.SYS, it should read at least 10 and should be raised to 20. If the number is greater than 20, then do not lower it.

If you are using OS/2, then you must update CONFIG.SYS in the same way you would update AUTOEXEC.BAT under DOS.

8. AUTOEXEC.BAT is executed by MS-DOS whenever you reboot your system and by Windows NT at login. UUPC/extended needs three environment variables set, which is best done by adding some commands to your AUTOEXEC.BAT file. At the bottom of your AUTOEXEC.BAT file, add the following lines. If you are running OS/2, add the same lines to your CONFIG.SYS file.

set UUPCSYSRC=c:\uupc\uupc.rc

set UUPCUSRRC=[userid].RC

But instead of writing [userid] on the second line, use your user name, the same as in the [userid].RC file you wrote above.

Under Windows NT, you don't need to modify CONFIG.SYS or AUTOEXEC.BAT at all. Instead, use the System Properties applet in the Control Panel. The UUPCUSRRC variable is optional under Windows NT.

You'll also need to set TZ, your local time zone. The format of the TZ variable is zzz##dddwhere zzz is the name of the time zone, ## is the offset in hours from Universal Standard Time (AKA GMT), and ddd is the name of the daylight savings time zone, if used.

Note: The offset from GMT is specified as positive number if you are west of the prime median (Western Europe and America), and a negative number if east of the prime meridian (Eastern Europe, Asia, Australia).

Note: UUPC/extended does not actually display the time zone name, but rather uses the actual hour offset in mail header messages. The number is negated from the value specified in the TZ variable, however, because the convention for UNIX environment variables (and used by the various C runtime libraries) is different than the standard for Internet mail.

Various possible TZ variable values are listed in Table 6 - Sample Time Zone (TZ) Environment Variable Values, below. Your mileage and time zone may vary.

Table 6 - Sample Time Zone (TZ) Environment Variable Values

TZ Value	Description
CST6CDT	Central Standard Time, 6 hours behind GMT, with daylight savings
EST5EDT	Eastern Standard Time, 5 hours behind GMT, with daylight savings
EST5	Eastern Standard Time, but no daylight savings change
GMT0	Greenwich Mean Time, no offset, no daylight savings
MST-3	Moscow Standard Time, 3 hours ahead of GMT, no daylight savings
MST7MDT	US Mountain Standard Time, 7 hours behind GMT, with daylight savings
PST8PDT	US Pacific Standard Time, 8 hours behind GMT

8. You'll also need to edit your path variable. Fred, who put his UUPC/extended executable files in C:\UUPC\BIN, added the line:

PATH=%path%;C:\UUPC\BIN

at the bottom of the file. In DOS, you must make sure the path does not exceed 128 characters. Under OS/2, the file you need to edit is CONFIG.SYS. There is no path size limit under OS/2, but the path must be on one line and cannot use variables. Under OS/2, Fred would simply append ";C:\UUPC\OS2BIN" to his existing path.

Note: Several of the programs, including uucico and uuxqt, change directories as required to search for spool files. Because of this, programs such as RMAIL and (if used) RNEWS must be in your path. Having them in the current directory is not sufficient.

9. For each user, customize the [userid].SIG file, and copy it to the 'Home' directory defined in [userid].RC for that user. This file is appended to all outgoing mail from the user, providing a boiler-plate signature with the user's reply address. If this file is not installed, then the line in the [userid].RC file describing it must be commented out with a pound sign (#) in column 1.

Note: Especially for users of new systems, we strongly advise you to create a signature file and include in it your name, electronic mail address, snail mail address, and telephone number. This extra information helps others contact you if your electronic mail address fails for any reason.^{^[18]}

Example: Here's a typical (boring) signature:

Fred Watt -- N1HMB Home: 617-555-9956

fbwatt@toscis.cambridge.ma.us Work: 617-555-4330

10. Reboot your system. This allows your changes to your AUTOEXEC.BAT/CONFIG.SYS to take effect.

Congratulations! If you've done all of these things, you are ready to start using UUPC/extended.

Testing

1. Begin testing by running the UUNAME program.

Just type UUNAME at a system prompt to prove your configuration is valid. This program will a) die gloriously or b) display a list of known systems (the remote systems you listed in your SYSTEMS file). If it dies, the error message you get should provide some clues. Check the necessary configuration files and try again.

2. Run uuxqt to check the PERMISSNS file information.

Type uuxqt at a system prompt. This program will a) die or b) print a copyright message and exit. If it dies, there is a problem with your PERMISSNS file and the error message you get should provide some clues. See Permissions (PERMISSN) Files, page 29, for more information.

3. Send mail to yourself.

Perform this test to convince yourself that UUPC/extended can send mail. At the system prompt, type:

C:\> mail -s "Test message" postmaster

? Test

? .

Abort, Continue, Edit, List, or Send? Send

Note: The "." only works as a message terminator if the "dot" Boolean option is set in your UUPC.RC file, as it is in the supplied sample. Otherwise, you have to use Ctrl-Z.

You should then receive the message:

Delivering mail from userid to postmaster

If you don't, the error messages should provide some clues. Correct the necessary configuration files and try again.

3. Test the PC <-> modem connection.

Perform this test to convince yourself that your modem responds to commands. Using a telecommunications program such as Kermit, send some commands to the modem. Just sending AT (attention) to the modem, and getting "OK" back,^{^[19]} is good enough.

4. Test the PC <-> modem <-> modem <-> mail server connection.

Perform this test to convince yourself that your computer can talk to your mail server, and that you can log in to the mail server using the user name and password your provider back in "Before You Begin Installing", step 4, on page 13, gave you. Using a telecommunications program like Kermit, dial up the remote system and try to log in. The remote system should give you a message like "Shere=[mailserv]". If you succeed, hang up^{^[20]} and go on to the final step. If the remote system does not recognize your account for some reason, talk to the provider who gave you the account and find out why.

5. Try sending remote UUCP mail.

If this test succeeds, your system is able to properly receive and send electronic mail. At the system prompt, type the following:

C:\> mail -s "Test message" postmaster@[mailserv].UUCP

? This is my first message. When you receive it, please reply.

? .

Abort, Continue, Edit, List, or Send? Send

Spooling mail from [userid] to postmaster via [mailserv]

but instead of typing "[mailserv]," on the first line, substitute the name of your mail server, exactly as you entered it on the "MailServ=" line in your UUPC.RC file.

Note: For full instructions on using the program, see MAIL, page 61.

If all goes well, you should be able to enter a message and send it off, with the mail program giving you messages like those above.

Then, dial out to the remote system:

C:\> uuio -s all

And watch the connection. With luck, you will have just sent your first UUCP mail message. Welcome!

All Dressed Up and No Where to Go?

Under certain circumstances, you may have installed your system and have no one to call. If you feel lonely and hurt over this state of affairs, you can call kewgate anonymously and download a UUPC/extended file or ten for the cost of the phone call. See Anonymous UUCP, page 168, for instructions.

Upgrading an Existing Installation

Follow these steps to upgrade.

1. If upgrading from a release of UUPC/extended prior to 1.11a, you must clear your spool directories of files before installing the new release. In general, this is done by invoking UUIO for the previous release to deliver any queued files to other sites.

2. Backup your system, especially the UUPC/extended directories.

3. If upgrading from MS-DOS to Windows 3.x, OS/2, or Windows NT, create new directories for the new operating environment binaries.

4. Delete or rename your old executables. Subtle file name changes occur between releases, such as file extensions changing between .COM and .EXE files, and this clearing out the executables directory is the safest way to insure you get the all new modules.

5. Uncompress the new executables and documents. Be careful not to overwrite your customized configuration and batch files with the supplied sample files. See page 15 for the list of files to uncompress for your operating system.

6. Read Changes From Previous Versions, page 180, for changes related to the newest release. In many cases, Changes From Previous Versions includes documentation of new configuration file variables and Boolean options before any other documents.

7. Earlier versions of UUPC/extended have different user-customizable variables. Type "uuname -x 2" to see a list of missing or obsolete variables in your configuration files.^{^[21]} Update as needed. Look at Changes From Previous Versions, page 180, to see what the new variables do.

8. If you are converting from a release previous to 1.10a, you must update the SYSTEMS file to the newer format. You must also write a PERMISSN file. See the sample files for details.

9. If upgrading from a previous OS/2 32-bit release of UUPC/extended which included DLL files, delete the DLL files from the previous release. (1.12i was the first OS/2 32 bit release with DLL files.)

10. If using the 32-bit OS/2 version, copy the new supplied DLL files to a directory in your LIBPATH list of directories. They cannot go into the binaries directory (\uupc\os2bin32) unless you have added the directory to your LIBPATH and rebooted.

11. If using the 32 bit OS/2 version and you do not have either or the Internet Access Kit (provided with OS/2 Warp) or IBM TCP/IP 2.x (or newer), replace the TCP/IP enabled versions of UUCICO and RMAIL with the serial-port only versions. To do so:

Rename UUCICO.EXE to UUCICOT.EXE

Rename uuCICON.EXE to UUCICO.EXE

Rename RMAIL.EXE to RMAILT.EXE

Rename RMAILN.EXE to RMAIL.EXE

12. If upgrading from a release previous to 1.12a, see the new section Modem ([modem].MDM) Files beginning on page 128 to determine if you should update your modem file(s) to take advantage of new options and keywords.

13. If running Windows 3.x on top of DOS, you may optionally install the Windows versions of uupoll, and uucico and uupoll. See Using UUPC/extended Under Windows 3.x, page 38, for additional Windows information.

14. Based on Changes From Previous Versions, page 180, and other documentation, update your configuration to exploit any new features of UUPC/extended you find useful. In particular, if using the OS/2 version of UUPC/extended, consider setting the Boolean option undelete in your UUPC.RC file.

15. Change or add a line as applicable to the UUPC.RC configuration file with the version= configuration file keyword and the current version number, for example:

Version=1.13j

Configuring Usenet News Support

Using UUPC/extended for news requires a few steps on top of the basic installation procedures defined above. The exact nature of these steps depends on whether you are using a news reader program which uses the C-news like support native to UUPC/extended, or a third party news engine such as SNEWS or Network News Systems for Windows/NT. In all cases, the general steps include:

1. Select and install program to read news.

2. Arrange a news feed

3. Configure the local system

4. Test

These topics are covered in more detail in the following sections.

Selecting a news reader

Since UUPC/extended does not come with a news reader of its own, you must chose and a news reader separately. Among the possible choices and the systems they run on include:

· RNR (DOS)

· TRN (OS/2)

· SNEWS (DOS, OS/2)

In addition, NNS (which is actually a full function news delivery system) can be used under Windows/NT to provide NNTP support to a host or network connected to the outside world via UUCP. This allows use of any NNTP compliant news reader under Windows/NT or other client on the same network as a Windows/NT server.

Arranging a News feed

Unlike mail, which is specifically addressed to a particular user and delivered on request of the sender, Usenet news must be subscribed on a group by group basis from a connected system already receiving it. This system can be your existing mail feed or a second system. If your primary mail feed cannot provide news, locating a news feed is much like locating a mail feed as described in Before You Begin Installing on page 13, that is to say painful. In addition to the normal information exchanged between you and another mail site (telephone numbers, login information), you must tell also your news feed what news groups you wish to receive. If you understand the Usenet hierarchy you may have specific groups in mind, otherwise ask the news feed what groups it receives and select off that list.

Warning: A full news feed requires hours a day of modem connect time to receive and hundreds of megabytes to store for any length of time. Select only those groups you actually want, especially if working on a personal system with limited free space.

Configuring for News

No matter what program you use to process news, if your news feed is not a system already defined to UUPC/extended, you must add the information for the system to SYSTEMS, PERMISSN, and (if the system is calling you) PERMISSN files.

Normal Configuration

1. Verify you have installed the expire, iNEWS, newsrun, rNEWS, SENDBATS, and uux programs as part of UUPC/extended.

2. If your news feed will be compressed, install a program to uncompress it. Programs commonly used to do this are gzip and compress. After installing the program, you may need up the uncompress= variable in the UUPC.RC file.

3. If you have multiple disk partitions on your system, you may wish to move the news spool directory from the default directory (\uupc\news) to a different drive. To so, specify the NewsDir= in the UUPC.RC directory.

4. Create a news ACTIVE file, documented in usenet News ACTIVE Groups File on 153, with all the news groups you will be reading locally.

5. Create a news SYS file, documented in Usenet news SYS (neighbours) file on page 155, to define your news feed and any other sites you wish to forward news to.^{^[22]}

6. Tell your news feed to start sending news.

7. Be sure to run expire daily. This can be done directly or via the UUCLEAN script.

Configuration for use with NNS

NNS is a self-contained network news server for Windows NT, and can run stand alone using the TCP/IP based NNTP protocol to process news. News is stored in multiple files and indexed in a NNS specific database. The system can be used as a leaf site or to feed multiple other sites. NNTP based news readers on Windows/NT or other systems on the same network can then access the articles stored on the NNS server.

Because NNS performs its own management of news, UUPC/extended is only used a news transfer program, allowing news to be sent and received via the UUCP protocols rather than the NNTP protocol that NNS natively supports. When using NNS with UUPC/extended, news is queued with UUX, transmitted to remote sites using UUCICO, and passed to the remote news system using RNEWS.

Once your news feed system is defined and you can exchange mail with it, you need to:

1. Install NNS if you have not done so.

2. Verify you have installed the RNEWS, regsetup, and uux programs as part of UUPC/extended.

3. If your news feed will be compressed, install a program to uncompress it. Programs commonly used to do this are gzip and compress. After installing the program, you may need up the uncompress= variable in the UUPC.RC file.

4. Add the Boolean option nns to your UUPC.RC file.

5. Run the program regsetup to copy the UUPC/extended configuration information to the Windows/NT registry for use by NNS.

6. Tell owner of your news feed to begin sending news.

Configuration for use with SNEWS

SNEWS is a self-contained news database and reader for DOS and OS/2, but requires another program such as UUPC/extended to exchange news with remote systems. The system best used as used as a leaf site.

Because SNEWS performs its own management of news, UUPC/extended is only used a news transfer program; mail is queued with UUX, transmitted to remote sites using UUCICO, and passed to the remote news system using RNEWS.

Once your news feed system is defined and you can exchange mail with it, you need to:

1. Install SNEWS if you have not done so.

2. Verify you have installed the RNEWS, and uux programs as part of UUPC/extended.

3. Add the Boolean option snews to your UUPC.RC file.

4. Tell the owner of your news feed to begin sending news.

Permissions (PERMISSN) Files

Each system you contact must be defined in a PERMISSN file located in the configuration directory. In the permissions file, systems can be classified by whether they are called out to or dial in to the local system, or both. Permissions files define which directories and commands are accessible to the remote system. They are discussed in more detail in Using & Managing UUCP.

For your own protection, think carefully before giving a remote system read or write access outside of the default (\uupc\public, \uupc\spool) directories. Think very carefully before giving write access to anonymous logins.

Systems you call out to must have a MACHINE entry, such as

MACHINE=pandora

This defines the existence of the machine "pandora", and grants it default permissions. These permissions include the ability to execute RMAIL and RNEWS, and the ability to send files to the spool directory. If the additional keyword REQUEST=yes is added to the MACHINE statement, then the remote system may also read and write files in your public directory, which defaults to \uupc\public or can be redefined by the variable PubDir in the UUPC.RC file.

Systems which dial into you must have a LOGNAME entry, such as:

LOGNAME=userid VALIDATE=system SENDFILES=YES

This allows host "system" to login as user id "userid" with the same default permissions as described above. It further allows your system to transmit files to the other system even though it called you (SENDFILES=YES)^{^[23]}. However, to run uuxqt the remote system must also have a MACHINE entry, because uuxqt does not look at LOGIN entries.^{^[24]} Thus, to handle the general case of a system calling you to deliver mail, both of the above entries must exist in the permissions file, but they can be combined:

LOGNAME=userid       \
            VALIDATE=system      \
            MACHINE=system      \
            SENDFILES=YES

The remote system can be granted access to additional directories and programs through the use of additional parameters on the LOGNAME and MACHINE statements; these are documented in Using & Managing UUCP.

If you allow anonymous logins, an entry should also be placed in the PERMISSN file for the system "*anonymous". Such an entry might look like this:

LOGNAME=nuucp \
            MACHINE=*anonymous \
            REQUEST=yes \
            READ=~/ NOWRITE=~/

This allows anonymous UUCP systems to login as nuucp (provided nuucp has an entry in your PASSWD file), and to read but not write to your PubDir.

Note: One difference between the PERMISSIONS file as defined in the Nutshell Handbooks and as implemented in UUPC/extended is that only one user id may be specified per LOGNAME entry in UUPC/extended. This restriction is a security feature to prevent one system from logging in as another.

PERMISSN files can be difficult to set up and use, so don't be alarmed if you have some trouble at first.

“Any sufficiently advanced technology is indistinguishable from a rigged demo. “

-- Andy Finkel

Part 3: Advanced Mail Installation and Configuration

This section explains how to use nickname, alias, and other files to control mail addressing and routing. Also, look here for information about networks, specialized communications drivers, and interfacing UUPC/extended to third party programs.

Changing How Mail is Addressed and Delivered Locally

An Overview of RMAIL

Much of the advanced configuration you can do with UUPC/extended involves changing how RMAIL delivers mail when invoked by MAIL (for locally originated mail) and UUXQT (for remotely originated mail). The formal description of RMAIL and its parameters is on page 75, and should be reviewed. In addition, a short summary of the default processing for mail sent from a local user is in order:

1) The user generates mail via the MAIL command.^{^[25]}

2) The user presses “s” to send the mail. The destination addresses entered by the user are processed by MAIL, which attempts to resolve them as described in Implicit Nickname Processing, (or, What Your Bear Never Told You about Aliases) on page 33. Then RMAIL is invoked.

3) RMAIL reads the headers for the newly created message, and decides to whom the message is addressed.

4) RMAIL invokes a subroutine called deliver() for each address.

5) deliver() determines if the destination address is local, remote UUCP, remote SMTP, or handled by a gateway program.^{^[26]}

6) For remote UUCP mail addresses, the mail is queued for uucico to transmit at a later time.

7) For remote SMTP mail, the mail is queued in the local host UUXQT queue for deferred processing under the conditions:

· The RMAIL was compiled without internal SMTP support. This is always true for the DOS version, and also for the alternative OS/2 version (RMAILN).^{^[27]}

· The -t option is provided on the RMAIL command line (the MAIL command always provides this) and the Boolean option fastsmtp is not set.

8) For local mail addresses, the system alias file is checked for the address. If the alias exists, it is expanded without checking the PASSWD file. The addresses in the expansion are processed via a recursive call to deliver(), except that addresses read directly from the system alias file are not checked to be system aliases again.

9) If the local address is not defined as a system alias, then the PASSWD file is searched. If the address is not a local user id, then the mail is bounced (delivered) to the local postmaster. If the "bounce" option is set, the mail is also returned to the sender.^{^[28]}

10) If the local address is valid, then the addressee's home directory is checked for a file named FORWARD. If this FORWARD file exists, it is processed for delivery instructions, otherwise the mail is delivered to the addressee’s system mailbox.

There are a number of ways to customize this processing to route mail to non-default files, to programs, or to other systems.

Using Nickname Files, Alias Files, Forward Files, and the HOSTPATH file

Aliases in electronic mail serve two purposes. First, the alias file works like an e‑mail address book, allowing an individual user to type a familiar nickname (fred) rather than a long full address (FFlintstone@dino.bc) to address mail.

Second, aliases allow groups of users (such as mailing lists) to be addressed through a single standard address. Under UUPC/extended, aliases are stored in two different types of optional alias files: the NICKNAME file, documented in User Mail Nickname File on page 148, and the system ALIASES file, documented in System Mail ALIASES File on page 146. The nickname file is used only for mail sent by a local user using the MAIL front end. The system alias file is used for all local addresses processed by the RMAIL command.

Many mail systems (including UUPC/extended) also support a user forwarding his/her own mail via an optional FORWARD file^{^[29]}. The processing performed by the FORWARD file overlaps that of the system ALIASES file. The primary difference between the system ALIASES file and an individual's FORWARD file is that the former is generally maintained by a system administrator for all special addresses in a system or network, while the latter file is maintained by the end user for just his own mail.

In addition to the files described above, UUPC/extended supports aliasing and re-routing entire systems via an optional HOSTPATH file. This file allows mail for entire remote systems to be treated as local mail, rerouted by a non-default path, or directed to an arbitrary program for further processing.

Implicit Nickname Processing, (or, What Your Bear Never Told You about Aliases)

When the MAIL command processes an address, it first attempts to find a matching entry in the NICKNAME file. If no match is found, mail looks for the user id and host on the address side of the NICKNAME and PASSWD lists, in that order. If a match is found, then the associated address and user name information are entered just as if the nickname had been used. (This behavior insures that a "standard" address is used for replies to mail.) If no match is found, and the address being processed does not include a system name, then the current value of FromDomain is appended to the userid.

Controlling Mail Routing for Entire Systems and Subdomains

Overview of Mail Routing

By default, the MAIL command and RMAIL command combine to deliver mail in the following fashion:

1. Mail to a user id without a host name is delivered locally, as described in An Overview of RMAIL on page 31.

2. Mail to the current system's host name (as defined by the UUPC.RC NodeName= line) is delivered locally.

3. Mail to the current system's domain name (as defined by the UUPC.RC Domain= line) is delivered locally unless the FromDomain= line is defined in UUPC.RC.

4. If a FromDomain= line is defined in UUPC.RC, then mail to the current system's domain name (as defined by the UUPC.RC Domain= line) is queued for the system listed on the UUPC.RC MailServ= line.

Note: The use of the FromDomain= keyword is further documented as part of The Ever So English Sport of Site Hiding, page 35.

5. Mail to a simple system name or a system of the form system.UUCP listed in the SYSTEMS file is queued for that system.

6. Mail to a system with a system name listed in the SYSTEMS file and the local domain name^{^[30]} is queued for that system.

7. All other mail is queued for the system defined as the mail server by the UUPC.RC MailServ= line.

You may sometimes need to override the default processing rules. For example, a system which is not directly connected may still be routed via a system other than the default mail server, or the local system's mail may be passed to a gateway program for delivery on a LAN. UUPC/extended handles such overrides via a HOSTPATH file, the basic syntax of which is described in HOSTPATH routing file on page 151.

Routing Mail Via Non-Default Mail Servers

As noted above, mail for other than the local system or directly connected systems is routed to the default mail server. This behavior is desirable when a system only handles mail destined for a mail server and/or a few other systems. However, if directly connected systems other than the mail server call additional systems, then UUPC/extended must be explicitly told about the additional mail routing.

For example, if the local system calls system fee in addition to its regular mail server, and fee provides the cheapest route to systems fie, foe, and foo, then the following entries would be required in the HOSTPATH file:

fie              fee
foe             fee
foo              fee

Once fie, foe, and foo are defined, additional systems can be routed via these connections, up to one hundred systems deep:

giant                      fie
bean.sales.com     foe
*.bean.stalk.com   foo

Note the sub-domain reference for *.bean.stalk.com: mail for all systems that may exist in that domain (low.bean.stalk.com, middle.bean.stalk.com, way.up.there.bean.stalk.com) will be routed via fee, foo, and then on to the bean.stalk.com domain.

Note: If the name of the directly connected system does not appear in the SYSTEMS file, the system is presumed to be routed via the default mail server. This exception effectively negates the routing entry in HOSTPATH.

Routing Mail for SMTP Delivery

Beginning with UUPC/extended version 1.12s, the 32-bit RMAIL client can deliver mail to remote hosts over an TCP/IP network. To direct mail to be delivered via SMTP, add to the hostpath file:

name @ any.internet.host.name
*.domain @ another.internet.host.name

Where the names on the left of the at-sign (@) are the names to be routed, and the names on the right are the valid host names of the SMTP servers to be contacted.

Note: It is legal to specify the host specified in the configuration variable mailserv as routed via an SMTP server. This means all mail going via the mailserv will also be sent via the SMTP gateway.

Keeping Local Mail on the Local System

A special case of routing occurs when a route is specified via the local system. If an otherwise unknown system or domain is defined to be routed via the local system, mail for that system is rejected as unreachable and bounced. The gateway for a domain can thus prevent mail from leaving the domain via a HOSTPATH entry like so:

*.my.domain.com localhost

If the local system is localhost, then mail for systems within the my.domain.com domain which are not listed in the SYSTEMS file or in a more specific HOSTPATH entry will be bounced by the local RMAIL. (Mail for the mail server will itself will be delivered normally, because the mail server is defined in the SYSTEMS file.)

Aliasing Systems Via The HOSTPATH File

At times, it is not enough to route mail via a particular system. For example, if a downstream system^{^[31]} is renamed (or has a different domain name than the upstream server), then the two names for the system must be made equivalent via the HOSTPATH file. For example, to define bull as an alias of cow:

bull = cow

If a system is both aliased and explicitly routed, then the route will override the alias.

Aliases for systems are taken into consideration when performing implicit nickname lookups. Thus, if the system bull is aliased as above and a nickname exists for a user at system cow, mail sent to the user at system bull will use the nickname for user at system cow. For a full discussion of implicit nickname processing, see Implicit Nickname Processing, (or, What Your Bear Never Told You about Aliases), page 33.

The Ever So English Sport of Site Hiding

One special combination of routing and aliasing is so common as to not always even require a HOSTPATH entry at all. Site hiding, which allows multiple systems to share a single domain name^{^[32]} to the outside world, is enabled by the FromDomain= keyword in the UUPC.RC file. This keyword overrides the Domain= keyword in selected mail headers, and automatically aliases the value of the Domain= header to the mail server. For example, if four systems, all in the "forest.oz" domain, share the domain name used by their mail server, then each hidden system will have UUPC.RC entries like:

Domain=lions.forest.oz
FromDomain=forest.oz
MailServ=toto

Domain=tigers.forest.oz
FromDomain=forest.oz
MailServ=toto

Domain=bears.forest.oz
FromDomain=forest.oz
MailServ=toto

Domain=ohmy.forest.oz
FromDomain=forest.oz
MailServ=toto

Mail from each of the systems would appear to come from forest.oz, and internally UUPC/extended would automatically alias toto to forest.oz. Mail to a simple user id would be expanded to include the FromDomain name, which would mean it would also be routed to toto.

Setting up the central server for site hiding requires a small amount of additional work. Each user on each hidden system must have a corresponding entry in the system alias file on the central server (See System Mail ALIASES File, page 146.). You must use either the full system name (lions.forest.oz, etc.) or the simple system name (lions, tigers, bears, ohmy ...) in the system aliases file, not the FromDomain which is the same for all systems. The mail server can be defined to be hidden as well, with UUPC.RC entries like:

NodeName=toto
MailServ=wizard
Domain=toto.forest.oz
FromDomain=forest.oz

However, in this case, you must use a HOSTPATH entry to define forest.oz as an alias of the local system:

forest.oz = toto

Otherwise, mail for forest.oz would be forwarded to the mail server, in this example wizard.

UUPC/extended as a Mail Gateway

An additional use of the HOSTPATH file is to redirect mail to an external program for processing. This processing is invoked via the or bar (|) separating the victim from the canonical name. In this case, the canonical name is actually the program to run. The following arguments are passed to the program:

The victim for whom routing is being done.

The actual host name of the addressee.

The user id of the addressee.

The mail to be delivered is read by the gateway program from standard input. For example, to route all mail for the funky.lan.com domain to a gateway program called foogate, add the following to the local HOSTPATH file:

*.funky.lan.com | foogate

UUPC/extended and Simple Mail Transport Protocol (SMTP)

A special case of mail gatewaying is moving mail between the UUCP and SMTP environments. Commencing with version 1.12s, UUPC/extended includes intrinsic support for exchanging mail with remote hosts via TCP/IP to SMTP mailers. This SMTP support is in three parts:

· The UUSMTPD server which receives mail under OS/2 or Windows NT.

· The SMTP enabled RMAIL, which under OS/2 or Windows NT can transmit mail to a SMTP server defined in the HOSTPATH file.

· The non-SMTP aware RMAIL client for DOS.

The functionality of these components is discussed in the sections below.

Receiving Mail via the UUSMTPD Server

General UUSMTPD daemon setup

To receive mail via SMTP protocol, you need to:

· Have an OS/2 or Windows NT based PC with the TCP/IP network stack installed and available to other machines.

· Define to other systems using SMTP mail that the PC can receive SMTP mail.

· Have the native OS/2 or Windows NT version of UUPC/extended installed.

· Run the UUSMTPD server directly (Windows NT or OS/2) or via the master Internet daemon inetd (OS/2 only).

The UUSMTPD server itself requires no additional configuration to run, although like all UUPC/extended mail programs various routing and other tuning is possible to handle special cases. See the UUSMTPD command reference on page 102 for an additional discussion of the server options and parameters.

Note: In its default configuration, the server will reject mail it does not recognize as either to or from a local user.

The SMTP server will pass all mail received to the same back-end used by RMAIL, so routing delivery takes place just as it had been received by the UUCP protocol and handled by RMAIL.

Directing Mail to the UUSMTPD Host

The primary issue with processing SMTP mail is have the server machine on-line and defined to other machines that it can receive SMTP mail; unlike UUCP where a peer machine can contact a remote system, authenticate itself with a password, and then request the bi-directional exchange of mail, the system with mail to send (the client) is always responsible for contacting the remote delivery machine (the server), and so the host name and/or IP address of the server must be known beforehand.

Note: Because the server name must be defined before use and accept connections on demand via TCP/IP, only continuously available hosts with statically assigned names can used for receiving SMTP mail. ^{^[33]}

The actual definition of remote SMTP servers is performed in a number of ways depending on the sending software:

· The most general method used for most Internet mailers is via the domain name servers MX (mail exchanger) record. These records define the names and ordering of hosts to attempt delivery to for mail. Definition of DNS servers and the general use of MX records is beyond the scope of this manual; contact your DNS administrator for additional details on MX record configuration.

· For Web browsers such as Netscape Navigator/Communicator, Microsoft Internet Explorer and IBM OS/2 Web Explorer, all have configuration parameters to allow specifying the address of the local SMTP server. For such browsers, the name of the UUSMTPD host should be specified.

· For another UUPC/extended system, the routing SMTP host(s) is specified in the HOSTPATH file; see HOSTPATH routing file on page 151

UUPC/extended and POP3 clients

Most POP3 clients including Netscape Navigator, Netscape Communicator, and Microsoft Internet Explorer retrieve mail using POP3 and send it with SMTP. This means you must run both the UUPOPD and UUSMTPD servers locally to service such clients.

If you one or more users to be able retrieve mail using UUPOPD, define each user in the PASSWD file with a valid password and as a member of the group pop3. Allow mail to be delivered normally, and then either UUPOPD or the MAIL command can be used to read it.

Note: You need not be connected to the Internet to use a web browser to read/send mail via UUPC/extended if you create a local hosts file or setup a local DNS service.

UUPC/extended in Multi-tasking and Multi-user Environments

Some consideration should be given to running UUPC/extended in environments other than, especially where those environments DOS may allow background and/or concurrent access to data used by UUPC/extended. These considerations are discussed in the following sections.

Using UUPC/extended Under Windows 3.x

Our general advice is, don’t run UUPC/extended under Windows 3.x. Use the DOS version on old systems, and on newer systems upgrade to Windows 95, OS/2, or Windows NT. Use of UUPC/extended with these operating systems is discussed in the following section, Using UUPC/extended Under OS/2, Windows 95, and Windows NT, on page 40.

Unlike the DOS, Windows NT, and OS/2 versions of UUPC/extended, the Windows version is not self-sufficient; the Windows version exists primarily to support uucico in the Windows environment, alleviating performance problems with the DOS version of the uucico program under Windows. Windows versions of most of the utilities (UUSUB, UUCP, etc.) are also included.

However, the Windows version of MAIL is a straight port of the DOS MAIL program (it does not support pull down menus or dialog boxes), and both MAIL and uuxqt operate more efficiently under DOS than Windows. Binaries for these programs and their support modules RMAIL and RNEWS are not included in the Windows archives.^{^[34]}

We specifically recommended that the DOS versions of MAIL, uuxqt, and RMAIL be used in conjunction with the Windows versions of uupoll, uucico, and the various status reporting programs.^{^[35]} To do so, install the supplied Windows programs in the \UUPC\WINBIN directory and when running Windows place the \UUPC\WINBIN directory before the \UUPC\BIN directory in your PATH. You may need to alter your path when you enter and exit Windows.

If you use the Windows version of uuxqt or MAIL, you must also use the Windows versions of RMAIL and RNEWS. A special flag (-f) is passed to RMAIL and RNEWS to take the place of file redirection, which is not available under Windows.

See General Advice on Multitasking Environments on page 45 for various considerations to keep in mind when running multiple copies of UUPC/extended programs on a single system.

Note: Under Windows 3.x, only one copy of uucico can run at a time. This is a Windows restriction on programs with multiple data segments.

Warning: As this document went to press, specific minor problems were known to exist with gracefully shutting down uupoll, and the manual pages for both uupoll and uucico should be reviewed before using these programs under Windows. Please report any problems with the Windows version to help@kew.com.

Using UUPC/extended Under OS/2, Windows 95, and Windows NT

UUPC/extended programs run as 16-bit^{^[36]} native text mode applications under OS/2 1.3 or 2.x and as 32-bit native text mode applications under OS/2 2.x, Windows 95, and Windows NT. Both Windows NT and Windows 95 use the same binaries. Given enough system resources, either OS/2 or Windows NT can support multiple uucico/uupoll and/or UUSMTPD processes in background without affecting foreground performance. DOS versions of all programs except uucico and UUSMTPD can also be used in the respective DOS compatibility boxes. The DOS uucico (and by extension uupoll) should not be used in a DOS box because overhead from simulating the DOS serial port environment can impact transfer speeds and can cause transmission errors (resulting in resent data, further impacting transfer speeds).

Note: DOS performance problems under OS/2 can be somewhat alleviated by using an OS/2 specific FOSSIL driver (such as the one supplied with the SIO.SYS driver), which uses blocked I/O.

Under both OS/2 and Windows NT, a passive uucico listening on a serial port can be suspended by another uucico dialing out or by the UUPORT command. This allows a terminal emulator such as Kermit to use the serial port without shutting down a poll running in background. The process of suspending and resuming the port can even be automated via a command file such as:

@echo off
uuport -s com1
kermit %1 %2 %3 %4 %5 %6 %7 %8 %9
uuport -r com2

It is not possible to suspend a uucico listening on a network port (named pipes or TCP/IP), but these connections generally use unique addresses reserved for UUCP transfers.

See General Advice on Multitasking Environments, page 45, for various considerations when running multiple UUPC/extended programs at once.

Using UUPC/extended On a LAN

UUPC/extended can be used in a LAN environment via a shared network drive, or with Universal Naming Convention (UNC) share names. In addition, uucico has limited direct network support (see Specialized Communications Drivers on page 41, below).

However, it is not possible to protect the configuration directory from the network nodes (MAIL and RMAIL require access to the SEQF, PASSWD, and SYSTEMS files), and thus local users can learn the passwords for remote systems and, in some configurations, read other users' mail. Network administrators must decide if this restriction presents a security exposure.

Note: Effective with release 1.12a, the SYSTEMS file and PASSWD files can be renamed using the UUPC.RC variables Passwd and Systems. Thus, two similar UUPC.RC files pointing at different sets of SYSTEMS and PASSWD files can be used; general users can access world readable files (with fake password data) in order to get mail routing information. A specially authorized user can access the live SYSTEMS and PASSWD files used by uucico to make and accept calls.

Even if all workstations on the LAN are running DOS, you should see General Advice on Multitasking Environments, page 45, for various considerations when running multiple UUPC/extended programs at once.

Configuring Universal Naming Convention (UNC) Names

UUPC/extended can be configured using Universal Naming Convention (UNC) names instead of conventional file names to refer to its configuration files. UNC names look like this:

\\machinename\sharename\path\filename.ext

Where machinename is the name of the remote system where the share point is located, sharename is the name of the remote share point, and path and filename.ext are just like normal paths and file names. Many PC network operating systems, including Novell, Lantastic, Windows for Workgroups, and Windows NT, allow you to use UNC names when opening files over the network.

Note: If you use UNC names in your UUPC.RC or [userid].RC files, you must make sure that RMAIL.EXE and RNEWS.EXE can be found in the path, or that the path= line is specified in UUPC.RC to point to the UNC share point and directory where RMAIL and RNEWS can be found.

Example: Some typical lines that might be in a UUPC.RC configured to use UNC names might be:

Path=\\dino\uupc\dosbin
ConfDir=\\dino\uupc
NewsDir=\\dino\uupc\news

Specialized Communications Drivers

Drivers Available Under Different Environments

Specialized communications drivers are enabled in a modem file via the Suite= keyword as described in Table 17 - Modem File Configuration Keywords on page 129.

Under MS-DOS, uucico supports connections driven by:

1. The internal communications driver (COMM), which directly controls to the Universal Asynchronous Receiver/Transmitter (UART) driving the serial port.

2. A generic FOSSIL (Fido-Opus-Seadog Standard Interface Layer) interface which supports any FOSSIL (INT 14) driver conforming to Version 5 of the FOSSIL specification.

3. An INT 14 BIOS level driver. The standard IBM PC BIOS interface is too slow for most serial connections (resulting in transmission errors), but many packages, such as LAN modem sharing software, emulate it.

Under Windows 3.x, Windows NT, and OS/2, uucico will use any serial device supported by the system. In addition, TCP/IP connections over a LAN be made if such support is installed under OS/2 (32 bit only), Windows 3.x or Windows NT. Under OS/2 2.x, named pipe connections can be made over a LAN if such support is installed.

For connections which uucico does not directly support via LAN protocols (i.e. IPX or NETBIOS), RMAIL can be used as a gateway to appropriate file transfer programs. See UUPC/extended as a Mail Gateway, page 36, for details.

Using with TCP/IP based hosts

UUPC/extended will communicate to the uucp port (decimal 540) of any system which supports UUCP connections on this port. Because the TCP/IP protocols guarantee reliable delivery, faster protocols which do little error checking (such as 't' or 'e') can and should be used in place of the slower but more robust modem-oriented protocols (such as 'g' and 'v').

For connecting other systems to a local system running UUPC/extended over a TCP/IP link, you may fire off a uucico running in passive mode with a modem file which specifies the suite=TCP/IP keyword (see Table 17 - Modem File Configuration Keywords on page 129). Under OS/2 with IBM TCP/IP running, you can run the supplied uucpd script to fire off uucico and then have the remote system connect as if the uucico were running continuously.^{^[37]}

Connecting to remote UNIX systems via an active polling is more complicated. The UUPC/extended system again uses a modem file which specifies suite=TCP/IP, and includes the host name to connect to in place of the phone number in the systems file. But, it's like this — not all UNIX systems are created equal. Because of bugs in some versions of the UNIX uucpd daemon (known to exist on the USL System V 4.1 box we tested with), connecting via TCP/IP may not work under the following conditions:

1. The UNIX system uses a shadow password file (a copy of passwd which only root can read) and /etc/inet.conf defines the user id to run uucpd as uucp or other non-root user id.

2. The shell for the user connecting to the UNIX system is not the same as the shell expected by the uucpd daemon; it normally looks for /usr/lib/uucp/uucico.

3. The UNIX system uses a shadow password file and uucpd does not look in it for the login passwd.

Note: One check for this condition is to determine the name of the shadow password file on your system and then run the UNIX strings program on both the uucpd module and the ftpd module. If the shadow password file name is listed in the ftpd module but not the uucpd module, then most likely the uucpd module is missing shadow password support and must be replaced.

Using FOSSIL communications drivers with UUPC/extended

As noted above, the DOS version of UUPC/extended supports using a special type of communications driver called a FOSSIL (Fido-Opus-Seadog Standard Interface Layer). A number of drivers support the FOSSIL standard, and these drivers are used by a wide variety of PC bulletin board programs, particularly in the FidoNet electronic mail and bulletin-board world. Because of this large installed base, FOSSIL drivers are robust and have been tested on a variety of systems.

While the internal COMMFIFO driver handles most serial ports with no trouble, FOSSIL drivers allow uucico to run on an even wider variety of systems. FOSSIL drivers can be used with uucico to support any of the following situations:

FOSSIL drivers are already installed for other programs.

Special serial port configurations such as non-standard interrupts for COM3 or COM4.

uucico using COMMFIFO cannot initialize the modem.

Running DOS uucico under OS/2.

Note: Kendra Electronic Wonderworks does not endorse or support any particular FOSSIL driver.

Here's how you configure UUPC/extended versions 1.11z and later for use with FOSSIL drivers.

Materials needed:

A FOSSIL driver

A text editor

The latest version of PKUNZIP

Steps to perform:

1. Get a FOSSIL driver.

2. Install the FOSSIL driver.

3. Edit your .MDM file, adding Suite=FOSSIL.

4. Reboot your system if CONFIG.SYS was edited.

5. Test the results.

Instructions:

1. Get a FOSSIL driver. These are available from many sources, including by anonymous UUCP from kewgate, and by anonymous FTP from any Simtel-20 mirror site, including wuarchive.wustl.edu and ftp.uu.net. Three drivers tested with UUPC/extended are:

BNU170.ZIP

OCOM_531.ZIP

X00V124.ZIP

Other FOSSIL drivers should work as well.

2. Install the FOSSIL driver.

The FOSSIL drivers all come with installation instructions. You will have to tune them for use with UUPC/extended, however. If you have a high-speed modem (9600 baud or greater), and you use large window-size protocols like G or v, you will need to install your FOSSIL driver with larger transmit and receive buffers than the defaults. The largest size you should need is 8 KB.

See the FOSSIL driver's instructions for further details.

Examples:

For a high-speed configuration, here are the settings our friend Fredrick Watt used for installing each of the three tested FOSSIL drivers on toscis:

BNU170: Nothing was added to CONFIG.SYS. In AUTOEXEC.BAT, Fred added the BNU directory to the path and then added:

BNU /T:4096 /R:4096 /F- /Z0

X00V124: Nothing was added to AUTOEXEC.BAT. In CONFIG.SYS, Fred added:

DEVICE=C:\X00\X00.SYS E F=15 R=4096 T=4096

OCOM_531: Nothing was added to CONFIG.SYS. In AUTOEXEC.BAT, Fred added the directory with the driver to the path and then added:

OPUSCOMM
OCOM_CFG C S2=4096,4096

Note: S2=4096,4096 set the communications buffers for COM2 only -- your setting may differ depending on your communications port. Read the instructions for the driver.

3. In your .MDM file, add the line Suite=fossil.

Example: In toscis' TBWORLD.MDM file, Fred added the line DOS.Suite=FOSSIL. Since toscis runs more than one operating system, Fred needed DOS.Suite so that OS/2 and Windows NT would still use the internal serial port drivers. If you don't use additional operating systems, there is no need for the DOS. prefix.

4. Reboot your system.

If everything was configured properly, you'll get a sign-on message from the FOSSIL driver you installed.

5. Test the results.

Call one of your neighbors with the new driver, and enjoy.

When things go wrong

Check the driver’s buffer sizes. uucico, which can queue 4K of data at once, can easily overrun the standard buffer sizes used by FOSSIL drivers.

The FOSSIL driver documentation is often helpful. In addition, several of the FOSSIL driver packages come with diagnostic programs that display the status of various RS-232 lines, so you can see whether data is actually being sent.

General Advice on Multitasking Environments

UUPC/extended includes specific support for environments where more than one program may be accessing UUPC/extended files at a time. Some of this support, such as checking the time stamp of a mailbox before overwriting it when exiting MAIL, requires little additional processing time and is always active. Other support requires special processing and must be enabled via the addition of the Boolean option multitask to the options= line in the UUPC.RC. Under DOS, you should also load the SHARE TSR program.

Note: Under all environments except DOS, the Boolean option multitask should always be enabled in the UUPC.RC file, and it may be enabled under DOS without ill effects. You must enable multitask if you run UUPOPD, UUSMTPD, and/or set the Boolean option bounce. This latter restriction applies even under DOS.

Specifically, the Boolean option multitask enables:

If a “Permission Denied” error is returned when opening a file, UUPC/extended retries up to 10 times waiting for the file to become available.

Log files are written to temporary files in the spool directory and then appended to the permanent log in the logging directory when the program exits.

The SYSLOG file, if enabled by the Boolean option syslog, is opened and closed for each file transmitted or received.

uucico creates a lock file when connecting to a system to insure only one conversation at a time can go on with that system.

uuxqt creates a lock file when processing commands from a system to insure only one uuxqt at a time is processing commands from that system.

When mail is read from the system mailbox for a user, it is copied to the user's home directory and the system mailbox is cleared to allow additional deliveries while the user is reading mail.

This additional processing prevents such conflicts as multiple programs writing to log files or mailboxes, and attempts to insure programs do not abort when files such as the SEQF file are being updated and are thus inaccessible. The only major remaining exposure is that a program can explicitly write to a mail file in a user's directory, but this situation is uncommon and MAIL will detect when the file size or date changes and warn the user before losing the other program's changes.

Passive Polling: Letting Other Systems Call You

What if you want to have other systems dial in to yours to route mail and news, rather than calling them? To configure UUPC/extended to allow other systems to call yours, you will need to modify several of the configuration files.

In addition, the owners of the other systems will have to modify configuration files on their machines. For UUPC/extended systems, see Configuring After Installation, page 16. Configuring non-UUPC/extended systems is beyond the scope of this documentation, but descriptions of how to configure many other systems can be found in Using & Managing UUCP.

To allow a remote system to dial in, you'll need to do the following:

A. Modify your SYSTEMS, PASSWD, and PERMISSN files.

B. Test your machine's new configuration.

C. Test having their machine call yours.

Example: Let's assume that one of your UUCP neighbors, whose machine is named "bosox," decides that she wants to be able to dial in to your machine, called "snuffles."

1.Modifying your SYSTEMS, PASSWD, and PERMISSN files

We'll go through the changes that need to be made to each of these files one at a time.

1. SYSTEMS

In your SYSTEMS file, you will need to add a line for the remote system.

If you already successfully call the other system, then the existing line in your SYSTEMS file is good enough: leave it alone.

If you don't already call the remote system, then add a line to your SYSTEMS file that looks like this:

Example: bosox Never TBWORLD 38400 999-9999

Replace bosox with the name of their machine.

As described in The SYSTEMS file, page 137, the second entry on this line describes how often the remote system is called. "Never" means that you never call the remote system. Because you never call them, the modem type, outgoing baud rate, phone number, and protocol fields are not used. Despite that, they still have to be filled in.

2. PASSWD

You will also need to add a line to your PASSWD file for the remote machine. For more information about the PASSWD file format, see the documentation in the file itself, or in step The PASSWD file of Configuring After Installation, page 136.

The PASSWD line you'll want to add will look something like this:

Example: Ubosox:Apple#Juice:::bosox

Replace Ubosox with their dial-in user name, Apple#Juice with their password, and bosox with the name of their machine. The name can be descriptive, since it's only used to report the login.

3. PERMISSN

For a simple configuration, add lines like the following to your PERMISSN file:

Example: LOGNAME=Ubosox VALIDATE=bosox MACHINE=bosox \
SENDFILES=yes REQUEST=yes COMMANDS=rmail:rnews

Replace Ubosox with their dial-in user name from your PASSWD file, and bosox with their machine name. The “\” is simply a continuation character.

Test your machine's new configuration

To test your new configuration, run UUNAME, and then uuxqt. If they do not print out any warnings, then you have probably configured your PASSWD, SYSTEMS, and PERMISSN files correctly.

Test having their machine call yours

Once your neighbor’s machine is configured, it can try calling in. For UUPC/extended, simply run uucico or UUIO:

uucico -s yoursystem or
UUIO -s yoursystem

For other UUCP packages, consult the documentation.^{^[38]}

Interfacing With Other Programs

Types of Support

UUPC/extended supports external programs in number of ways, most of which are documented as part of the individual programs. This external program support includes:

INEWS, NewsRUN, and RNEWS accept news for processing on the local system, saving it (as documented in RNEWS on page 78, and NEWSRUN on page 69) for processing by third party news packages such as TRN, SNEWS, and TIN.

RMAIL accepts RFC-822 mail (with some restrictions) from any mail user agent and performs delivery or other action as described under An Overview of RMAIL on page 31. Rmail also supports a direct interface to write the mail into a queue for other mailers as defined below in Using V-mail and Other Third Party Mailers on page 48.

uux allows queuing any command and its associated parameters for uuxqt running locally or remote program, subject to security restrictions.

UUCP allows copying files between any two systems, again subject to security restrictions.

Under DOS, uucico can be invoked by other programs which answered the phone and validated the user access to the system.

Under DOS, OS/2, and Windows NT, uucico can invoke external programs when that program is specified in the [ConfDir]\PASSWD file, and connection specific information such as the user id and port speed can be passed to the program as documented in Having uucico Invoke External Programs on page 49.

Those features not described as part of the various commands or in the description of mail delivery are covered below.

Using V-mail and Other Third Party Mailers

In order to efficiently drive V-Mail Server by Vandenburg Systems Research,^{^[39]}^,[40] UUPC/extended includes special support for writing mail directly in the external V-Mail queue. This support can also be used for interfacing to other third party mailers.

Note: Use of this interface has a major advantage over trying to read the UUPC/extended spool directory: the spool uses a complex mapping routine to map names between DOS's monocase file system and UNIX systems's mixed case file system.^{^[41]} The external queue support simply uses the true DOS name of the file.

As noted in System Mail ALIASES File on page 146, external queue support is enabled by an alias beginning with a greater than (>) sign. When such an alias exists, the mail as received is written into a file in the directory defined by the UUPC.RC variable VMSQueueDir=, with a prefix of UUPC followed by four unique characters and an extension of ".D".

A second file is written into the same directory with a name having the same format, except the extension is ".X". The .X file contains two lines. The first line begins with the letter D (data), followed by a space and the full file name of the associated file. The second line begins with the letter C (command), followed by the contents of the UUPC.RC variable Vmail=, and finally the contents of the original alias line following the greater than sign.

Thus, if the UUPC.RC file includes:

Vmail=e:\vms\mail.exe
VMSQueueDir=e:\vms\queue

And the system ALIASES file contains:

listserv: >-t listserv

Then, when mail is sent to Listserv on the local system, the contents of the mail will be written to a file E:\VMS\QUEUE\UUPC????.D and the additional file E:\VMS\QUEUE\UUPC????.X will be created containing:

D E:\VMS\QUEUE\UUPC????.D
C E:\VMS\VMAIL.EXE -t listserv

Of course, the external program (in the case of V-Mail, VMAIL.EXE) must be run to actually read the files and process them for mailing.

Invoking uucico From External Programs

Under all environments except Windows 3.1, uucico in passive mode can be invoked with the phone already off hook and user id and password validated by external program. To do so, use the speed (-z) and user id (-w) parameters to specify the processing already performed, and under Windows NT and OS/2, specify the port handle (-h). It is not possible to directly override the port name to be answered; you must override the modem file (where the port name is configured) instead.^{^[42]}

Having uucico Invoke External Programs

uucico may be invoked to validate access for and then invoke external programs if those programs handle the serial port in a compatible fashion. The standard command processors such as COMMAND.COM under DOS and CMD.EXE under OS/2 cannot be used because they do not talk to the serial port.

For the external program to be compatible, it must handle the port as follows:

Under DOS, the external program must provide its own communications handler to talk to the serial port or shares an external driver (such as the FOSSIL interface) with uucico.

Under OS/2 or Windows NT, the program must be native for the environment (OS/2 uucico cannot invoke an external DOS program), and must accept and operate on an open file handle.

Note: External shells are not supported under Windows 3.x

To invoke the external program, the program and any arguments must be specified as the last field in the PASSWD file as described in The PASSWD file on page 136. The program will be run from the specified home directory, but the home directory will not be searched for the program unless the full path name of the program is specified or the home directory is included in the PATH environment variable in effect when uucico is invoked.

In order for the program to receive information about its operating environment, the substitution parameters defined below may be used to pass information to it. All parameters begin with a percent sign (%) followed by a single character denoting the parameter to be inserted.

Table 7 - Substitution Parameters Allowed in Shell Field of PASSWD File

Parameter	Resulting Value	Example Output
%%	Single Percent Sign (%)	%
%l	File handle (OS/2 and Windows NT only)	3
%p	Port name	COM2
%s	Port speed	19200
%u %w	User id	Utoscis

Thus, a shell specified as:

/bin/myprog port %p baud %s

will be invoked as:

/bin/myprog port COM2 BAUD 19200

“When you're in command, command.”

-- Admiral Chester A. Nimitz

Part 4: Command Reference

Overview

This section describes the syntax of the commands supplied with UUPC/extended. It assumes you have installed the programs and configured them as described in Part 2: Basic UUCP Installation, page 11, and that you have access to the Nutshell Handbook Using & Managing UUCP.

Command Syntax

To obtain the syntax of the various command line options, enter the command name followed by '-?'; for example:

uuxqt -?

COMM34

Synopsis

comm34 port3 [port4]

Availability

MS-DOS only (possible in OS/2 DOS box, see below)

Description

COMM34 defines non-default addresses for communications ports 3 and 4 (COM3 and COM4) under MS-DOS. It does this by poking the provided operands into the BIOS memory segment at hexadecimal address 0040:0000, where uucico and other programs such as Kermit search for port addresses. It also displays all defined port addresses for COM1-4.

Note: This command is not available under OS/2, but may be used in an OS/2 DOS box. However, the preferred way to define port addresses for COM3 and COM4 for both OS/2 and DOS boxes under OS/2 is to add information to the relevant DEVICE= statements in the OS/2 CONFIG.SYS file.

Options

comm34 supports the following options:

port3 is the hexadecimal address for COM3, or 0 if omitted and port4 is specified.

port4 is the hexadecimal address for communications port 4.

Note: If using the native UUCICO communications driver, COM3 must use Interrupt Request Line (IRQ) 4 and COM4 must use IRQ 3. To use other IRQ’s, you must use a FOSSIL driver. See Using FOSSIL communications drivers with UUPC/extended on page 43 for additional information on FOSSIL drivers.

COMM34 must be run before uucico, and only needs to be run once, perhaps by putting the appropriate line in your AUTOEXEC.BAT file. If all operands are omitted, COMM34 displays a help screen and the current port assignments.

EXPIRE

Synopsis

expire [-x debuglevel] [-e days] [newsgroup newsgroup newsgroup…]

Availability

MS-DOS, Windows 3.x, OS/2, and Windows NT

Description

EXPIRE archives and/or deletes articles created by RNEWS in normal mode after a specified period of days. For EXPIRE to run, the ACTIVE file must exist. (See usenet News ACTIVE Groups File, page 153, for the layout of the ACTIVE file.) Articles are stored in the directory hierarchy defined by the NewsDir variable as they are received. EXPIRE deletes the articles after the period specified.

Options

The expire program supports the following options:

-e days Number of days news is to be kept in directories accessible to the user before being deleted. The default period is seven (7) days.

-x debug Display debug messages at or below level debug. The default value is 1, but the option may be set to 0 for unattended production use, or as high 20 for detailed debugging.

newsgroup The name of the newsgroup to scan for expired articles. The default is to scan all news groups in the ACTIVE file for articles to expire.

FMT

Synopsis

fmt [-#] [-c string] [-s] [input-file [output-file]]
fmt [-#] [-c string] [-s] [-i input-file [-o output-file]]

Availability

MS-DOS, OS/2, and Windows NT

Description

FMT is a simple paragraph formatter for use when entering mail in line mode. It effectively removes all carriage returns from within a paragraph and then writes the paragraph out in lines as close as possible to 72 characters in length without going over. Paragraphs are separated by blank lines in the input and output files.

Note: If the first word on a new line is longer than the maximum line length, it is written by itself on the line. It is not truncated.

Options

fmt supports the following options:

-# specifies the maximum line length as #. For example, -72 specifies the maximum line length as the default 72 columns.

-c string specifies that string is to be appended to at the end of each new line inserted. Note that if -s is specified, existing lines do nothave Istring appended.

-s specifies overlength lines are to split but no lines are to be joined together.

-i input-file specifies the name of the input file. The default is standard input.

-o output-file specifies the name of the output file. The default is standard output. If the output-file specified, the input-file must be specified as well.

input-file specifies the name of the input file. The default is standard input.

output-file specifies the name of the output file. The default is standard output. If the output-file specified as a positional operand, the input-file must be specified as a positional operand as well.

Examples

To format all the text you have typed in from line mode, use fmt as a pipe at the question mark (?) prompt while sending mail:

~|FMT

Bugs

The program doesn’t support all the options of the UNIX version, in particular it doesn’t handle hanging indents well.

Specifying both the option switch (-o or -i) for a file name and the positional arguments causes the positional arguments to silently override the option switch.

The program fails to preserve intra-line spacing, if even if it doesn’t need to do anything to the line. It’s specially rude about transforming nuking tabs into spaces to avoid having to determine how wide the the tab logically is.

See Also

MAIL, NOVRSTRK

History

Written by Drew Derbyshire of Kendra Electronic Wonderworks in August 1990. Added both the -c and -s options in a great hurry in May 1998 for a UUPC/extended Makefile hack which wasn’t actually needed. Also corrected inter-paragraph spacing in May 1998.

FROMWHO

Synopsis

fromwho [-l] [-s] [-n] [-a] [-f [mailbox]]

Availability

MS-DOS, OS/2, Windows 3.1 and Windows NT

Description

The fromwho command summarizes the contents of the specified mailbox, or of the current user’s system mailbox if no mailbox is specified.

Options

fromwho supports the following options:

-l Turn listing of users/subjects off.

-s Turn listing of subjects off.

-f mailbox Set the mailbox to summarize.

-n List only new mail

-a Show sender address instead of sender name

Bugs

The program does not fully support UUPC/extended mailbox names, and for example does not automatically add the standard mailbox extension.

Author

Originally by jearls@data.acs.calpoly.edu, modified for use with UUPC/extended by Kai Uwe Rommel.

GENHIST

Synopsis

genhist [-x debug]

Availability

MS-DOS, OS/2, and Windows NT

Description

GENHIST generates the history database used for processing Usenet news articles. It need only be run when the history database does not exist or has been corrupted. If you have upgraded your version of UUPC/extended from a version earlier than 1.12e, and you received news from one of your UUCP neighbors before you installed version 1.12e, then you will need to run this program to regenerate the history database.

Options

genhist supports the following options:

-x debug Display debug messages at or below level debug. The default value is 1. The option may set to 0 for unattended production use, or as high 20 for detailed debugging.

Bugs

None reported so far.

GENSIG

Synopsis

gensig fixed.inp variable.inp merged.out

Availability

MS-DOS, OS/2, and Windows NT

Description

GENSIG reads a standard signature file and appends random text selected from a second file, writing the combined data to a third file. The format of the command is:

gensig fixed.inp variable.inp merged.out

Where fixed.inp is the fixed portion of the signature file containing your name and address, and variable.inp is a file which begins which a delimiter line followed by quotes or other text separated by additional delimiter lines. For example, the variable input file might look like this:

**
The above is a delimiter line.
**
Free the Intel 386!
**
"UUPC/extended" is "system crash" spelled sideways.
**
Don't quote me!

The file merged.out will contain the entire text of the fixed.inp file followed by one delimited text block from variable.inp. If you use this utility to generate a signature file, then your [userid].RC should reference the file merged.out as your signature file.

Note: To generate fresh quotes, this program should be run from your AUTOEXEC.BAT or other regularly run batch file.

GETUUPC

Synopsis

result-string = getuupc( variable-name [, [ default-result ] [, personal-rc-name ]] )

Availability

OS/2

Description

The getuupc command is an external REXX subroutine used by other OS/2 UUPC/extended REXX commands to retrieve UUPC/extended configuration variables. Because it returns text strings, it cannot be executed from the command line in a useful fashion.

The program looks up the value of variable-name in the PERSONAL.RC file (if provided) and if not found then in the UUPC.RC file (as determined by the UPCSYSRC environment variable) and returns the value found there. If the variable is not found in the UUPC.RC file, then the default is returned. If the variable is not found and no default is provided, an empty string is returned.

Options

variable-name specifies the label of the configuration variable to be retrieved.

default-result specifies the string to be returned if no value is found for variable-name.

personal-rc-name specifies the name of a [userid].RC file to be searched before the system UUPC.RC configuration file.

Bugs

The retrieval function does not implement the entire range of functionality exploited by the various programs written in C. In particular, it doesn’t handle conditional prefixes on keywords, and the complex relative path name resolution used by the C programs cannot be emulated on the fly.

See Also

WAITING, UUCLEAN, UUHOUR

INEWS

Synopsis

inews -h [-x debug] [ < article ]

Availability

MS-DOS, OS/2, and Windows NT

Description

INEWS is a filter that posts articles to newsgroups. It reads the header and contents of the article on standard input, adds any headers or other information missing from the article text, and then passes the article to rnews for delivery.

The syntax of the INEWS command is:

inews [-x debug]

Where:

-x debug Display debug messages at or below level debug. The default value is 1. The option may set to 0 for unattended production use, or as high 20 for detailed debugging.

-h Doesn't do anything. It's there for UNIX compatibility.

Bugs

INEWS doesn't correctly support posting to moderated newsgroups.

See Also

PNEWS, RNEWS

MAIL

Command line interface for read and sending mail

Synopsis

mail [-x debug] [-p] [-t] [-f name]
mail [-x debug] [-p] [-t] [-u userid]
mail [-x debug] [-s subject] address ... [-c] address ... [-b] address

Availability

MS-DOS, Windows 3.x, OS/2, and Windows NT

Description

The MAIL command is used to both compose and read mail. It provides a human interface to the user mailboxes, and formats mail so the RMAIL command can deliver it to local and remote users.

If MAIL is invoked interactively with one or more addresses, it prompts for the subject of the message (if not provided via the -s flag), and then prompts for the text of the message either directly or via a user-specified editor. (See The UUPC.RC and [userid].RC files, page 115, to find out how to specify an editor. The program then prompts for the action to take (list, edit, input additional lines of text directly, abort, or send) until the message is sent or aborted. When sent, the required RFC-822 headers are added to the mail and the entire message is passed to RMAIL for delivery.

If MAIL is invoked with one or more addresses and the input is not the keyboard, then the input is taken without prompting or editing and passed to RMAIL with the appropriate RFC-822 headers.

If invoked without addresses, MAIL reads the user's system mailbox (or other mailbox specified on the command line), displays a one line summary of each message, and prompts for a user command with an item number and a question mark (?). Commands can be issued to read, save, delete, or send mail until the program is terminated by the quit or exit command.

The following option is always accepted by MAIL:

-x debug Amount of debugging information to display. The default is taken from the environment variable UUPCDEBUG if set and is otherwise 0. The higher the debug level, the more information overwhelms the unsuspecting user.

The following options are accepted when composing mail:

-s subject Subject of the message to send. Multiple words must be enclosed in quotes. This option must precede any addresses and the -c and/or -b flags, if supplied.

-c address One or more carbon copy addresses. Such addresses are listed under the CC: field of the RFC-822 header rather than in the To: field. One or more addresses must be listed after the -c flag.

-b address One or more blind carbon copy addresses. Such addresses are listed under the Bcc: field of the RFC-822 header, which is dropped by RMAIL after processing. Thus, no one will see these addresses in the mail header.

The following options are accepted when reading mail:

-f filename Name of the file to read rather than the system mailbox. See below for the syntax of accepted file names.

-u userid Name of the user whose system mailbox is to be read.

-t Rather than display who mail is from in the summary, display who the mail is to. This option is automatically enabled for the file defined by the UUPC.RC variable FileSent= (See The UUPC.RC and [userid].RC files, page 115, for a further explanation.), which defines where a copy of mail you send is saved. If the -t flag is specified for the FileSent= file, it reverts to normal processing (displaying whom the mail is from).

-p Print all the mail in the specified mailbox and exit.

Types of operands

In the list of commands available when reading mail, messages refers to one or more messages in the mail box. These items can be specified in one of the following ways:

Table 8 - Valid message Operands for MAIL Subcommands

Operand	Description
Message Number	A single numeric value, the special character dot (.) to specify the current item, or the special character dollar sign ($) to specify the last item in the mailbox.
Message range	Two message numbers separated by a hyphen (-). The messages must be in ascending order; for example, 1-$ is valid, but $-1 is not.
List of messages	A list of message numbers and/or message ranges, separated by spaces. The list need not be in ascending order. An example is: 1-5 8 7 14-17.
Asterisk (*)	Selects all messages in the mailbox
Subject	A slash (/) followed by a subject to search for, optionally followed by a terminating slash. Each Subject: or Resent-Subject: will be searched for the specified string. An example is /UUPC bugs/
User id	A single word (no white space) appearing in the From or Resent-From lines of the mail header. Note that if the command accepts both an item and a userid, you cannot specify the item as a user id. Note: If the command accepts both an item and file name and you specify a user id for the item, you must explicitly provide the default filename unless the user id includes the characters at sign (@), percent sign (%), or exclamation point (!).

Some commands also allow file names as operands. File names may look like any of the following:

Table 9 - Valid filename Operands for MAIL subcommands

Type of file	Description	Example
Simple file name	An MS-DOS file name with no path name	snuffles.spb
Relative path name	An MS-DOS file name with one or more back slashes (\) which does not begin with a back slash or drive letter.	mail\snuffles.spb
Absolute path name	An MS-DOS file name with one or more back slashes (\) which begins with a back slash or drive letter.	d:\uupc\snuffles.spb
UNC name	Universal Naming Convention name. A file located on a network server.	\\kewgate\uupc\mail\snuffles.spb
Mailbox	A simple file name prefixed by the plus sign (+) character. This will cause the file be referenced as if it is the mailbox for the specified user. For example, +postmast refers to the mailbox for user postmast.	+snuffles
Relative to your home directory	A simple file name preceded by a tilde and slash (~/). The file is then referenced by the prepending the home directory listed in your [userid].RC to the simple file name.	~/oldmail/snuffles.spb
Relative to another's home directory.	A simple file name preceded by a tilde, the userid, and a slash (~userid/). The file is then referenced by the prepending the home directory listed in the PASSWD file for user "userid" to the simple file name.	~snuffles/oldmail.spb

When sending mail from the command line or via the mail or forward commands, the destination address must be entered. Acceptable addresses look like any of the following:

Table 10 - Valid address operands for MAIL subcommands

Address type	Description	Example
userid	A simple user id, for delivery on the local system.	snuffles
userid@node	A user id and node combination, for delivery to userid on system node.	snuffles@kew.com XE "Kendra Electronic Wonderworks:kew.com"
node!userid	A user id and node combination, for delivery to userid on system node	smersh!kendra!snuffles
nickname	A user or list defined in the user's aliases.txt file or local system aliases file.	pbear

If the flag -c is inserted before a user id, then mail to the following users is sent as Carbon Copy (Cc:) addresses. If the flag -b is inserted before a user id, then mail to the following users is sent as blind carbon copies, whose addresses do not appear in the mail header. The blind carbon copy flag must follow all normal and carbon copy addressees.

Example: mail -s "Test message" Snuffles -c athena!binkley -b software@kew.com

Commands available when reading mail

Commands are entered in response to the mail question mark prompt (?). All commands must be separated from their operands, if any, by white space. Most commands can be abbreviated to a single character; the commands which cannot be so abbreviated and their shortest allowable abbreviation are debug (deb), dquit (dq), previous (pre), set (se), and status (st). Note that several of the command names are case sensitive.

The following commands can be used within MAIL:

Table 11 - Mail subcommand summary

Command	Description
empty line	If the current message has not been read, then an empty line acts as a print command; otherwise, it acts as a next command.
! command	Executes command as an MS-DOS, OS/2, or Windows NT command. If command is omitted, runs an inferior command processor (which gives the user a new command prompt.)
?	Prints a summary of available commands.
+ integer	Alias for next command.
- integer	Alias for up command.
alias a1 a2 a3	Displays alias information loaded from the user's aliases.txt file for nicknames a1 a2 a3. If an alias is a list of other aliases, then the list is recursively exploded and displayed. This command has no default operand; at least one alias must be specified.
copy items file	Copies mail items into file with headers. Default file is the printer on device PRN.
debug integer	Sets internal trace level to integer. The default is 0 when mail starts, and gets set to 1 if you just type "debug" without entering an integer. The internal trace level can also be set by the command line flag -x.
delete messages	Sets status of messages to deleted. Deleted messages are ignored when selecting mail by subject or user id, and are purged from the mailbox when the quit command is issued. See also undelete.
dquit messages	Short for delete followed by quit.
exit	Exits mail without updating mailbox; deleted items are left alone. Compare this to the quit command.
forward messages address	Resends messages to address. Note that if the askcc Boolean option is set, each message forwarded will be prompted for Carbon Copy addresses.
go messages	Positions to the last of the messages selected.
headers	Displays summary information for all items in the mailbox.
Headers items	Displays summary information for the selected items in the mailbox.
help	Prints this long help text.
mail -s subject address mail address	Interactively send mail to address with optional subject.
next integer	Move down in mailbox by integer items. Default is 1.
previous integer	Alias of up command.
print messages	Display messages from the mailbox, using the external pager if defined in the configuration file and ignoring (not printing) a standard list of RFC-822 fields in the mail header such as Received: and Message-Id:. Compare this to the Print, type, and Type commands.
Print messages	Display messages from mailbox, using internal pager and ignoring (not printing) a standard list of RFC-822 fields in the mail header.
quit	Terminates the reading of mail. All deleted messages are purged, and all other messages are saved in the original mailbox or in ~/mbox depending on the setting of the save flag.
reply messages	Interactively sends mail to the authors of each of the messages requested. Note that each item is replied to separately, specifying "reply 1-10" will send ten pieces of mail to ten people.
save messages file	Saves the specified messages complete with mail headers into file, and then deletes the messages. Compare this to the copy and write commands.
set	Sets various Boolean options. These options can also be set in your [userid].RC file. The options are listed in The UUPC.RC and [userid].RC files, page 115.
status	Reports miscellaneous information, including: The version and creation time of the program The operating system version The current user address and related information The current file name, size, and date last updated
type messages	Display messages from mailbox, using external pager if available and displaying RFC-822 fields suppressed by the print command. Compare with the print, Print, and Type commands.
Type messages	Display messages from mailbox, using internal pager and displaying RFC-822 fields suppressed by the print and Print commands.
undelete messages	Changes status of messages to unread.
up integer	Move up in the mailbox by integer items. Default is 1.
write messages file	Writes messages to file without the RFC-822 headers and then deletes them from the mailbox. The default file is ~/mbox. Compare with the copy and save commands.
xit	Alias for the exit command.

Subcommands available while sending mail:

The commands in Table 12 - Subcommands Available While Sending Mail are available when entering mail text in line mode. Line mode is automatically entered when sending mail unless the editor Boolean option is enabled or after selecting Continue (C) at the send mail prompt. The commands must be entered at the beginning of an input line, in columns one and two.

Table 12 - Subcommands Available While Sending Mail

Command	Description
~a	Insert standard signature file.
~A	Insert alternate signature file.
~e	Invoke editor on current message.
~m item	Include body of message(s) defined by item, indented.
~M item	Include message(s) define by item with headers, indented.
~f item	Include body of message(s) defined by item, without indenting it.
~F item	Include message(s) define by item with headers, without indenting it.
~p	Print message entered so far using external pager.
~P	Print message entered so far.
~r file	Read in an arbitrary file.
~s subject	Add new subject or replace existing subject with subject
~v	Alias for ~e command (for compatibility with UNIX sendmail).
~?	Display this mail subcommand list.
~\|command	Filter message entered so far through command
~!command	Execute command (does not alter message)
~~	Enter a data line beginning with a tilde (~)

Note: The ~m and ~M commands use the same syntax for items as the main mail parser; this allows specifying message number(s), user id, or subject. Type "help" at a MAIL prompt for a detailed description of the allowed syntax.

Note: The exact meaning of ~p and ~P commands are inverted by the use of the pager Boolean option.

Files

/tilde.hlp Help file for tilde (~) commands when sending mail.
/mail/[userid].spb System Mailbox for [userid].

Bugs

Command line option checking is not as robust as it could be.

The automatic advancing of the current item pointer to an undeleted item makes multiple operations on a deleted item interesting.

Under MS-DOS, redirection from NUL looks like a device, not a file, and thus the program prompts for input when it has no business doing so.

MAIL incorrectly parses an return address with a quoted exclamation point, such as:

"Smarter than the average bear!" <snuffles@kew.com>

Some editors, like EDLIN, cause the signature file to be lost because the editor appends a ^Z (Ctrl-Z) to the file.

The reply command gets confused by mixed mode addresses.

How MAIL determines return addresses is sometimes flaky.

There is no 'Replyall' command to reply to all interested parties to a message.

In MAIL, entering '1' should print the first item in the mailbox if the Boolean option autoprint is set. Currently, it doesn't.

See Also

RMAIL, MAILCHEK

MAILCHEK

Synopsis

mailchek

Availability

OS/2

Description

mailchek uses OS/2 Visual REXX to put up a small window which automatically reports the mail waiting for all users of the system. The command accepts no operands.

Bugs

Visual REXX is not provided as part of base OS/2 or as part of UUPC/extended. It has to be obtained from IBM anonymous sites, such as software.watson.ibm.com.

Running the application can cause some systems to hang. This is no doubt a problem with REXX or the Visual REXX DLL, since the mailchek script itself has no intent, facility (or even ability) to hang the system.

See Also

WAITING, FROMWHO

NEWSRUN

Synopsis

newsrun [[-f | -F] filename] [-x debug]

Availability

MS-DOS, OS/2, and Windows NT

Description

NEWSRUN processes incoming news from other systems, and is normally never directly invoked by the user. It is invoked automatically by RNEWS upon the arrival of news at the local system or by INEWS when a local user posts an article. In either case, NEWSRUN is invoked directly when the Boolean option fastNews is set or otherwise via a uux command run by uuxqt .^{^[43]}

Article processing by NEWSRUN is controlled by the SYS file and the ACTIVE file. See usenet News ACTIVE Groups File on page 153 for the formats of these files.

Note: If the ACTIVE file does not exist or is empty, NEWSRUN will abort and the incoming news will be lost.

Note: If the SYS file does not exist, a default SYS file which accepts all remote news and sends all locally generated news to the news server is automatically generated.

Options

The options for NEWSRUN are as follows:

-f filename Specifies filename is to be used in place of standard input

-F filename Specifies filename is to be used in place of standard input, and the file is to be deleted after use.

-x debug Display debug messages at or below level debug. The default value is 1, but the option may set to 0 for unattended production use or as high 20 for detailed debugging.

Processing

News is processed as follows:

1. The ACTIVE file is loaded and the news history database is opened.

2. If news is batched with multiple articles per file transferred, then the articles in the file are written to a temporary file. The temporary file is then processed as a single article.

3. Each article is passed through the filters defined in the SYS file for the various defined systems. If an article passes the filters for any but the locally defined system, it is immediately queued or otherwise processed as defined by the SYS file. Articles for the local system are processed as defined below.

4. The news groups defined in article header are automatically overridden for all control messages; the article is saved in the group control if it exists in the ACTIVE file, or group junk if control does not exist and junk does. Newsrun automatically cancels (deletes) articles if it receives a cancel control message. If the Boolean option honorcontrol is set in UUPC.RC, then newgroup and rmgroup control messages are also processed.

For more details about control messages, see Using & Managing UUCP

5. If the message-id of the article is already in the history database, the article is saved in the group duplicates (if it exists in the ACTIVE file), and all other processing for the article is skipped.

6. The news groups line of the header is scanned for each article processed. For each group listed in the header which is also in the ACTIVE file, the article is copied to the group's directory under the next available article number.

7. If no valid local groups are defined in the header and the local group junk exists in the ACTIVE file, the article is saved to junk. Otherwise, the article is discarded.

8. Once all articles are processed, the ACTIVE file is written out with updated article numbers and the history database is closed.

Environment

If the environment variable UUCPSHADOWS is set to one or more space delimited system names and the SYS file does not exist, a default SYS file is generated to distribute all locally received articles to the remote systems. If the SYS file exists, the UUCPSHADOWS environment variable is ignored.

Bugs

Updates to the ACTIVE file can be lost if NEWSRUN crashes while writing it. Given an old ACTIVE file, the article numbers can be brought back up to date by running GENHIST.

See Also

EXPIRE, GENHIST, RNEWS, INEWS

NOVRSTRK

Synopsis

novrstrk [input-file [output-file]]

Availability

MS-DOS, OS/2, and Windows NT

Description

NOVRSTRK strips overstrikes from files with carriage control to allow viewing on a terminal. If used to display the UUPC/extended documentation, it will drop the overstrikes created when back spaces are used to create bold and underscored text on a printer. The syntax of NOVRSTRK is:

novrstrk [input-file [output-file]]

The default input and output files are the console.

PNEWS

Synopsis

pnews

Availability

OS/2 only

Description

pnews allows the user to post news under OS/2. It prompts for important information, like newsgroups to post to and subject information, and then invokes the user’s defined editor to create the body of the post and perform additional header edits, if desired. When the user is done editing and confirms the post, the program invokes inews to actually perform the post.

Options

This program accepts no command line options.

Bugs

The program should be ported from REXX to C so its available on all platforms, not just OS/2.

See Also

INEWS

REGSETUP

Synopsis

regsetup [-s] [-u ] [-c]

Availability

Windows NT only

Description

REGSETUP writes the contents of the UUPC.RC and [userid].RC files into the Windows NT Registry. It is provided to allow other Windows NT programs access to UUPC/extended's configuration data. REGSETUP also writes the UUPCSYSRC and UUPCUSRRC environment variables into the registry.

The UUPC.RC configuration information is written into HKEY_LOCAL_MACHINE; the [userid].RC configuration is written into HKEY_CURRENT_USER. UUPC/extended’s hive in the registry begins at "Software\Kendra Electronic Wonderworks\UUPC/extended", under either the HKEY_LOCAL_MACHINE or HKEY_CURRENT_USER keys. The configuration information is written into a subkey, whose name is the same as either the UUPCSYSRC or UUPCUSRRC environment variable's value.

Note: UUPC/extended will automatically retrieve the UUPCSYSRC and/or UUPCUSRRC values out of the registry if the environment variables are not set. Those are the only registry entries that UUPC/extended actually uses: it always retrieves the other configuration information from the text format configuration files. UUPC/extended ignores all other output from this program.

Options

regsetup supports the following options:

-c clears the current contents of the UUPC/extended hives in the NT registry.

-s writes the UUPC.RC file's contents into HKEY_LOCAL_MACHINE.

-u writes the [userid].RC file's contents into HKEY_CURRENT_USER.

These options can be used together. For example, if you run "REGSETUP -s -c", then the registry hive for UUPC/extended will be cleared before the new configuration data is copied into it.

Operational Notes

Once REGSETUP is run, this is how UUPC/extended resolves UUPCSYSRC and UUPCUSRRC under Windows NT:

1. It checks to see if the environment variables UUPCSYSRC and UUPCUSRRC exist. If they do, then it accepts those values.

2. If the variables aren't set, then UUPC/extended checks in HKEY_CURRENT_USER\Software\Kendra Electronic Wonderworks\UUPC/extended for a key called UUPCSYSRC and another key called UUPCUSRRC. If it finds them, then it uses those values.

3. If the variables aren't there either, then UUPC/extended checks in HKEY_LOCAL_MACHINE\Software\Kendra Electronic Wonderworks\UUPC/extended for a key called UUPCSYSRC and another key called UUPCUSRRC. If it finds them, then it uses those values. (These two steps are provided so that a user can override the default settings, if he or she so chooses, using the registry instead of environment variables.)

4. If none of these procedures result in a value being set, an error is reported and configuration initialization fails.

Bugs

REGSETUP does not write any of UUPC/extended's Boolean options (e.g. history, askcc, etc.) into the registry.

RMAIL

Synopsis

rmail [[-f | -F] filename] [-x debug] [-q] address(es)

rmail [[-f | -F] filename] [-x debug] [-s subject] -w address(es) [-c address(es)] [[-b address(es)]

rmail [[-f | -F] filename] [-x debug] -t]

Availability

MS-DOS, Windows 3.x (not distributed), OS/2, and Windows NT

Description

RMAIL is the Mail Delivery Agent (MDA) for UUPC/extended. Other programs such as MAIL and uuxqt pass it mail for delivery on standard input (STDIN), and RMAIL then handles actual writing to local mailboxes and/or queuing for remote systems. RMAIL is designed to be invoked from other programs, and as such, end-users should never have to invoke RMAIL directly. The following information is included primarily for those who need to invoke RMAIL from another program, such as an external news reader.

RMAIL operates in one of three modes, described below:

As an RFC-822 parsing back-end to the MAIL user agent program

As a stand alone mailer for utility programs such as uuxqt

As substitute for the UNIX RMAIL program invoked by uuxqt for remote mail delivery.

Options

-b address(es) Specifies optional blind carbon copy address(es). Must follow all other flags and addresses. Used only with -w flag.

-c address(es) Specifies optional carbon copy address(es). Must follow all other flags and addresses except for the -b flags and its associated addresses.

-f filename Specifies filename is to be used in place of standard input

-F filename Specifies filename is to be used in place of standard input. The file is deleted after use.

-s subject Optional subject. Used with and implies the -w flag.

-t Enables RFC-822 header parsing mode.

-w Enable stand-alone mailer mode.

-x debug Display debug messages at or below level debug. The default value is 1. The option may be set to 0 for unattended production use, or as high 20 for detailed debugging.

address(es) One or more addresses the mail is to be delivered to. Not used with -t flag, but required for other modes.

RFC-822 Mode

In RFC-822 mode, RMAIL is invoked with the (-t) flag, which directs RMAIL to determine the addresses by parsing the mail's RFC-822 header. This mode acts as the back-end to a program such as MAIL which generates the RFC-822 header and passes the mail to RMAIL for both local and remote delivery. RMAIL reads the header, validates the From: address, generates a UUCP From line, RFC-822 Message-ID: and Received: lines, and delivers mail to each address included in the To:, Cc:, and Bcc: headers. The Bcc: header, if any, is read for its addresses but not copied; all other header lines are copied as-is.

Note: When an RFC-822 header prefixed by Resent- is found, only the Resent- headers are used; the original headers are copied but otherwise ignored. In this case, the preceding description applies to the Resent- headers: the original headers are copied without being examined.

The RFC-822 header read by RMAIL is subject to the following restrictions:

All Resent- headers, if any, must precede the original headers.

The From: header must precede the To: header.

Note: If the address in the From: header does not match the address of the user defined in the UUPC.RC and/or [userid].RC files, a Sender: line is generated with the correct address.

The To:, Cc:, and Bcc: headers must be together in the listed order. Each address in these headers must begin on a new line and be less than 512 bytes long.

Stand alone Mode

In stand alone mode, RMAIL is invoked with the (-w) flag to process mail without an existing RFC-822 header, bypassing the Mail User Agent (MAIL) for specialized applications such as mail generated by another program. This mail is subject to the following restrictions:

Mail is not logged in the user's outgoing mailbox

The user's signature file is not appended to the mail

User aliases are not expanded

All addresses plus the subject (if any) must fit on the MS-DOS or OS/2 command line

The following services are performed by RMAIL in stand alone mode:

A UUCP From line is generated.

A valid RFC-822 header is generated with Received:, Date:, Message-ID:, From:, and To: lines. In addition, Subject: and Cc: lines are generated as required if the Subject (-s) and/or Carbon Copy (-c) options are specified.

The generated RFC-822 header also includes a From: user id derived from the environment variable LOGNAME^{^[44]}, if defined; otherwise the default current user is used. When LOGNAME is defined the real name of the user will be taken from the UUPC/extended PASSWD file if available, or a dummy name will be used.^{^[45]}

Mail is queued for the addresses on the command line, including primary addresses, carbon copied addresses, and blind carbon copied addresses. As with RFC-822 mode, the output of RMAIL in stand alone mode does not include any reference to blind carbon copy users in the actual mail header.

UNIX RMAIL Emulation Mode

In the absence of other options, rmail runs in UNIX RMAIL emulation mode. The following processing takes place:

Mail is read in to a temporary file. The UUCP From line, which is the first line in the file, is parsed and stripped from the mail. No other mail headers are examined.

Mail is delivered to each local user on the command line with a UUCP From line generated from the system name(s) parsed from the incoming From line.

Mail is delivered to all other users on the command line with a UUCP From line generated from the system name(s) parsed from the incoming From line, with the system name from which uuxqt received the mail prefixed to the list unless it is already the first system in the list.

Note: uuxqt normally passes the incoming system name in the UU_MACHINE environment variable, if set. Otherwise, the incoming system name is taken from the "remote from system" portion of the From line. If this data is also missing or invalid, the incoming system name is generated as being from the local system and user id /dev/null.^{^[46]}

Bugs

All RFC-822 address data within quotes is ignored. It should be processed in accordance with RFC-822.

With the bounce option enabled, RMAIL only bounces mail back to the address it parsed from the information passed by uuxqt; it does not examine the RFC-822 headers for fields such as Errors-To:.

RNEWS

Synopsis

rnews [[-f | -F] filename] [-x debug]

Availability

MS-DOS, OS/2, and Windows NT

Description

RNEWS processes incoming news from other systems, and is normally never directly invoked by the user. It is invoked automatically by uuxqt upon the arrival of news at the local system.

RNEWS reads the news on standard input, and distributes news to various internal and external news programs depending on how the configuration options snews and nns are set in the UUPC.RC configuration file:

· If the Boolean option snews is set, a copy of the input data to rnews is saved in the NewsDir with a unique name and a file extension of .ART; the news is not uncompressed, unbatched or otherwise pre-processed. It is the responsibility of the SNEWS command or another news package to process the data and delete the file.

· If the Boolean option nns is set, then the news is uncompressed if it is compressed, and then saved in the NewsDir directory with a unique name and an extension of .NNS. It is the responsibility of the Network News System or other news package to complete processing of the data and delete the file.

· If neither the nns nor snews options are set, or a SYS file exists in the ConfDir, then the news is uncompressed if needed and the news is passed to NEWSRUN in one of two ways, depending on whether or not the Boolean option fastNews is set. If fastNews is set, NEWSRUN is invoked immediately, otherwise the data is queued to be processed by NEWSRUN via uux.

For those delivery routes which require possible decompression of incoming news, the program and its operands can be specified in the UUPC.RC file via the uncompress keyword as described in Table 14 - System Wide Configuration Keywords on page 119. Otherwise the program name is chosen dynamically based on the file contents to be one of compress, freeze, or gzip, and the -d flag followed by the input and output file names are automatically appended to the name.

Note: The various decompression programs are not supplied with UUPC/extended or supported by Kendra Electronic Wonderworks^{^[47]}.

Options

RNEWS supports the following operands

-f filename specifies filename is to be used in place of standard input

-F filename specifies filename is to be used in place of standard input, and the file is to be deleted after use.

-x debug Display debug messages at or below level debug. The default value is 1, but the option may set to 0 for unattended production use or as high 20 for detailed debugging.

Bugs

It would appear that between NEWSRUN and RNEWS data can be corrupted, resulting in lost news batches. However, we have not sorted out which program is the actual cause of the problem. (We think we fixed this in 1.12r. Stay tuned.)

Bad news batches are discarded rather than being kept around for later examination. This might be considered a feature on systems with limited disk space.

See Also

EXPIRE, INEWS

SENDBATS

Synopsis

sendbats [-x debug]

Description

SENDBATS takes articles queued for batch transmission to remote systems by newsrun and actually creates, compresses and invokes uux to queue the news batch. Its processing is driven by the articles queued by newsrun and by the contents of the SYS file (documented on page 155). All systems are processed in sequence by this program; no option is provided to process only one system.

Options

SENDBATS supports the following operand:

-x debug Display debug messages at or below level debug. The default value is 1, but the option may set to 0 for unattended production use or as high 20 for detailed debugging.

Bugs

SENDBATS ought to support handling one system at a time.

The SYS file should support different batch sizes for the various systems you are queuing news for.

See Also

NEWSRUN

SU

Synopsis

su userid [command]

Availability

MS-DOS and Windows NT (batch file)

OS/2 (REXX script)

Description

SU changes the environment variable UUPCUSRRC to change the user profile of the user using UUPC/extended. This allows multiple users to easily share the same PC for UUPC/extended.

Note: Because SU is a batch file under DOS and Windows NT, it does not examine UUPC.RC for the name of the UUPC/extended configuration directory. Thus, under DOS and Windows NT, if the directory is not the default \uupc, the SU command file must be edited to point at the correct configuration directory.

The syntax of the SU command is:

su userid [command]

Where:

userid defines the user to use when setting the UUPCUSRRC variable. The file \UUPC\[userid].RC must exist.

command defines an optional command to execute as this user, i.e. MAIL. The default is to run a second copy of COMMAND.COM. The default user id is restored by typing EXIT to terminate the inferior command processor.

uucico

Synopsis

uucico [-r 1] [-s system] [-x debug] [-l logname] [-n] [-t]

uucico -r 0 [-m inmodem] [-h handle] [-w user] [-x debug] [-z baudrate] [-l logname] [-d hhmm] [-t] [-U]

Availability

MS-DOS, Windows 3.x, OS/2, and Windows NT

Description

uucico performs the actual exchange of files with other systems. Normally, uucico is invoked from either uupoll or UUIO, but the program can also be invoked directly. Depending on the operating environment, uucico can be used to establish connections over modems, TCP/IP sockets, or named pipes. For information about these transport layers, see Specialized Communications Drivers, page 41, and Modem ([modem].MDM) Files, page 128. To make uucico call all connected systems to deliver and pickup remote mail and files:

uucico -s all

This directs uucico to poll all the systems listed in the SYSTEMS file.

To make uucico wait for an incoming call:

break on
uucico -r 0

uucico will wait for a successful telephone call, and exit upon completion. Entering Ctrl-Break from the keyboard will terminate uucico.^{^[48]}

Under OS/2 and Windows NT only, when uucico is invoked in passive mode to listen for a phone to ring, it will automatically surrender the port to a uucico calling out or to the program UUPORT. If an actively calling uucico suspends a passive uucico, it will automatically wake the sleeping uucico to take the port back. If UUPORT is used to suspend a uucico, UUPORT must be invoked a second time to reactivate the sleeping uucico.

The full list of options supported by uucico is as follows:

-d hhmm Duration. This flag specifies that uucico running in passive mode will terminate after hh:mm (hours and minutes). Note that this is a duration, not an end time.

Note: This flag replaces the execute period flag (-u) in previous versions of uucico.

-g grade Call grade. If specified for an outbound poll, only files of this grade or higher are requested from the remote system. This option is ignored if the -r 0 option is specified or implied.

-h handle Under OS/2 or Windows NT, specifies that the indicated file or socket (OS/2 only) has been opened on behalf of uucico by the calling program and that uucico is to use this handle rather than opening a new port or socket. Under DOS, this parameter implies the port is already open, but the actual handle operand is ignored. This option implies the -r 0 option and is modified by the -z and -w options.

-l logname Specifies the name of the log file used by uucico. The default extension is ".LOG" and the default log file is uucico.LOG.

-m inmodem Specifies the name of the modem file to use for passive polling. This flag implies the -r 0 flag. The default is to use the value of the UUPC.RC variable InModem.

-r 0 Slave Mode: initializes the modem and waits for the telephone to ring with an incoming call, presenting the caller with a UNIX style login prompt. This option is modified by the -d, -w, -x, and -z options.

-r 1 Master Mode: actively poll (call out to) the system defined by the -s option. This option is the default, and is modified by the -n and -s options.

-n Call now flag: when specified, uucico ignores the time fields defined in the SYSTEM file when determining if a system should be called, and treats all systems as if they were defined with a time of "any".

-s sysname System name to call. Default is to call "any"— any system for which the local system has work queued. Sysname may also be specified as "all", which calls all systems listed in the SYSTEMS file, or as the name of any system listed the SYSTEMS file. This option is ignored when -r 0 is specified.

-t Trace all data sent or received through communications port to file LINEDATA.LOG in the spool directory.

Note: Routine use of this option is not recommended as it will rapidly fill your hard disk with debugging output.

-U specifies that uuxqt is to be executed on the completion of such successfully connection.

-w who Begin processing in slave mode as if user who had just logged in. This option is for use when another program has answered the modem and validated the user id. It implies the -r 0 option and is modified by the -z option.

-x debug Display debug messages at or below level debug. The default value is 1, but the option may set to 0 for unattended production use, or as high 20 for detailed debugging.

Note: Use of debug level 5 or higher for extended periods of time is not recommended as it will rapidly fill your hard disk with debugging output.

-z bps Set modem speed to bps bits per second when used with -w option. The default speed is the speed listed in the modem definition file defined in the UUPC.RC variable InModem. This option is ignored if -w is not specified.

Exit codes

uucico exits with a status of 0 if it manages to successfully connect to at least one remote machine while it was running.

Other exit codes and their meaning:

5          A normal exit, but uucico never connected to any remote sites.
69        The program aborted due to a panic situation.
100      The user pressed Ctrl-C to terminate uucico.

Files

BANNER Optional login banner file, displayed to all remote users before the login prompt is displayed. (Defined by the configuration variable Banner in the UUPC.RC file)

[ConfDir]/[modem].MDM Defines modem specific information for initializing and resetting modem, and selected performance parameters.

[ConfDir]/[userid].RC Personal UUPC/extended configuration file, defined by UUPCUSRRC environment variable set in AUTOEXEC.BAT.

[ConfDir]/HOSTATUS File with summary of file transfer volume and last connection information

[ConfDir]/PASSWD Defines valid users, their passwords, and program to execute upon login.

[ConfDir]/PERMISSN Defines file access for remote systems

[ConfDir]/SYSTEMS Defines systems this system can call, and associated dialing information

[ConfDir]/UUPC.RC System UUPC/extended configuration file, defined by UUPCSYSRC environment variable set in AUTOEXEC.BAT.

MOTD Optional Message of the Day file, displayed upon remote login to all users not running default (internal uucico) shell. (Defined by MOTD keyword in UUPC.RC file.)

[SpoolDir]/hostname/C/* Call files defining what files are to be transferred to or from host hostname.

[SpoolDir]/hostname/D/* files spooled for transfer by uucico to hostname, and remote data files sent from hostname for processing by uuxqt.

[SpoolDir]/hostname/X/* Execute files received by uucico defining commands to be executed on the local system by uuxqt.

[SpoolDir]/SYSLOG Detailed log of all file transfers. Written if Boolean option syslog is enabled.

[SpoolDir]/uucico.LOG Default location of uucico log file.

Bugs

Special care should be taken to enable the Boolean option multitask in UUPC.RC if multiple copies of uucico may be running at the same time.

Connections with 'g' protocol to real UNIX systems fail in mysterious ways (generally, at the end of the first file transfer) if the Boolean modem option variablepacket is set in the [modem].MDM file. This actually happens because most UNIX vendor's UUCP programs don't fully implement the protocol options, but UNIX sysadmins normally blame UUPC/extended.

Connections with 'f' protocol over modems are very prone to failure because the 'f' protocol assumes a reliable, flow-controlled transport layer.

On UNIX systems, the default for uucico is -r 0 (wait to be called) rather than -r 1 (call out). uucico -r 1 is a more reasonable default for a PC, but might be unexpected for a UNIX expert.

Under Windows 3.x, only one copy of uucico can be run at a time because the program has multiple read/write data segments. This restriction does not exist for the native OS/2 or Windows NT versions. (Hint, hint.)

Under Windows 3.x, uucico running in background and doing disk I/O can adversely affect foreground system performance, causing the keyboard to appear to lock up for a second or two. (This sentence was typed when uucico was dishing out such abuse.)

Under Windows 3.x, uucico must be killed with Ctrl-C typed into its console window. Closing uucico with the mouse, Alt-F4, or Close menu item will only cause the window to pop up elsewhere the next time a message is written.

DECUS UUCP 1.1 won't exchange protocol information with UUPC/extended. A fix for DECUS UUCP 1.1 was posted to the net, and the bug is also fixed in version 1.2.

UUPC/extended forces communications to No Parity, 8 data bits, 1 stop bit, no in-band flow control.

Note: This is a requirement of the UUCP "g" protocol, which requires a transparent data line, and thus is a permanent restriction for "g" protocol connections.

If uucico is suspended, woken up, and suspended again immediately, the second suspend may fail because uucico has not finished reinitializing the modem yet.

If for some reason uucico is not woken up after being suspended (if, for example, the suspending program crashes), the suspended uucico will do a Rip Van Winkle and sleep forever. It must be killed or manually woken up using UUPORT.

Named pipes under OS/2 are incredibly inefficient, with low throughput (~2K-4K bytes per second on a loop back to the local system with 'e' protocol) and high CPU usage. It is unclear if this is a uucico bug or lossage in the operating system itself.

uucico uses operating system messages when possible for operating system API errors (such as communications port errors) under OS/2 and Windows NT. However, it does not perform parameter substitution, meaning percent signs (%) followed by a single numeric digit may show up in error message texts.

Under OS/2, uucico runs at a raised priority to improve throughput. While this has no noticeable impact on response time with the IBM serial port driver, the publicly available SIO.SYS driver may take sufficient CPU time to affect interactive response time. The Priority keyword in the [modem].MDM file can be used to adjust the uucico priority under OS/2.

uucico for OS/2 will fail upon startup with a mysterious message about a not being able to find a file (actually, a DLL) if TCP/IP or the IBM Internet Access Kit (IAK) is not installed. This can be corrected by using UUCICION instead.

Under Windows NT, Ctrl-C does not work correctly when breaking UUCICO out of a network connection. You will eventually get out, but you may have to press ^C and say yes a couple of times.

See Also

uupoll, UUCPD, UUIO, uuxqt, RMAIL, UUPORT, and RNEWS

uucicon

Synopsis

See uucico, above

Availability

OS/2 only

Description

The standard version of uucico for OS/2 requires various dynamic link libraries (DLL) for TCP/IP, even if you are not using TCP/IP based connections, and will fail if these libraries are not available. uucicon is a version of uucico which does not require that either IBM TCP/IP (2.0 or above) or the IBM Internet Access Kit (IAK) be installed.

In general, to use this version, rename it to uucico:

ren uucico.exe uucicot.exe
ren uucicon.exe uucico.exe

Bugs

If the TCP/IP libraries in question were dynamically loaded by the program (a la C-kermit for OS/2), we could actually dispense with the second module and internally disable the TCP/IP support if the libraries are not available. However, given that IBM now gives the libraries away with every copy of OS/2, the work does not seem to be worth the effort.

See Also

uucico

UUCLEAN

Synopsis

uuclean [spooldir [tempdir]]

Availability

MS-DOS and Windows NT (batch file)

OS/2 (REXX script)

Description

UUCLEAN ages log files through five generations and clears old UUPC/extended temporary files from the spool and temporary directories. Under OS/2, UUCLEAN also executes UNDELETE to purge these files and other spool files from the OS/2 undelete cache. UUCLEAN must be executed when programs which create log files (uucico, uuxqt, and RMAIL) are not running.

Note: Under DOS and Windows NT, UUCLEAN does not clean log files created with non-standard names via use of the uucico log file (-l) flag.

The syntax of the UUCLEAN command is:

uuclean [logdir [spooldir [tempdir]]]

Where:

logdir Specifies the UUPC/extended log directory to clean. The default is \uupc\log on the current drive.

spooldir Specifies the UUPC/extended spool directory to clean. The default is \uupc\spool on the current drive.

tempdir Specifies the temporary directory to clean. The default is the value of the TEMP environment variable.

Note: Because UUCLEAN is a batch file under DOS and Windows NT, it does not examine UUPC.RC. Therefore, the batch file must be edited if you do not use the default directory structure and do use UUCLEAN.

Note: tempdir is a positional argument. If you want to specify tempdir, you must also specify spooldir.

UUIO

Synopsis

UUIO [uucico options]

Availability

DOS, OS/2, Windows/NT

Description

UUIO is a batch file which executes UUSTAT -q and uucico followed by uuxqt. All UUIO command line arguments are passed to uucico. No user arguments are passed to UUSTAT or uuxqt.

Note: The UUSTAT command can be deleted from the UUIO command file with no loss of function. It is included for the informational display only.

See uucico on page 82, above, for a description of the command line arguments.

See Also

uucico, UUSTAT, uuxqt, uupoll

UUCP

Synopsis

uucp [ -cCdfjmr ] [ -ggrade ] [ -nusername ][ -x debug] srcfile system!destfile
or
uucp [ -cCdfjmr ] [ -ggrade ] [ -nusername ][ -x debug] system!srcfile destfile

Availability

MS-DOS, OS/2, and Windows NT

Description

UUCP queues binary or text files for transfer between two or more directly connected systems. The basic UUCP command syntax is:

uucp srcfile system!destfile or
uucp system!srcfile destfile

The first example copies a local file (srcfile) to a remote host (system) as destfile. The second example copies a file (srcfile) on a remote host (system) to the local file destfile. Filenames may be specified as an absolute path name, relative to a user's home directory (~user/file), or a path relative to the UUCP public directory (~/name). Systems may also be specified as a list of names such as system1!system2!...!destsystem!destfile, in which case the file is sent to the destination by way of the specified route.

Note: On most systems, access will be severely restricted. Check with a user or system administrator on the intermediate and destination systems before transferring files to possibly restricted locations.

Note: Beginning with UUPC/extended version 1.12e, multi-hop UUCP and uux transfers are supported. Because of the resulting system security exposure, the uucico program now validates all file transfer requests from outside the spool directories using the PERMISSN file. Before it only validated requests from the remote system and did not validate requests which were queued by the local system. Unless, according to the PERMISSN file, uucico can read the directory a file is queued from, the UUCP command must be used with the -C option to copy queued files to the spool directory. Otherwise, a remotely queued UUCP command could be used to steal your entire disk ... a Bad Thing.

UUCP accepts the following command line options:

-C Make a copy of outgoing files in the UUCP spool directory, rather than copying the source file directly to the target system. This lets you remove the source file after issuing the UUCP command.

-c Use the source file when copying out rather than copying the file to the spool directory. This is the default.

-d Make all necessary directories for the file copy. This is the default.

-f Do not make intermediate directories for the file copy.

-g grade grade is a single letter or number, from 0 to 9, A to Z, or a to z; 0 is the highest grade, and z is the lowest grade. Lower grades will cause the job to be transmitted earlier during a particular conversation. The default grade is n. By way of comparison, uux defaults to A; mail is usually sent at grade C.

-j Output the job identification ASCII string on the standard output. This job identification can be used by UUSTAT to obtain the status or terminate a job.

-m Send mail to the requester when the copy is complete.

-n username Notify username on the remote system (that is, send username mail) that a file was sent.

-r Do not start uucico, just queue the job. This is the default, and the option exists only for UNIX compatibility reasons.

-x debug Display debug messages at or below level debug. The default value is 1. The option may set to 0 for unattended production use, or as high 20 for detailed debugging.

For additional information on the UUCP command, see chapter 2 of Using & Managing UUCP.

Bugs

Access checking is not as severely enforced as it would be on a true UNIX system, particularly for locally originated UUCP commands.

See Also

MAIL, UUSTAT, uux, uucico, uuxqt.

UUCPD

Synopsis

uucpd socketNumber

Availability

OS/2 only; IBM TCP/IP support required

Description

UUCPD is a batch script that allows UUPC/extended to be invoked as a service from the OS/2 TCP/IP program called inetd. With inetd, you will not need to invoke a copy of uucico to wait on a network port when your machine boots up -- inetd will automatically invoke uucico when one of your network neighbors attempts to connect to you.

To configure inetd to invoke uucico when a remote host tries to connect on the UUCP network port, add the following line to the %ETC%\INETD.LST file:

uucp tcp uucpd

Otherwise, configure UUPC/extended as you normally would.

Note: inetd is only included in the full TCP/IP 2.0 package and Warp Connect, not in the Internet Access Kit (IAK) supplied with OS/2 Warp.

The UUCPD script takes one argument -- the handle number of the socket on which the network conversation is conducted.

Note: This command will not work unless it is invoked by inetd. Other attempts to use it will result in network errors.

Bugs

Since the associated uucico is run in the same session as the INETD, the window name tends to get mangled. Changing the uucico command in the UUCPD script to a START command will correct the problem, but doing so entails a perform hit, and who cares what the task switcher reports as the name of INETD, anyway?

UUHOUR

Synopsis

uuhour

Availability

OS/2

Description

uuhour generates dummy jobs via uustat based on times listed in the POLL file. uucico can then be invoked to call only those systems with work (including dummy jobs), which tilts polling towards those systems which have not been recently contacted.

Note: This program is not run automatically; it must be regularly invoked via the -B option of uupoll or other method to be effective.

Note: uuhour remembers the last time it was run, and if the previous run was since the beginning of the current hour, it exits with an informational message.

Options

uuhour does not accept any command line options.

Bugs

The program should be ported to C and made available on all the UUPC/extended platforms.

See Also

uucico, uupoll, uustat

UUNAME

Synopsis

uuname [-l | -d ] [-x debug]

Availability

MS-DOS, Windows 3.x, OS/2, and Windows NT

Description

UUNAME reports names of the remote systems defined to UUPC/extended via the SYSTEMS file or the local system name (nodename) defined in UUPC.RC.

The syntax of the UUNAME command is:

uuname [-l | -d ] [-x debug]

Where:

-d reports the local domain name.

-l reports the local system name.

-x debug Display debug messages at or below level debug. The default value is 1. The option may set to 0 for unattended production use, or as high 20 for detailed debugging.

By default uuname reports all the defined remote systems.

Bugs

Too stupid to have any.

uupoll

Synopsis

uupoll [-r 0 | 1] [-f firsttime] [-i hhmm] [-d hhmm] [-e hhmm] [-c hhmm] [-l logfile] [-m modem]
[-B batchfile] [-C command]

Availability

MS-DOS, Windows 3.x, OS/2, and Windows NT

Description

uupoll allows unattended operation of the PC, automatically running uucico on a timed basis. Each time uupoll invokes uucico, it also automatically runs uuxqt to process any files received by uucico.

To use uupoll to have uucico call out on a regular basis:

uupoll -f 0240 -i 0600

This will cause uucico to call out at 2:40 A.M. and every six hours thereafter until the user presses Ctrl-Break. Both flags are specified as hhmm (hours and minutes).

To use uupoll to have uucico call out on a regular basis, and automatically answer the telephone between outgoing calls:

uupoll -f 0240 -i 0600 -r 0

This will cause uucico to call out at 2:40 A.M. and every six hours thereafter until the user presses Ctrl-Break, and in addition uucico will be invoked in passive mode to answer the telephone between outgoing calls.

The full list of arguments allowed by uupoll are as follows:

-a hhmm Automatically call system "any" after each successful incoming poll if hhmm seconds have passed since last active poll. This option allows mail delivered by incoming systems to be automatically forwarded if the local system is allowed to call the destination system. The delay time may be specified as 0, in which case uucico will call system "any" after every successful incoming telephone call. This option has no effect unless -r 0 is specified.

-B command Batch command to execute before each active call at -i hhmm intervals. Default is to execute no commands before calling out.

-c hhmm Time of day to execute UUCLEAN to clean the spool directory in hours and minutes. The default is don’t run UUCLEAN daily.

-C command Command to run to clean spool directory at time specified by -c flag. The default is run the UUCLEAN command with no operands.

-d hhmm Duration of polling in hours and minutes. If the exit (-e) flag is not specified, then after this period uupoll exits. If neither -d or -e is specified, the default is poll until the user presses Ctrl-Break.

-e hhmm Time of day that uupoll is to exit. If neither -d or -e is specified, the default is poll until the user presses Ctrl-Break. If the specified time has already passed and the duration (-d) flag is not specified, then uupoll immediately exits. If the duration flag is specified, then uupoll will poll if and only if the exit time (-e hhmm) would be reached before the duration (-d hhmm) expires. In any case, uupoll will exit no later than the time specified by the exit time.

Example: uupoll -e 2400 -d 2400 will always run until the next midnight, but uupoll -e 300 -d 1200 will exit immediately if it is more than 12 hours before 3 AM (that is, the current time is before 3 PM).

-f hhmm First time to poll in hours and minutes. Default is to not actively poll unless the user specifies an interval via -i, in which case the default is the current time plus the interval.

Note: uupoll automatically determines when it is later than the specified first poll time and selects the available next time to poll. If it is desired for uupoll to poll 24 hours a day, then the first poll time should be specified as close to the previous midnight as possible.

If, for example, the system is to poll at 6:13 AM, 2:13 PM, and 10:13 PM, uupoll must be invoked with:

uupoll -i 0800 -f 0613

Even if it is after 6:13 AM.

-i hhmm Interval to poll in hours and minutes. Default is 0400 (4 hours) if -f is specified.

-l log log file name to pass to uucico.

-m modem modem name to pass to uucico for inbound calls.

-r 0 Directs uucico to answer telephone between active polls. Default is to not answer the telephone.

-r 1 Directs uucico not to answer the telephone, but to actively poll after the interval specified with -i.

-s system System name to call. Default is "all" for the first poll, followed by "any" for succeeding polls, which cannot be explicitly specified.

-x debug Debug level passed to uucico and uuxqt. Default is 1.

Note: Either -r, -i, or -f must be specified.

Note: For additional information on the -l, -m, -s, -x, and ‑r options, see the description of uucico on page 82, above.

Note: If you specify both the -r 0 and either the -f or -i options, the effect is to have uucico invoked to answer the telephone between the active polls defined by the -f or -i options.

Exit codes

uupoll exits with a status of 0 if it ran, carried out its work, and exited without encountering any problems.

Other exit codes and their meaning:

69 The program aborted due to a panic situation.
100 The user pressed Ctrl-C to terminate uucico.

Bugs

Polls after 2 AM on the day when daylight savings time begins or ends in the US will be off by one hour. This is due to the way that uupoll handles (or fails to handle) days that are not 24 hours long. uupoll will not attempt to poll during the 25^th hour of such days, instead waiting for the first poll of the next day.

UUPOPD

Send mail from a UUPC/extended user mailbox to a POP3 client over a TCP/IP network.

Synopsis

UUPOPD [-d hhmm] [-g grade] [-h handle] [-l logname] [-U] [-x debug]

Availability

OS/2 32 bit and Windows NT only

Description

The UUPOPD daemon listens on the well-known TCP/IP POP3 port for network clients such Netscape Navigator and Microsoft Internet Explore. Clients can connect as a specified user and then query, retrieve, and delete messages from the standard UUPC/extended user mailbox. The daemon uses round-robin scheduling to process multiple connections on a single program thread.

Note: For a user to make use of the UUPOPD daemon, he/she/it must have a non-null password defined in the PASSWD file, and have a group entry of “pop3”. The same user id cannot be used for both UUCICO and UUPOPD, to discourage assword hacking attempts.

The options for the UUPOPD command are:

-d hhmm Duration. This flag specifies that UUPOPD running in passive mode will terminate after hh:mm (hours and minutes). Note that this is a duration, not an end time.

-g grade This is for compatility with the UUSMTPD daemon, which this program shares components with. It is silently ignored if specified.

-h handle Under OS/2 or Windows NT, specifies that the indicated file or socket (OS/2 only) has been opened on behalf of UUPOPD by the calling program and that UUPOPD is to use this handle rather than opening a new port or socket.

-l logname Specifies the name of the log file used by UUPOPD. The default extension is ".LOG" and the default log file is UUPOPD.log.

-p port The port name or number to use. The default is the port defined as the POP3 port (110).

-U This is for compatility with the UUSMTPD daemon, which this program shares components with. It is silently ignored if specified.

-x debug Display debug messages at or below level debug. The default value is 1, but the option may set to 0 for unattended production use, or as high 20 for detailed debugging.

Files

To Be Determined.

Bugs

Internally, the round robin scheduler can lead to delays for connections if expensive operations such as host name lookups or retrieving a long message take excessive time. This is balanced by faster response under moderate loads in normal use.

Hitting Ctrl-Break under Windows NT gives an immediate response from the daemon, but it then takes until the end of the time-out period of the network select call to actually exit.

The server only supports clear text password authorization, making it prone to Network sniffer attacks.

See Also

RMAIL, UUSMTPD, MAIL, PASSWD

Author

Written over a period of three days by Drew Derbyshire of Kendra Electronic Wonderworks and released with UUPC/extended 1.12v in March, 1998.

UUPORT

Communicate with background uucico to surrender communications port.

Synopsis

uuport [-s | -r] port

Availability

OS/2 and Windows NT only (also in DOS or Windows OS/2 compatibility box)

Description

UUPORT contacts an already running uucico via a named pipe and requests the uucico to surrender or resume use of the communications port specified. This allows another program to use the port without canceling and restarting the uucico using the port by hand. This command also works if UUPORT is run from an OS/2- or Windows NT-spawned DOS or Windows 3.x environment, provided the target is a native OS/2 or Windows NT uucico invocation. UUPORT is harmless under native DOS or Windows 3.x, but doesn't do anything useful.

The syntax of the UUPORT command is:

uuport [-s | -r] port

where:

-s surrender the port.

-r resume use of the port.

Note: If both the -s and -r flags are omitted, the current status is queried but left unchanged.

port The port name to process.

Files

\PIPE\uucico\ZZport                        pipe for contacting local background uucico under OS/2
\\.\PIPE\uucico\ZZport                   pipe for contacting local background uucico under Windows  NT
\\servername\PIPE\uucico\ZZport   pipe for contacting networked background uucico

Bugs

If the DOS or Windows 3.x version of UUPORT is run to talk to a native Windows NT uucico, then the UUPORT command line must specify the server name: "\\.\port".

See uucico for additional problems and caveats.

See Also

uucico, uupoll

Author

Kai Uwe Rommel for OS/2, with the usual additional hacking by Kendra Electronic Wonderworks.

Dave Watt did the associated support in uucico for the Windows NT version.

UUSMTPD

Receive Mail via a TCP/IP network from a Simple Mail Transfer Protocol (SMTP) Mailer

Synopsis

uuSMTPD [-d hhmm] [-g grade] [-h handle] [-l logname] [-U] [-x debug]

Availability

OS/2 32 bit and Windows NT only

Description

The UUSMTPD daemon listens on the well-known TCP/IP SMTP port for network clients sending mail. It uses round-robin scheduling to process multiple connections on a single program thread. Any mail received from network clients is queued for local or remote delivery using an internal copy of the same back-end delivery engine used by RMAIL.

Note that you must configure clients to point to the mailer, either via MX records in your domain name server and/or by configuring desktop clients such as Netscape or Internet Explore to use the server running UUSMTPD as their server.

The options for the UUSMTPD command are:

-d hhmm Duration. This flag specifies that uuSMTPD running in passive mode will terminate after hh:mm (hours and minutes). Note that this is a duration, not an end time.

-g grade Specifies the mail grade used for remote mail queued by the delivery back-end.

-h handle Under OS/2 or Windows NT, specifies that the indicated file or socket (OS/2 only) has been opened on behalf of uuSMTPD by the calling program and that uuSMTPD is to use this handle rather than opening a new port or socket.

-l logname Specifies the name of the log file used by uuSMTPD. The default extension is ".LOG" and the default log file is uusmtpd.log.

-p port The port name or number to use. The default is the port defined as the SMTP port (25).

-U specifies that uuxqt is to be executed on the completion of each successfull connection.

-x debug Display debug messages at or below level debug. The default value is 1, but the option may set to 0 for unattended production use, or as high 20 for detailed debugging.

Files

To Be Determined.

Bugs

Internally, the round robin scheduler can lead to delays for connections if expensive operations such as host name lookups take excessive time. This is balanced by faster response under moderate loads in normal use.

Hitting Ctrl-Break under Windows NT gives an immediate response from the daemon, but it then takes until the end of the time-out period of the network select call to actually exit.

It takes too long to close down a connection from Netscape clients, it appears Netscape does not properly put a CR/LF on the end of the QUIT command.

The server claims to support ESMTP, but has a relatively small feature set.

The server does not perform checks of sender domains well, thus allowing more unsolicited e-mail (SPAM) through than is desirable.

The server delivery engine is specifically configured to not use the immediate SMTP delivery mode enabled by the Boolean option fastsmtp. Such immediate delivery attempts would have an adverse affect on the daemon response time to clients.

See Also

RMAIL

Author

This was written from scratch (except for the delivery engine) in two major periods of activity in late Spring and late Autumn of 1997 by Drew Derbyshire of Kendra Electronic Wonderworks for inclusion beginning with release 1.12t of UUPC/extended.

UUSTAT

Synopsis

uustat [-a] [-m] [-q] [ -k jobid ] [ -r jobid ] [-x debug]
uustat [ -s system] [ -u user] [-x debug]
uustat [ -P system] [-x debug]

Availability

MS-DOS, Windows 3.x, OS/2, and Windows NT

Description

UUSTAT will display the status of, or cancel, previously specified uucp commands, or provide general status on uucp connections to other systems. Only one of the following options can be specified with UUSTAT per command execution:

-a List all jobs in queue.

-m Report the status of accessibility of all machines.

-q List the jobs queued for each machine. If a status file entry exists for the machine, its date, time and status information are reported. In addition, if a number appears in parentheses next to the number of C or X files, it is the age in days of the oldest C/X file for that system.

Note: For systems with a large number of outstanding jobs, this command could take 30 seconds or more of real-time to execute.

-k jobid Kill the uucp request whose job identification is jobid.

-r jobid Rejuvenate expired job jobid. The files associated with jobid are touched so that their modification time is set to the current time.

Note: The refresh option hasn't yet been fully implemented, but that's okay because job expiration doesn't happen either.

-P system Create a poll work file. This empty call file causes system to be called every time uucico is invoked with the "-s any" option until the system is contacted.

-P all Create poll work files for all systems.

Any or all of the following options can also be specified with UUSTAT:

-s sys Report the status of all uucp requests for remote system sys.

-u user Report the status of all user requests issued by user.

-x debug Display debug messages at or below level debug. The default value is 1, but the option may set to 0 for unattended production use, or as high 20 for detailed debugging.

When no options are given, UUSTAT outputs the status of all uucp requests issued by the current user.

Note: Poll files created by the current user with the -P option are not displayed unless the -s or -a options are used.

Returns

Exits with a status of 0 upon successful completion of its task.

Other exit status code and their meaning:

1          Bad usage.
2          stat(), open(), access(), or utime() call failed.
3          fopen() failed or file pointer was NULL .
4          An internal problem, usually with file access.
69        The program aborted due to a panic situation.
100      The user typed Ctrl-C.

Files

/spool/system/C/*              Command Files for host "system"
/spool/system/D/*              Data files
/hostatus                             System status summary file

Bugs

The Retry and Count features shown by UNIX systems are not implemented since UUPC/extended doesn't implement STST.system files where some of the needed information would come from.

Work poll files are created with class Z, which is what SunOS 4.1.3 uses for poll files. This behavior may not be desirable if the local system exploits call grading to process only classes above Z.

UUSTAT does not actually refresh times with the -r option.

The time reported by UUSTAT for each system is the time the local system last connected to the remote system, not the time of the last attempt as in UNIX versions of UUSTAT. This behavior is both for historical reasons and because the author thought it was more useful. UUSUB can be used to view the time of the last attempt.

Poll work files (generated with the -P flag) are not shown in a per user display.

See Also

UUCP, uucico, UUSUB

History

Originally Written Using MSC 3.0, MASM 2.0, April 1988

Ported to UUPC/extended with Borland C++ 2.0 and MS C 6.0, June 1991.

UUSUB

Synopsis

uusub [-x debuglevel] [-c] [-s system]

Availability

MS-DOS, Windows 3.x, OS/2, and Windows NT

Description

UUSUB reports statistics on the data transmitted between the local and remote systems since the last time the file HOSTATUS in the UUPC/extended spooling directory was created. UUSUB is invoked with no operands to report these statistics:

uusub

The syntax of UUSUB is:

uusub [-x debuglevel] [-c] [-s system]

Where:

-c Clears (resets) the totals.

-s sysname System name to report on or to clear. The default is report on or clear all known systems.

-x debug Display debug messages at or below level debug. The default value is 1. The option may be set to 0 for unattended production use, or as high 20 for detailed debugging.

See Also

UUSTAT, UUCICO, and UUNAME

UUTRAF

Synopsis

uutraf [options] [statfile | - ]

Availability

MS-DOS, Windows 3.x, OS/2, and Windows NT

Description

UUTRAF analyses the UUPC/extended SYSLOG file and reports transfer statistics using a default sorting format or an optional user-specified sorting format.

The syntax of the UUTRAF command is:

uutraf [options] [statfile | - ]

Where:

statfile optional file to read input from. The default is the Spooldir SYSLOG file. A hyphen (-) causes UUTRAF to take input from stdin.

-a sort in ascending order, rather than descending.

-b[r|x|b] sort by number of bytes Received, transmitted(X), or Both.

-c[r|x|b] sort by transfer rate Received, transmitted(X), or Both.

-f[r|x|b] sort by number of files Received, transmitted(X), or Both.

-H include the header lines for restricted report forms.

-h Display a more verbose help message

-M merge per-port sub-totals for each node. This option implies the setting of -N.

-N restrict the report to the nodes (sites) summary.

-n sort by name (overrides following options).

-P restrict the report to the ports summary.

-S restrict the report to totals summary.

-s take the input from stdin rather than a file.

-t[r|x|b] sort by connect time Received, transmitted(X), or Both.

-V display version identification information

Examples

uutraf -bb will display the total bytes transferred, in descending order. (This is the default.)

uutraf -cx will display the connections with the fastest transfer rates, in descending order.

uutraf -tba will display the connections by total amount of transfer time, in ascending sort order.

Bugs

UUTRAF is not supported under Windows because the Borland C++ for Windows library is missing a floating point error handling function, and so the program won't link. Snuffles is deeply annoyed by this...

Multiple sorting options may not work as you would hope, and the sorting option syntax goes against de-facto rules for option syntax.

The -s option is redundant. ('-' is also valid) The -H option alone does nothing with the standard defaults (it is the default!). The -M option alone does imply -N but does not automatically supplement the standard defaults.

There is no header part in the totals summary, and no way to get the descriptive text to go away leaving only the numbers.

The field widths and formats are all fixed.

Transfer times alone do not necessarily reflect true port utilization.

Some versions of uucico skew transfer times and transfer rates by not resetting their timers at the appropriate point. In this case, and in the case where the sender must wait for a slow receiver to checksum the data before completing the job, the transfer rates will not be representative of the low-level throughput on the port. Modems that spoof UUCP protocols and/or contain large buffers will also skew these figures.

Authors

Greg Hackney <hack@texbell.swbt.com> - wrote the original.
Greg A. Woods <woods@robohack.uucp> - wrote the dist library, added new features.

Contributors

Doug Davis <doug@letni.uucp>, David Butler <gdb@ninja.uucp>, Bud Hovell <bhh@whizz.uucp>, David Kaelbing <drk@igor.uu.net>, Joe Garvey <garvey%cmic@mips.com>, D'Arcy Cain <darcy@druid.com>, Georg S. Nikodym <georgn@noweh.com>, Bill Duncan <bduncan@ve3ied.uucp>, Robert Story <rstory@elegant.com>, Kai Uwe Rommel

uux

Synopsis

uux [ - ] [ -bcCjnprz ] [ -a name ] [ -g grade][ -x debug] command-string

Availability

MS-DOS, OS/2, and Windows NT

Description

The uux command queues commands for execution on remote systems. It is used by other facilities, such as news functions and the UUCP command, to handle processing more complex than simple file transfers. uux will gather 0 or more files from various systems, execute a command on a specified system and send the standard output to a file on a specified system.

Note: For security reasons, most installations severely limit the list of commands executable on behalf of an incoming request from uux, permitting only the receipt of mail. Check with a user or system administrator on the target systems before attempting to use this command.

The command-string is made up of one or more arguments that look like a command line, except that the command and file names may be prefixed by system-name!. A null system-name is interpreted as the local system.

Any special characters such as <>, ;, and | should be quoted either by quoting the entire command-string, or by quoting the special characters as individual arguments.

uux will notify you if the requested command on the remote system was disallowed, or if the command fails (that is, returns a non-zero exit status). This notification can be turned off by the -n option. The response comes by remote mail from the remote machine.

uux accepts the following options:

- sends the standard input to the uux command as the standard input to the command-string.

-a name Use name as the user identification replacing the initiator user ID. Notification will be returned to this user.

-b Return whatever standard input was provided to the uux command if the job fails (that is, returns a non-zero exit status).

-c Do not copy local file to the spool directory for transfer to the remote machine. This is the default.

-C Force the copy of local files to the spool directory for transfer.

-e Remote system should use /bin/sh to execute the command.

-E Remote system should use the exec call to execute the command.

-g grade grade is a single letter or number, from 0 to 9, A to Z, or a to z; 0 is the highest grade, and z is the lowest grade. Lower grades will transmit the job earlier during a particular conversation. The default grade is A.

-j Output the jobid ASCII string on the standard output. This job identification can be used by UUSTAT to obtain status information or terminate a job.

-n Do not return any indication by mail of success or failure of the job.

-p Same as '-': the standard input to uux is made the standard input to the command-string.

-r Do not start uucico, just queue the job. This is the default, and the option exists for UNIX compatibility reasons only.

-x debug Display debug messages at or below level debug. The default value is 1. The option may set to 0 for unattended production use, or as high 20 for detailed debugging.

-z Return an indication by mail even if the job succeeds (that is, returns a zero exit status).

See Also

MAIL, UUCP, UUSTAT, uucico

For additional information on the uux command, see chapter 3 of Using & Managing UUCP.

Bugs

uux interaction with uuxqt is ill-defined, and uuxqt tends to be paranoid about command line arguments because of the inherent lack of security in most supported operating systems.

uuxqt

Synopsis

uuxqt [-x debuglevel] [-s system]

Availability

MS-DOS, OS/2, and Windows NT

Description

uuxqt must be executed to process remote files after uucico has received these files from a remote host. It normally is invoked with no operands:

uuxqt

This will automatically process all eXecute files in the local spool queues with the default debugging level in effect.

uuxqt supports the following command line options:

-s sysname Process work only for sysname. The default is system "all", which processes work for all known systems.

-x debug Display debug messages at or below level debug. The default value is 1. The option may be set to 0 for unattended production use, or as high 20 for detailed debugging.

To automatically execute uuxqt every time uucico is run, use uupoll or UUIO.

Bugs

None known.

WAITING

Synopsis

waiting [userid]

Availability

MS-DOS and Windows NT (batch file)

OS/2 (REXX script)

Description

The WAITING command reports on which users have mail waiting in the UUPC/extended mail directory. It exits without comment if no mail is waiting.

Note: Because WAITING is a batch file under DOS and Windows NT, it assumes the mail directory is \uupc\mail on the current drive. The file must be edited by hand if this is not the directory for system mailboxes.

Note: This command is more effective if the multitask option is specified in the UUPC.RC file, as then mail is moved out of the system mail directory as soon the user invokes the MAIL command after new mail arrives.

The syntax of the WAITING command is:

waiting [userid]

Where:

userid defines the userid to check for waiting mail. The default is all users.

Bugs

WAITING assumes the extension of mailbox files is SPB.

WAITING does not support the directory option, which would require looking in subdirectories for the waiting mail.

“The sendmail configuration file is one of those files that looks like someone beat their head on the keyboard. After working with it... I can see why!”

-- Harry Skelton

Part 5: Configuration Files

Overview

This section describes the UUPC/extended configuration files. It assumes you have installed the programs and configured them as described in Part 2: Basic UUCP Installation, page 11, and that you have access to the Nutshell Handbook Using & Managing UUCP.

The UUPC.RC and [userid].RC files

Introduction

The UUPC.RC file provides the basic configuration information required to initialize the various UUPC/extended programs. It provides information which applies to the entire local system. It can also provide defaults for individual users. These defaults can then be overridden by the values in each user's [userid].RC file^{^[49]}.

Blank lines and lines beginning with a pound sign (#) are ignored. Entries in the file are of the form:

prefix.keyword=value

If multiple lines exist with the same keyword, the last line is used. An exception to this rule is the options= line; if multiple options= lines exist, the options are processed individually and the last occurrence of each option is used.

The prefix is optional, and if present must be:

1. DOS,

2. 32BITOS2 (for OS/2 2.x),

3. 16BITOS2 (for OS/2 1.x),

4. WIN16 (for Windows 3.x),

5. WIN32 (for Windows NT or Windows 95/98)

6. WIN9X (for Windows 95/9x)

7. WINNT (for Windows NT)

and must be followed by a period. Case is not significant for the prefix or keyword. If the prefix is present, the line is only used if the current environment matches the keyword. This allows multiple lines in the same configuration file for different environments, such as:

      DOS.Editor=edit %s
      OS2.Editor=epm %s
      WIN16.Editor=notepad %s
      WIN32.Editor=notepad %s

This allows the use of three different editors in four different environments. This could also be specified as:

      Editor=notepad %s
      DOS.Editor=edit %s
      OS2.Editor=epm %s

In the latter example, the program notepad is the editor specified for all environments, but it is superseded for both the DOS and OS/2 environments.

Note: If the DOS versions of UUPC/extended programs are invoked under OS/2 or Windows NT, they will use the DOS environment keywords rather than attempting to determine the native environment.

The fields are described in Table 13 - User/System Configuration Keywords and Table 14 - System Wide Configuration Keywords below as being of several types, most of which are self-explanatory. Of special note, however, are fields described as tokens, path names or file names. Tokens are single words with no spaces. Any tab or space terminates the value. As for path and file names:

Path and file names must be valid names under the host operating system.

Path and file names without drive letters are presumed to reside on the same drive as the UUPC/extended configuration directory.

Slashes (/) and back slashes (\) are considered equivalent in paths. Back slashes are translated to slashes internally and translated back when opening files and for external commands such as editors.^{^[50]}

Relative path and file names (except for those listed in the next paragraph) are presumed to be relative to the UUPC/extended configuration directory.

The files defined by Aliases, AltSignature, and FileSent fields are assumed to be relative to the user's home directory. In addition, only these files may use the ~userid convention defined for files in MAIL, page 61.

Keywords Valid in Individual or System Configuration Files

Table 13 - User/System Configuration Keywords lists valid fields for the UUPC.RC or [userid].RC file. They are normally placed in the UUPC.RC if applicable to all users of local system, and otherwise put in each [userid].RC file as needed. The word omitted in the Example column indicates that most users will not need to worry about (or change) the field.

Table 13 - User/System Configuration Keywords

Keyword	Type	Description	Default^{^[51]}	Example^{^[52]}
Aliases	File name	This keyword is Obsolete. Use the Nickname keyword instead.
AltSignature	File name	Name of alternative file included in response to ~A command when sending mail.	None.	omitted
BackupExt	File Extension	Extension used for files renamed by backup processing. Note: See backup option, below.	BAK	omitted
Editor	String	Command string including the name of the editor used for editing outgoing mail. Note: %s must appear in the string to define where the file name should be substituted.	None.	edit %s
FileSent	File name	Name of file in which all mail sent by local user is saved.	None. Note: If this parameter is omitted, no copy is saved.	outgoing
FirstGrade	Character	uucico scans the queue for files of this grade and above, and sends those files first.	C	omitted
Folders	Path name	Included for use by MUSH (Mail User's Shell). Not used by UUPC/extended.	N/A	omitted
Home	Path name	Home directory of current user. This directory is the directory in which FORWARD files are searched for, and the default directory for the files defined by FileSent, Aliases, and Signature files.	None. Note: This field is required.	C:\u\snuffles
MailBox	User id	Name (userid) of the currently active user. Should be 1-8 characters and only contain valid alphanumerics.	Note: This field is required.	snuffles
MailGrade	Character	Default UUCP class used for mail.	C	omitted
Name	String	Full name of the user	Note: This field is required.	Snuffles P. Bear
NewsCache	Integer	Pages of news history file index to cache in memory.	128 for 32-bit systems, 4 for 16-bit systems.	omitted
Nickname	File name	User aliases (nicknames) file. Note: If the path is omitted, this file is presumed to reside in the current user's home directory.	None.	nickname.txt
Organization	String	Name of the organization to be listed in the Organization field in headers of outgoing mail.	None.	Itty-Bitty Machines Corporation
Pager	String	Command string including the name of the pager used for displaying incoming mail. Note: %s must appear in the string to define where the file name should be substituted.	None.	list %s
ReplyTo	Token	Address to which replies to outgoing mail are to be sent.	Replies are sent to the originator of the mail.	omitted
ReplyToList	List of tokens	List of headers used to identify the address for a reply.	"Resent-Reply-To:", "Resent-From:", "Reply-To:", "From:"	omitted
Signature	File name	Name of signature file included in response to ~a command or by the Boolean option autosign when sending mail.	None.	omitted
TZ	Token	Specifies the system’s time zone. Normally specified as a system environment variable, see Configuring After Installation, page 16.	Value of the TZ environment variable.	omitted
Version	Token	UUPC/extended version for which the file was last updated.	None.	1.13j
Vmail	File name	Program name inserted on X (execute) lines	None.	vmail.exe
VMSQueueDir	Path	Queue directory used for delivery of mail to VMAIL.	None.	c:\vmail\queue
XqtRootDir	Path	Current directory for programs run from within uuxqt.	Use the UUPC/extended spool directory.	omitted

Keywords Valid Only in System Configuration Files

The following keywords listed in Table 14 - System Wide Configuration Keywords are only valid in the UUPC.RC configuration file, and always apply to all users of the local system.

Table 14 - System Wide Configuration Keywords

Keyword	Type	Description	Default	Example^{^[53]}
AnonymousLogin	Token	Specifies times (using same format as time field in SYSTEMS file, page 137) when anonymous login is allowed.	None. (No anonymous logins are allowed.)	Any Night Evening
BackupExt	File Extension	Extension used for files renamed by backup processing. Note: See backup option, below.	BAK	omitted
Banner	File name	File displayed before login prompt by uucico.	None.	omitted
BatchSize	Integer	Minimum size, in bytes, of a news batch spooled for a downstream system.	65536	omitted
CharSet	String	Valid characters allowed in file names and used for mapping UNIX names to local names.	a-z, 0-9, !#$%&'()-@^_`{}~	omitted
Compress	String	Command string containing the name of the program used to compress outgoing news batches.	compress %s	omitted
ConfDir	Path name	Base UUPC/extended configuration directory. Location of various files (SYSTEMS, PERMISSNS, PASSWD) and default parent directory for MailDir, NewsDir, PubDir, SpoolDir, and TempDir. Note: If this, or any other, UUPC/extended directory is the root directory of the drive, be sure to include a trailing slash after the drive name.	Taken from path component of UUPCSYSRC environment variable.	C:\UUPC F:\
Domain	Token	Fully-Qualified Domain name of the local system, included in headers of all mail sent. Note: A specific machine name is typically included here, but is not required.	None. Note: This parameter is required.	kew.com nodename.UUCP
FromDomain	Token	Fully-qualified Domain name of system which overrides the Domain field for the RFC-822 From: field. Used in site hiding. See The Ever So English Sport of Site Hiding, page 35 Note: This option should only be used when site hiding. Omit it otherwise.	None.	omitted
InModem	Simple file name	Simple name (without path or extension) of [modem].MDM file to use for when uucico is invoked with the -r 0 (accepting incoming calls) option.	None. Note: This field is required to use with uucico the option -r 0 unless the -m modem option is also supplied.	HAYES24
InternalCommands	List of commands	List of commands processed by uuxqt as internal commands.	break cd chdir copy ctty date del dir echo erase for md mkdir rd rem ren rename rmdir time ver verify vol	omitted
LocalDomain	Token	Domain name which is automatically appended to simple system names being searched for during host table look-ups. Note: See also the sections on mail routing in Part 3: Advanced Mail Installation and Configuration on page 31.	If the Domain has one or two parts (x.y or UUCP), the entire domain name. Otherwise, all but the left most word of the domain name (y.z out of x.y.z.)	omitted
LogDir	Path name	Directory to which log files are written.	[ConfDir]/LOG	omitted
MailDir	Path name	Directory to which RMAIL delivers mail.	[ConfDir]/MAIL	omitted
MailExt	Token	Extension used for mailbox files.	None.	SPB^{^[54]}
MailServ	Host name	Simple host name of system to handle default mail forwarding. Note: This system must be listed in your SYSTEMS file. The systems file is discussed in The SYSTEMS file,, page 137.	None. Note: This parameter is required.	myserv
MaximumHops	Integer	Maximum number of Received: lines allowed in remote mail before it is rejected by RMAIL because of looping.	20	omitted
MaximumUUXQT	Integer	Maximum length of an RMAIL-generated command line for a remote uuxqt to execute.	512	omitted
MOTD	File name	File name with text to be displayed after successful login of non-uucico shells.	None.	omitted
MushDir	Path name	Included for use by MUSH (Mail User's Shell). Not used by UUPC/extended.	N/A	omitted
NewsDir	Path name	Directory into which RNEWS writes news. Note: Must be on same disk partition as the ArchiveDir	[ConfDir]/NEWS	omitted
NewsServ	Host name	Host to which posted news is sent for distribution to the outside world. Note: Posting news is currently not supported. This field is included for future expansion only.	Value of MailServ.	omitted
NodeName	Host name	Simple UUCP host name of the local system.	None.	toscis
Options	List of tokens	List of Boolean options from list below, optionally prefixed by “no” (such as nodoskey to disable an enabled option.	See list below.	doskey expert nodisplaycopyright undelete symmetricgrades
Passwd	File name	File name of PASSWD file containing name and directory information for local users and passwords for remote systems logging in.	[ConfDir]/PASSWD	omitted
Path	Path String	Semi-colon delimited list of directories for uuxqt to search for external programs.	Value of PATH variable when uuxqt is invoked.	omitted
Permissions	File name	File name of PERMISSN file containing access information for use by file transfers and uuxqt processing.	[ConfDir]/PERMISSN.	omitted
Postmaster	User id	Name (userid) of the user to receive bounced mail and all other mail addressed to local user Postmaster. Should be 1-8 characters and only contain valid alphanumerics.	None. Note: This field is required.	postmast
PubDir	Path name	Default file upload directory for files sent to the local system via remote UUCP commands.	[ConfDir]/PUBLIC	omitted
SpoolDir	Path name	Directory used for log files, files queued for other systems, and incoming mail/news files.	[ConfDir]/SPOOL	omitted
Systems	File name	File name of SYSTEMS file containing names and dialing information for all remote systems.	[ConfDir]/SYSTEMS	omitted
TempDir	Path name	Path of directory for temporary files generated by MAIL, uuxqt, and other programs. The drive this directory resides on must have space for twice the largest mail or news file you expect to receive. Note: If possible, this directory should be located on a RAM drive or a drive with a lazy disk cache.^{^[55]}	The value of the TMP or TEMP environment variables if set, otherwise [ConfDir]/TMP	omitted
Uncompress	String	Command string including the name of the program used for decompressing incoming news. Note: %s must appear in the string to define where the input file name should be substituted. A second %s must appear to define the output file name if the default output file name is not the input name minus the extension.	compress -d %s %s	compress -d %s gzip -d %s

Boolean Options Valid in Either UUPC.RC or [userid].RC

The following are Boolean options, which can be enabled or disabled by the user in the UUPC.RC file, their [userid].RC file, or via the MAIL set command (See MAIL, page 61).

Note: All options default to disabled except for the following list: askcc autoedit autoinclude autoprint autosign backup bounce displaycopyright domainfrom dot imfile longname multiqueue multitask newspanic pager purge showspool symmetricgrades syslog verbose.

Table 15 - Boolean Options Valid in User/System Configuration Files

Option name	Disabled operation	Operation if set (enabled)
askcc	The user must enter all addresses when invoking mail or forward. Additional addresses cannot be added to mail generated by reply.	After composing, reply to, or forwarding mail, the user is prompted for carbon copy (Cc:) addresses.
Autocall	When the UUX or UUCP command is executed, UUCICO program is not automatically invoked.	When the UUX or UUCP command is executed, UUCICO program is not automatically invoked to call the target system.
autoedit	When sending mail, the user is presented with the line oriented send mail interface. To use a full screen editor, the user must use the ~e (edit) command or exit line oriented data entry to invoke his editor.	If the user has defined an editor, when sending mail the editor is immediately invoked for the user to enter mail with.
Autoinclude	Do not automatically include the text of mail being replied to.	When the reply command is invoked, automatically include the text of the mail being replied to as if the ~m command was issued.
Autoprint	Do not print mail unless explicitly requested via the print, Print, type, or Type commands.	The next item in the mailbox is printed automatically when it is moved to by the goto, next, or previous commands, or by saving or deleting the previous item.
Autosign	When sending mail, the user's signature file is not appended to outgoing mail automatically. If defined, the user may still include the file via the ~a (include autograph) command.	If defined in the user's configuration file, the signature file is automatically appended to all outgoing mail.
Backup	Do not create a backup of the mailbox being processed before rewriting or deleting it.	Before updating or deleting the current file when exiting mail, rename the existing file to the same file name with the extension defined by the UUPC.RC variable BackupExt. Note: If no extension is defined, a default extension of "BAK" is used.
DisplayCopyright	Suppress the copyright notice at program startup. Of course, this does not suppress the associated responsibility. Note: This option must be set in a system or user configuration file, because it is only examined at start up.	Display the UUPC/extended copyright notice at program startup.
doskey	Under DOS, interactive input is read from the console using standard DOS services (INT 21H function 0AH). DOSKEY, if installed, is ignored. Empty input lines are processed normally.	If installed, the MS-DOS 5.0 (or higher) DOSKEY program is used to read input from the console; normal DOSKEY functions, including the ability to edit and scroll input, along with macro expansion, are available. Empty lines (which can be generated by DOSKEY macro processing) are ignored at the command prompt unless the expert option is also set. Note: If DOSKEY is not installed, when the user is first prompted for input the doskey option is reset to nodoskey with a warning message.
dot	When sending mail, interactive input must be terminated by the DOS end of file character (Ctrl-Z).	When sending mail, interactive input can be terminated by a single period (.) in column one.
expert	All informational messages are displayed, and if the doskey option is also set, empty input lines are ignored in response to the command prompt.	Boiler plate messages, such as the initial help prompt, are suppressed, and empty input lines are not ignored when the doskey option is set.
forwardsave	Mail sent via the forward command is not saved in the user's outgoing mailbox.	If the user has defined an outgoing mailbox, then mail sent via the forward command is saved in the same fashion as other outgoing mail.
fromsep	Items in the mailbox must be separated by a line of binary ones (1). (If you use the DOS type command to look at your mailbox, these look like smiley faces.) Note: This option is provided for compatibility with other RMAIL versions.	Items in the mailbox can be separated only by UUCP format From lines. The line of binary ones (1) required between items by the default operation of nofromsep is still generated when updating mailboxes. Note: This option must be set in the UUPC.RC or [ userid].RC file, because it is only examined at start up.
IMFile	Disk-based work files are used.	MAIL, NEWSRUN, and RMAIL use memory buffering rather than disk-based work files when possible. Falls back to disk-based files when data size exceeds a preset limit.
Pager	help, print and type use the external pager if one is defined, and Print and Type use the internal pager.	help, print and type use the internal pager, and Print and Type use the external pager if one is defined
PromiscuousRelay	UUSMTPD rejects all mail does not either originate from a host within the local domain or is addressed to a host explicitly defined in either the SYSTEMS file or HOSTPATH file.	UUSMTPD accepts all mail without regard to the origination host or destintation address.
Purge	Empty mailboxes are left in place when the user exits mail.	Empty mailboxes are deleted when the user exits mail.
Save	Mail is left in the user's system mailbox after reading.	If mail is not deleted from the user's system mailbox after reading, it is automatically saved in his ~/mbox file when the user exits mail.
Speedovermemory	Strings are allocated favoring low memory usage. Specifically, when allocating fixed permanent strings, strings already allocated are examined to determine if a pointer to existing duplicate string can be used.	Strings are allocated favoring speed over memory usage. Specifically, permanent strings are allocated without examining if a copy of the string already exists.
SuppressBeep	The program generates a beep when a panic abort occurs, when mail arrives (if configured by the user), if an invalid one letter command is issued, and under certain other conditions.	Suppress all program beeps. This is a hack to prevent crashes in DOS boxes on a certain OS/2 system here at Kendra Electronic Wonderworks.
Undelete	OS/2 only. The environment variable DELDIR is reset to a null string by uupoll, causing files deleted by its children (uucico, uupoll, and UUCLEAN) to not be archived by the OS/2 operating system for later recovery.	The DELDIR environment variable is left alone, causing OS/2 to copy all deleted files to a hidden directory. This causes a performance and free disk space impact by saving files which the user should never have to access, much less recover. Note: This option must be set in the UUPC.RC or [ userid].RC file, because it is only examined at uupoll start up.
Verbose	When invoked from mail, RMAIL only displays error messages.	When invoked from mail, RMAIL displays both error messages and nominal status messages, including the addresses mail was delivered to. Note: This option must be set in a system or user configuration file, because it is only examined at start up.
Windows	uuxqt uses input redirection to pass a -f flag and filename to RNEWS and RMAIL.	Causes uuxqt to use a file name to pass a -f flag and filename to RNEWS and RMAIL.

Boolean Options only used in the UUPC.RC file

The following system-oriented options must apply to all users on a system and can only be set in the UUPC.RC file:

Table 16 - Boolean options valid in System Wide Configuration Files

Option name	Default operation	Operation if set
bang	RFC-822 headers are generated with a "User name" <user@node> format.	RFC-822 headers are generated with UUCP style (User name) node!user format.
bounce	Undeliverable mail is delivered directly to the local postmaster mail with no additional header or text generated.	Undeliverable mail is sent to the originator of the mail (as determined by the uuxqt requester information) and to the local postmaster via a newly generated mail message from UUCP which explains why the mail failed. Note: If you enable bounce, you must also enable the Boolean Option multitask. Otherwise, RMAIL will fail when it is invoked a second time to deliver the bounce delivery message.
Collect	The size of mail is not reported by RMAIL.	The RMAIL delivery and spooling messages include the size of the files delivered.
Directory	Mail for "user" is delivered to the file user in the directory specified by the maildir= line in the system configuration file.	Mail for "user" is delivered to the file newmail in the user sub-directory of the directory specified by the maildir= line in the UUPC.RC configuration file.
Escape	Only Ctrl-Break can be used to exit from uupoll or uucico.	If the Esc (Escape) key is pressed, then the next time uupoll or uucico polls the type-ahead buffer the program will act as if Ctrl-Break was pressed. Note: Enabling this option effectively disables type-ahead, since all characters except Esc are discarded with an error message.
fastnews	NEWSRUN is queued to run under uuxqt by an RNEWS-generated uux command.	NEWSRUN is executed directly by RNEWS or INEWS.
honorcontrol	NEWSRUN ignores Usenet newsgroup commands from remote systems.	Causes NEWSRUN to execute various Usenet newsgroup commands (such as those adding or deleting groups) from remote systems.
honordebug	When uucico is called by another system, it ignores any debugging level transmitted by the caller.	When uucico is called by another system, it uses any debugging level transmitted by the remote system to set its own debugging level.
kanji	No translation of characters takes place during RMAIL processing.	Mail which originates locally is translated from a 2 byte Kanji code called Shift-JIS (Japanese ideogram) to Kanji in a 7-bit subset of ISO 2022 which can be transmitted via SMTP. Mail from remote systems which is delivered locally is translated from JIS 7bit back to Shift-JIS.
longname	Under OS/2 and Windows NT, file names for incoming files are made to conform to the DOS 11 character name limit even if the file system supports longer names.	Under OS/2 and Windows NT, file names are not made to conform to DOS name 8 + 3 naming conventions.
monocase	Job sequence ids are generated in base 62 using numerics and upper and lower case alphabetics.	Job sequence ids are generated in base 36 using numerics and upper case alphabetics.
multiqueue	When queuing mail for other hosts, each addressee is delivered separately.	When queuing mail for other hosts, a single file delivered via the remote UUCP can have multiple addressees.
multitask	Processing is optimized for speed over system integrity. Note: We strongly recommend that you enable this option in all environments except DOS.	Additional processing is performed to insure system integrity. This additional processing includes creating lock files to prevent concurrent access to system spool directories, writing program logs to temporary files and then appending the file to the permanent log file at program termination, and moving new mail from the user's system mailbox into the user's home directory when MAIL is first run after the new mail's arrival.
Newspanic	uuxqt proceeds to its next item if RNEWS fails.	uuxqt aborts immediately if RNEWS fails.
nns	No special processing occurs to create files for NNS.	All incoming news batches are uncompressed and left in NewsDir with the extension .NNS. This is in addition to any processing driven by the ConfigDir SYS file or by the snews option.
Senddebug	When uucico calls another system, it does not report its debugging level to the remote system.	When uucico calls another system, its debugging level is transmitted to the remote system.
Shortfrom	A UUCP File-From line is written at the beginning of each mail file, showing the previous and destination systems.	Truncates the normal UUCP File-From line to omit reference to the previous system. Does not affect the RFC-822 From: header line.
Showspool	Transferred spool files are not displayed on the screen.	Displays files destined for spool directories during transfer. (The default behavior prior to version 1.11y)
snews	Incoming news is written to separate files in directories based on the news group names listed in the ACTIVE file located in the NewsDir directory.	Incoming news is written exactly as received to a file with extension .ART in the NewsDir directory without examining the ACTIVE file. This is in addition to any processing driven by the ConfigDir SYS file or by the nns option.
Suppressemptypassword	Sends a password prompt for all logins.	Suppress the password prompt for user ids that do not have an assigned password.
Suppressfrom	A UUCP File-From line is written at the beginning of each mail file, showing the previous and destination systems.	Completely omits the normal UUCP File-From line. Does not affect the RFC-822 From: header line.
Suppresslogininfo	When uucico answers a connection, it displays version number, communications port, system name, and other information.	Suppresses normal login information messages.
Symmetricgrades	When actively polling, uucico does not transmit the maximum grade for file transfers allowed by the SYSTEMS file to the remote system at startup.	uucico transmits the maximum grade for file transfers allowed by the SYSTEMS file to the remote system at startup.
syslog	No record is made of files transferred.	The file SYSLOG is written in the spool directory with a record for each file transferred to or from the local system.

Modem ([modem].MDM) Files

Introduction

Modem files (.MDM) define the strings used to command a modem when dialing out. They allow commands always used with a particular modem to be written once rather than being placed everywhere they are used, and also allow different modems to be used by changing only the modem file (or changing the reference to the modem file in the SYSTEMS or UUPC.RC files).

All strings defined in a modem file are standard scripts as described in The Fine Art of Chat Scripts, page 143, with the exception of the dial prefix and dial suffix strings. The dial prefix and suffix strings are combined with the phone number listed in the SYSTEMS file and sent as one string to the modem when dialing out. Most modems have behavior similar to one of the sample modems, so minor changes to one of these files should get you up and running.

Note: If you make changes to a modem file, copy it to a new name to avoid confusion with the distributed version.

The syntax of a modem file is the same as the UUPC.RC and [userid].RC files described in The UUPC.RC and [userid].RC files, page 115. The keywords accepted in modem files are described below.

Modem File Guidelines

There are several things to keep mind when writing a modem file, especially for an error correcting modem. Not all of the following apply to all modems, but as a general rule:

1. Initialize the modem from factory defaults as opposed to simply resetting the modem. Starting with factory defaults allows the modem configuration to be shared between modems that may not have been initialized the same way.

Note: Do not have the modem file rewrite the modem defaults to non-volatile RAM (often done with a AT&W command). This may confuse other programs which use the modem.

2. Turn the modem speaker off. (Typically ATM0)^{^[56]}

3. Have the modem hang-up and reset to factory defaults when Data Terminal Ready (DTR) is lowered.

4. Write a unique modem file for dialing out with error correction only, rather than taking a modem default which accepts error or non-error correcting connections. Rejecting a remote connection if the expected speed or protocol is not available insures that a long distance connection does not run at a sub-par rate.

5. Likewise, write a modem file with error correction disabled, to bypass attempts at modem-to-modem protocol negotiations with modems which do not support them.^{^[57]}

6. Disable auto-answer unless you actually want to have the modem ready to answer the phone.

7. Disable software (XON/XOFF) flow control, and enable hardware (CTS/RTS) flow control.^{^[58]}

8. Enable the modem inactivity time-out to automatically hang up the modem after two minutes if no data is sent or received. If no data is send by uucico in two minutes with the modem off hook, the program and/or operating system has crashed.

9. Some modems have a time delay to insure all data buffered for the remote system is sent. Set this delay to zero (no delay), as uucico will have insured data delivery via software protocols.

10. Disable remote loop back testing.

Once you have a working modem file--one that successfully connects and transfers files--you can start playing with packet sizes, protocols, and so forth to improve your throughput.

Valid Fields in Modem Files

The following fields are valid in a modem file.

Table 17 - Modem File Configuration Keywords

Keyword	Type	Description	Default	Example^{^[59]}^,^{^[60]}
Answer	Script	Script to pick up phone (if Ring script did not enable auto-answer) and determine an incoming call has been answered.	None. This field is required for answering the phone.	CONNECT
AnswerDelay	Integer	Time in seconds for last response expected by Answer script.	30 seconds	omitted
BigGPacketSize	Integer	Maximum number of bytes the remote host may send the local host per packet when using the "G" protocol. Must be a power of 2 between 32 and 1024	1024 bytes	omitted
BigGWindowSize	Integer	Number of packets active at a time when using the "G" protocol. Must be in the range 1 to 7.	7	omitted
CharDelay	Integer	Delay in milliseconds between characters sent to the modem when processing dialing scripts.	0	omitted
Connect	Script	Script used to determine if modem has connected to remote host.	None. This field is required for dialing the modem.	CONNECT
Description	String	One line description of the modem file. This field is for documentation purposes, and is extracted to build the list of modems in Table 19 - Modem Files Included on page 134.	None.	Zoom v32bis with v.42 and v.42bis enabled
Device	Token	Communications Port Name This field is ignored by the TCP/IP and named pipe suites.	None. This field is required.	COM1
DialPrefix	String	String prepended to the phone number in SYSTEMS file to dial modem.	None. This field is required for dialing the modem.	ATDT
DialSuffix	String	String appended to the phone number in SYSTEMS file to dial modem.	None. Normally not needed.	omitted
DialTimeout	Integer	Time in seconds last string in Connect script is allowed to wait for a respond.	40	20 (local calls) 60 (long distance)
ePacketTimeout	Integer	Time in seconds allowed for responses by the remote host under "e" protocol.	60	omitted
fPacketSize	Integer	Bytes processed at a time by the "f" protocol.^{^[61]}	1024	omitted
fPacketTimeout	Integer	Time in seconds allowed for responses by the remote host under "f" protocol.	20	omitted
gPacketSize	Integer	Maximum number of bytes the remote host may send the local host per packet when using "g" protocol. Must be a power of 2 between 32 and 1024. Note: Due to kernel buffer sizes, most UNIX systems cannot handle a gpacketSize larger than 128.	64 bytes	omitted
gPacketTimeout	Integer	Time in seconds allowed for responses by the remote host under "g", "G", and "v" protocols.	10	omitted
gWindowSize	Integer	Number of packets active at a time when using "g" protocol. Must in range 1 to 7.	7	omitted
Hangup	Script	Script to hang-up modem. Note: Before this script is executed, the modem Dataset Ready (DTR) line is dropped for 0.5 seconds to request a modem hang-up.	None.	ATH OK
Initialize	Script	Script to initialize modem.	None. This field is required.	AT &F OK ATEM OK
InSpeed	Integer	Speed at which modem is initialized for remote login.	None. This field is required for answering the phone.	2400 38400
MaximumErrors	Integer	For all protocols except "e" and "t", the number of consecutive errors allowed before the connection is dropped. Note: Consecutive errors are defined as errors occurring with no data successfully transmitted between the errors.	10	omitted
ModemTimeout	Integer	Number of seconds allowed for modem command responses in scripts except for the last responses to the Answer and Connect.	3	omitted
NoConnect	One or more strings	Modem responses, which, if given, indicate that dialing or answering has failed and the call should be given up on.	None.	"NO DIALTONE" "NO CARRIER" ERROR
Options	List of Boolean options	See below for individual options.	Nocarrierdetect nodirect nofixedspeed novariablepacket	carrierdetect fixedspeed
PortNumber	Integer	When using the TCP/IP suite, specifies the port number to listen on for inbound connections.	540	omitted.
Ring	Script	Script to initialize modem for answering and to detect ring.	None. This field is required for answering the phone.	ATS0=1 OK "" RING
ScriptEchoTimeout	Integer	Time allowed for echoing of transmitted characters driven by the \E command in scripts.	5	omitted
ScriptTimeout	Integer	Time allowed for responses to scripts specified in SYSTEMS file.	30	omitted
StartupTimeout	Integer	Controls the amount of time UUPC/extended waits while exchanging system names and file transfer protocol to use with the remote system.	40	omitted
Suite	Token	Name of communications software driver suite. All systems support the default, internal, which drives the serial port using internal and Operating System support. DOS systems can also use the fossil, or Int14 suites. OS/2, Windows 3.x and Windows 95/NT systems can also use the TCP/IP suite if they have TCP/IP support installed.^{^[62]} Windows 95/NT 4.0 can specify tapi, which uses the native modem configuration support. OS/2 2.x systems can use the NamedPipes suite, although this support is primarily of use for testing on a single system.	internal	omitted
tPacketTimeout	Integer	Time in seconds allowed for responses by the remote host under the 't' protocol.	60	omitted
TransferBuffer	Integer	Size in bytes of internal disk I/O buffer in bytes. Note: If the specified value is less than the default, the default is used.	1024	omitted
Version	Token	Program version number the file was last updated for. This field is for documentation purposes and is extracted to build the list in Table 19 - Modem Files Included on page 134.	None.	1.13j
vPacketSize	Integer	Bytes sent per packet when using "v" protocol. Must be a power of 2 between 32 and 1024.	1024 bytes	omitted
vWindowSize	Integer	Number of packets active at a time when using "v" protocol. Must in range 1 to 7.	7	omitted

Boolean Options In Modem Files

The following option flags can be set on the options line of the modem file.

Table 18 - Boolean options valid in Modem files

Option name	Default operation	Operation if set
CarrierDetect	uucico processing ignores the state of the modem status lines.	If the modem Terminal Ready (DTR) or Carrier Detect (DCD) lines drop after a connection is established, the connection is aborted.
FixedSpeed	After the Connect or Answer script executes, uucico reads the serial port for the connect speed of the modem and changes the port speed to match this reported speed.	The modem speed is fixed at the value specified by the InModem keyword or Systems file speed.
VariablePacket	Data Packets sent by the "g" and "G" protocol are always padded to the full packet length negotiated at startup.	Data Packets sent by the "g" and "G" protocols are padded only to the nearest power of 32 (32, 64, 128 ...) and these short packets are sent. Note: Most UNIX systems cannot handle variable length packets, and connections to such will fail in mysterious ways if this option is enabled.^{^[63]}
Direct	The modem Dataset Ready (DSR) line is used for hardware flow control: When the modem lowers this signal, uucico stops transmitting data until the signal is raised again.	The modem Dataset Ready line is ignored.

Supplied Modem files

The follow table lists the sample modem files supplied with UUPC/extended. As these files have been collected from a number of sources previous to the above guidelines being written, the modes and setups vary. Most of the files do not exactly conform to the above guidelines.

Note: Please mail new and updated modem files to modems@kew.com. Please verify the file is updated to conform with the guidelines on page 128, supply Description= and Version= fields, and include instructions as to whether the file modifies an existing modem file or should be added to the collection as a new file.

Table 19 - Modem Files Included

File name	Version	Description
CODEX		CODEX Modem with MNP Protocol enabled
DIR		Direct connection, between two systems connected by a null modem cable.
GVCV32		GVC 9600 V.32/V.42bis with smart options, serial port speed locked
GVCV32G		GVC V.32/V.42bis with autobaud, for answering calls from 2400 baud modems
HAYES12		Hayes Smartmodem 1200
HAYES24		Generic Hayes Smartmodem at 2400 baud, disabling command echo
HAYES241		Generic Hayes Smartmodem at 2400 baud
HAYES24D		Generic Hayes Smartmodem at 2400 baud
INSATFAX		Intel SatisFaxtion modem
INTEL24E		Intel 2400ex modem
PIPES	1.12b	Named Pipes Modem definition file for OS/2
PPI-V32B		PPI 14400FX V.32bis/V.42bis modem
QBLAZER		Telebit QBlazer Modem - v32 mode with port locked at 9600
QBLAZER2		Telebit QBlazer Modem - v32 mode with speed shifting
SAMPLE	1.12a	Generic sample modem file
SUPRA		Supra V.32bis FAXmodem with MNP 2, 5, and 10
SUPRA12		Supra V.32bis FAXmodem with MNP disabled, 1200 baud only
SUPRA24		Supra V.32bis FAXmodem with MNP disabled
SUPRV32B	1.12a	Supra V.32bis FAXmodem
SX1200		Microcom SX1200 MNP/4 modem with MNP 4 enabled
SX1200D		Microcom SX1200 MNP/4 modem with MNP disabled
TB1000		Telebit Trailblazer T1000
TB2500		Telebit Trailblazer T2500 (V.32/V.42bis) with 7.x PROM upgrade
TB2500A		Telebit Trailblazer T2500 (V.32/V.42bis) with 7.x PROM upgrade
TBPLUS		Telebit Trailblazer Plus with 7.x PROM upgrade
TBPMNP5		Telebit Trailblazer Plus with 4.x PROMs -- MNP5, but no V.42bis
TBPPEP		Telebit Trailblazer Plus locked into PEP mode
TBW56K		Telebit WorldBlazer (V.32bis/V.42bis) modem, at 57.6 Kbaud
TBWORLD		Telebit WorldBlazer (V.32bis/V.42bis) modem
TCPIP	1.12f	TCP/IP Network connection
TELEPATH		Gateway 2000 Telepath modem
USRCV32B		U. S. Robotics V.32bis/V.42bis Courier Dual Standard
USRSPORT		U. S. Robotics Sportster V.32/V.42bis
USRSPRT2		U. S. Robotics Sportster V.32/V.42bis
WBDUMB		Telebit Worldblazer modem with MNP/5 and V.42bis disabled
ZOOM2400		Zoom 2400/V.42bis, with V.42bis disabled
ZOOM4BIS		Zoom 2400/V.42bis with v.42/v.42bis options enabled
ZOOMBUFF	1.12d	Zoom VFX 14400 with V.42bis and MNP5 disabled, buffering enabled
ZOOMDUMB	1.12d	Zoom VFX 14400 with V.42bis and MNP5 disabled, unbuffered
ZOOMV32T		Zoom Turbo V.32/V.42bis modem
ZOOMVFX	1.12a	Zoom VFX 14400 modem with v.32/v.32bis/v.42/v42bis enabled but not forced
ZOOMVFXB	1.12a	Zoom VFX 14400 modem locked into V.32/V.42bis mode
ZYXEV32B		ZyXEL U-1496E+ V.32bis/V.42bis modem

The PASSWD file

The PASSWD file serves two purposes. If you have several people reading mail on your system, it is used to assign them default directories and mail files. Entries in the PASSWD file also control whether remote machines can log in to your system to send and receive mail themselves.

Note: The home directories and user names in the PASSWD file must match the same entries in the [userid].RC files.

Copy the PASSWD file to the \UUPC directory, and then replace the sample users with your local users. This file defines the name and home directory of each local user, and the user id and password for remote users (systems) logging in using the following format:

mailbox:password:special:group:name:home:shell

More specifically:

Table 20 - Fields in the PASSWD File

Field name	Description	Examples
mailbox	User id to receive mail locally or login remotely. This should be from 1 to 8 valid DOS characters. For local users, this should be the same as the mailbox field(s) of the [userid].RC file(s).	fbwatt postmast
password	Ye ole security field. A * in this field means that no remote logins are allowed for that user. For instance, a local user is not able to login via phone lines. If the field is empty, no password is required. For your own protection, a system that allows dial-in access should assign either a * or a password to all accounts.	* AppleJuice
special	This field contains the user id number on UNIX systems. UUPC/extended uses it to play music or otherwise make noise to announce incoming mail from remote systems if desired. The format of field is tone1, length1, tone2, length2, and so on, where "tone" is the frequency in hertz and "length" is the time the tone is to sound in milliseconds. If the final length is omitted, the final tone will sound for 500 milliseconds. A special tone is 0, for silence. Under Windows 95/NT only, the field be also be the full path name of a .WAV audio file to play. Other environments will ignore such a name if provided.	(empty) c:\windows\media\The Microsoft Sound.wav 2000,250,1000,250
group	This field is the group id on UNIX systems. In UUPC/extended, it specifies the name of the group “pop3” for those user authorized to the UUPOPD daemon to retrieve their mail.	(empty) pop3 uucp
name	The real human name of the user. For local users, this field is included in mail headers if no other name for the user is known.	Frederick B. Watt
home	Home directory for this user. Used only for local users. Default is /UUPC/PUBLIC, which is a lousy choice. Note: This field should match the Home= field for the user in his [userid].RC file.	/u/fbwatt
shell	Login shell for remote users. The default is to perform normal UUCP processing. Note: Use of a shell other than the internal UUCP protocol process is covered in Having uucico Invoke External Programs on page 49.	(empty)

The SYSTEMS file

Introduction

The SYSTEMS file contains the names of your UUCP neighbors, and describes how and when to communicate with them.

The SYSTEMS file contains comments and system descriptions. As in the other system configuration files, any line beginning with "#" is treated as a comment. The system descriptions lines look like the following:

hostname Time MODEM speed phone protocol expect-string send-string expect-string send-string...

Example: Toscis's SYSTEMS file entry for kewgate looks like this:

kewgate Any TB2500 19200 781-279-9816 vg gin:--gin: Utoscis ssword:--ssword: AppleJuice

The SYSTEMS file may contain several entries for the same remote system. If UUPC/extended can't connect to a system using the first entry in the SYSTEMS file, it tries the others. See Multiple entries in the SYSTEMS file, page 145, for more details.

Each of the fields in the SYSTEMS file is described in the table below.

Table 21 - Description of the fields in the SYSTEMS File

Field name	Description	Example
hostname	Name of the system to call. Any system you call or are called by must be listed at least once in this file.	vanilla
Time and grade	When calls may be made to this system. Any allows calls 24 hours a day, Night and Evening refer to night and evening phone rates respectively. Never is used for systems which only call you. See the chart, below.	Any
MODEM	Name of the modem file (without the .MDM extension) used to call this system.	TB2500
Telephone, TCP/IP host name (and optionally port name), or pipe name	Telephone number to call, host name/port number to connect to over the network (when using TCP/IP suite). or named pipe to connect to (when using NamedPipes suite).^{^[64]} Note: For TCP/IP connections, the format of the field is host:port. The port is optional, and defaults to the standard entry for UUCP in the TCP/IP services configuration, or port 540 if no services file exists.	781-279-9816 mailserver.domain.name server.host.name:540 \\servername\pipe\uucp
p (protocol)	Protocol to use when calling. If you don't know what protocols are available, then leave the "g" alone for a modem connection, or specify "get" for a network connection. Note: See below under "Protocols" for a full list of available protocols.	g v e gGv
script	Login script for the system. Note: See below under "Scripts" for a further explanation.	gin:--gin: Utoscis ssword:--ssword: AppleJuice

Time

The Time field allows you to restrict the hours that your machine calls your neighbors. You can combine several different times to call into the Time field. When you do so, the times your machine is permitted to call is the or-combination of all of the times entered.

Note: Time fields are ignored (treated as if you specify Any) if the -n option is used on the uucico command line.

The entries in the time field are combinations of labels and times. The labels represent days of the week, or groups of days, or combinations of days and times that match U. S. telephone rate schedules, like Evening or Night. The times are on a 24 hour clock, and must use four digits. The specified times are logically and-ed together with the times for the labels listed in the table below.

Example: Mo0800-1700,Night

In this example, the machine would be permitted to call out on Mondays between 8 AM and 5 PM, or at any time that night rates are in effect. (The exact time is in the table below.)

Example: ROA0800-1700

In this example, the times listed below for ROA are and-ed with the times listed in the table, so in practice, the system will only be permitted to call out between 8 AM and 5 PM on Saturdays.

If you don't care what time your machine calls your neighbors, put "Any" in the Time field. If you never want to call your neighbor (if they want to call you instead, for example), then put "Never" in the Time field. The other possible entries are:

Table 22 - Values Allowed for Time field in SYSTEMS File

Keyword in Systems File	Days of the week dialing can occur	Time of day dialing can occur
Any	Any time at all	24 hours a day
Never	None	None
Wk	Weekdays only	24 hours a day
Mo	Mondays only	24 hours a day
Tu	Tuesdays only	24 hours a day
We	Wednesdays only	24 hours a day
Th	Thursdays only	24 hours a day
Fr	Fridays only	24 hours a day
Sa	Saturdays only	24 hours a day
Su	Sundays only	24 hours a day
Evening	Monday through Friday Weekends	5 PM until 8 AM 24 hours a day
Night	Monday through Friday Saturday Sunday	11 PM until 8 AM 24 hours a day Midnight until 5 PM and after 11 PM
NonPeak^{^[65]}	Weekdays Weekends	6 PM until 7 AM 24 hours a day
ROA^{^[66]}	Weekdays Saturday Sunday	10 PM until 8 AM 24 hours a day midnight until 5 PM and after 10 PM

Call grades

Each job which is queued for uucico to transfer has a call grade associated with it. This is simply the first letter of the job name after the system name as shown by the UUSTAT command. Grade 0 has highest priority, and z has the lowest. Overall, the priorities from highest to lowest are 0-9, A-Z, and a-z, in that order. RMAIL queues jobs at class C by default, and UUCP queues jobs at class n by default.

Normally these classes are of no concern to the end user, but if the local system must call long distance or has other reasons to restrict traffic processed at particular hours, then each time field in the SYSTEMS file may modified by appending a slash and the lowest call grade to processed at that time. For example, to process only mail during the day and all other files to a system at night, the SYSTEMS file time entry would look like this:

Any/C,Night

Note: The processing of call grades is affected by both the grades used by the remote system, the use of the symmetricgrades option in the UUPC.RC file (as described in The UUPC.RC and [userid].RC files, page 115, and use of the -g option on the uucico command line.

Protocols

Two machines which talk to one another using UUCP can use one of several protocols to do so. Some of these protocols are more efficient than others, depending on the how fast and reliable the modem connection is, and whether or not 7- or 8- data bits are used in transmitting messages and files between them. UUPC/extended supports several different protocols, any of which might be used for talking to a remote system, depending on the circumstances.

In addition, the protocols have tunable parameters, set in the [modem].MDM file, which can improve their performance, depending on the circumstances. The protocols, the names of their tunable parameters, and the circumstances under which you might choose a particular protocol are described in the table below.

Table 23 - Protocols Supported in Systems File

Protocol^{^[67]}	Tunable parameters	When to use the protocol
*	none	This flag denotes the entry is not for a UUCP system at all, but rather for calling the U.S. National Institute for Standards and Technology (NIST) atomic clock to set the local system time.^{^[68]} Note: The NIST clock can be reached at 1-303-494-4774 at 1200 characters per second with no error correction.
e	ePacketTimeout	This protocol is for use over reliable network connections, such as TCP/IP or named pipes. With this protocol, files are transferred with no checksums to detect errors, which improves transfer speeds. Because no error correction is performed, this protocol is not available for modem connections.^{^[69]} Note: If a network level error occurs, this protocol aborts with no retries.
f	fPacketSize fPacketTimeout MaximumErrors	This is intended for use over reliable 7-bit links such as X.25, where XON/XOFF (software) flow control is used instead of RTS/CTS (hardware). It is also only a 7-bit protocol, which means that it is inefficient on binary data.
G	BigGPacketSize BigGWindowSize GPacketTimeout MaximumErrors	For supported systems, G protocol allows for higher performance on high-speed modems by increasing the number of bytes between packet checksums and acknowledgments. Its drawback is that the UNIX implementation of the G protocol is only available on newer implementations (System V Release 4), and is hard to configure.
g	gPacketSize gWindowSize GPacketTimeout MaximumErrors	When attempting to make the FIRST connection to another system, use g protocol with the default packet size of 64 bytes. It is widely supported. The 'g' protocol is it is slow because its default configuration requires six bytes of overhead data to be transmitted for every sixty-four bytes of user data. The 'g' protocol also requires an acknowledgment after sending only 448 bytes of data, which is smaller than the internal buffer of many error correcting modems. This protocol should also be used with Telebit Modems and other modems which spoof the UUCP 'g' protocol for additional performance boosts. Spoofing modems generally only support 'g' protocol but have better performance compared to non-spoofing modems.
t	tPacketTimeout	This protocol is for use over reliable network connections, such as TCP/IP or named pipes, to systems such as BSD based UNIX systems which do to not support the faster 'e' protocol.. With this protocol, files are transferred with no checksums to detect errors, which improves transfer speeds. Because no error correction is performed, this protocol is not available for modem connections. Note: If a network level error occurs, this protocol aborts with no retries.
v	vPacketSize vWindowSize MaximumErrors	When two systems running UUPC/extended version 1.11x or greater are talking to each other, use v protocol. The 'v' protocol supports larger packet sizes, while more flexible and easier to configure than 'g' or 'G' protocols. The main disadvantage to the 'v' protocol is that only UUPC/extended and the next release of Taylor UUCP support it.^{^[70]}

Scripts

Finally, the last few fields of the system description are the strings that UUPC/extended expects, and will send, when it has successfully connected to the remote system, and is trying to log in. The example on page 137 is a typical simple example. If you need something more complicated, see read The Fine Art of Chat Scripts, below..

The Fine Art of Chat Scripts

Setting up custom chat scripts used in the SYSTEMS and modem [*.MDM] files is the hardest part of configuring UUPC/extended. The easiest way to think of chat scripts is as a dialogue between the local system and a modem or remote system. The script consists of a series of strings sent to the modem/remote system alternating with the expected response to those strings.

Note: Road warriors will find that the SYSTEMS and modem file need to be changed each time you use a different physical telephone line. Each hotel’s system has its own quirks, and we don’t even want to talk about international calling . . . At least until you get the hang of it, you’ll probably want to pack your modem manual and a copy of this section along with the computer.

For example, a modem file needs to contain an initialization sequence, which will look something like this:

"" "" "" \pATZ OK \dATX4&D2 OK

That line looks awfully intimidating at first, so we'll break it down into its component parts.

"" An empty string. The first one is a flag marking the start of the script and showing that nothing is expected from the modem.

"" The second empty string sends nothing followed by an automatically appended carriage return so that the following statements will start on a new line.

"" The third empty string indicates that no response to the second one is expected.

\p Pause for 0.4 seconds to allow the modem to catch up.

ATZ This command resets a Hayes-compatible modem to its stored profile. Again the carriage return is appended.

OK The response from the modem showing that it has been reset.

\d An escape sequence which produces a two second delay to give the modem time to recover from the previous input.

ATX4&D2 A modem initialization string. Contents of this string depend on your modem and desired options. As always, a carriage return is appended.

OK The modem responds that it has been initialized and is ready to dial.

The complete list of supported escape sequences follows. The empty string ("") is used on input. All other strings are recognized on output only. Quotation marks may be used on input or output to enclose a string which includes whitespace. The list includes:

Table 24 - Strings Supported in Chat Scripts

String	Associated action or meaning
""	Expect a NULL string. May also enclose a string which includes whitespace.
\\	Insert a backslash (\)
\b \B	Insert a backspace
\c \C	Omit the automatic carriage return at the end of the string
\d \D	Delay two seconds.
\E	Enable echo checking. uucico will wait for each character sent to the serial port or network to be echoed back to it before waiting for the next character. Note: If echo checking is enabled, it should be disabled before sending strings which are not echoed such as passwords.
\e	Disable echo checking. This is the default.
\m \M \r \R	Insert carriage return.
\n	Insert newline.
\nnn	Convert the numeric octal string nnn to a single character and transmit it.
\p \P	Delay four-tenths of a second.
\s \S	Insert space character.
\t \T	Insert tab character.
\Znnnn	Set serial port speed to nnnn in the range 300 to 57600^{^[71]}
BREAK	Send BREAK.

One other special syntax exists. To allow for alternate output when an expected string is not received, hyphens in an expect string delimit alternate output to be sent, such as:

"" "" ogin:--ogin:--ogin:

If a login prompt (ogin:) is not received by the standard time-out period (generally, 30 seconds, but configurable in the modem file), the string between the hyphens (nothing, followed by the appended carriage return) is sent; if no response is received, the sequence is repeated one more time.

If your chat script doesn't work, check and make sure that you have allowed delays between transmissions to allow the modem to recover. Failure to include needed delays can cause dropped characters and is one of the most common mistakes made by new chat script writers.

Multiple entries in the SYSTEMS file

It is possible to have more than one entry in the SYSTEMS file for the same remote system. You might want to do this if one of your UUCP neighbors has several phone lines, several ways of logging in, or just has trouble connecting on the first try.

If the SYSTEMS file has multiple lines for one remote system in it, UUPC/extended uses the entries for the system in the order they appear until it gets connects to the remote system and completes the call. The call will not complete if:

The time field specifies an entry should not be used at the current time

The modem fails to initialize

Your system doesn't connect to the remote system because of a busy signal or other dialing error

The connection fails, because of trouble with the log-in script or an excessive number of bad packets.

In other words, the later lines in the SYSTEMS file for the system will only be used if the first connection is not completely successful.

Example: A system has SYSTEMS file entries for kewgate that looks like this:

kewgate Any TB2500 19200 1-617-555-4817 g gin:--gin: Utoscis ssword:--ssword: AppleJuice
kewgate Any TB2500 19200 1-617-555-4817 g gin:--gin: Utoscis ssword:--ssword: AppleJuice
kewgate Night HAYES24 2400 1-617-555-4817 v gin:--gin: Utoscis ssword:--ssword: AppleJuice

In the example, kewgate will be dialed up to three times until the call completes, twice using the TB2500 modem file and once using the HAYES24 modem file. Both TB2500 attempts are made at any hour, but the HAYES24 is only attempted at night.

System Mail ALIASES File

The system mail alias file can be used to reroute mail for local addresses to local or remote users or groups, or to pipe mail into a program (such as an automated response program). RMAIL checks all local addresses that it processes against the system alias file. If an alias is found, the mail is redirected but the mail header is never changed.

To be used, the system wide alias file must be called ALIASES^{^[72]} and reside in the configuration directory. While the nickname file performs a simple text substitution, the system alias file interacts more subtly with the rest of mail delivery.

As in the nickname file, blank lines and lines beginning with a pound sign (#) are ignored. Unlike the nickname file, aliases may span more than one line, and one or more blank lines must be inserted between aliases. Also, the system alias file does not include the full (human) name of the aliased address. The general format of an alias in the system alias file is:

alias:         address1
      address2
      address3 ...

alias:
      address1
      address2
      address3

At least one address must be specified, and only one address may appear per line. The address may take one of the following formats:

address Simple address, subject to normal forwarding rules on the local system.

\address An address prefixed by a backslash. Remote addresses are delivered normally, but local addresses are delivered without user id verification or forwarding.

|command An MS-DOS, OS/2, or Windows NT command prefixed by an "or bar" ( | ). The mail, including the header, is piped into the specified command.

>progflags Program flags for secondary mailer specified by VMail= variable in UUPC.RC file. See Using V-mail and Other Third Party Mailers on page 48, below.

pathname The absolute path name of a file. To be recognized as a file, the file must begin with a slash (/), a tilde (~), or a driver letter/colon sequence (x:). The mail is appended at the end of the specified file normally, with a line of binary ones separating mail items just as if it were a mailbox.

Note: For file names beginning with tilde (~), the file name is expanded as described in MAIL, page 61

:include: pathname The indicated file is read for additional addresses. The entire included file is read. Blank lines are ignored in the included file, but unlike the system aliases file blank lines do not indicate the alias is ended.

One special rule applies to the above. If a simple local address appears in the system aliases file, then when forwarding rules are applied it will not be looked up in the system aliases file a second time. If the same address appears in either a file included by the system aliases file or in a FORWARD file the system alias will be used. This rule allows a group of systems to all use the same system alias file to forward mail to users spread across the systems but at the same time allows the use of system aliases in mailing lists or personal FORWARD files. For example, given the following systems alias file on the systems mine.woods.com, cottage.woods.com, and atlarge.woods.com:

dopey: dopey@mine.woods.com

sneezy: sneezy@mine.woods.com

doc: doc@mine.woods.com

swhite: swhite@cottage.woods.com

prince: prince@atlarge.woods.com

If mail is sent from any of these systems to the user swhite, the system aliases file will cause it to be rerouted to swhite@cottage.woods.com. However, once cottage.woods.com receives the mail it will process the alias once and then deliver it normally.

User Mail FORWARD File

Any user can use a file to direct how mail inbound to the user is handled. This file must be named FORWARD and reside in the user's home directory as defined in the PASSWD file or [userid].RC file. The file format is simply one or more addresses on separate lines:

address1
address2
address3

These addresses are in the same format as the system alias file addresses described in System Mail ALIASES File, page 146, above. Blank lines and comment lines with a pound sign (#) in the first column are ignored but do not terminate reading of the file.

As an example, the following file, if saved in the user's home directory under the name FORWARD, would cause the mail to be formatted to the console via the FMT program (See FMT, page 54) to be forwarded to the postmaster normally, to be saved in the mailbox for user BOGUS without checking to see if BOGUS exists or has forwarding enabled, and finally to be saved in the user's home directory in the file BKUPMAIL.TXT:

|FMT
postmaster
\bogus
~/BKUPMAIL.TXT

User Mail Nickname File

MAIL uses the nickname file to translate a short nickname to the longer full name and address needed to send mail to a remote site. The expanded name and address are actually written as part of the mail header generated by MAIL.

The nickname file may have any name. It is located by the Nickname= variable in the UUPC.RC or [userid].RC file. If this variable is not defined in either configuration file, no nickname file is used.^{^[73]} Blank lines and lines which begin with the pound sign (#) are ignored. Multiple users may share a nickname file by defining the same name on the Nickname= line in the UUPC.RC file or their [userid].RC file, but only one alias file is included by MAIL. If the Nickname= line appears in both the UUPC.RC and file the [userid].RC file, only the alias file in the [userid].RC file is used. A sample nickname file, NICKNAME.TXT is included with the distribution file.

Note: The addresses supplied in the NICKNAME.TXT file are valid addresses. They are provided as examples and to assist you in getting more information about UUPC/extended, communications software in general, Usenet, and the Internet. However, they are not for random testing. Abuses such as the user who sent mail to all the addresses in the file as a "hello world" test would force discarding of the live information for future releases.

Nicknames are defined in one of two formats. One is used to a define a nickname for a single addressee, and the other defines a list of users. The first format, defining one addressee's real name and associated e-mail address, is done by putting the information on one line in the alias file with the following syntax:

nickname "Fullname" <address>

Where nickname is the name you wish to use for the person when sending mail to them, "Fullname" is the full name of the person, and <address> is the electronic mail address for the person. The three fields must be separated by spaces or tabs. Nicknames are not case sensitive, addresses are case sensitive for some older mailers, and the full name is not case sensitive but its owner may be. Thus, for our friend Fred, the alias would be:

fred "Fredrick Flintstone" <FFlintstone@dino.bc>

When sending mail, the command:

mail fred

Will produce an addressee line with:

"Fredrick Flintstone" <FFlintstone@dino.bc>.

You can also define lists of addresses by defining a nickname with one or more nicknames for the addressee, such as:

groupname nickname1 nickname2 nickname3 ...

You must not put multiple full names/address pairs on one line, as the results will be unpredictable.^{^[74]} You can specify groups^{^[75]} within other groups. As an example, to define all of Fred's family and send to them as group, the aliases could look like:

WRONG:

parents "Fred" <FFlintstone@dino.bc> "Wilma" <WFlintstone@dino.bc>

RIGHT:

fred "Fredrick Flintstone" <FFlintstone@dino.bc>
wilma "Wilma Flintstone" <WFlintstone@dino.bc>
pebbles "Pebbles Flintstone" <Pebbles@dino.bc>

family pebbles parents
parents fred wilma
flintstones family

Note that the alias for flintstones is totally optional, it merely allows you have an additional choice to send mail to the users defined by the family alias. This allows sending to the entire first family of Bedrock by typing either:

mail flintstones

mail family

HOSTPATH routing file

Synopsis

victim canonical-name

victim @ SMTP-server-hostname

victim = canonical-name

victim | program-name

Description

The HOSTPATH file provides host routing, aliasing, and gatewaying information to the RMAIL program to allow special processing of mail on a per host basis. Use of the file is optional. If used, the file must be called HOSTPATH and must reside in the configuration directory.

Within the file, blank lines and lines which begin with a pound sign (#) are ignored. Other lines have one of three formats, with common guidelines:

· The operands must be separated by white space.

· All operands must fit on one line.

· The victim (the system for which rerouting is desired) may be specified as a simple host name (dino), a fully qualified domain name (dino.bc), or a sub-domain prefixed by an asterisk (*.bedrock.bc) to denote all hosts within a sub-domain.

· A canonical-name may be a simple host name or a fully qualified domain name, but it cannot be a generic sub-domain definition.

Basic Routing

For a entry defining the routing of a system or sub-domain, the syntax is simply:

victim canonical-name

Where victim is the system or sub-domain to be routed via canonical-name. This causes any mail for the specified victim system to queued via the system canonical-name, but does not presume the two systems are the same.

SMTP Delivery

For an entry defining a system or sub-domain for which mail is routed via TCP/IP to an SMTP server, the syntax is:

victim @ SMTP-server-hostname

Where victim is the system or sub-domain that is to be delivered via the TCP/IP networked system SMTP-server-hostname.

Note: If the mail transport agent does not support TCP/IP, it will be queued in the local host’s UUXQT queue for later execution by a TCP/IP enabled mail transport agent. No check is made that such an agent is actually installed.

Host Name Aliasing

For an entry defining a system or sub-domain as an alias of another system, the syntax is similar but adds a literal equals sign (=) between the two names:

victim = canonical-name

Where victim is the system or sub-domain that is to be considered equivalent to the system canonical-name. Mail will be queued for the victim systems as if they had the canonical-name.

Gateway Delivery

Lastly, when mail for a system or sub-domain is to be piped into a program, the equals sign is replaced by a pipe (|) symbol:

victim | program-name

The use of these entries is further described under Changing How Mail is Addressed and Delivered Locally on page 31 in separate sections.

Note: When the HOSTPATH file is used to alias systems or change default routes, the original system information is not changed in the mail header or in commands passed to other systems. This means that the systems defined by canonical-name must have at least the same amount of information about routing as the local system has.^{^[76]}

usenet News ACTIVE Groups File

The ACTIVE File defines the list of news groups and range of articles available in those news groups on the local system. The file is used by NEWSRUN, EXPIRE, news readers, and other news processing programs.

Format

The format of the ACTIVE file defines one news group per line, with the format for each line as follows:

news.group first last post

Where:

news.group The name of the news group.

first The number of the first article currently on system for news.group. If no articles are on the system, the number should be 0. Each component of the name (between the periods) must be 14 characters or less.^{^[77]}

last The number of the last article on the system for news.group. If no articles are on the system, this number should be 1.

post A single character describing whether or not local users can post to the news group:

y allows unrestricted posting,

n disallows all posting, and

m defines the group as moderated, posts are forwarded to the moderator via mail rather than being added to the news group.

Note: This file does not support comment lines.

In general, you don’t want to create a ACTIVE file from scratch, but rather get one from your news feed and prune out the groups you don’t need.

Special News Groups

Three special news groups can be defined, control, junk and duplicates. These do not receive normal articles per se, but rather have the following special functions:

· control is where all Usenet control messages are saved. Such messages cancel articles, create and remove new news groups, and other control functions. If control is not defined as a valid local group, all such messages are ignored by UUPC/extended.

· junk is the local article junk pile. All articles which received by the local system and pass all SYS file filters but that have no valid local group listed are saved in junk, if it exists. This is useful for debugging. A system which has a news feed consistent with its SYS file and ACTIVE file will never get articles into junk. Articles are not delivered to junk they if do not pass the SYS file filters for the local system or can be forwarded to a remote system.

· duplicates is similar to junk in that the group is normally empty on a well run system. It contains articles which have duplicate message ids for articles previously received. Such articles are never forwarded to third party systems.

Other Considerations

If the article numbers in the ACTIVE file become corrupted or out of date (if for example an old file is restored), they can be brought up to date by running the program GENHIST.

The ACTIVE file is automatically maintained in a sorted order by the UUPC/extended software; if new groups are added in an unsorted order by hand, they will be moved to their proper place automatically. Likewise, empty lines are automatically purged as part of the sort.

If you insert ill-formatted entries into the file, the bad fields are automatically updated with default values.

Usenet news SYS (neighbours) file

The SYS file describes for the newsrun and sendbats commands which news groups this site is willing to receive and which groups it is willing to transmit to each netnews neighbour. It is public information and is sent automatically to any site that sends a sendsys news control message.^{^[78]} The SYS file must be called SYS and reside in the configuration directory.

Format

A SYS line has four fields, separated by colons:

· system-name / exclusion1 exclusion2...

· subscriptions / distributions ...

· flags

· transmission command

A hash mark (#) as the first character in a line denotes a comment. Empty lines are ignored. A logical line may be continued to the next physical line by putting a backslash (\) at the end of the current physical line. Spaces are permitted in the SYS file only in comments, in transmission command when it really is a command and not a filename, and, for B news compatibility, at the start of a continuation line (after a backslash and a newline).

Of the SYS file fields, only the system-name need be present. If a field and all the fields after it are omitted, the colon immediately before that field and all the colons after it may be omitted too. The optional subfields (exclusion and distributions) and their leading slashes may be omitted.

The system name is the name of the system news is being sent to, and is checked against site names in the news article Path: headers to avoid sending an article back to a site that has seen it. The exclusion names are also checked against the Path: header and articles are not sent to system name if they have visited any of the exclusions. (The special system name ME stands for the name of the machine news is running on, as determined from the nodename variable in the local UUPC.RC file).

The ME line, or a line whose system name is explicitly that of the machine news is running on, has a rather different meaning from that of the other SYS file lines: its subscriptions subfield identifies the newsgroups that this site subscribes to (i.e. is willing to receive), and its other fields and subfields are ignored. There should be one such line in the file.)

subscriptions is a comma-separated list of newsgroup patterns specifying the newsgroups to be transmitted to the system; each newsgroup from the Newsgroups: header of each article is matched against the pattern list, and if any newsgroup matches the pattern list, the article is transmitted.

Matching Rules

The rules for matching a newsgroup against a single pattern are:

· Words in a newsgroup or a pattern are delimited by periods;

· Words of a pattern and a newsgroup match only if they are identical, except that the word all in a pattern matches any newsgroup word;

· A newsgroup is matched against a pattern word by word, and all words must match for the newsgroup to match that pattern;

· If the pattern has fewer words than the newsgroup, the pattern is implicitly extended to the same number of words by appending .all as many times as necessary;

· If the newsgroup has fewer words than the pattern, the newsgroup does not match the pattern;

· If pattern matches a newsgroup, !pattern mismatches that newsgroup.

A newsgroup matches a pattern list if, and only if, it matches at least one of the patterns and:

· the newsgroup does not mismatch any of the patterns, or

· the longest matched pattern is longer than the longest mismatched pattern (length is measured in number of words, with each explicit occurrence of all counted as slightly less than one word, and does not include the implicit extension of patterns with .all).

Note: Order in the lists is not significant, and that ties are broken in favor of not matching.

An example:

comp,comp.SYS.sun,!comp.SYS

matches all the comp groups, except the comp.SYS groups but including comp.SYS.sun.

The distributions in the Distribution: header are similarly matched against the distributions subfield, if any. If no distributions are supplied, Distribution: will be matched against the subscriptions instead. (The Distribution: header is ignored when receiving news; it is only significant when sending.

Note: Some older news software reportedly attached magical significance to the distributions world and local; UUPC/extended treats them as ordinary distribution names with no special properties (except that world is the default distribution of an article if none appears explicitly).

For example, a distributions list like all,!local will not prevent local articles from being sent unless they contain explicit "Distribution: local" lines.

Note: The distribution world must be permitted perhaps by the distribution all in order to feed Distribution:-less articles (the common case) to a site.

The flags are a set of letters describing how the article should be transmitted.

Note: No flags should be specified for the local system entry.

Valid flags are listed inTable 25 - Processing Flags Specified in Usenet SYS file.

Table 25 - Processing Flags Specified in Usenet SYS file

Flag value	Definition
f	Batch news for the remote system. Each article to be sent is saved in a subdirectory under the UUPC/extended newsDir, and transmission command is interpreted as the name of a manifest file to save the name of the actual articles in along with the article sizes. A default name of going.out/system/togo is used for the transmission command if omitted.
F	Like f, but omit the size.
I	Vaguely like f, but the article is not saved and only the article Message-Id: is written to the manifest list.
n	Like f, but the Message-Id: is written in place of the article size.
L###	Only send articles generated within fewer than ### hops of here, as determined by the number of systems in the Path: header line. The default for ### is zero, that is to send only locally generated articles.
m	Transmit only moderated groups. (Not supported by UUPC/extended sendbats.)
u	Transmit only unmoderated groups. (Not supported by UUPC/extended sendbats.)
c	Do not compress batches to this site. This must be specified in combination with one of the flags which enable batching. Note: This flag is specific to UUPC/extended.
B	Do not create a batch to this host until the batch is equal or greater to the size defined by batchSize in UUPC.RC. Note: This flag is specific to UUPC/extended.

If none of the batch options is specified, then the transmission command is executed by newsrun with the article to be transmitted as the standard input. The substring %s will be replaced at most once per command with the host name the article is being transmitted to.

Note: The default transmission command if none is specified is:

uux -a news -p -ggrade -x debuglevel -C system!rnews

where grade is the value of newsGrade in UUPC.RC, and debuglevel is the debuglevel currently in effect for the program (newsrun) queuing the article.

Examples

A simple SYS file:

# News configuration file, automatically generated by UUPC/extended 1.12m
# at Sun, 01 Jan 1995 19:12:00 -0500
# The local system, kendra
ME:all
# Our news feed, not batched to speed our posts, and we don’t send local or kew specific groups.
ci-pioneer:all/!local,!kew::

A complex SYS file.

# line indicating what we are willing to receive; note local groups near end
ME:comp,news,sci,rec,misc,soc,talk,can,ont,tor,ut,to
# sample insignificant feed not using batching (for special situations only)
huey:news.config,to.huey/all::uux - -r -gd huey!rnews
# sample of mailing newsgroups to someone (note distribution)
daisy:soc.women,soc.couples/all::mail daisy@duck
# sample small feed using batching
gladstone:comp.protocols.tcp-ip,rec.aviation/all:f:
# sample major batched feed, including assorted regional newsgroups, with
# (unnecessary) explicit file name
dewey:comp,news,sci,rec,misc,soc,talk,can,ont,tor,ut,to.dewey/all:f:dewey/togo
# sample long-haul feed; note no regional groups, exclusion of a local
# distribution, and exclusion of anything that passed through him under
# another name (needed because he puts that form, not just "donald", in
# his Path lines)
donald/donald.angry.duck:comp,news,sci,rec,misc,soc,talk,to.donald/all,!ut:f:
# sample local-postings-only feed direct to major site (gets them out fast)
scrooge:comp,news,sci,rec,misc,soc,talk,to.scrooge/all:Lf:

Note: The to.sysname groups are normal newsgroups used for testing individual news feeds and conveying ihave/sendme messages.^{^[79]}

Bugs

The flags field is a bit of mess: there are too many formatting flags and they aren't orthogonal.

The batch size should be configurable on a per system basis in a manner similar to local hops.

The name SYS is easily confused with the similarly named SYSTEMS file, especially since in UUPC/extended they reside in the same directory.

History

This manual page was written by Geoff Collyer and Henry Spencer for the C News project. Converted from troff to Word for Windows and adapted for UUPC/extended by Drew Derbyshire.

Environment	Compiler
DOS	Borland C++ 3.1 (no longer distibuted) MS Visual C++ 1.52
OS/2 16 Bit (no longer distibuted)	MS C 6.01
OS/2 32 Bit	IBM Visual Age C++ 3.0
Windows 3.1(no longer distibuted)	Borland C++ 3.1
Windows NT Windows 9x	MS VC++ 6.0

Name	Description
announce.txt	A summary of the newest release. This file is generally an abridged version of the current CHANGES.PRN file included in the documentation archive. This file is not created if the current release has limited changes. For all releases, CHANGES.PRN is the definitive summary of changes. (not available on all systems)
howtoget.txt	This file. (not available on all systems)
index	The current directory listing for the UUPC/extended archive. (not available on all systems)
upc13jad.zip	Formatted documentation files (dumb printer format). This is the most generally useful documentation archive.
upc13jah.zip	UUPC/extended Installation and User Reference manual formatted as HTML for a reading by a web browser.
upc13jap.zip	UUPC/extended Installation and User Reference manual formatted for a PostScript printer
upc13jaw.zip	UUPC/extended Installation and User Reference manual Word for Windows source files
upc13jd1.zip upc13jd2.zip upc13jd3.zip	UUPC/extended executable files for MS-DOS, built with MS VC++ 1.52.
upc13jn1.zip upc13jn2.zip upc13jn3.zip	UUPC/extended executable files for Windows NT or Windows 95 (for Intel x86), built with MS VC++ 6.0
upc13j21.zip upc13j22.zip upc13j23.zip	UUPC/extended executable files for 32 bit OS/2 (version 2.x or Warp)
upc13js1.zip upc13js2.zip upc13js3.zip upc13js4.zip	UUPC/extended source files
upc13jb1.zip upc13jb2.zip upc13jb3.zip	UUPC/extended alternative executable files for MS-DOS, built with Borland C++ 3.1 compiler. Note: These archives are now considered obsolete. They included are for closer compability with the older (1.12k and before) DOS versions of UUPC/extended; most users will only need the new MS-DOS archives (upc13jd?.zip).

Other __________________________________________

Network

Brand: __________________________________________

Protocols: __________________________________________

Comments

_______________________________________________________

_______________________________________________________

_______________________________________________________

_______________________________________________________

Binkley’s Use Only

Pandora __________ Athena __________

Comments _________ Other _________

Items Ordered

Description	Amount	Quantity	Total
(A) Basic support services	$20.00
(B) Next release on diskette (includes A)	$40.00
(C) Documentation (includes A and B)	$50.00
(D) Additional nodes	$10.00
(E) Current release on diskette (does not include A)	$20.00
(F) Special Media (Zip Volume; also must also order B, C, or E, and specify diskette size below.)	$10.00
Overseas postage (per item B, C, E above)	$5.00
Snuffles' Chocolate Ice Cream Fund	$1.00
Subtotal
5% sales tax (Massachusetts residents only)
Total enclosed

“The fountain code has been tightened slightly so you can no longer dip objects into a fountain or drink from one while you are floating in mid-air due to levitation. Teleporting to hell via a teleportation trap will no longer occur if the character does not have fire resistance.”

-- README file from the NetHack game

Appendix 6: Changes From Previous Versions

Introduction

This section summarizes most changes made to UUPC/extended since release 1.12b. Please contact Our technical support department, help@kew.com, for information on changes previous to the scope of this document or other questions.

Version 1.13f – 1.13j Revision Summary

Bug Fixes

If RMAIL processes mail in the local queue, it does not add (yet) another Received: line, which could cause a piece of mail to appear to be looping.

UUXQT would loop endlessly if a SMTP RMAIL job got stuck. The queue manager is modified to ignore files newer than the start of the queue processing.

In UUSMTPD, force initialization of the address routing table to avoid aborts when examing the name of the local domain.

Corrected POP3 processor to use unique POP3 rules for quoting leading periods in lines, not the more complex (and wrong) SMTP rules.

Correct SMTP bounce processing to not cause received bounces to be dropped because of an invalid return address (which we ourselves corrupted).

Corrected TCP/IP network buffering to be slower but reliable.

Modified SMTP server to possibly work with driver script under OS/2, accepting a single connection per execution in the same manner as UUCICO and UUCPD.

Disabled optimization for computing packet size in ‘v’ and ‘g’ protocols under VC++ because of bug in compiler bit shift code which caused an endless loop.

Under Windows NT, selected error messages were sent to standard output when they should have been directed to standard error. This is corrected.

Enhancements

Numerous obsolete third party and Kendra Electronic Wonderworks documents are purged from the documentation.

Windows 3.x support is dropped.

Removed OS/2 named pipes support to reduce UUCICO module size.

Added short circuit check for local host making TCP/IP connections to avoid network domain name lookups when disconnected from the Internet.

Add supported for throwing UUPC/extended intop debugger under Windows NT.

Revamp internal file name recording to use RCS information.

Clarify in routing of messages received from UUCP destined for UUCP.

Version 1.13e Revision Summary

Bug Fixes

This version is simply a rebuild of the 1.12d version. The OS/2 platform archives were incorrectly built, and thus the distributed version of the archives did not match the distributed 1.13d source.

Version 1.13d Revision Summary

Bug Fixes

Under OS/2 only, the routine to set the task name of running UUPC/extended programs could cause the programs to crash. Corrected in the OS/2 version of setTitle().

An overlength user id on the POP3 USER command caused the UUPOPD to crash. Corrected commandUser() to check the string length before making use of it.

Large mailboxes where the tenth or greater message had at least a megabyte of data could cause an internal buffer to overflow, crashing UUPOPD. The formatting of both the affected string and buffer space have been corrected in popBoxUIDL().

If a client of UUSMTPD failed to issue a HELO as the first command, the message which was supposed to warn of this fact would crash UUSMTPD instead. The offending message is corrected in commandSequenceIgnore().

Overlength UUXQT input buffers, in particular long addresses destined for RMAIL, could cause UUXQT to crash. Corrected in a number of places to use a consistent definition of maximum command line sizes and related buffer sizes.

Under OS/2 only, if UUPOPD was directed to leave mail in the user's mailbox, it used the wrong parameters to open the user mailbox for updating. This open() is corrected to use the correct parameters for OS/2 in popBoxUnload().

The fix previously applied for addresses of the format @@domain.name failed to handle the normal case where the address is actually enclosed in angle brackets (<>) during the SMTP address transmission. Corrected commandMAIL() to handle this case.

If an address presented to UUSMTPD could not be parsed by by the standard UUPC/extended address parser, the error returned by the parser was not actually captured and reported back to the client. Corrected in isValidAddress() to percolate error message upward.

If RMAIL running in address parse (-t) mode received a message which already had a Message-ID: line, RMAIL added a second one anyway. This duplicate then confused such esteemed mail clients as Netscape Messenger. Parse822() is modified to prevent the generation of this duplicate header.

The System ALIAS File parser was not checking the result of every call to allocate memory. The code is corrected to perform check the results and to abort after any allocation failure.

On some Windows 98 systems, a missing Microsoft DLL used by the modem sharing code causes passive opens of modems (used to answer the phone for incoming calls) to fail. This code is now modified to gracefully ignore the failure, and to continue running sans modem sharing support.

Various source archives had incorrectly acquired bare linefeeds at at the end of each line instead of the correct carriage return/linefeed. This is being corrected on an ongoing basis.

Enhancements

Two new environment keywords are supported in the UUPC.RC and [userid].RC files:

· winnt (for Windows NT environments)

· win9x (for Windows 95/98 environments)

The OS/2 port is now built with the IBM Visual C++ 3.0 optimizing compiler, graciously provided by IBM.

Version 1.13c Revision Summary

Bug Fixes

When a mis-configured SunOS mailer bounces mail, it can generate an return address of @@domain.name instead of the correct special empty address of <>. This bogus address was rejected by the UUSMTPD command, causing otherwise valid bounce messages to refused. This is corrected by explicitly accepting and transforming the badly formatted return address in the the correct postmaster address (<>).

The modem configuration documentation in Table 17 - Modem File Configuration Keywords had several obsolete and missing entries. The documentation is now corrected.

The UUSMTPD and UUCICO commands tended to attempt to spin off logs when a child process (UUXQT) was active. This child process prevented the log from being successfully being removed. Both programs are corrected to not run UUXQT while the log is being spun off.

The RMAIL SMTP delivery module failed to properly handle lines which were longer than the internal buffer size (which is always at least 512 bytes). This is corrected to allow transmission of such lines, except for the limited case of an overlength line containing only periods.

The UUCICO ‘t’ protocol module failed to compile with Microsoft Visual C++ 5.0; this is corrected by changing the inclusion files.

Enhancements

The uucp command and uux command both now support automatically invoking UUCICO. This operation can be set by supplying the Boolean option autocall in the UUPC.RC file, or specifying the new command line flag -R. When autocall is set in the UUPC.RC file, the old behavior to not call can also be forced on a per command basis with the -r option.

Version 1.13b Revision Summary

Bug Fixes

An inverted if test caused routine printmsg() to not correctly format the log file timestamp under all debug levels, resulting in garbage appearing in the program logs. Corrected to display the correct timestamp or debug level as required.

The UUSMTPD server would abort if it started a mail transaction and then didn’t actually process any data it because of no valid addresses or other errors. This was caused by an underlying failure to fully initialize its major transaction structure in commandMAIL(). The structure is now properly initialized.

Under OS/2 only, the UUSMTPD and UUPOPD servers reported errors in openSlave() attempting to raise the buffer size used by the system for socket data. This is corrected by lowering the amount of buffer size requested.

The UUSMTPD and UUPOPD servers would hang trying to read a socket if it no transaction had been received from the client for a specificied timeout period. Modified timeout processing to explicit skip reading the socket when processing the timeout transaction.

The server TCP/IP support module smtpnetw.c truncated traced conversations with remote clients after 75 characters, which is not sufficient for many routine responses. The limit is raised to 125 characters.

The FMT command was failing to echo the first empty line after each paragraph to the output file. Corrected to echo the missing line.

Enhancements

Moved log files from spool directory to a new directory defined by configuration variable LogDir. The default logging directory is \UUPC\LOG. Note that the various flavors of the UUCLEAN command are also modified to support this new directory.

Modified the core logging routines in logger.c to copy logs files faster and with less possibility for error by changing a close/reopening of the temporary log file to a simple rewind of the file. Also modified core logging support to allow spinning off partial log for long running programs.

Modified UUSMTPD and UUPOPD servers to now write out log files at least once an hour if actively processing clients.

Added new Boolean option promiscuousrelay. The default setting of nopromiscuousrelay does not allow third-party relaying of SMTP mail through the SMTP server, where third-party mail is defined as mail which does not originate from a host whose host name is in the local domain (defined by the existing configuration variable LocalDomain) and is not addressed to an system defined in the SYSTEMS file or HOSTPATH file.

The UUPOLL command, which by design doesn’t use the normal logging functions, tended to leave the log file it writes when compiled for debugging in whatever directory it was started from. The program is modified to use the new LogDir directory for its log file.

The FMT command is modified to support the following new switches:

-c string specifies that string is to be appended to at the end of each new line inserted. Note that if -s is specified, existing lines do nothave Istring appended.

-s specifies overlength lines are to split but no lines are to be joined together.

-i input-file specifies the name of the input file. The default is standard input.

-o output-file specifies the name of the output file. The default is standard output.

The -o and -i switches are actually alternative syntax for the existing positional parameters to specify the same information.

Version 1.12w - Version 1.13a Revision Summary

Bug Fixes

The line length data of handled by the UUPOPD and UUSMTPD were limited by buffer sizes. This limit is now raised to 64 kilobytes for UUSMTPD and completely removed for UUPOPD.

Mail processed by UUPOPD and then forwarded by the MAIL command had X-UIDL: headers added them. These headers are now dropped when forwarding.

The temporary file (imfile.c) routines still had a number of minor problems. These are corrected, especially problems with handling long lines.

The mail address parser, which correctly determined ignored RFC-822 From: lines which were truly empty, was confused if an RFC-822 From: was empty except for trailing whitespace. The parser is now corrected to ignore such badly formatted lines as well.

The RMAIL would fail if it could not parse the address on the UUCP From line. It is modified to continue delivery if this address cannot be parsed.

Delivery to the UUSMTPD daemon was slow , especially for large files (>> 30K in size). Corrected through allocating larger network buffers, mininimizing the amount data must be moved once received, and prioritizing the delivery of data once received.

Likewise, retrieval of the mail from the UUPOPD server was sometimes slow, and under certain conditions data could be corrupted. Corrected by rewriting the message transmission function in UUPOPD.

The audio announcement of message delivery could be excessive at times; it is now modified to not issue an audio announcement (beep or .WAV file) more than once every thirty seconds if the previously delivered mail has not been read.

The UUCP command could improperly format names with backslashes for UUX when queuing multi-hop file transfers, causing multiple files transferred to the same destinition to overlay each other. The program is corrected to use only forward slashes.

Enhancements

Steve Drew (<Steve.Drew@digital.com>) contributed code to support both Microsoft Windows Telephone API (TAPI) (eliminating most need to write a unique modem file under Windows NT/95) and also GUI Widnows support for the non-interactive programs such as UUCICO, UUPOLL, UUSMTPD, and UUPOPD. These GUI and TAPI modules, which are not built by default, can be built from the sources via the command:

nmake -f nmake.mak gui

The configuration file process now expects to find the correct version number in the UUPC.RC configuration file as a check that the user actually read the update documentation.^{^[85]}

Selected Boolean options are now automatically enabled. Formerly, all Booleans options were disabled by default, which is not desirable for such important performance and integrety options such as bounce, domainfrom, imfile and multitask.

Note: As part of this change, the Boolean option nosuppresscopyright is now changed to displaycopyright; the “quiet” mode is is now nodisplaycopyright.

Version 1.12v - Version 1.12w Revision Summary

Bug Fixes

The batch file (.BAT) of the UUCLEAN command failed to clean the log for numerous newer programs ranging from NEWSRUN to UUPOPD. The list has now been expanded to include the newer programs.

The UUSMTPD -d (duration) option now works properly.

The UUSMTPD -U (automatically execute UUXQT) option now works properly.

The mail delivery engine used by RMAIL and UUSMTPD was not properly determining if mail was from a remote user, and thus failed to beep even if the option was set for the user in the PASSWD file. This is now corrected.

UUSMTPD was incorrectly reporting that lines which began with multiple periods had NULL (0x00) characters in them, which caused the server to reject mail. The error is corrected, and if NULL’s are detected, the mail is rejected with a transient error to encourage the remote server to retry the transmission.

The UUPOPD and UUSMTPD TCP/IP supported routines tended cause the daemon to loop when a network error occurred. This is now corrected.

If an otherwise long format valid file name had uppercase characters in it, the name was truncated to 8.3 format name. This is now corrected.

The temporary file (imfile.c) routines had multiple problems when a file expected to be smaller than the limit storing in-memory was actually larger. The correct behavior is to move the data to backing disk store under such conditions, and this behavior is now the reality.

Enhancements

A POP3 server, UUPOPD, is added to the suite. This program reads the standard format UUPC/extended mailbox and transmits the contents to the authorized user as described in the new manual page for it on page 98.

Note: This server does not support the recently added Boolean option UniqueMailbox. Only those formats supported by the MAIL command are supported by UUPOPD.

Both UUPOPD and UUSMTPD enforce the requirement they be run with the Boolean option multitask set. The programs both abort with an error message if the option is not set.

Under 32 Bit Windows only, the mail delivery engine audio notification support now allows a WAV format file name in the PASSWD file preceding or in place of the numeric tones list.

Version 1.12t - Version 1.12u Revision Summary

Bug Fixes

The NUL device (AKA the bit bucket) was named differently under NT compared to all other environments, causing the DOS version of RMAIL to fail if invoked under Windows NT. Normalized to be NUL in all environments.

The in-memory file open function, imopen(), failed to properly initialize all memory it used for its primary control structure. This caused a variety of interesting errors.

The in-memory file function for running inferior commands, executeIMFCommand(), would truncate files to zero length when reopening them. This caused to such functions as the RMAIL command gateway support to fail if directing mail to more than one address.

Under certain conditions, the default for the optional configuration variable LocalDomain was not initialized, causing the executing application to crash when performing a host name lookup. The initialization is corrected in all programs which require it, and internal check is added to prevent attempts to access it when not initialized.

In UUXQT, the security checks for selected files was inverted for write access, allowing access under exactly the wrong conditions. The check is now corrected.

In UUXQT, if an RMAIL command was queued with no operands, the UUXQT attempt pre-scan of the non-existent operands caused UUXQT to crash. This is corrected, and a suitable dummy address of address-missing-on-rmail-command-line is passed to RMAIL to cause the mail to bounce.

In 16 bit environments running the news support, 32 bit pointers to internal buffers used for caching history index information were routinely corrupted when passed among routines. The declarations of the routines are corrected to use consistent declarations for the pointers.

Selected memory allocations for strings in the news support were two bytes short of the needed length. This caused classic memory corruption problems, and is corrected.

The program GENHIST would abort if it when scanning a directory it attempted to open a file and failed, such as if it accidentally tried to open a directory as a file. The program is corrected to gracefully skip the processing of the single file and continue onward.

If any program attempted to open a directory as file under Windows NT, it would waste ~ 30 seconds retrying the open. The fopen() function is modified to fail immediately.

Any program which attempts to determine the size of a directory when it expected a file would get apparently valid answer back. The stater() function is modified to detect that the object is a directory and report an error.

Both the parsing and generation of addresses on the UUCP From header line in mail headers left something to be desired in the program RMAIL. Causing errors for both the return addresses used by SMTP delivery mode of RMAIL and general processing of bounce messages. The support is completely rewritten:

· Internal passing of the sender information is formalized to a standard structure in place of the previous inconsistent use of shared variables.

· The new Boolean option domainFrom is added. When specified, the UUCP From address is written as the RFC-822 address of the sender in the simplest form possible. This form is the least likely to be wrong and is accepted by sendmail 8.x.

· If the Boolean option bang is specified, then the address is written as simply as possible with the relay specified as the “from remote” string.

· If the neither Boolean option domainFrom nor the Boolean option bang is specified, the basic user address is written as one token in UUCP format (! syntax) with no trailing “from remote” phrase.

The RMAIL SMTP delivery engine did not correctly process lines which consisted only of periods (“.”). This could cause delivered mail to be truncated.

The RMAIL SMTP delivery engine sent bounce messages with a non-empty return address, which could allow two mailers to get into a loop bouncing mail to each other. UUCP and Mailer-daemon mail sent via SMTP are now automatically translated to the canonical mailer bounce address (“<>”) to prevent such loops.

The default line size allowed in mail messages in 32 bit environments is now 1024 characters. This allows better handling of long lines into SMTP and other environments.

The import file name routine, used to convert UNIX format names to local format names, did not properly convert names which:

· Had characters not valid for the local file system

· Had no period in the name, and

· Were shorter than eight characters.

The results of attempting to convert such a name could result in garbage.

The import file name routine mapper did not accept multiple periods in long file names.

The import file name routine did not believe Windows NT FAT volumes (VFAT) could support long names, when in fact they do so.

The routine to format the standard RFC-822 format date used in mail headers presumed the type time_t is unsigned, which is incorrect for certain (unsupported) compilers. The particular instance is corrected, although in general it should be noted we only respond to issues for the compilers listed in Appendix 2: Working With UUPC/extended Source on page 163.

Several routines handling news files, especially the history file, were allocating buffers exactly two characters short. The affects of this were unknown but no doubt unpleasant.

The ability to be build the DOS and Windows 3.1 versions under Borland C++ 3.1 is restored through minor Makefile updates.

The Borland C++ Makefile is renamed to borlandc.mak, to place it on an even footing with the Microsoft/IBM nmake.mak file.

Finally, the Borland C++ Makefile was cleaned up by deleting the clutter of the unused OS/2 support.

Enhancements

The new SMTP server UUSMTPD is added to receive mail over TCP/IP networks. The use of this command is fully documented as part of the Command Reference on its own
UUSMTPD manual page on page 102. This new daemon shares the delivery engine of RMAIL, and thus has full UUCP delivery and limited SMTP delivery support.

The mail delivery engine now has the ability to delivery mail one message per file for programs such as PMAIL and MAIL4U. This support is enabled by the new Boolean option UniqueMailbox; when this option is enabled, each mail message is written into a file with the name MailDir/Userid/UUMX#####.ext where:

· “MailDir” is the directory name specified as the configuration variable MailDir (default \UUPC\MAIL) in the UUPC.RC file.

· The “/” (slash) is a literal.

· “Userid” is the user id the mail is being delivered to.

· “/UUMX” is a literal

· “####” is a unique alphanumeric sequence number.

· The “.” (period) is a literal. It is omitted if no extension is specified.

· “ext” is the optional extension to the file specified by the configuration variable MailExt (the default is no extension).

Note: The MAIL command cannot be used to read mail messages written with the UniqueMailbox option set.

The internal e-mail address tokenizer function, tokenizeAddress(), is modified to optionally only tokenize the input address without normalizing the host name or determining the best path to the host. In addition, the general reporting of the associated host alias support is improved.

The ability of a volume to support long names is now cached under Windows NT by the import file name routines.

The documentation is revised for the various SMTP support and other updates, and an fairly broad index is added as well.

Version 1.12s Revision Summary

Bug Fixes

The 32 bit Windows version failed when mapping names between DOS and UNIX formats if used on file systems which had names longer than 6 characters, including NETWARE and HPFS386. Corrected to allow file system names of up the length of a standard file name.

Various programs would abort in the address router if they received an invalid address which had a leading at-sign (@) but was not an RFC-822 style explicit route. This is corrected.

Under certain conditions, RMAIL would not bother to parse a valid UUCP From line, and internally set an address which could not be parsed. This is corrected on both counts.

When compiling on systems for which ferror is a true function and not simply a macro, the suite would not compile because of missing parentheses. This is corrected.

Use of the flawed memory allocation routine makebuf is removed from the various programs, especially news programs; memory has reverted to more standard malloc and stack strategies, as appropriate.

Internally, the call to bugout is updated to reflect the standard ordering of source file name and line number used elsewhere in the program.

The execute function is modified to reset the program title after running a command to cause the Window title and/or task list to more accurately reflect the current program.

The debugging (-x 8) dump of the host table now includes the internal numeric flag which indicates the class of host in the table.

The copyright dates are updated to reflect the current year.

Various corrections are applied to the In-memory temporary file (imfile) support. These changes affect both in-memory and disk resident temporary files:

· If a temporary work file needs to be opened and the imopen call specified text mode, this now honored.

· A missing free of an internal I/O buffer used to dump the imfile to disk is now added.

· The imfile work structure is freed when the imfile is closed.

The UUCP command failed to catch some errors when copying files. This is now corrected.

The UUX command is now modified to properly process files in binary mode, rather than text mode. This did not previously work properly on all systems.

On some systems, use of the raw name “*status” for the status file caused some file system checks to fail. Corrected to use new name “_status”, which is only contains valid characters.

The setting of the current system time via the NIST time support failed on Windows 95. This is now corrected by Dave Watt.

Enhancements

The TCP/IP-based mail delivery protocol SMTP delivery support is added to rmail.

1) The hostpath file can now include entries of the form:

host @ smtp.gateway
*.host @ smtp.gateway

Note: The whitespace is required around the at-sign (@).

This will route all mail for the host or domain to the specified gateway via SMTP. The specified host can be the mail server, which to say all outbound mail can be redirected to the gateway.

2) The system specified in the UUPC.RC as the mail server via the configuration variable mailserv may now be a gatewayed or SMTP routed host.

3) By default, mail is only queued by RMAIL if running in -w or -t mode (new mail being queued from a Mail front-end); such queuing is performed under the local host name (the same queue used for local news processing), one (or more as required) per SMTP gateway host used.

4) When running in -t mode, RMAIL can be requested to be deliver immediately by setting the new Boolean option fastsmtp. Mail in daemon mode (-w) cannot be forced for immediate delivery, to prevent endless recursion.

5) The time-out for all reads from the remote SMTP server is controlled the new UUPC.RC configuration variable TimeoutSMTP; the default is 60 seconds

6) Mail locally queued for SMTP delivery will be processed by UUXQT and RMAIL normally, and RMAIL will automatically be passed the new -q option on the command line to flag it should be processed in SMTP mode. When running in this mode, failure to connect to the remote host will result in a the new RMAIL exit status of 75, which will cause UUXQT to gracefully leave the spooled mail in untouched for later processing.

7) When running in -q mode, RMAIL will deliver ALL queued mail on the command line to the same SMTP host as determined by the first addressee's routing. (This is consistent with the queuing performed described above.)

8) If the hostpath file is changed after the mail has been queued but before the mail is actually delivered via SMTP, and the first addressee is no longer delivered via SMTP as defined by the hostpath file, the mail will automatically be delivered via normal RMAIL routing.

9) This full support is included for 32 bit OS/2 and 32 bit Windows only. No actual delivery under DOS or 16 bit Windows is provided. The standard distributed Windows 3.1 package normally does not include RMAIL or UUXQT, and we include NO TCP/IP support at all with the DOS versions.

10) The 16 bit environments which do not support SMTP delivery still understand the new hostpath syntax and SMTP local queuing; this means that 16 bit environments (DOS, OS/2 and Windows) can share a hostpath and a spool directory with the SMTP enabled 32 bit environments, which will deliver the mail on the behalf of the 16 bit environments.

11) The SMTP support is designed for connecting to one or more friendly local gateways which can handle general delivery; it is not designed for general Internet use, having no MX (host lookup) support, only a single time-out period for all network reads, and no anti-SPAM protection.

12) No SMTP server currently exists for receiving mail; this facility only supports sending mail.

Note: Special thanks to Jacques Rebiscoul of S.S.T.I. for the prototype code used for the SMTP support.

When compiled with debugging enabled, the DOS FOSSIL driver can now report the internal FOSSIL status block.

The TCP/IP port number for uucico to connect and/or to listen for connections upon can now specified in the modem file via the configuration variable PortNumber.

The maximum number bytes saved in any one log file before rotation by uuclean under OS/2 is upped from 20,000 to 50,000.

In 16 bit environments, most news history cache data is now kept in far memory.

Version 1.12r Revision Summary

Bug Fixes

When the local user table (loaded from the PASSWD file) was nearly full, reallocation of the table was done improperly, causing the loading program to crash.

The fast in-memory temporary file routines always operate in binary mode, never text mode. This causes problems when disk memory is used as backing storage and the file is passed directly into another program. Corrected imopen() to allow specifying text or binary processing modes.

Previously, various grossly invalid address could cause either a program panic or, in some cases, a program crash. The validation of address formats by the mail routines has been strengthened and unparsable addresses are rejected by rmail and other programs are now gracefully with an error message without terminating all other processing.

If RMAIL read a UUCP From line which was incomplete, the program would crash because of an invalid pointer. Corrected to supply defaults for missing information on the From line.

Internal references (including source file names) nickname processing to have been updated to be consistent with the external documentation.

Various buffering and index sizes within the news history routines were inconsistent between 16 bit and 32 bit compilers and internally among 16 bit routines. Corrected to allow consistent buffers and index of sufficient size for history processing.

Various news history functions failed to report the nature of errors they incurred. Corrected to reported standard C run-time library errors as needed.

In newsrun, processing of news control messages was broken because of a parsing error. This has been corrected.

In inews, news header processing was case sensitive. Corrected to ignore case.

The news ACTIVE file module tended to randomly drop news groups from its internal list, and also to suffer from various performance and memory related issues. The entire ACTIVE file processing module has been rewritten to use a single red-black binary tree, which allows fast lookups while retaining low-overhead during loading.

Because new ACTIVE files were written over the previous edition of the file, an error when writing the file would cause the loss of data. Corrected to write the file out to a temporary name and then rename the file to the permanent file after verifying the number of entries in it.

Longer news groups names in the ACTIVE file could cause file name buffers to overflow. Overlength news groups names are now rejected at active file load time, preventing their use in file names.

The OS/2 pnews command added a Path: header line to the news article to be posted. This should be left to the inews program; the insertion of the line is now deleted from the pnews command.

If UUPOLL was built with debugging enabled, multiple copies of the program could started at the same time could cause one program to abort when a logging file could not be opened. Corrected to use the normal retry functions available from the FOPEN function.

FOSSIL serial port drivers did not work if UUCICO was built with the Microsoft Visual C++ compiler because of problems retrieving serial port data. Corrected retrieval routine to work under MS C compiler.

Under OS/2, UUX did not properly process data in binary mode. Corrected by opening new binary input stream rather than copying standard in.

Under DOS with the MS VC compiler, stack overflows continued to be common under most programs built as .COM files. All modules are now built as .EXE files rather than .COM files.

Enhancements

The various configuration files, including UUPC.RC, modem files, and PERMISSN file used a linear scan of the lookup table for determining keywords. This routine has been changed to perform a faster binary search.

The local user table was checked for duplicates on every single user; this required repeated linear scans of the table and impacted load performance. Corrected to only scan the table for duplicates once after table is fully loaded.

In RMAIL, The system alias processor now reports the number of aliases loaded.

Version 1.12p Revision Summary

Bug Fixes

The manual was reorganized, with the configuration files broken out into their own section and most of the missing files added. Also added an appendix with a brief overview on uucp file transfer protocols.

If no known delivery path was known for a host (and use of the default mail server was explicitly barred via the HOSTPATH file), when RMAIL reported the error it reported the host in error as the local host. The message is corrected to report the actual problem host.

If a negative sequence number for UUCP spool files was generated, the resulting generated UNIX format file name could incorrectly have spaces in it. Corrected this by only using an unsigned long integer for the UUCP sequence number.

If an in-memory temporary file actually residing on disk is used in a for redirected command input (such as bounced mail), the use of the file fails. Corrected by closing the file before reopening it for input.

The address parser debugging messages would report an address as "local" if the address did not include a host name, which confused users on site hiding hosts. Changed the message to more precisely report that no host is included in the name.

RMAIL would not properly handle bouncing of mail if the originator address started with a dash (-) because it would be taken as an option. Modified RMAIL to use "--" option to prevent address from being taken as an option.

Because RMAIL has trouble with addresses being with dashes (-), UUXQT would delete any address destined for RMAIL if it began with a dash. Modified UUXQT to gracefully handle such addresses gracefully by terminating option processing with double dashes (‑‑).

UUXQT would not properly invoke RMAIL for all addresses if it was passed more than one DOS command line full of data. Corrected processing to execute RMAIL for all addresses provided.

In newsrun, if the search for a news group in the active file fails, under certain conditions the search will cause the program to terminate with a memory violation.

The history file processor did not use the same buffer size under DOS as opposed to various 32 bit environments. This could cause history record truncation of records during processing. Corrected to use standard size buffers across all platforms.

On multiple disk systems, UUCLEAN under DOS may not find the news directory if it is on a different drive than the UUPC.RC configuration file. Modified UUCLEAN under DOS to look for history file as a signal to run expire as opposed to active file.

When using the UUCICO NIST support, if an attempt was made to set the clock before 2 AM GMT during daylight savings times at least 48 days before the change back to standard time, daylight savings would be ignored and the clock would be set one hour slow.

When debugging, it was difficult to determine the UNIX file name of a file in the spool directory. RMAIL has modified to include various file identifying information in the execute file.

Version 1.12o Revision Summary

Enhancements

The new Boolean option suppressLoginInfo is added to allow disabling the display of the system version and login time during remote system login.

The previously unimplemented Boolean option undelete now works under OS/2. When noundelete is set or defaulted, files are deleted by ALL UUPC/extended programs using a faster file delete call which bypasses the OS/2 Undelete Cache.

Bug fixes

The ACTIVE file processing used by newsrun, expire, and other news programs could not handle large ACTIVE files well, relying on a simple linked list structure. The progress has been rewritten to use a tree mimicking the natural structure of the Usenet news hierarchy.

As usual, Kai Uwe Rommel contributed many of the news related fixes to this release.

When no news server was defined in the UUPC.RC file and no SYS file existed, an invalid SYS file was generated. The automatic generation of the SYS file was corrected to use the mail server as the default news server as well.

The unused Boolean option compressbatch is dropped.

When no parameter are passed to a program from uuxqt or other programs, a bug in the IBM OS/2 C/Set++ compiler will generate invalid parameters to the program. A workaround has been applied to various programs to always pass at least a debug level to various programs such as RNEWS, INEWS, and SENDBATS.

The code added to 1.12n to determine the starting sequence number would sometimes generate a negative sequence number for jobs. Corrected to always limit the sequence number between one and one million.

Various programs tended to have stack overflows under the MS C DOS 8.0 compiler, especially when various common routines called memory intensive C library functions such as sprintf. Various common routines were revised to use more efficient formatting, and in addition various DOS modules were changed from .COM files to .EXE files to allow additional memory usage.

Previously, if an entire subdomain (denoted with an asterisk prefix) was listed in the HOSTPATH file to be routed to a gateway program, the subdomain entry was passed to gateway program by RMAIL. RMAIL is corrected to pass the actual host name being gatewayed to the program.

If RMAIL processed a forward file with no aliases, it would exit with a non-zero return code but no error message. It now bounces the mail properly with a message reporting no addresses could be delivered to, and then exits with status zero.

When writing entries into the V-Mail server queue, RMAIL searched the directory for a free file name, which because of a race condition could result in a file name collision. RMAIL is modified to use normal sequencing instead for more reliable and faster operation.

If an entry in the system aliases file was immediately preceded by a comment line, the comment was processed as part of the alias. System alias processing is corrected to completely ignore the comment.

Under Windows NT, changes to the internal configuration table would cause REGSETUP to fail because of references to NULL pointers.

If uupoll was running with auto-uuxqt (-U) mode where uucico normally runs uuxqt in background, uuxqt was never run for the local host. This in turn caused news command which would locally queued to never run.

uupoll is modified to automatically run uuxqt for the local host when in auto-uuxqt mode.

When a call grade was specified in the time field of the SYSTEMS file and uucico was invoked to call any system with work ("-s any"), uucico might try to call a system it has no work to send to.

The NIST clock setting code failed to work properly with the MS C DOS 8.0 compiler, and generally smelled bad. Restructured the code to break apart system dependent and independent parts, corrected system dependent code, also revised messages to make the action taken clear.

In some cases, various programs either overreported or undereported problems with deleting files. Modified affected programs to exactly report failed deletions of files.

If a group was removed from the ACTIVE file by a rmgroup command, all groups after that group were deleted as well. Corrected ACTIVE file processing routines to not truncate ACTIVE file list.

A space in a message id would cause severe problems with the history file database. Modified history file processing to properly handle such ill-formatted fields.

When RNEWS is processing news from a pipe, it failed to properly process the data. RNEWS is modified to (more) gracefully handle such input.

Maximum hop processing news caused infinite loops in NEWSRUN. Corrected this error and moved the check maximum hops to inside the SYS file processor where it belonged.

Other Changes

Correcting of various compiler warnings continued.

Version 1.12j Through Version 1.12n Revision Summary

Enhancements

All program beeps can now be suppressed via the new Boolean option suppressbeep. (This strange little hack prevents crashes in DOS boxes on an OS/2 system near and dear to Snuffles's heart, not to mention her plush tail.)

Specifying a new default grade for mail is now supported via the configuration variable mailGrade, and defaults to class 'C'.

uucico file transfers are now processed on a per-grade basis. All files of a specified class and above are sent first, then all any lower grade files, one class at time. The initial cut-off point (above which all files are sent into random order) is class 'C', and is configurable via the configuration file variable firstGrade.

Mike McLagan contributed new code to handle news distribution. News distribution is now automatically handled by a C news style SYS file. If no SYS file exists and one is needed, a default configuration is automatically generated. In support of news the other following changes were also made:

1) Remote batched news is now handled by the new program SENDBATS. This program must be run by hand or via the uupoll -B option.

2) If the local site was previously configured to accept news and send copies to other sites using the UUPCSHADOWS environment variable, entries for these systems are also automatically added to the generated SYS file. This is true even if snews processing is enabled.

3) RNEWS has been broken into two programs, RNEWS and NEWSRUN. NEWSRUN is either executed directly by RNEWS and INEWS if the Boolean option fastnews is set, otherwise queued to run under uuxqt by an RNEWS generated uux command. (Note fastnews was broken in 1.12n, and was fixed in 1.12o)

4) A maximum news batch size can be configured via the variable BatchSize, the default for which is 64 kilobytes.

5) A new default grade send news at is configured via the variable newsGrade, and defaults to class 'n'.

6) The program used to compress new can be specified via the variable compress, and defaults to the program 'compress %s'

7) History file processing is now always enabled; the Boolean option history is dropped. Users first using 1.12n with news should run the GENHIST program to insure the history file is up to date.

8) By default, uuxqt no longer aborts if RNEWS fails. The previous behavior can be restored via the new Boolean option newsPanic.

9) The undocumented Boolean option uupcnewsserv is dropped.

10) Archiving old news is no longer supported, and the Archive variable is dropped.

11) Active file processing no longer bothers to validate whether or not directories exist.

12) In addition to C news SYS file processing, support is added for Jeff Coffler's Network News System (NNS) for Windows NT. Processing for NNS is enabled by the new Boolean option nns.

13) Existing snews support is also modified to behave compatibility with SYS file mode processing. If snews processing is enabled and a news SYS file exists, normal SYS directed processing takes place in addition snews processing.

14) Kai Uwe Rommel wrote a caching function to speed news history processing.

15) The OS/2 PNEWS script has been modified to support prompting for distribution and providing default responses to prompts.

Note: Both snews and nns modes can be enabled at the same time. This makes for really weird results and a full hard disk if you don’t actually have NNS and snews running.

Note: If NNS processing is enabled and a news SYS file exists, normal SYS directed processing takes place in addition to NNS processing.

Note: Version 2.05 of NNS is required to exploit UUPC/extended.

The programs MAIL, NEWSRUN, and RMAIL have all been modified to allow using memory buffering for work files rather than disk based files when possible if the new Boolean option imfile is set. All program use a common API which automatically falls back to disk based work files when imfile is not set and/or when data size exceeds a pre-defined limit. A 64K limit is used in 16 bit environments, and one megabyte limit is used for 32 environments.

If one more or user ids do not have a password, the password prompt for these user ids can be suppressed via the new Boolean option suppressemptypassword.

Configuration file processing is now optimized to limit parsing of variables to those actually needed. This trades speed for some parameters not being checked until the programs that need them being run.

The current time zone can again be set in the configuration file via the variable TZ.

Note: While the time zone is set using the syntax EST5EDT, it always prints as a simple hour and minute offset.

Dave Watt contributed REGSETUP, to allow inserting UUPC/extended environment and configuration information into the NT registry.

Kai Uwe Rommel ported FROMWHO, a program to quickly display mailbox contents.

The job number sequence file (\uupc\seq) is changed from an ASCII file to a binary file and renamed (to \uupc\spool\seq.dat). Use of the file is optimized to use a single open to read and update the file.

The secondary host routing table (\uupc\hostpath), is now only loaded when needed by the mail router functions. Previously, it was loaded whenever the main host table (\uupc\systems) was loaded.

Mail alias processing is now modified so that system aliases will be gracefully processed recursively, allowing a mail alias in the system alias file (\uupc\aliases) to directly refer to other aliases in the system file or itself, which case it is resolved as a local address.

uupoll is modified to support the uucico auto-uuxqt flag (-U).

When an external shell is invoked by uucico, the current debuglevel can be passed to the external shell via the %x substitution string.

When generating a dummy job via the poll (-P) option, UUSTAT now supports specifying the job grade via the grade option (-g).

Bug fixes

Miles Zarathustra extensively tested and tuned the Windows serial communications interface, making it more robust. In addition, Drew Derbyshire added application level buffering and line pacing to allow additional data to be queued for a remote system.

Under DOS using the native (internal) serial port driver, uucico would corrupt memory when exiting. Corrected in COMM.ASM to load correct register.

Note: This change was the primary difference between versions 1.12i and the more widely distributed 1.12j.

uucico acted unpredictably if given a login script which ended in an expect string. Script processing was modified to properly support this.

UUSTAT failed to report if it was unable to delete a file as part of kill processing. The program has been modified to check for such errors and report them.

If transmitting more than 26 files in one job, the UUCP command used non- alphanumeric characters in the work file names. Modified UUCP command to use 0-9, then A-Z, and then a-z for intermediate file names.

The default packet size for 'G' and 'v' protocols was 1024 bytes, which is large enough to easily overload many systems. The default was reduced to 512 bytes per packet, although the larger value can still be explicitly specified in the modem file.

The invalid characters percent sign (%) and exclamation point (!) are now rejected in the domain name.

Host name lookup processing is modified to report in the case of failure the calling routine and not the internally called common lookup routine.

OS/2 editors and pagers are now invoked via the system() call, which allows use of PM based editors without going through hoops. As a result, support of the Boolean option neweditorwindow and Boolean option newpagerwindow are dropped.

Directory processing, especially the expansion and normalization of directory paths, has been optimized. This corrects severe performance problems with the Windows NT versions of various programs, which were punished by slow system calls to examine the file system.

Attempts to determine file system types and whether they supported long file names was incomplete under OS/2. Now under OS/2, long file name (HPFS) support on a drive is now determined by actually trying to open a file with a long name rather than asking for the name of the file system.

Under OS/2 and the 32 bit C/Set++ compiler, the time was not properly set by the NIST during daylight savings time. Modified to add in the required offset.

An extra Windows NT console was being created when running synchronous programs. The NT specific support code is corrected to avoid this.

Selected debugging messages have been wrapped into conditionally compiled code to make the shipped modules smaller.

Under Windows NT, directory search debugging messages no longer insert blank lines into the log.

The mail address parser is modified to detect and handle an invalid (empty) host name being passed in, returning question marks (?) rather than a NULL pointer which will crash the program.

If no address information was provided for a entry in nickname file, the nickname is now ignored. Previously, this could crash MAIL.

If quote characters, including double quotes (") and/or angle brackets (<>) were unbalanced on an entry in the nickname file, the resulting processing was unpredictable and usually undesired. This condition is now explicitly trapped and the offending entry ignored.

The queuing of mail for remote hosts has been rewritten so that the call file is written only once, not multiple time as was possible previously if multiple addresses were queued for the same address. This prevents possible errors with uucico prematurely sending the file and also improves performance.

Various programs which did not write the user (U) line of the execute (X.*) file first had problems communicating remote systems running the brain damaged MKS toolkit. The programs have been modified to generate the user line first.

If RMAIL had a problem before fully initialized (such as an invalid or missing parameter), the message would not be logged. This has been corrected by opening the log file before parsing options.

The DOS and Windows/NT batch file version of UUCLEAN would loop if neither TMP nor TEMP were in the environment. Modified the batch files to use a reasonable default.

The uupoll status in the OS/2 task list and Windows NT title bar would be obsolete during sleep periods. uupoll now updates the message more often.

uucico execution duration would vary up to 59 seconds from the desired time relative to uupoll. Modified uupoll and uucico to more exactly handle when a passive poll terminates, allowing an active poll to start at a more consistent time.^{^[86]}

Rapid suspends and resumes of ports under OS/2 could cause uucico to hang. Corrected by Kai Uwe Rommel by the addition of suitable delays.

The UUCP 't' protocol support was just plain wrong, and would not inter-operate with any non-UUPC/extended uucico. Corrected to use the correct protocol.

Note: This makes the uucico 't' protocol incompatible with versions of UUPC/extended previous to 1.12m. A workaround for these old systems is to use 'e' protocol, which is compatible (and correct).

The UUCP 'e' protocol failed to report when a time out occurred, causing uucico to hang if a remote connection was lost.

Both the UUCP 't' and 'e' protocol modules failed to report when various time-out errors occurred, leaving it up to the user to guess. Both modules have been to report time-outs, and in addition the TCP/IP protocol module has been modified to report if an end of file condition arises.

If for a TCP/IP connection, the port number was appended to the host name in the systems file, it was not converted properly into binary. Corrected in ulibip.c.

Other changes

The Microsoft Visual C++ 2.0 compiler for Windows NT is now supported.

The Microsoft Visual C++ 1.5 (DOS 8.0) for DOS is now supported.

The License has been rewritten and included with each archive.

Numerous compiler warnings for various compilers have been suppressed.

Versions 1.12h through 1.12i Revision Summary

Enhancements

Added support for the OS/2 IBM C Set++ 2.01 compiler. This was based on work from Kai Uwe Rommel.

Added Ignore= variable to allow configuring headers ignored by Print command in mail.

Added ReplytoList= variable to allow configuration address replied to from the Reply command in mail.

Added Boolean option HonorControl to determine where or not addgroup and rmgroup news control messages are honored.

The OS/2 version of the WAITING command now prints the mailboxes with waiting mail in user id order.

If a remote error correcting modem connects to a UUPC/extended system without an EC modem, the login prompt could be presented before the remote system was ready for it. The AnswerDelay= variable has been added to allow a configurable delay in how long the answering uucico waits before sending the login prompt, with a default of 2 seconds.

Bug Fixes

Modified change directory functions to properly update saved directory if any and only change directory works.

Corrected various functions to RMAIL to insure redirection of input works properly for nested invocations of programs.

Revised memory allocation of host name table and associated information to reduce storage fragmentation in memory constrained (16 bit) versions.

Revised memory allocation in MAIL to allow processing large mailboxes (greater than ~ 250 items) under DOS by freeing constrained NEAR memory.

Control characters are now stripped out of OS/2 generated messages so they appear on one line.

If the public directory for a host is overridden by the Permission file, the directory is now correctly expanded in other directory references for that host in the Permissions.

Modified ExtractAddress() to correctly parse multiple addresses from the same input line as required.

Leading and trailing spaces are now stripped from addresses in alias and forwarding files.

When attempting to access devices (i.e. the printer port) to save files on, MAIL no longer appends the default suffix.

RMAIL was unable to generically parse RFC-822 headers. The parsing of headers is now revised to handle any valid input.

RNEWS failed to properly assign article numbers for duplicate articles when using a history file. Corrected by Kai Uwe Rommel.

The database functions used by RNEWS and EXPIRE failed to report the nature of various operating systems errors (such as missing files). Corrected by addition of new messages and additional checks for error returns from function calls.

The GETUUPC.CMD, used under OS/2 to perform configuration file lookups, had trouble locating path names under selected conditions. Corrected.

The buffer allocated by the communications suite handler for communications I/O was sometimes smaller than the default system I/O buffer size (BUFSIZ) on 32 bit systems. Updated to insure at least BUFSIZ bytes are allocated.

The updates of the system status file was overly aggressive, and collisions would impact performance if two copies of uucico were dialing out at the same system. The status file is now only updated when connecting or exiting uucico.

The system status file was renamed and backed up every time it was updated. This was redundant since the file is now locked using the uucico lock manager; the backup is now omitted.

The 'g' protocol handler in uucico was allocating an unused local buffer which could consume up to 1K in extra memory. The allocation is deleted, and an additional buffer is also moved to FAR memory to release constrained NEAR memory under DOS and 16 bit OS/2.

Some UUCP systems (including Taylor UUCP v1.04) only send 7 characters of their host name when answering a call, and UUPC/extended required 8 if it knows the system by 8 characters or longer. Corrected to only compare 7 characters if that is all is that presented.

An anonymous host attempting to send a file would cause uucico to abort the connection. Modified uucico to reject the file gracefully without dropping the connection.

The NIST clock setting routine could be easy confused by garbage input from the remote system, and set the time off by several hours. Modified nbstime() to require an exact match of all expected characters before setting the clock.

nbstime() failed to properly report the number of seconds the clock was adjusted. Corrected to report the delta, and to also report when the system believed it was perfectly in sync with the time server when it set the clock.

Numerous internal changes have been made to the building of UUPC/extended from source. By default, pre-compiled headers are used for the IBM C Set++ compiler and Borland C++, all supported compilers except Borland C++ use the same rewritten NMAKE.MAK file, a full list of dependent headers is generated and included to insure files are correctly recompiled after a header file update, etc.

The reported serial port speeds in messages under OS/2 with 32 bit compilers was humorous, if dead wrong. Corrected to report the boring but correct speeds.

The OS/2 serial port handler, which includes support to attempt to fill its internal receive buffer when one character is read at speeds over 2400 bps. Unfortunately, it was attempting to fill the buffer if one character was read OR the speed was over 2400 bps. Corrected processing to the logical AND intended.

UUPORT did not return the documented return codes. Corrected by Kai Uwe Rommel.

UUSTAT suffered from a memory leak and other inefficiencies which caused it to run out of memory under DOS. Deleted various unneeded debugging code, and corrected status function to free unneeded memory.

Versions 1.12c through 1.12g Revision Summary

Bug Fixes

Under DOS with the Borland C++ 3.1 compiler, uuxqt would randomly abort or cause RMAIL to abort if too many files were processed in one pass. This was finally traced to problems with C run time library function putenv(), and the problem call deleted.

Richard Gumpertz <rhg@cps.com> made numerous changes to allow clean compilation under MS C 7.0.

Richard Gumpertz modified the internal DOS communications driver (COMM.ASM) to better support 8250 based serial ports, to handle RTS flow control (to prevent the modem from overrunning the serial port), and to allow non-standard IRQ/port assignments at compile time. (This latter support is not enabled in the shipped executables.)

Richard Gumpertz converted the ArtiComm specific INT 14 communications driver into a generic INT 14 driver and corrected various bugs within it.

Both OS/2 and Windows NT communications drivers were modified to attempt to read and buffer as many input characters as possible to reduce the number of calls to the operating system communications functions, improving through-put.

If a 'g'/'G'/'v' protocol connection encountered a time-out condition, it tended not to be reflected for double the user specified time-out condition. Corrected to use the true time-out.

The communications suites which use internal buffers were changed to use a common buffer in FAR memory which is allocated and released as needed by the communication suite selection functions. This allows a bigger buffer to used without multiple copies being required by individual suites.

Kai Uwe Rommel and Drew Derbyshire converted arpadate() to use actual time zone offsets rather than time zone names. This is necessary to allow proper display of time zones outside North America.

The OS/2 version of MAIL could not start a PM editor or pager in version 1.12b. Added Boolean options neweditorwindow and newpagerwindow to allow starting a new editor window or new pager window under OS/2 to handle PM based editors and/or pagers.

If a environment prefixed configuration file variable (i.e. OS2.foo) was invalid, the environment name was reported, not the actual keyword. Corrected to report both parts of the name.

Under Windows, file direction didn't work properly for output files. Corrected by Richard Gumpertz.

expand_path() did not always save current directory properly. Corrected by Richard Gumpertz.

Conversion for the Kanji character set did not work properly under Borland C++ because of differences between error returns in the MS C and BC++ run time libraries. Corrected by using generic error check.

If the temporary directory was a root directory, double slashes were inserted into the name. Corrected by checking for multiple slashes and deleting them in mktempname().

Under Windows NT, abort of communications processing in uucico was not graceful. Corrected by Dave Watt.

The Windows NT file mapping routines could not determine if remote volumes accepted long names. Corrected by Dave Watt.

Programs which saved and restored the current directory when changing directories did not work if the new directory was changed to a different drive. Corrected by Richard Gumpertz.

If remote file access was granted to an entire drive through the permissions file, access was denied to the drive because the directory searched for did not match the actual saved path in the security tables. Corrected.

The Windows 3.x version of uupoll would crash the first time uucico exited. Corrected via new function declarations by Paul Steckler.

In MAIL, issuing the header or Header commands to display the summary of the items in the mailbox often caused the last header description to be displayed twice. Corrected.

In MAIL, trying to save mail to the parent directory using .. notation was rejected because the first period was taken to be the current item in the mailbox. Corrected.

In mail, entering a mail command within the program with a subject but no addresses caused the program to crash. Corrected mail sending functions to verify at least one address exists.

RMAIL incorrectly attempted to initialize the current date string before the time zone information had been initialized. Corrected by Kai Uwe Rommel.

uucico printed dialing and connection speeds for network oriented protocols which in truth have no speeds associated with them.

New messages were added for these suites.

Reordered 't' protocol packet processing to correct problems encountered when running over named pipes.

Modified file buffering into the common uucico packet processing to correct nasty OS/2 32 bit performance hits because of unbuffered files.

Adding missing winsock.h to distribution source.

Virtually every error message in the OS/2 serial port driver reported the routine name for OS/2 API errors as DosDevIOCtl. Revised messages to reflect the sub-function of this routine being invoked to make error reporting more unique.

The OS/2 and Windows NT serial port drivers have been modified to save and restore modem settings to their original state when the port is closed.

On non-FAT file systems, different subdirectories were created in the spool directory for use by uuxqt under DOS and the native OS/2 or Windows NT uuxqt. Corrected so all generated names use a system name of no longer than eight characters.

RMAIL makes use a new configuration variable MaximumUUXQT, to determine the longest line which can be written in a command line to a remote system. The old hard coded value and new default is 512 bytes.

If neither environment information nor a UUCP From line with "remote from" was passed to RMAIL, the program would generate an invalid new UUCP From line. Corrected by examining the From line more diligently in ParseFrom().

In 16 bit OS/2, uucico would report an out of memory condition in dcpxfer(). Corrected by adjusting default transfer buffer size which had implicitly risen from increased packet sizes.

uucico would incorrect attempt to suspend processing on network devices before calling them. Corrected by checking for network port before calling suspend function.

Carrier detect logic for OS/2 and Windows NT both incorrectly checked the actual modem status bits. Corrected in ulibos2.c and ulibnt.c.

uux wrote the wrong file name in the execute file when queuing data from standard input to be executed on the local system. Corrected in uux.C.

Enhancements and Other Hacks

uucico was modified to check the access of all file transfers outside the spool directory, not just remote initiated transfers. This is more secure and compatible with the UNIX uucico processing.

Note: The UUCP command -C option causes the input file to be copied to the spool directory and transferred from the spool. This option should be used to transfer a file from the local system residing in a directory uucico is not granted read access to.

RMAIL will now directly queue mail for Vandenburg Systems Research's v-mail automated list processor. Other packages can also process this queue in a simpler fashion than directly looking in the UUPC/extended spool queue.

uucico now has the ability to pass various connection to child processes invoked via the shell parameter of the PASSWD file. The following parameters are substituted as follows:

Table 28 - Supported Substitution Parameters

Parameter	Information Substituted
%%	Insert a single percent sign (%)
%l	Communications port handle (OS/2 and Windows NT only)
%p	Base name of modem file in use.
%p	Communications port name
%u	Logged in user name
%w	Logged in user name (alias compatible with uucico command line flags)
%s	Communications port speed

The default maximum buffer size for 'g'/'G'/'v' protocol packets was raised to 1024 bytes from 512 bytes.

RMAIL now accepts the -g option to set the grade of outbound mail.

Renamed Aliases keyword in UUPC.RC file to Nickname to better reflect the use of the file as compared to the system aliases file.

Added Permissions keyword to UUPC.RC file allow renaming the Permissions file.

Restored ability to display files destined for spool directories during transfer, as was the default in releases previous to 1.11y. The display of such transfers is enabled by the new Boolean option showspool.

Richard Gumpertz modified uux and uuxqt to work properly together in the same fashion as UNIX systems. NOTE THAT AS OF RELEASE 1.12e, NO SECURITY CHECKING IS DONE ON COMMAND LINE ARGUMENTS TO PROGRAMS EXECUTED BY uuxqt.

Modified user configuration processing to pick up the current user id from either the system environment variables LOGNAME (used by RCS under variable environments) or USERNAME (created automatically under Windows NT). If UUPCUSRRC is not set, this user id is then used to locate the [userid].RC file.

Kai Uwe Rommel made numerous enhancements to news processing, especially centering on new history support (prevent duplicate posts) and writing a back end for posting (INEWS). Drew Derbyshire then added backwards compatibility in EXPIRE for installations which do not have the Boolean option history set.

Kai Uwe Rommel ported the UUTRAF utility to summarize the connections as recorded in the SYSLOG file.

Note: To use UUTRAF, you must have the Boolean option syslog set.

Note: This required minor changes to the SYSLOG file output format.

Added Boolean option shortfrom and Boolean Option suppressfrom to alter generation of the UUCP From line within RMAIL.

When RMAIL queues mail for a single address, the Received: line now contains a field specifying the address.

RMAIL now makes additional efforts to determine where mail is from using the environment data set up by uuxqt if incoming mail is lacking a UUCP From line. Also, mail for which the source cannot be determined is labeled as coming from somewhere!unknown rather than the local host /dev/null.

Kai Uwe Rommel ported the OS/2 version to IBM C Set/2.

Dave Watt ported the automatic port suspension code from OS/2 to Windows NT.

Dave Watt wrote an 'e' protocol module.

The login script processor was enhanced to support the new escape sequences \E and \e to enable and disable waiting for each character sent during script processing to be echoed. This provides an alternative to CharDelay to prevent data overruns when dialing and logging into remote systems.

UUSTAT has been modified to report both the number of call files queued for and the unprocessed execute files received from remote systems when the -q option is issued.

^{^[1]}Kendra Electronic Wonderworks has no connection with O'Reilly and Associates. However, both of these books are on the bookshelf here.

^{^[2]}This is available from your local bookstore or software house, or call O'Reilly and Associates at 1-800-338-NUTS, or send them electronic mail at nuts@ora.com.

^{^[3]} Nutshell Handbooks also be ordered from Softpro Books, Burlington, MA. Call Softpro at (781) 273-2919, FAX them at (781) 273-2499, visit them on the web at http://www.softpro.com, or send them mail at <books@softproeast.com>. Kendra Electronic Wonderworks is a satisfied customer of Softpro, but we have no other connection with them, either.

^{^[4]}Registered users will be provided an update when a fix becomes available if they explicitly request it. See How to Register on page 177 for details.

^{^[5]}The news support was originally promised for the end of 1991. We admit it, the schedule got blown.

^{^[6]} The astute reader will notice athena dropped off our inventory from 1994 though 1996, or more precisely was last described as a Toshiba T3400 in the previous edition of this document. That’s because athena the elder was living under an assumed name with extended family in New Hampshire for two years, and was able to return to its true home and name after the second athena (athena the lighter) was replaced by electra. Athena the lighter is now living in Arizona with yet more family, but is, alas, not networked any more and therefore remains (literally) nameless.

^{^[8]}A single system will not have all these files. For example, a UUPC/extended system or a system running the BNU version of UUCP will have Permissions and Systems.

^{^[9]}However, RFC1178.TXT states that system names need not be unique because the Internet supports sub-domains. If you plan to register your system with the UUCP mapping project, the name does have to be unique. Sigh...

^{^[10]}Specifically, someone must have the power to add legal accounts to the remote system and to configure their mailer to recognize you. This is not the time for knowing people in low places.

^{^[12]}The Windows 3.1 version requires a working DOS version for selected functions. Thus, you need the DOS archives as well.

^{^[13]}You can actually use different directory names for the configuration and other directories throughout this installation procedure. Not all the directories even need to be on same hard drive. Moving files around makes installation more complicated, though, and you can always change things later.

^{^[14]}The public directory is where your UUCP neighbors would send you files via the UUCP command. The directory must exist because UUCICO and UUXQT's initialization of internal security tables will otherwise print warning messages.

^{^[15]}UUPC/extended can also be configured to accept incoming calls, to process Usenet news, and to tap dance, but we're trying not to confuse the issue here. All large software systems that work start from small systems that work. See Part 3: Advanced Mail Installation and Configuration on page 31 for further information on more complex configurations.

^{^[16]}Additional examples of the optional fields are in a second sample file, UUPCBIG.RC. A third sample configuration file, UUPC.KEW, is the live configuration file for kendra.kew.com.

^{^[17]}Fred registered his domain with the .US domain mapping project, which is discussed in uucpmap.txt in the upc13cad.zip archive.

^{^[18]}Recently, a user with an invalid return address sent multiple copies of the same query to help@kew.com. He failed to include his telephone number or other address in his note. Thus, we could not reply to either his original query or the follow-up letters asking why the original query was not answered.

^{^[19]}This check assumes your modem is a Hayes Smartmodem compatible. If it's not, you long ago discovered numerous programs which only work with Hayes modems and clones, and know better than to type AT to wake up your modem.

^{^[20]}If you want to drive the Sysadmin nuts, type (with no spaces):

Ctrl-P S snuffles Ctrl-Shift-@ Enter

which will tell the remote system your system is snuffles (and make it hang up since it doesn't know you). Otherwise, just make the modem hangup via a terminal emulator command or the Big White Switch, since the remote system won't let you logout without answering the prompt.

^{^[21]}We know 1.11v didn't work with this option. We fixed this, honest.

^{^[22]} For the initial releases supporting the C-news style news SYS file, a default SYS file will be generated if none exists. However, this may be incorrect if your news feed is not specified in your UUPC.RC file, you want to batch outgoing news, or if other options are not defaulted in the desired fashion.

^{^[23]}The default, carried over from UNIX, is that files are only transmitted when you are the calling system. This means that SENDFILES=YES is not needed on a MACHINE statement.

^{^[24]}This is because UUXQT runs and processes eXecute files after UUCICO has terminated. As UUCICO has terminated, there is no way to tell if the file was delivered by an outbound or inbound telephone call, so UUXQT treats the file as if it were from an outbound call.

^{^[25]}For remote mail, the MAIL program is bypassed, with UUXQT given the job of invoking RMAIL for mail which has arrived on the local system via UUCICO.

^{^[26]}By default, mail destined for the nodename or domain name specified in the UUPC.RC configuration file is assumed to be local, and all other mail is remote. This behavior is warped by entries in the optional HOSTPATH and ALIASES files, if they exist.

^{^[27]} In addition, UUSMTPD is never built with internal SMTP send support. This insures that the daemon is never trying to receive and send mail at the same time, but rather queues the mail for later processing.

^{^[28]}If for some reason the postmaster is not a valid user, the mail bounces again, but with validation bypassed to avoid an endless loop. The mail is written to the local mail directory under the Postmaster's user id.

^{^[29]}In UNIX systems which use SENDMAIL, the file is normally called .forward.

^{^[30]}The local domain name is taken from the LocalDomain= line in the UUPC.RC file if it exists. If the Domain= value ends in UUCP, UUCP is defined as the local domain. Two level domain names (x.y) are used as-is, and all longer domain names are stripped of the first name (for example, kendra would be stripped from kendra.kew.com) and the rest used as the local domain.

^{^[31]} A downstream system is one for which you are the mail server.

^{^[32]}Across the puddle, the rocket scientists controlling domain names in Great Britain in 1992 were charging for each system in a domain hierarchy, which led numerous small sites to cluster themselves under one name. Never mind that even UUPC/extended will handle sub-domains correctly and thus the authorities need not concern themselves with sites within a domain, but what do we Yanks know?

^{^[33]} Exceptions to this rule exist, but are beyond the scope of this document. Besides, UUCP works better for on-demand e-mail retrieval, and we support that too, lest you failed to notice.

^{^[34]}Because we strongly discourage using the Windows versions of UUXQT, MAIL, RMAIL and RNEWS, they must be built from the available source files using Turbo C++ 3.1 or Borland C++ 3.1.

^{^[35]}The gory details: Several UUPC/extended programs, such as MAIL and UUXQT, invoke child programs such as RMAIL and RNEWS to process data for them. When running RMAIL and/or RNEWS, the invoking program usually redirects the input and output streams (called stdin and stdout), so that instead of reading from the keyboard, the child programs read data and write disk files. Unfortunately, stdin and stdout cannot be redirected under Windows, and as a consequence, programs that read from a redirected stdin and stdout under DOS must be restructured for Windows.

^{^[36]}16-bit support for OS/2 1.x will be dropped after version 1.13 as 32-bit support is phased in. Certain features, such as TCP/IP support, have not been and will not be implemented for the 16-bit version. Please contact help@kew.com if you have a continued need for 16-bit OS/2 support.

^{^[37]}No, we are not going to try to tell you how to configure the UNIX system to contact the local system. There are too many different ways. As always, consult your UNIX system's documentation.

^{^[38]}As usual, Managing uucp and Usenett has many useful suggestions on various system behaviors.

^{^[39]}This program handles both the UUPC/extended mailing lists and automatic mailing of requested files to users. For further information on using the server, send help in the body of a message to Listserv@kew.com.

^{^[40]} Due to Vandenburg Systems Research effectively dropping support for V-mail, we may remove this support at a future date. You;ve been warned, however vaguely.

^{^[41]}The C source to the name mapping routines, which do fun leisure time activities such as base-90 arbitary length arithmetic and esoteric operating system calls to determine what formats of names are supported, are contained in the source archive, as files lib\import.c and lib\export.c. If you really need to access the spool files directly, use these routines to insure compatibility; however, try to use the supplied interfaces (UUCP, UUX, and RMAIL ) first.

^{^[42]}This restriction is somewhat bogus. However, we had time to document or to fix silly trivial errors like this, and more people need the documents than to invoke UUCICO from another program and override the the port name.

^{^[43]} This queuing is done for two reasons. The first, applicable only to DOS, is to prevent running out of memory while running RNEWS or NEWSRUN. The second, applicable to all environments, is to limit concurrent updates to the ACTIVE file and HISTORY file.

^{^[44]}Note that this is an operating system environment variable, not a UUPC.RC or [userid].RC variable.

^{^[45]}"Postmaster" is used for the user id defined as Postmaster in UUPC.RC and for the address POSTMASTER, "UNIX-to-UNIX Copy" for the userid UUCP. For all other undefined addresses, the real name is set to the same value as the userid itself.

^{^[46]}This behavior is based on the similar behavior of the BSD sendmail program. Why BSD sendmail behaves this way is beyond the scope of this document (or most human understanding).

^{^[47]}Either compress or gzip can be used to uncompress compressed news. Both can be found on many Internet archives. Check at wuarchive.wustl.edu for MS-DOS versions, hobbes.nmsu.edu for OS/2 versions. NT versions also exist, such as the ones at http://www.windowsnt.digital.com/freebies/gzip.htm or ftp.cica.indiana.edu

^{^[48]}The BREAK ON command is required to insure that MS-DOS polls the keyboard for the Ctrl-Break sequence; otherwise, you may have to reboot your system to terminate UUCICO. BREAK ON is always enabled under OS/2, Windows 3.x, and Windows NT.

^{^[49]}Note that text fields which are supplied in the UUPC.RC file cannot be cleared in the [userid].RC file. For example, a user cannot remove the organization field from her mail's headers if the UUPC.RC supplied a default one. However, the user could change the organization name by adding an "Organization=[name]" line to her [userid].RC file.

^{^[50]}Forward slashes are not translated to backslashes for the compress program invoked from RNEWS, which is technically a bug but not a problem in practice since most compress programs are derived from UNIX programs which don't care about the difference.

^{^[51]}Required fields must appear in one of the two files, but need not appear in both.

^{^[52]}For omitted entries, the entire entry would be omitted to allow the default to be in effect.

^{^[53]}For omitted entries, the entire entry would be omitted to allow the default to be in effect.

^{^[54]}Snuffles will feel hurt if you don't use this.

^{^[55]}On the other hand, if you don't know what a RAM disk or lazy disk cache is, you don't want to use them.

^{^[56]}You may want the speaker enabled for initial testing, but UUCICO is designed to run unattended, and waking house mates up to hear a modem dial at 3 AM will not make you popular.

^{^[57]}Phone calls to the system *nbstime listed in the sample systems file will fail if error correction is not disabled, because otherwise an expected string is lost from the remote system while the modem is still trying enable error correction.

^{^[58]}Sample files in older releases of UUPC/extended explicitly turned off hardware flow control. Enabling it is a change from the previous suggestions, and is required for many high speed modems.

^{^[59]}Examples are for a ZOOM VFX v32bis modem. Your mileage will vary.

^{^[60]}For omitted entries, the entire entry would be omitted (blank) to allow the default to be in effect.

^{^[61]} This parameter is used only for an internal buffer size and does not affect the transmitted stream of data.

^{^[62]}Windows 3.1 systems must have the WINSOCK.DLL installed to use TCP/IP support. Contact your TCP/IP vendor to see if they this library for their product.

^{^[63]}Systems running Ian Taylor's Taylor UUCP are a notable exception, but virtually all UUCP programs shipped with various UNIX systems will die if fed short packets. Just because UNIX developers invented the UUCP 'g' protocol doesn't mean they implemented it properly.

^{^[64]}When UUCICO listens on a named pipe, it always listens to the hard coded name \pipe\uucp.

^{^[65]}These are the permitted hours for non-peak use of the Telenet PC-Pursuit network as of summer, 1989. Your mileage and network vendor may vary.

^{^[66]}These are the permitted hours for use of AT&T's "Reach Out America" program. Some program features exist mainly because the program's author has a specific use for them.

^{^[67]}To prevent use of the ‘e’ or ‘t’ protocol over a modem connection, UUPC/extended UUCICO will not present it as an available protocol when another system logs in.

^{^[68]}The NIST was formerly called the National Bureau of Standards (NBS). The sample SYSTEMS file includes an entry for calling NIST under the entry *nbstime. (A rose by any other name . . .)

^{^[69]}To prevent use of the 'e' or 't' protocols over a modem connection, UUPC/extended UUCICO will not present it as an available protocol when another system logs in via modem.

^{^[70]}If you use or connect to a system running Taylor UUCP, send a note to Ian Taylor (ian@airs.com) thanking him for adding 'v' protocol support to his package.

^{^[71]}The maximum port speed is 38400 when using FOSSIL drivers, and 57600 under DOS. People have reported running OS/2 and Windows NT ports at speeds up to 115200, but we haven't tested UUPC/extended at those speeds.

^{^[72]}This file, which has a fixed name, should not be confused with the user nickname file described on page 150, above.

^{^[73]}This should not be confused with the SYSTEM aliases file, which has a fixed name as described on page 148.

^{^[74]}and will also be unpleasant. Note that such undefined behavior can be changed by the Wonderworks at will.

^{^[75]}You cannot directly or indirectly include a group within itself. If you violate this rule MAIL will cheerfully recursively expand the alias until it runs out of memory or disk space, leaving you cursing.

^{^[76]} The reason is simple: If you screw with something long enough you will break it, and mail headers are no exception.

^{^[77]} This is the Usenet standard. UUPC/extended actually allows a little longer, but because the component names are saved in a fixed length buffer, there is a limit. Illegal names are automatically purged from the file.

^{^[78]} Actually, sendsys is not supported by newsrun at this time. However, as commands are added to newsrun, this command will be added and honored.

^{^[79]} UUPC/extended does not support ihave/sendme messages.

^{^[80]} UUPC/extended actually maps these UNIX style names to names which fit the monocase FAT/HPFS/NTFS file systems used on personal computers, but the files are internally processed as if they have these names.

^{^[81]} Files outside the spool directory can also be transferred, but this is generally restricted in the interests of security. In any case, such transfers are still driven by call files in the spool directory.

^{^[82]} An empty call file is also valid; such dummy files are referred to as poll files, and are used to make the local system think it has work for the remote system. UUSTAT can be used to generate such files.

^{^[83]} For reasons of performance and memory usage, UUPC/extended RMAIL has internal support which provides the equivalent functionality of UUX. Most other UUPC/extended applications, including RNEWS, NEWSRUN, SENDBATS, and UUCP do invoke UUX to queue commands for UUXQT. (UUCP does write its own call files for direct file transfers.)

^{^[84]}The owner of kendra.kew.com married the owner of athena.kew.com in October, 1992. The transcontinental UUPC/extended link previously used by the happy couple has been replaced by an intra-office Ethernet. Send congratulations to binkley@kew.com, our resident ether bunny and social secretary.

^{^[85]} And yes, we do have the nerve to call this a feature.

^{^[86]} Wrong, but consistent. It seems about a minute off.