UUPC/extended version 1.13j

Installation and User Reference

September 13, 2003

Kendra Electronic Wonderworks
Post Office Box 80144
Stoneham, MA 02180-0002 USA

Telephone: 781-279-9812
E-mail: help@kew.com
URL: https://www.kew.com

The UUPC/extended software is Changes and Compilation Copyright © 1989-2001 by Kendra Electronic Wonderworks, and also subject to our license agreement on page ix.

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

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

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

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

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

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

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 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

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

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

Other Trivia............................................................................................................. 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

# Tables

Table 1 - Archive Files Needed for Various Operating Systems                                       15

Table 2 - Files to Update for Basic Installation                                                                 16

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

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

Table 5 - Contents of a Simple SYSTEMS File                                                                  20

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

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

Table 8 - Valid message Operands for MAIL Subcommands                                               62

Table 9 - Valid filename Operands for MAIL subcommands                                               63

Table 10 - Valid address operands for MAIL subcommands                                               63

Table 11 - Mail subcommand summary                                                                            64

Table 12 - Subcommands Available While Sending Mail                                                  66

Table 13 - User/System Configuration Keywords                                                           117

Table 14 - System Wide Configuration Keywords                                                            119

Table 15 - Boolean Options Valid in User/System Configuration Files                         122

Table 16 - Boolean options valid in System Wide Configuration Files                           125

Table 17 - Modem File Configuration Keywords                                                              129

Table 18 - Boolean options valid in Modem files                                                             133

Table 19 - Modem Files Included                                                                                     134

Table 20 - Fields in the PASSWD File                                                                              136

Table 21 - Description of the fields in the SYSTEMS File                                               137

Table 22 - Values Allowed for Time field in SYSTEMS File                                             139

Table 23 - Protocols Supported in Systems File                                                              140

Table 24 - Strings Supported in Chat Scripts                                                                  143

Table 25 - Processing Flags Specified in Usenet SYS file                                               157

Table 26 - Compilers Used to Build UUPC/extended                                                      163

Table 28 - Supported Substitution Parameters                                                               205

"If you feed [UUPC for the Mac] after midnight, and it gets nasty and shreds your living room furniture, that's your problem, not mine.  ;-)"

-- Dave Platt

# Licensing, Redistribution, and Warranty

## Terms and Conditions for Copying, Distribution, and Modification

"UUPC/extended", below, refers to the entire UUPC/extended package, as distributed by Kendra Electronic Wonderworks.  A "work based on UUPC/extended" means either UUPC/extended or any derivative work under copyright law: that is to say, a work containing UUPC/extended or a portion of it, either verbatim or with modifications and/or translated into another language.  (Translation is included without limitation in the term "modification".)  Each licensee is addressed as "you".

Activities other than copying, distribution and modification are not covered by this License; they are outside its scope.  UUPC/extended may be installed and run on as many systems as desired without restriction.

1.   You may copy and distribute verbatim copies of UUPC/extended's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of UUPC/extended a copy of this License along with UUPC/extended.

a)      You may not distribute versions of UUPC/extended that you know to be obsolete.  You are specifically prohibited from knowingly distributing obsolete versions of UUPC/extended in order to support third party programs.

b)      You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee.

c)      If you publish UUPC/extended as part of a larger collection, compilation, or product, including but not limited to inclusion in a book as bonus software or as part of a CD-ROM collection, you agree to provide Kendra Electronic Wonderworks with two copies of each edition of the compilation free of charge for our review and use.  Such copies are to be delivered to our address of record via US Mail.

We may waive our right to receive a particular edition, collection, or product without surrendering future rights to the same or other collections in which UUPC/extended is included.

2.   You may modify your copy or copies of UUPC/extended, or any portion thereof, thus forming a work based on UUPC/extended, and copy and distribute such modifications or works under the terms of Section 1 above, provided that you also meet all of these conditions:

a)      The modified files must carry prominent notices stating that you changed the files and the date of any change.

b)      You must cause any work that you distribute or publish, that in whole or in part contains or is derived from UUPC/extended or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.

c)      You may not make malicious changes to UUPC/extended.  You may not insert computer viruses, worms, or other code intended to damage or disrupt the end user's system and/or data.

d)      You may not cripple UUPC/extended's functionality in any way.  In particular, you may not make continued use of UUPC/extended contingent on payment of a registration fee.

This does not preclude you from charging for services such as access to your own system running UUPC/extended or other mail software, but merely prevents you from charging a premium for providing the UUPC/extended software to others.

These requirements apply to the modified work as a whole.  If identifiable sections of that work are not derived from UUPC/extended, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections.  Specifically, unique works may interface to UUPC/extended via configuration, spooling, or other files using routines based on UUPC/extended source code without falling under the scope of this License.

It is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on UUPC/extended.

3.   You may copy and distribute UUPC/extended (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:

a)      Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,

b)      Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,

c)      Accompany it with the information you received as to the offer to distribute corresponding source code.  (This alternative is allowed only for non-commercial distribution and only if you received UUPC/extended in object code or executable form with such an offer, in accord with Subsection b above.)

d)      Distribution of multiple copies of the object code within a single legal organization is specifically exempted from this section.

The complete UUPC/extended source code means all the source code for all modules UUPC/extended contains plus the scripts used to control compilation and installation of the executable.  However, UUPC/extended source code does not include any components of either the operating system under which UUPC/extended runs or the compiler and runtime libraries used to construct the executable.

4.   Hardcopy distribution of the documentation for this program, including this Installation and User Reference, is restricted.

