summaryrefslogtreecommitdiffstats
path: root/crypto/heimdal/appl/popper/README
diff options
context:
space:
mode:
Diffstat (limited to 'crypto/heimdal/appl/popper/README')
-rw-r--r--crypto/heimdal/appl/popper/README381
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.
OpenPOWER on IntegriCloud