diff options
Diffstat (limited to 'crypto/heimdal/appl/popper/README')
-rw-r--r-- | crypto/heimdal/appl/popper/README | 381 |
1 files changed, 381 insertions, 0 deletions
diff --git a/crypto/heimdal/appl/popper/README b/crypto/heimdal/appl/popper/README new file mode 100644 index 0000000..0735fdd --- /dev/null +++ b/crypto/heimdal/appl/popper/README @@ -0,0 +1,381 @@ +@(#)@(#)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. |