a)   You may distribute this Installation and User Reference, in its raw or formatted form, in softcopy format with or without any source and object files, so long as you fulfill the requirements of the remainder of this license.

b)   You may print as many copies of this document as needed for your own use.

c)   You are prohibited from commercially publishing this document in hardcopy for third parties without the express written consent of Kendra Electronic Wonderworks, with the exception of this license and the appendixes.

This license and the appendixes may be distributed in hardcopy without restriction so long as the other conditions of this license are met.

5.   You may not copy, modify, sublicense, or distribute UUPC/extended except as expressly provided under this License.  Any attempt otherwise to copy, modify, sublicense or distribute UUPC/extended is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.

6.   You are not required to accept this License, since you have not signed it.  However, nothing else grants you permission to modify or distribute UUPC/extended or its derivative works.  These actions are prohibited by law if you do not accept this License.  Therefore, by modifying or distributing UUPC/extended (or any work based on UUPC/extended), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying UUPC/extended or works based on it.

7.   Each time you redistribute UUPC/extended (or any work based on UUPC/extended), the recipient automatically receives a license from the original licenser to copy, distribute or modify UUPC/extended subject to these terms and conditions.  You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.

## NO WARRANTY

General

8.   Because UUPC/extended is licensed free of charge, there is no warranty for UUPC/extended, to the extent permitted by applicable law.  Except when otherwise stated in writing, the copyright holders and/or other parties provide UUPC/extended "as is" without warranty of any kind, either expressed or implied, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose.  The entire risk as to the quality and performance of UUPC/extended is with you.  Should UUPC/extended prove defective, you assume the cost of all necessary servicing, repair or correction.

9.     In no event unless required by applicable law or agreed to in writing will any copyright holder, or any other party who may modify and/or redistribute UUPC/extended as permitted above, be liable to you for damages, including any general, special, incidental or consequential damages arising out of the use or inability to use UUPC/extended (including but not limited to loss of data or data being rendered inaccurate or losses sustained by you or third parties or a failure of UUPC/extended to operate with any other programs), even if such holder or other party has been advised of the possibility of such damages.

High Risk Activities (in Case You Didn’t Get it the First Time)

10. UUPC/extended is not fault-tolerant and is not designed, manufactured or intended for  use or resale as on-line control equipment in hazardous environments requiring fail-safe performance, including but not limited to the operation of nuclear facilities, aircraft navigation or communication systems, air traffic control, direct life support machines, or weapons systems, in which the failure of the software could lead directly to death, personal injury, or severe physical or environmental damage ("High Risk Activities"). Kendra Electronic Wonderworks and other contributors to UUPC/extended specifically disclaim any express or implied warranty of fitness for High Risk Activities.

# Revision

This is the 2nd revision of this document, and applies to UUPC/extended version 1.13j.  This document was last updated on September 13, 2003 by Andrew H. Derbyshire.  Even if you have read previous versions of this document, Required Reading on page 3 and Changes From Previous Versions on page 180 should be reviewed for updates.

# Viewing this document

## Viewing on a Terminal

This document includes overstrikes for printing on a printer.  To read this document on-line, extract the program NOVRSTRK from the UUPC/extended optional programs archive and issue the following command:

NOVRSTRK UUPCDOCS.PRN UUPCDOCS.TXT

You can then browse the terminal ready version of the document, UUPCDOCS.TXT.  However, given that this document is 243 pages long, you'll want to either print it or have a good search function handy.

## Viewing on a Under Windows

This document was written using Word for Windows 97, and is distributed in Word format in the archive file upc13jaw.zip.  If you have Windows but don’t have Word for Windows, you can download a free Word viewer/printer from Microsoft.  The last we saw, the page was:

However, like at many Web Sites, the folks in Redmond move things around a lot, so you may just want to start at http://www.microsoft.com and use their search function.

## Viewing using a Web Browser

We convert the manual into HTML browser format, with varying success.  We post it to our web site, https://www.kew.com.  We also distribute the HTML format document in archive file upc13jah.zip.

# Special Note for the 1.12u Edition

In autumn of 1997, the telephone area code for Stoneham, Massachusetts changed from 617 to 781.  This document has been updated to reflect this new area code in our telephone numbers.

”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.”

# 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:

·         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.

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 elec­tronic 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 pro­vide 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

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 adminis­trative 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.

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:/per­missn, 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.

4.      Find a UUCP neighbor.

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

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 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

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

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 Mail­box Your user id. fbwatt Name Your real name Frederick B. Watt File­Sent 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 Signa­ture 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 Tele­phone 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 run­time 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

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

? .

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.

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.

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.

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.

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 \

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.

-- 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

#### Steps to perform:

1.      Get a FOSSIL driver.

2.      Install the FOSSIL driver.

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

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.

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.

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.

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."

### 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.”

# 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.

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.

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

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.

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.

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]

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

### 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 auto­include auto­print auto­sign backup bounce display­copyright domainfrom dot imfile long­name multiqueue multi­task news­panic pager purge showspool symmetric­grades syslog verbose.

Table 15 - Boolean Options Valid in User/System Configuration Files

#### 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

## 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]

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

### 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 Carrier­Detect 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. Fixed­Speed 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. Variable­Packet 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:

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\me­dia\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

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 bi­nary data. G BigGPacket­Size BigGWindow­Size GPacketTimeout MaximumErrors For supported systems, G protocol al­lows for higher performance on high-speed modems by increasing the num­ber of bytes between packet check­sums and acknowledgments.  Its drawback is that the UNIX implemen­tation of the G protocol is only avail­able 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 acknowledg­ment 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 perform­ance 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:

