31 January 1997
Mark Crispin
Bugs or questions regarding this software may be reported to the author:
Internet: MRC@CAC.Washington.EDU
Postal mail: Mark Crispin
University of Washington
Networks and Distributed Computing
4545 15th Avenue NE
Seattle, WA 98105-4527
USA
Phone: +1 (206) 543-5762
FAX: +1 (206) 685-4045
In general, it is best to send email. The telephone is not any faster; in fact, it can be considerably slower.
This directory tree contains the following:
mtest has been run under UNIX, DOS, Macintosh, TOPS-20, and VMS. It is a very primitive interface, however, and is suited mainly as a model of how to write a main program for c-client. You should take a look at the source to figure out how to use it. Briefly, it first asks for a mailbox name (either a local file path or an IMAP mailbox in the form "{hostname}mailbox") and then puts you in a command mode where "?" will give you a list of commands.
The Pine mailer for UNIX and DOS uses c-client, and is available separately on the FTP.CAC.Washington.EDU archives.
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-4.1/Makefile, which will run a "process" step the first time and create the imap-4.1/c-client, imap-4.1/ipopd, and imap-4.1/imapd directories in which building actually takes place.
Before doing a make on UNIX, you should read imap-4.1/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 an IBM AIX 3.2 system on an RS/6000, your system type is a32, and the appropriate command is:
make a32
There are other make options, described in imap-4.1/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-4.1/Makefile and imap-4.1/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.
WARNING: The MacMint (mnt) and SVR2 (sv2) ports are *incomplete*. Neither of these systems appear to have any way to do ftruncate(), which is needed by the bezerk, mbox, mbx, mmdf, mtx, and tenex drivers. Additionally, I was never able to get the interface code to MacTCP working with MacMint, so on the mnt port the imap4, nntp, pop3, and smtp drivers are also useless. I abandoned MacMint after I got MachTen.
Binaries from the build are:
mtest is normally not used except by c-client developers. The ipop2d, ipop3d, and imapd daemons should be installed in a system daemon directory, 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").
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
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.
This software is designed to run without privileges. The mail spool directory should be protected 1777; that is, with world write and the sticky bit. Of course, mail *files* should be protected 600!
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