build

SIP 1.5.0源代码

			       UNIX BUILD NOTES

     A change has been made from previous versions of the IMAP toolkit.
There are no longer separate ANSI and non-ANSI source trees.  Nor is it
possible to build directly on the source tree.  Instead, you *must* build
through the top-level imap-2000/Makefile, which will run a "process" step the
first time and create the imap-2000/c-client, imap-2000/ipopd, and
imap-2000/imapd directories in which building actually takes place.

     Before doing a make on UNIX, you should read imap-2000/Makefile and see if
your system type is known.  The various system types are three-letter codes.
If your system type is known, then use this as the make option.  After the
first time you do a make, this option is remembered in a file called OSTYPE,
so just typing "make" suffices.

     For example, if you are using a more or less modern Linux system, your
system type is either slx (shadow passwords only) or lnp (PAM), and the
appropriate command is:
	make slx	(or make lnp)

     There are other make options, described in imap-2000/src/osdep/Makefile.

     It's probably best to see if an existing port will work on your system
before inventing a new port.  Try:
	sv4		generic SVR4
	a32		modern SVR4, SVR4 with gcc
	bsd		basic 4.3 BSD
	nxt, mct, gul	modern BSD, BSD with gcc

     If you must invent a new port, you need to create an entry in
imap-2000/Makefile and imap-2000/src/osdep/Makefile for your new port, as well as
osdep/os_???.h and osdep/os_???.c files with the appropriate OS-dependent
support for that system.  You also need to determine which setup process to
use.  You should use the ua process unless you are sure that your compiler
supports *ALL* aspects of ANSI C prototyping.  Note that some compilers, such
as Ultrix, support some aspects of ANSI C but not others; c-client really
beats on the full prototyping capability of ANSI C so you have to use the
non-ANSI source tree for such systems.

     If you send a new port back to us, we will make it available for others
who use your particular system type.

     The mbox driver is now enabled by default.  If the file "mbox" exists on
the user's home directory and is in UNIX mailbox format, then when INBOX is
opened this file will be selected as INBOX instead of the mail spool file.
Messages will be automatically transferred from the mail spool file into the
mbox file.  To disable this behavior, delete "mbox" from the EXTRADRIVERS list
in the top-level Makefile and rebuild.

     WARNING: The SVR2 (sv2) port is *incomplete*.  SVR2 does not appear to
have any way to do ftruncate(), which is needed by the mbox, mbx, mmdf, mtx,
tenex, and unix drivers.

			   UNIX INSTALLATION NOTES

     Binaries from the build are:
	imap-2000/mtest/mtest		c-client testbed program
	imap-2000/ipopd/ipop2d		POP2 daemon
	imap-2000/ipopd/ipop3d		POP3 daemon
	imap-2000/imapd/imapd		IMAP4rev1 daemon

     mtest is normally not used except by c-client developers.

STEP 1:	inetd setup

     The ipop2d, ipop3d, and imapd daemons should be installed in a system
daemon directory (in the following examples, /usr/local/etc is used), and
invoked by your /etc/inetd.conf file with lines such as:

pop	stream	tcp	nowait	root	/usr/local/etc/ipop2d	ipop2d
pop3	stream	tcp	nowait	root	/usr/local/etc/ipop3d	ipop3d
imap	stream	tcp	nowait	root	/usr/local/etc/imapd	imapd

     Note that different variants of UNIX have different versions of inetd,
so you should verify the precise form of these commands (for example, some
versions of inetd do not require the "nowait").

     IMPORTANT NOTE: inetd has a limit of how many new connections it will
allow in a certain interval, and when this limit is exceeded, it shuts down
the server.  If you have anything beyond a small-scale server, you are
probably going to run up against this limit.  You'll know when it happens;
your syslog will give the misleading message "imap/tcp server failing
(looping), service terminated" and users will complain that IMAP service is
unavailable for the next 10 minutes.  Similarly with "pop3/tcp server
failing"...

     It must be emphasized that this is *NOT* a bug in the IMAP or POP
servers, nor is it anything that I can "fix".  It is an inetd problem, and
the only way to fix it is to change inetd's behavior.

     By default, the parameters of this limit are (from inetd.c source code):