or

alias:

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 ap­pended 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:

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.  How­ever, 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 informa­tion 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:

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

OR

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  transmit­ted 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 ap­pears 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
# 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.

ACTIVE, rnews, inews, newsrun, and sendbats.

#### 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.

- Dave Platt

Portions of this software are copyrighted by the following persons:

Additional thanks go to Harry Broomhall, Harald Boegeholz,  Robert B. Denny, John DuBois, Edward Keith, Phillip Meese, Dave Platt, Mike O'Carroll, Kai Uwe Rommel, Cliff Stanford, and Wolfgang Tremmel.  Honorable mention goes to Snuffles P. Bear, who says to please send chocolate.  Warm thanks to Russell Nelson, who, among many other more practical services rendered, did so.

The run-time libraries are copyrighted as follows in various versions, and used by permission:

·         Borland C++ (DOS, Windows 3.1) libraries copyrighted by Borland International.

·         Microsoft C and C++ (16 bit, Windows NT) copyrighted by Microsoft.

·         IBM C/Set++ libraries are copyrighted by IBM.

Borland C++, Microsoft C, Microsoft Word for Windows, Microsoft Windows, MS-DOS, OS/2, Windows NT, and IBM are trademarks or registered trademarks of their respective owners.  Other brand and product names are trademarks or registered trademarks of their respective holders.

