diff options
Diffstat (limited to 'crypto/heimdal/appl/popper/README')
-rw-r--r-- | crypto/heimdal/appl/popper/README | 381 |
1 files changed, 0 insertions, 381 deletions
diff --git a/crypto/heimdal/appl/popper/README b/crypto/heimdal/appl/popper/README deleted file mode 100644 index 0735fdd56c39..000000000000 --- a/crypto/heimdal/appl/popper/README +++ /dev/null @@ -1,381 +0,0 @@ -@(#)@(#)README 2.6 2.6 4/2/91 - - -The Post Office Protocol Server: Installation Guide - - - -Introduction - -The Post Office Protocol server runs on a variety of Unix[1] computers -to manage electronic mail for Macintosh and MS-DOS computers. The -server was developed at the University of California at Berkeley and -conforms fully to the specifications in RFC 1081[2] and RFC 1082[3]. -The Berkeley server also has extensions to send electronic mail on -behalf of a client. - -This guide explains how to install the POP server on your Unix -computer. It assumes that you are not only familiar with Unix but also -capable of performing Unix system administration. - - -How to Obtain the Server - -The POP server is available via anonymous ftp from ftp.CC.Berkeley.EDU -(128.32.136.9, 128.32.206.12). It is in two files in the pub directory: -a compressed tar file popper-version.tar.Z and a Macintosh StuffIt archive -in BinHex format called MacPOP.sit.hqx. - - -Contents of the Distribution - -The distribution contains the following: - -+ All of the C source necessary to create the server program. - -+ A visual representation of how the POP system works. - -+ Reprints of RFC 1081 and RFC 1082. - -+ A HyperCard stack POP client implementation using MacTCP. - -+ A man page for the popper daemon. - -+ This guide. - - -Compatibility - -The Berkeley POP server has been successfully tested on the following -Unix operating systems: - -+ Berkeley Systems Distribution 4.3 - -+ Sun Microsystems Operating System versions 3.5 and 4.0 - -+ Ultrix version 2.3 - -The following POP clients operate correctly with the Berkeley POP server: - -+ The Berkeley HyperMail HyperCard stack for the Apple Macintosh - (distributed with the server). - -+ The Stanford University Macintosh Internet Protocol MacMH program. - -+ The Stanford University Personal Computer Internet Protocol MH - program. - -+ The mh version 6.0 programs for Unix. - - -Support - -The Berkeley POP server is not officially supported and is without any -warranty, explicit or implied. However, we are interested in your -experiences using the server. Bugs, comments and suggestions should be -sent electronically to netinfo@garnet.Berkeley.EDU. - - -Operational Characteristics - -The POP Transaction Cycle - -The Berkeley POP server is a single program (called popper) that is -launched by inetd when it gets a service request on the POP TCP port. -(The official port number specified in RFC 1081 for POP version 3 is -port 110. However, some POP3 clients attempt to contact the server at -port 109, the POP version 2 port. Unless you are running both POP2 and -POP3 servers, you can simply define both ports for use by the POP3 -server. This is explained in the installation instructions later on.) -The popper program initializes and verifies that the peer IP address is -registered in the local domain, logging a warning message when a -connection is made to a client whose IP address does not have a -canonical name. For systems using BSD 4.3 bind, it also checks to see -if a cannonical name lookup for the client returns the same peer IP -address, logging a warning message if it does not. The the server -enters the authorization state, during which the client must correctly -identify itself by providing a valid Unix userid and password on the -server's host machine. No other exchanges are allowed during this -state (other than a request to quit.) If authentication fails, a -warning message is logged and the session ends. Once the user is -identified, popper changes its user and group ids to match that of the -user and enters the transaction state. The server makes a temporary -copy of the user's maildrop (ordinarily in /usr/spool/mail) which is -used for all subsequent transactions. These include the bulk of POP -commands to retrieve mail, delete mail, undelete mail, and so forth. A -Berkeley extension also allows the user to submit a mail parcel to the -server who mails it using the sendmail program (this extension is -supported in the HyperMail client distributed with the server). When -the client quits, the server enters the final update state during which -the network connection is terminated and the user's maildrop is updated -with the (possibly) modified temporary maildrop. - - -Logging - -The POP server uses syslog to keep a record of its activities. On -systems with BSD 4.3 syslogging, the server logs (by default) to the -"local0" facility at priority "notice" for all messages except -debugging which is logged at priority "debug". The default log file is -/usr/spool/mqueue/POPlog. These can be changed, if desired. On -systems with 4.2 syslogging all messages are logged to the local log -file, usually /usr/spool/mqueue/syslog. - -Problems - -If the filesystem which holds the /usr/spool/mail fills up users will -experience difficulties. The filesystem must have enough space to hold -(approximately) two copies of the largest mail box. Popper (v1.81 and -above) is designed to be robust in the face of this problem, but you may -end up with a situation where some of the user's mail is in - - /usr/spool/mail/.userid.pop - -and some of the mail is in - - /usr/spool/mail/userid - -If this happens the System Administrator should clear enough disk space -so that the filesystem has at least as much free disk as both mailboxes -hold and probably a little more. Then the user should initiate a POP -session, and do nothing but quit. If the POP session ends without an -error the user can then use POP or another mail program to clean up his/her -mailbox. - -Alternatively, the System Administrator can combine the two files (but -popper will do this for you if there is enough disk space). - - -Debugging - -The popper program will log debugging information when the -d parameter -is specified after its invocation in the inetd.conf file. Care should -be exercised in using this option since it generates considerable -output in the syslog file. Alternatively, the "-t <file-name>" option -will place debugging information into file "<file-name>" using fprintf -instead of syslog. (To enable debugging, you must edit the Makefile -to add -DDEBUG to the compiler options.) - -For SunOS version 3.5, the popper program is launched by inetd from -/etc/servers. This file does not allow you to specify command line -arguments. Therefore, if you want to enable debugging, you can specify -a shell script in /etc/servers to be launched instead of popper and in -this script call popper with the desired arguments. - - -Installation - -1. Examine this file for the latest information, warnings, etc. - -2. Check the Makefile for conformity with your system. - -3. Issue the make command in the directory containing the popper - source. - -4. Issue the make install command in the directory containing the - popper source to copy the program to /usr/etc. - -5. Enable syslogging: - - + For systems with 4.3 syslogging: - - Add the following line to the /etc/syslog.conf file: - - local0.notice;local0.debug /usr/spool/mqueue/POPlog - - Create the empty file /usr/spool/mqueue/POPlog. - - Kill and restart the syslogd daemon. - - + For systems with 4.2 syslogging: - - Be sure that you are logging messages of priority 7 and higher. - For example: - - 7/usr/spool/mqueue/syslog - 9/dev/null - -6. Update /etc/services: - - Add the following line to the /etc/services file: - - pop 110/tcp - - Note: This is the official port number for version 3 of the - Post Office Protocol as defined in RFC 1081. However, some - POP3 clients use port 109, the port number for the previous - version (2) of POP. Therefore you may also want to add the - following line to the /etc/services file: - - pop2 109/tcp - - For Sun systems running yp, also do the following: - - + Change to the /var/yp directory. - - + Issue the make services command. - -7. Update the inetd daemon configuration. Include the second line ONLY if you - are running the server at both ports. - - + On BSD 4.3 and SunOS 4.0 systems, add the following line to the - /etc/inetd.conf file: - - pop stream tcp nowait root /usr/etc/popper popper - pop2 stream tcp nowait root /usr/etc/popper popper - - + On Ultrix systems, add the following line to the - /etc/inetd.conf file: - - pop stream tcp nowait /usr/etc/popper popper - pop2 stream tcp nowait /usr/etc/popper popper - - + On SunOS 3.5 systems, add the following line to the - /etc/servers file: - - pop tcp /usr/etc/popper - pop2 tcp /usr/etc/popper - - Kill and restart the inetd daemon. - -You can confirm that the POP server is running on Unix by telneting to -port 110 (or 109 if you set it up that way). For example: - -%telnet myhost 110 -Trying... -Connected to myhost.berkeley.edu. -Escape character is '^]'. -+OK UCB Pop server (version 1.6) at myhost starting. -quit -Connection closed by foreign host. - - -Release Notes - -1.83 Make sure that everything we do as root is non-destructive. - -1.82 Make the /usr/spool/mail/.userid.pop file owned by the user rather - than owned by root. - -1.81 There were two versions of 1.7 floating around, 1.7b4 and 1.7b5. - The difference is that 1.7b5 attempted to save disk space on - /usr/spool/mail by deleting the users permanent maildrop after - making the temporary copy. Unfortunately, if compiled with - -DDEBUG, this version could easily wipe out a users' mail file. - This is now fixed. - - This version also fixes a security hole for systems that have - /usr/spool/mail writeable by all users. - - With this version we go to all new SCCS IDs for all files. This - is unfortunate, and we hope it is not too much of a problem. - - Thanks to Steve Dorner of UIUC for pointing out the major problem. - -1.7 Extensive re-write of the maildrop processing code contributed by - Viktor Dukhovni <viktor@math.princeton.edu> that greatly reduces the - possibility that the maildrop can be corrupted as the result of - simultaneous access by two or more processes. - - Added "pop_dropcopy" module to create a temporary maildrop from - the existing, standard maildrop as root before the setuid and - setgid for the user is done. This allows the temporary maildrop - to be created in a mail spool area that is not world read-writable. - - This version does *not* send the sendmail "From " delimiter line - in response to a TOP or RETR command. - - Encased all debugging code in #ifdef DEBUG constructs. This code can - be included by specifying the DEGUG compiler flag. Note: You still - need to use the -d or -t option to obtain debugging output. - -1.6 Corrects a bug that causes the server to crash on SunOS - 4.0 systems. - - Uses varargs and vsprintf (if available) in pop_log and - pop_msg. This is enabled by the "HAVE_VSPRINTF" - compiler flag. - - For systems with BSD 4.3 bind, performs a cannonical - name lookup and searches the returned address(es) for - the client's address, logging a warning message if it - is not located. This is enabled by the "BIND43" - comiler flag. - - Removed all the includes from popper.h and distributed - them throughout the porgrams files, as needed. - - Reformatted the source to convert tabs to spaces and - shorten lines for display on 80-column terminals. - -1.5 Creates the temporary maildrop with mode "600" and - immediately unlinks it. - - Uses client's IP address in lieu of a canonical name if - the latter cannot be obtained. - - Added "-t <file-name>" option. The presence of this - option causes debugging output to be placed in the file - "file-name" using fprintf instead of the system log - file using syslog. - - Corrected maildrop parsing problem. - -1.4 Copies user's mail into a temporary maildrop on which - all subsequent activity is performed. - - Added "pop_log" function and replaced "syslog" calls - throughout the code with it. - -1.3 Corrected updating of Status: header line. - - Added strncasecmp for systems that do not have one. - Used strncasecmp in all appropriate places. This is - enabled by the STRNCASECMP compiler flag. - -1.2 Support for version 4.2 syslogging added. This is - enabled by the SYSLOG42 compiler flag. - -1.1 Several bugs fixed. - -1.0 Original version. - - -Limitations - -+ The POP server copies the user's entire maildrop to /tmp and - then operates on that copy. If the maildrop is particularly - large, or inadequate space is available in /tmp, then the - server will refuse to continue and terminate the connection. - -+ Simultaneous modification of a single maildrop can result in - confusing results. For example, manipulating messages in a - maildrop using the Unix /usr/ucb/mail command while a copy of - it is being processed by the POP server can cause the changes - made by one program to be lost when the other terminates. This - problem is being worked on and will be fixed in a later - release. - - -Credits - -The POP server was written by Edward Moy and Austin Shelton with -contributions from Robert Campbell (U.C. Berkeley) and Viktor Dukhovni -(Princeton University). Edward Moy wrote the HyperMail stack and drew -the POP operation diagram. This installation guide was written by -Austin Shelton. - - -Footnotes - -[1] Copyright (c) 1990 Regents of the University of California. - All rights reserved. The Berkeley software License Agreement - specifies the terms and conditions for redistribution. Unix is - a registered trademark of AT&T corporation. HyperCard and - Macintosh are registered trademarks of Apple Corporation. - -[2] M. Rose, Post Office Protocol - Version 3. RFC 1081, NIC, - November 1988. - -[3] M. Rose, Post Office Protocol - Version 3 Extended Service - Offerings. RFC 1082, NIC, November 1988. |