#define TOOMANY         40              /* don't start more than TOOMANY */
#define CNT_INTVL       60              /* servers in CNT_INTVL sec. */
#define RETRYTIME       (60*10)         /* retry after bind or server fail */

That is, no more than 40 connections (TOOMANY) in 60 seconds (CNT_INTL), and
if exceeded, shut down the server for 10 minutes (RETRYTIME).  This was a
good setting in the 1980s ARPAnet, but is much too small today.

     Some versions of inetd allow you to see a higher maximum in the
/etc/inetd.conf file.  Read "man inetd" and see if you see something like
this in the text:

     The wait/nowait entry is applicable to datagram sockets only [...]
     [...]  The optional ``max'' suffix (separated from
     ``wait'' or ``nowait'' by a dot) specifies the maximum number of server
     instances that may be spawned from inetd within an interval of 60 sec-
     onds. When omitted, ``max'' defaults to 40.

If you see this, then edit the /etc/inetd.conf entry for imapd to be
something like:

imap	stream	tcp	nowait.100	root	/usr/local/etc/imapd	imapd
 (or, if you use TCP wrappers)
imap	stream	tcp	nowait.100	root	/usr/local/etc/tcpd	imapd

     Otherwise, you'll need to edit the inetd source code to set TOOMANY to a
higher value, then rebuild inetd.


STEP 2:	services setup

     You may also have to edit your /etc/services (or Yellow Pages,
NetInfo, etc. equivalent) to register these services, such as:

pop		109/tcp
pop3		110/tcp
imap		143/tcp


STEP 3:	optional rimap setup

     If you want to enable the rimap capability, which allows users with a
suitable client and .rhosts file on the server to access IMAP services
without transmitting her password in the clear over the network, you need
to have /etc/rimapd as a link to the real copy of imapd.  Assuming you have
imapd installed on /usr/local/etc as above:
	% ln -s /usr/local/etc/imapd /etc/rimapd

     Technical note: rimap works by having the client routine tcp_aopen()
invoke `rsh _host_ exec /etc/rimapd' in an child process, and then returning
pipes to that process' standard I/O instead of a TCP socket.  You can set up
`e-mail only accounts' by making the shell be something which accepts only
that string and not ordinary UNIX shell commands.


STEP 4:	notes on privileges

     Neither user "root", not any other UID 0 account, can log in via IMAP or
POP.  "That's not a bug, it's a feature!"

     This software is designed to run without privileges.  The mail spool
directory must be protected 1777; that is, with world write and the sticky
bit.  Of course, mail *files* should be protected 600!

     An alternative to having the mail spool directory protected 1777, at the
cost of some performance, is to use the external "mlock" program, available
as part of the imap-utils package.  With mlock installed as /etc/mlock and
setgid mail, the spool directory can be protected 775 with group mail.
Please disregard this paragraph if you don't understand it COMPLETELY, and
know EXACTLY what to do without question.


STEP 5:	SVR4 specific setup

     There is one "gotcha" on System V Release 4 based systems such as
Solaris.  These systems do not use the standard UNIX mail format, but rather a
variant of that format that depends upon a bogus "Content-Length:" message
header.  This is widely recognized to have been a terrible mistake.  One
symptom of the problem is that under certain circumstances, a message may get
broken up into several messages.  I'm also aware of security bugs caused by
programs that foolishly trust "Content-Length:" headers with evil values.

    To fix your system, edit your sendmail.cf to change the Mlocal line to
have the -E flag.  A typical entry will lool like:

Mlocal, P=/usr/lib/mail.local, F=flsSDFMmnPE, S=10, R=20, A=mail.local -d $u

		      WIN32 BUILD AND INSTALLATION NOTES

     I build for Windows 9x and Windows NT using Visual C++ 6.0.  If
you build with an earlier version of Visual C, you may need to install
the Platform SDK (formerly called the Win32 SDK) separately.  If you
get errors while building os_nt.c that LogonUser() is undefined, it's
a good bet that you don't have the Platform SDK installed and/or in
your path properly.

     I build for Windows 2000 using Visual C++ 6.0 and the Windows