IMAP for VM OpenEdition

    4 Jun 1998

    IMAP VMARC


    Table of Contents

    IMAP4rev1/c-client Development Environment

  • Bug Reporting Address
  • CONTENTS
  • Documentation
  • Sources
  • Directories created at build time on UNIX and NT
  • NOTES ON THE VARIOUS COMPONENTS
  • UNIX BUILD NOTES
  • UNIX INSTALLATION NOTES

  • IMAP4rev1/c-client Development Environment

                                   
    31 January 1997
                                         


                                     
    Mark Crispin

    Bug Reporting Address

    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.


    CONTENTS

    This directory tree contains the following:

    Documentation

    README
    this file
    docs
    IMAP4 protocol RFCs and related documents

    Sources

    Makefile
    master makefile for UNIX
    makefile.nt
    master makefile for NT
    src
    portable C sources
    src/c-client
    pre-processed c-client sources
    src/ipopd
    pre-processed POP2/POP3 daemon sources
    src/imapd
    pre-processed IMAP4 daemon sources
    src/mtest
    pre-processed c-client testbed sources
    src/osdep/UNIX
    pre-processed UNIX-specific sources
    src/osdep/amiga
    pre-processed Amiga-specific sources
    src/osdep/dos
    pre-processed DOS-specific sources
    src/osdep/mac
    pre-processed Mac-specific sources
    src/osdep/nt
    pre-processed NT-specific sources
    src/osdep/os2
    pre-processed OS/2-specific sources (incomplete)
    src/osdep/tops-20
    pre-processed TOPS-20 specific sources
    src/osdep/vms
    pre-processed VAX/VMS specific sources
    tools
    internal tools needed as part of the build process

    Directories created at build time on UNIX and NT

    c-client
    post-processed c-client sources and binary
    ipopd
    post-processed POP2/POP3 daemon sources and binaries
    imapd
    post-processed IMAP4 daemon sources and binaries
    mtest
    post-processed c-client testbed sources and binaries

    NOTES ON THE VARIOUS COMPONENTS

    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.


    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-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.


    UNIX INSTALLATION NOTES

    Binaries from the build are:

    imap-4.1/mtest/mtest
    c-client testbed program
    imap-4.1/ipopd/ipop2d
    POP2 daemon
    imap-4.1/ipopd/ipop3d
    POP3 daemon
    imap-4.1/imapd/imapd
    IMAP4rev1 daemon

    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