UUPC/extended is packaged using Info-ZIP's compression utility.  Info-ZIP's software (Zip, UnZip and related utilities) is free and can be obtained as source code or executables from various anonymous-ftp sites, including ftp.uu.net:/pub/archiving/zip/*.

-- Eric S. Raymond, DECWars

# Appendix 2: Working With UUPC/extended Source

UUPC/extended is written in C, with one additional module in 8086 Assembler (MASM/TASM) for the MS-DOS version.

We build UUPC/extended under a number of environments as described below in Table 26 - Compilers Used to Build UUPC/extended.  Due to upgrade cost considerations, many of our compiler levels are back-level; we are unable to support newer versions without a licensed versions of the compiler on-site.

Table 26 - Compilers Used to Build UUPC/extended

 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

"Unix-to-Unix Copy Program," said PDP-1.  "You will never find a more wretched hive of bugs and flamers.  We must be cautious."

-- Eric S. Raymond, DECWars

# Appendix 3: How UUCP File Transfers Work

## Overview

This is a short tutorial on how the UUCP file transfer layer works. More detailed descriptions of the UUCP file transfer and communications protocols levels are available from the papers stored in the PROTOCOL subdirectory of our automated file server; for instructions on retrieval of these and other files, see Appendix 4: How to Get UUPC/extended on page 168.

Systems connected via UUCP operate as a store and forward network, that is a particular message is transmitted in its entirety from one system to the next before any part of the message is send on to its ultimate destination.  This is like postal mail;  it differs from telephone networks and TCP/IP networks, where end-to-end connections are established and data streams from the originator to the destination a spoken word or data packet at a time.

## What’s in a Name?

uucp is short for UNIX-to-UNIX-Copy.  The term uucp may refer to one of several related but different items:

·         The UUCP command is used to request the copy of files between systems. The actual file transfers are done via the program  (UUPC/extended includes a UUCP program which is documented on page 90.)

·         A communications protocol, such as the UUCP “g” or “t” protocols define the actual byte streams sent over the wire between two UUCICO programs on different systems and control making and breaking connections, detecting and recovering from transmission errors, and so forth.

·         Above the various communications protocols level is the UUCP file transfer protocol, which defines how files are queued and processed. This is a batch oriented file transfer protocol which mail and news services run over.

## Files in the UUCP spool directory

A spool directory exists on each system supporting uucp file transfer to store files between connections.  Files in the spool directory can have one of three prefixes:[80],[81]

·         Files with a C. (Capital C followed by a period) prefix are referred to call files.  A call file contains one or more lines of ASCII data;[82] each line requests that a single file be transferred, and the line will include the original name of the file, the name of the file in spool directory (if it was copied there at the same the call file was created), and the file name at the remote destination.

·         Files with a D. (capital D followed by a period) prefix are data files.  These can have any content, and are processed by either call files or execute files.  A data file on a local system can be renamed during transmission to be an execute file on a remote system by putting both names in the call file.

·         Files with a X. (capital X followed by a period) prefix are referred to execute files.  These files specify commands to execute on the local system, and the associated input data files for the commands.

Note:   Never edit data or execute files in the spool directory.  Because UUPC/extended emulates UNIX file formats, the files do not have normal carriage-return/linefeed pairs terminating each line, but rather follow the UNIX conventions and use only linefeeds.  Using a PC editor on these files can corrupt them, causing problems during processing on the remote system.

## Basic UUCP Processing

In its most basic form, systems connected via UUCP work like this:

1.      A program, usually the UUCP command or UUX command,[83] writes a call file.  The program may only queue data files for transfer, or a data file and a second which is treated as a data file by the sender and an execute file by the receiver.  This allows, for example, sending a mail message and a command which directs how to deliver the message on the remote system.

This process can be repeated a number of times, allowing multiple call files (or jobs, as they are sometimes referred to) to be queued for the remote system in the local spool directory.

2.      The program UUCICO runs and connects to a remote system via a modem line or other method, such as a TCP/IP network. UUCICO then reads each call file for the remote system, transmits the data files listed in the call file, and then deletes the call file and any associated temporary data files in the spool directory.

When UUCICO has processed all its call files, it requests the remote system to read its own queued call files for queued data to send to the local system.

3.      After UUCICO is done, the program uuXQT is run; it looks for execute files, and executes the command listed in the each file with the associated input file.  This may cause the process to be repeated again, if for example mail has to be forwarded via several systems, UUXQT on each system will run be directed to run RMAIL, and the RMAIL will in turn run UUX to queue the mail for it next system.

Note:   This is a very general description; it omits such factors as security, user notification, and other functions supported in full blown uucp systems.

## Sample UUCP Job

A sample call file which sends a mail message and the execute file to request processing of the message might look like this:

S D.kendra0XDFd D.kendra0XDFr snuffles - D.kendra0XDFd 0666

S D.kendra0XDFe X.kendra0XDFr snuffles - D.kendra0XDFe 0666

This directs the local data file D.kendra0XDFd to be sent to the remote system as the data file D.kendra0XDFr, and the local data file D.kendra0XDFe to be sent to the remote system as the execute file X.kendra0XDFr.  Both files were sent by snuffles.

The execute file looks like this:

U snuffles kendra

R snuffles@kew.com

F D.kendra0XDFr

I D.kendra0XDFr

C rmail postmaster

The first line beginning with U shows the actual creator of the files, and the second line beginning with R shows the original requester; in this case, both are the same user.  The third and fourth line, both of which reference the data file D.kendra0XDFr, specify the file must exist before running the specified command, and that the file is to be used as input to the command.  Finally, the last line beginning with C specifies the command to run.

The other file sent, D.kendra0XDFr, is simply the message to be delivered:

From pandora!snuffles Sat Sep 13 7:39:00 2003 remote from kendra

Sat, Sep 13 2003 7:39:00 -0500

Message-ID: <309d3867.kendra@pandora.kew.com>

Date: Sat, Sep 13 2003 7:39:00 -0500

From: "Snuffles P. Bear" <snuffles@kew.com>

Organization: Kendra Electronic Wonderworks

To:         pandora!postmaster

Sample test mail for UUCP manual example.

--

Snuffles P. Bear

Give!  Support the Wonderworks Tosci's Chocolate Ice Cream Fund!

“You are in a maze of twisty little passages, all alike”

-- Will Crowther and Don Woods, Adventure

# Appendix 4: How to Get UUPC/extended

## Introduction

### Supported Methods

UUPC/extended 1.13j is available via:

·         Anonymous FTP

·         The World Wide Web

·         Anonymous UUCP from kewgate, Kendra Electronic Wonderworks's file server

Note:   Because of time and disk space restrictions, we do not manually e-mail copies of the source or executables, provide custom .ARC or .ZIP files with only a limited set of the files, or provide other custom distribution services-- please don't ask.

### Obsolete Methods

Due to the rise of the World Wide Web and corresponding drop in need for other download methods, we have suspended the anonymous UUCP service described later in this section and completely dropped the following methods:

·         CompuServe

·         E-mail (including Listserv)

## Sources for UUPC/extended

### Anonymous FTP

UUPC/extended is available from the following our anonymous FTP site ftp://ftp.kew.com/pub.

FTP programs vary from system to system.  Contact your local system support staff for instructions on anonymous FTP.

### Anonymous UUCP

Note:   Contact us to have anonymous UUCP enabled before using this method.

The UUPC/extended files are archived in the directory "~nuucp" on kewgate and can be downloaded via anonymous UUCP.  To use anonymous UUCP, define entries for the system kewgate in your SYSTEMS file and PERMISSN file.  The  SYSTEMS file entry should define the phone number as 781-279-9816, the user id as "nuucp", and the password as "nuucp".   kewgate uses a Zoom Telephonics V.34bis modem, so connect speed may be up to 28800 baud, depending on your modem.  kewgate presently accepts anonymous UUCP phone calls 24 hours a day, seven days a week, except for interruptions for system maintenance.  We reserve the right to change these hours without notice.

Note:   The sample systems file in the documentation archive includes an entry for kewgate.

Note:   You cannot send mail or files to kewgate via the anonymous dial-in.  Send mail to help@kew.com, our normal e-mail support address.

The files are located in the home directory for nuucp, so files should be requested via the UUCP command with the syntax ~nuucp/filename.  For example, to retrieve the index for the archive to your local public directory, issue the command:

uucp  kewgate!~nuucp/index  /public

Note:   Effective with release 1.12e of UUPC/extended, the directory you use download files to via the UUCP command must have write access enabled for it in the PERMISSN file.

The uucico program must then be invoked to actually process the request.  Users should retrieve the file index first, and then issue additional requests for the actual files wanted based on the current directory listing.

To receive a copy of the next major release when it becomes available, register your current copy according to the instructions in How to Register, page 173.  You can also order the current release from us using the form in How to Register.

### General Description of the Files

You will need version 2.04g or later of PKUNZIP or version 5.0P1 of the public domain UNZIP utility to unpack the file archives.  PKUNZIP and/or UNZIP is available at most of the same places as UUPC/extended, including the Kendra Electronic Wonderworks listserv.

The available files are listed below in Table 27 - Manifest of UUPC/extended Files Available for Download.  For those table entries with multiple file names group together (such as upc13j13.zip, upc13j12.zip and upc13j13.zip), all of the files in the group should be downloaded together to provide the full functionality for the specified environment.

 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).

The files names change with each release to include the current release number in the file name.  For example, the source archive for version 1.24b would be upc24bs1.zip.

From time to time, test releases are loaded to kewgate and/or the various ftp sites.  Contact help@kew.com if you have questions as to the correct release to use.

### Summary of Archive Contents

#### Formatted Documentation Archive Contents

The documentation archive includes the formatted documents describing UUPC/extended (*.PRN), sample configuration files, and supplemental information files (*.TXT).

#### HTML Archive Contents

The HTML archive contains the UUPC/extended Installation and User Reference manual been formatted for browsing using a web browser.

#### PostScript Archive Contents

The PostScript archive contains the UUPC/extended Installation and User Reference manual been formatted for printing on a PostScript printer.

#### Program Archive 1 of 3

The first program archive (upc13jd1.zip,  upc13jb1.zip, upc13j21.zip and upc13jn1.zip) includes programs which are mandatory for most, if not all, installations.

#### Program Archive 2 of 3

The second program archive (upc13jd2.zip, upc13jb2.zip, upc13j22.zip and upc13jn2.zip) includes files which, though highly recommended, are not required.

#### Program Archive 3 of 3

The third program archive (upc13jd3.zip, upc13jb3.zip, and upc13jn3.zip) includes optional programs, mostly associated with news processing.

#### Source Archives

The source archives include all of the files needed to build UUPC/extended.  See Appendix 2: Working With UUPC/extended Source on page 163  for the supported compilers.

Note:   The upc13js?.zip files should be PKUNZIPed with the unpack directory (-d) option.  This option is the default with UNZIP.

#### Word for Windows Documentation Archive

The unformatted documentation archive includes all of the Word for Windows (Word 97) files and templates used to create the formatted documents in the regular documentation archive.

Note:   This archive has restrictions associated with distributed it in hardcopy as documented in Licensing, Redistribution, and Warranty on page ix.

## Other Trivia

Please direct all questions on retrieving UUPC/extended to our technical support department at help@kew.com.  Within the United States, we will help you get a current copy of this document if you call us at our voice number, 781-279-9812.

- Warren Zevon

# Appendix 5: How to Register

## Why You Should Register

Kendra Electronic Wonderworks offers the opportunity for you to register your copy of UUPC/extended.  Here's why:

More than five years of work have gone into it here at the Wonderworks.  This is a non-trivial amount.

Most of the e-mail received outside the KEW.COM domain is now related to UUPC/extended.  This, combined with the major intra-domain e-mail requirements[84] for KEW.COM having gone away, threatens to make UUPC/extended its own perpetual motion machine: we maintain UUPC/extended to stay in touch with the outside world, and the outside world sends us mail about maintaining UUPC/extended.

It is an accepted fact that the original UUPC was not written by Kendra Electronic Wonderworks, and that others have written numerous features.  What is not as clear is the work done here which goes into integrating and polishing these features.  Because of work done here, people can take the work done all over the world and use it by unpacking a few files.

Ryder rents trucks, Avis tries harder, MIT wins the Yale/Harvard game, and Kendra Electronic Wonderworks hunts bugs.  Lots of bugs: bugs from the dawn of UUPC, bugs from other people's code, and even bugs we introduced (oops!).  Extra systems are maintained here primarily for providing downloading services to others via anonymous UUCP and for hunting bugs.  Only RAID® kills more bugs.  We also integrate bug fixes from other people, so those few files we give to others to unpack not only have more features but also bug fixes.

Bug hunting can be a bitch, and writing documentation is worse.  Kendra Electronic Wonderworks did done both gratis for five years.  Beginning with release 1.11m, the documentation has been expanded, and will be further enhanced to make the package easier to use.  This does not benefit the internal users; we know how it works, and don't need the documents.

Because if you register, we can buy more chocolate ice cream for Snuffles.

The short version of the above is you have the package; what you can optionally pay for is additional enhancements and support by the creatures most knowledgeable about UUPC/extended.  However, we would rather you used an unregistered copy of our package than used someone else's inferior package.

## And as an Added Bonus

Send us anything and Snuffles will think you're wonderful.

Send us $20 and you can call us for telephone support at the UUPC/extended support telephone number [781-279-9812] for 18 months. We'll even return your phone calls in the United States. Send us$40 and you can use the support number for 18 months.  When available, we'll also mail the next major release on floppies.

Note:   We said next major release; such releases are only shipped about once every 18-24 months.  We normally assume you have a current release when you register.  You are welcome to download new interim releases as they are announced, of course.

Note:   If you need the current release, our registration form now includes a space for ordering it.

Send us $50 and you can use support number for 18 months, we'll mail the next major release of UUPC/extended when available, and we'll throw in a hard copy of the documentation. Send us$100 and you can use the support number for 18 months, we'll mail the next major release, throw in a hard copy of the documentation, and have you committed to the sanitarium of your choice.

Corporations cannot be committed to sanitariums, but we will take your money.  Use the above schedule for each contact person, and add $10 for each additional node supported. For example, XYZ Systems Corp. has one contact person who calls the Wonderworks for support and needs the next release and hard copy documents ($50), and one backup contact at a secondary location ($20). They want the documents so that they can distribute them to 10 different UUPC/extended nodes scattered around the company ($10 each).  The primary contact person figures out how to get a contribution to Snuffles' chocolate Ice Cream Fund ($1) past accounting. XYZ Systems would thus send us a check for$171.

We will invoice corporations on request.  Corporations wishing to register 100 or more nodes should contact us for large site pricing.

## Disclaimer of Warranty

Please note that none of the above contradicts the No Warranty clause of our license agreement.  Should UUPC/extended prove defective or unsuitable for your purpose, we will gladly refund your registration fee.  We will not, however, be liable for any incidental or consequential damages resulting from your use of the package.  Please read our license agreement (Licensing, Redistribution, and Warranty, page ix, or available upon request) for further details.

## Instructions

Please fill in all pages of the form, and enclose a check or money order in US dollars on a US bank payable to Kendra Electronic Wonderworks.  Do not enclose cash.  We do not accept credit card orders.  Mail the completed form to:

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

## The Form

### User Information

We can't provide support services without this information, and we promise not to sell or give it to anyone else.  Please give us your:

Name:   ____________________________________________

Company:   ____________________________________________

Street:   ____________________________________________

City:   ____________________________________________

State/Province: ______________________ Zip/Postal Code: ___________

Country:   _____________________           Telephone:      _____________________

__   Check Here to not be automatically added to the UUPC/extended announcements list (see UUPC-Announce on page 6 for description).

### System Information

We need this information to keep track of the environments UUPC/extended is running in so we'll know what enhancements might be useful.  We also can't send you a floppy if we don't know what size or operating system.

#### Current UUPC/extended Release

__   Version 1.13j

__   None

__   Other (specify) __________

#### Operating System

Specify the versions of all that apply

____   OS/2

____   MS-DOS

____   Microsoft Windows 3.1

____   Microsoft Windows NT/2000 Professional

____   Microsoft Windows 95/98/ME

Other  (specify)  __________

#### Diskette Size

Check preferred size.  For multiple copies (duly ordered below), give number of each size.

Note:   No check mark gets CD-ROM!

__   360K (Low Density 5 1/4 inch)

__   1.2M (High Density 5 1/4 inch)

__   720K (Double Density 3.5 inch)

__   1.44M (High Density  3.5 inch)

__   CD-ROM

#### Processor

__   8088/8086

__   80286

__   Other 16 bit processor

__   80386SX

__   80386DX

__   Other 386 family

__   80486SX

__   80486DX

__   Pentium class

__   Pentium Pro class

__   Pentium II class

__   Pentium III class

__   Pentium IV class

__   Celeron class

__   So new this form doesn’t list it.

#### Modem

Brand: __________________________________________

Speed:

__   300 BPS

__   1200 BPS

__   2400 BPS

__   9600 BPS

__   14400 BPS

__   28800 BPS

__   34400 BPS

__   56K BPS

__   ISDN (64 kb)

__   ISDN (128kb)

__   LAN

__   WAN (Direct Internet)

__   So fast this form doesn’t list it.

Modem Protocols supported:

__   v.42/v.42bis

__   v.32

__   v.32bis

__   v.FC

__   v.34

__   v.90

__   v.92

__   PEP

__   Turbo PEP

__   MNP 5

__   MNP 10

__   So weird this form doesn’t list it.

Other  __________________________________________

#### Network

Brand:   __________________________________________

Protocols:   __________________________________________

_______________________________________________________

_______________________________________________________

_______________________________________________________

_______________________________________________________

Binkley’s Use Only

Pandora  __________     Athena  __________

### 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 RMAILRMAIL 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 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.

# Index

This index is still under construction, as each entry has to be selected by hand for inclusion.  Please be patient with us.  We’re open to suggestions as to what you need in the index the most.

—[—

[modem].mdm, 128

[userid].RC, 16

—A—

ACTIVE (active newsgroups) File, 28, 53, 69, 70, 127, 153, 154, 192, 193, 194, 196

ACTIVE File, 153

ALIASES, 31

ALIASES File, 146

ALIASES File, System, 31, 32, 36, 48, 146, 148

—B—

Bear, Snuffles P., 8, 11, 13, 14, 64, 109, 118, 120, 161, 167, 173, 174, 179, 196

Boegeholz,Harald, 161

Boolean options, 25, 65, 74, 121, 122, 125, 132, 133, 185, 203

autoprint, 67

autosign, 118

bang, 187

compressbatch, 195

fastNews, 196

fastsmtp, 32, 103, 191

for modem files

variablepacket, 85

history, 197

honorcontrol, 70

imfile, 197

longname, 10

monocase, 10

neweditorwindow, 199

newpagerwindow, 199

nns, 28, 78, 197

promiscuousrelay, 183

shortfrom, 206

snews, 29, 78

suppressBeep, 196

syslog, 45, 85, 206

undelete, 26, 194

Boolean Options, 122, 125

for Modem Files, 133

Broomhall,Harry, 161

Brown, Jordan, 161

—C—

Chocolate, 8, 167, 179

Coffman, Dewey, 106, 161

COMM34 command, 19, 52

CONFIG.SYS, 12, 17, 21, 22, 23, 43, 44, 52

configuration variable MailDir, 189

Configuration variable MailDir, 189

configuration variable TimeoutSMTP, 191

Configuration variable TimeoutSMTP, 191

—D—

Denny, Robert B., 161

Derbyshire, Drew, xiii, 55, 99, 103, 159, 198, 203, 206

via FTP, 168

via UUCP, 168

Drew, Steve, 185

DuBois, John, 161

—E—

Environment variable

LOGNAME, 29, 30, 47, 77, 206

TZ, 8, 22, 118, 197

UUPCSYSRC, 8, 22, 73, 74, 84

UUPCUSRC, 8, 22, 73, 74, 81, 84, 206

—F—

File System

FAT, 10

HPFS, 10, 165, 199

NTFS, 10, 165

VFAT, 10, 188

FMT command, 54, 148, 183, 184

FORWARD (Personal mail forwarding) File, 32, 117, 147, 148

FORWARD File, 148

FOSSIL drivers, 8, 10, 40, 41, 43, 44, 45, 49, 52, 144, 191, 193

FROMWHO command, 56, 68, 198

—G—

gateway, 7, 31, 33, 34, 35, 36, 42, 186, 190, 191, 195

GENHIST, 197

GENHIST command, 57, 70, 154, 187, 197

GENSIG command, 58

GETUUPC command, 59, 201

Gumpertz, Richard, 203, 204, 206

—H—

HOSTPATH, 151, 195

HOSTPATH File, 31, 32, 34, 35, 36, 37, 38, 124, 151, 152, 183, 193, 195

—I—

INEWS command, 47, 60, 69, 70, 72, 79, 126, 195, 196, 206

Info-Zip, 161

Installation, 11

—K—

Keith, Ed, 161

kendra, 7

Kendra Electronic Wonderworks, i, ii, ix, xi, xii, 1, 3, 4, 5, 6, 7, 13, 43, 55, 73, 74, 78, 99, 101, 103, 106, 124, 167, 168, 169, 173, 175

Human Support (help@kew.com), i, 4, 5, 23, 39, 40, 169, 171, 172, 180

kew.com, i, xiii, 4, 5, 17, 23, 33, 39, 40, 48, 64, 67, 119, 134, 167, 168, 169, 171, 172, 173, 180

listserv@kew.com, 5

Web Server (http

//www.kew.com), xiii, 168

Web Server (www.kew.com), xiii

—L—

Lam, Samuel, 1, 161

Lamb, Richard H., 1, 161

Licensing, ix

Lipsie, Mike, 161

Lynne, Stuart, 1, 161

—M—

MAIL, 99

MAIL command, 31, 32, 33, 38, 61, 113, 184, 186, 189

MAILCHEK command, 67, 68

Managing uucp and Usenet, 47

McLagan, Mike, 196

Meese, Phillip, 161

Microsoft

Internet Explorer, 38

VC++, 163, 170

Mitchell ,Mitch, 161

MS-DOS, 1, 6, 7, 9, 10, 11, 14, 15, 16, 17, 19, 21, 22, 23, 25, 26, 27, 29, 31, 37, 38, 39, 40, 41, 43, 44, 45, 47, 48, 49, 52, 53, 54, 56, 57, 58, 60, 61, 63, 64, 67, 69, 71, 75, 76, 78, 81, 82, 83, 88, 89, 90, 94, 95, 100, 104, 107, 108, 110, 112, 113, 115, 116, 123, 124, 126, 132, 136, 144, 146, 161, 163, 170, 176, 186, 188, 189, 191, 193, 194, 195, 196, 198, 199, 200, 201, 202, 203, 204

Multiple Users, 6

—N—

Nelson, Russell, 161

Netscape

Communicator, 38

Navigator, 38, 98

Network News System (NNS), 27, 28, 29, 78, 127, 197

NEWSRUN command, 47, 69, 70, 78, 79, 80, 124, 126, 153, 166, 185, 196, 197

NICKNAME (Personal mail address book) File, 32, 33, 148

NOVRSTRK command, xiii, 16, 55, 71

—O—

O'Carroll, Mike, 161

OS/2, 1, 6, 7, 9, 10, 11, 14, 15, 17, 21, 22, 23, 25, 26, 27, 29, 31, 37, 38, 39, 40, 42, 43, 44, 47, 49, 50, 52, 53, 54, 56, 57, 58, 59, 60, 61, 64, 68, 69, 71, 72, 75, 76, 78, 81, 82, 83, 85, 86, 87, 88, 89, 90, 92, 93, 94, 95, 98, 100, 101, 102, 104, 107, 108, 110, 112, 113, 115, 116, 124, 125, 126, 132, 134, 144, 146, 161, 163, 170, 176, 183, 188, 191, 192, 193, 194, 195, 196, 197, 199, 200, 201, 202, 203, 204, 205, 206

16 bit, 15

32 bit, 15, 26, 98, 102, 204

—P—

Passwd file, 136

PASSWD File, 6, 8, 12, 17, 21, 30, 32, 33, 38, 40, 41, 46, 47, 49, 63, 77, 84, 98, 99, 119, 121, 136, 148, 185, 186, 192, 205

PERMISSN (Permissions) File, 3, 8, 12, 17, 21, 24, 26, 27, 29, 30, 46, 47, 84, 90, 121, 169, 193

Platt, Dave, ix, 7, 161

PNEWS command, 60, 72, 197

—R—

Redistribution, ix

Registration, 173

REGSETUP, 195

REGSETUP command, 73, 74, 195, 198

RMAIL, 195

RMAIL command, 4, 9, 23, 26, 29, 31, 32, 33, 34, 35, 37, 39, 40, 41, 42, 47, 48, 61, 62, 67, 75, 76, 77, 86, 88, 99, 102, 103, 120, 121, 124, 125, 126, 140, 146, 151, 166, 167, 182, 184, 185, 186, 187, 189, 191, 192, 193, 194, 195, 197, 199, 201, 202, 204, 205, 206

RNEWS command, 6, 9, 23, 28, 29, 39, 41, 47, 53, 60, 69, 70, 78, 79, 86, 116, 121, 125, 126, 166, 195, 196, 197, 201

Rommel, Kai Uwe, 56, 101, 109, 161, 194, 197, 198, 200, 201, 202, 203, 204, 206

—S—

SENDBATS command, 28, 80, 166, 195, 196

Shere message, 9, 24

SMTP Protocol, 31, 32, 34, 37, 38, 102, 103, 126, 151, 182, 183, 187, 188, 189, 190, 191

Spool Directory

Naming Conventions, 10

Stanford, Cliff, 161

SU command, 6, 81

Support.

electronic mail, 4

Telephone, 5

US mail, 4

SYS (News Distribution) File, 22, 28, 52, 69, 70, 78, 80, 127, 154, 155, 157, 158, 195, 196, 197

SYS file, 155

SYSTEMS file, 137

SYSTEMS File, 3, 4, 8, 9, 17, 20, 23, 26, 33, 34, 35, 40, 41, 46, 82, 83, 94, 119, 120, 122, 124, 127, 128, 130, 132, 137, 139, 140, 141, 145, 159, 169, 183, 195

—T—

Taylor UUCP, 7, 20, 133, 142, 202

TCP/IP Procotol, 1, 2, 13, 26, 28, 34, 37, 38, 40, 42, 82, 86, 87, 92, 98, 102, 130, 132, 135, 138, 141, 142, 151, 152, 165, 166, 183, 185, 188, 190, 191, 192, 200

telephone, xiii

Tremmel, Wolfgang, 161

—U—

Universal Naming Convention (UNC), 40, 41, 63

Using & Managing UUCP, 3, 9, 13, 21, 29, 30, 46, 51, 70, 91, 111, 115

uucico

DOS version under OS/2, 9

UUCICO command, 10, 15, 26, 28, 29, 30, 31, 49, 52, 82, 86, 98, 107, 123, 128, 138, 141, 165, 166, 167, 182, 185, 193, 194

UUCLEAN command, 28, 59, 88, 95, 125, 183, 185, 194, 199

UUCP command, 3, 15, 90, 91, 110, 121, 123, 165, 166, 169, 184, 190, 198, 205

UUCP file transfer, 165

uucpd command

bugs in UNIX version, 42

UUCPD command, 86, 92

UUHOUR command, 59, 93

UUIO command, 25, 47, 82, 86, 89, 112

UUNAME command, 12, 23, 47, 94, 107

UUPC.RC (System configuration) File, 4, 6, 8, 9, 12, 16, 17, 18, 19, 24, 25, 26, 28, 29, 31, 33, 35, 36, 41, 45, 48, 59, 61, 62, 65, 70, 73, 76, 77, 78, 81, 83, 84, 85, 88, 94, 113, 115, 116, 119, 122, 123, 124, 125, 128, 140, 146, 148, 155, 157, 158, 182, 185, 189, 191, 193, 194, 195, 205, 206

uupoll, 195

UUPOLL command, 183, 185, 193

UUPOPD command, 38, 45, 98, 136, 183, 184, 185, 186

UUPORT command, 40, 82, 86, 100, 202

UUSMTPD, 32

UUSMTPD command, 32, 37, 38, 40, 45, 98, 99, 102, 124, 182, 183, 184, 185, 186, 188

UUSTAT command, 89, 91, 104, 105, 107, 111, 140, 166, 198, 202, 206

UUSUB command, 39, 105, 107

UUTRAF command, 108, 109, 206

UUX command, 28, 29, 48, 123, 166, 167, 184, 190, 193

uuxqt, 195

UUXQT command, 15, 30, 31, 39, 121, 152, 166, 167, 182, 185, 186, 191, 194

—V—

v protocol, 198

Version

1.05, 1

1.12j, 196

1.12n, 196

1.12o, 194

1.12p, 193

1.12r, 192

1.12s, 189

1.12t, 186

1.12u, 186

1.12v, 185

1.12w, 176, 184, 185

1.13a, 176, 184

1.13b, 183

1.13c, 176

—W—

WAITING command, 113, 201

warranty, xi

Watt, David M., 101, 161, 190, 198, 203, 206

Windows, xiii, 1, 6, 7, 8, 10, 11, 14, 15, 16, 17, 22, 25, 26, 27, 28, 29, 37, 38, 39, 40, 41, 42, 44, 47, 49, 50, 53, 54, 56, 57, 58, 60, 61, 64, 69, 71, 73, 75, 78, 81, 82, 83, 85, 86, 88, 89, 90, 94, 95, 98, 99, 100, 101, 102, 103, 104, 107, 108, 109, 110, 112, 113, 115, 116, 125, 126, 132, 136, 144, 146, 159, 161, 163, 170, 171, 176, 185, 186, 187, 188, 189, 190, 191, 195, 197, 198, 199, 200, 203, 204, 205, 206

Windows 3.x, 1, 7, 11, 15, 25, 26, 38, 39, 42, 49, 53, 56, 61, 75, 82, 85, 94, 95, 100, 104, 107, 108, 115, 132, 161, 163, 176, 188, 191, 204

Windows 95, xiii, 1, 6, 7, 11, 14, 15, 38, 39, 40, 132, 136, 163, 170, 176, 190

Windows NT, 1, 6, 7, 11, 14, 15, 16, 17, 22, 25, 28, 37, 38, 39, 40, 41, 42, 44, 47, 49, 50, 53, 54, 56, 57, 58, 60, 61, 64, 69, 71, 73, 75, 78, 81, 82, 83, 85, 86, 88, 90, 94, 95, 98, 99, 100, 101, 102, 103, 104, 107, 108, 110, 112, 113, 115, 116, 126, 132, 144, 146, 161, 163, 170, 176, 185, 186, 187, 188, 189, 195, 197, 199, 200, 203, 204, 205, 206

Windows NT, 189, 191

—Z—

Zarathustra, Miles, 198

[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.

[7]I LOVE Thin Mints!!!--SPB

[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.

[11]And I'm cute, too!! [S.P.B.]

[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