Conference gyro::internet_toolss

    Does a POP3 server exist that allows mail folder management ON the
    server (ala Exchange Server)?
    
    Ken.... 

        I believe ZMail implemented a variant of POP3 to do this.  I don't know
  the details.  The proper solution to doing this is IMAP4.  There are now
  available a number of IMAP Servers, both free and commercial, as well as IMAP4
  Clients for most platforms.

                Danny

    
    Re .-1,
    
    Danny, 
    
    do you know of a good IMAP4 that would run on VAX VMS ? I looked after
    and found only two : one, rather old, without any work done on it
    anymore and a second one included in PMDF.
    
    Rgds,
    
          Guy 

>    do you know of a good IMAP4 that would run on VAX VMS ? I looked after
>    and found only two : one, rather old, without any work done on it
>    anymore and a second one included in PMDF.

	Check with the University of Washington.  They own the IMAP spec and
  have a list of available IMAP Servers.  Also check with the VMS folks.

		Danny

    
    
    Danny,
    
    It is the VMS folks that came to me sking this, anyway I'll check with
    the University of Washington, if I can get in touch with them.
    
    Thank you and regards,
    
            Guy
    

    re:  Note 1778.36 by BACHUS::ROELANDTS
    
    Guy,
    	There's lots of info at the University of Washington's IMAP site:
    
    	http://www.imap.org/index.html .
    
    Ken....
    
    

    
    
    Ken,
    
    Thank you, the only kit that is available for VMS is the one from
    INNOSOFT, called PMDF-MTA.
    
         Rgds,
    
              Guy

>    Thank you, the only kit that is available for VMS is the one from
>    INNOSOFT, called PMDF-MTA.

Guy,

Check out this article that was posted to the comp.os.vms newsgroup last summer:

<snip>

X-News: ucxaxp comp.os.vms:154352
From: Andy Harper - KCL Systems manager <A.HARPER@kcl.ac.uk>
Subject:IMAP server for VMS - update port available
Date: Wed, 04 Sep 1996 17:17:33 BST
Message-ID:<009A7E0D.6C6ACE20.3362@alder.cc.kcl.ac.uk>

A couple of weeks back, I posted details of an IMAP mail server which I had
completed for VMS. I've now ported a later version of the server to VMS and
this message contains details.

What is IMAP ?
--------------
Several people asked 'what is IMAP' after my earlier message went around. Well
it's a protocol that allows a client to access mailboxes on a server. It
differs from the POP protocol in a number of key areas:

  *  POP only accesses the NEWMAIL folder; IMAP can access any folder

  *  POP downloads messages to the client; IMAP keeps them on the server
     (in either case, messages can be downloaded or left on the server if you
     wish but access to such messages with POP becomes tricky). POP is not
     good for people who move from PC to PC, whereas IMAP handles this neatly.

  *  POP can only read a mailbox and delete items from it; IMAP can
     additionally search, rename and store (though store is not implemented in
     this VMS port). This allows suitable clients to move messages between
     folders on different systems.


What Mail clients use IMAP?
---------------------------

Most of the clients around still use POP (Eudora, pegasus, netscape mail etc.)
but a number are starting to incoporate IMAP access to. The commercial one we
use is called Simeon by ESYS Corporation (this is not a recommendation and I
have no connection with the company!) and there is a freeware one called
ATISMAIL around. There's also talk of adding IMAP to NETSCAPE mail and perhaps
EUDORA. It IS an internet 'standard' and is therefore likely to become more
prevalent over time.


What about this IMAP server?
----------------------------
We had a need for a functional IMAP server on our VMS systems, and a number of
others seemed to be interested too, so I set about finding one. One such is the
IMAPD server included with the PINE software from Univ. of Washington, which
was ported to VMS by Yehavi Bourvine (based on the one included in the PINE
3.91 kit from U of Washington). This was known as 3.91 beta 5 for VMS.

I've updated Yehavi's port with some additional bug fixes and features and
called it 3.91 Beta 6. Although there are later releases of pine (3.95 is
current I believe) there are no working VMS ports (though 3.95 does include a
partial port which is grossly incomplete). My improvements to 3.91 are primarily
  * Completing the port of the IMAP server
  * Fully supporting the NETLIB TCP/IP interface
  * Adding a few new features, such as logging and decnet node mapping
  * Supporting builds with DEC C 5.3 and VAXC 3.2, on both VAX and ALPHA

Should anyone be interested in this, I've made the code available on my file
server. Details below. Also Included below is a summary of changes I've made so
that you can see if it's worth using.

Regards

Andy Harper
Kings College London

AVAILABILITY:
-------------

FTP:
     ftp://ftp2.kcl.ac.uk/zip/pine_3_91_beta_6.zip	(ZIP format)


CHANGES MADE:
-------------

Here's the 000changes.kcl file:


PINE AND IMAP FOR VMS		--- Version 3.91
---------------------

Yehavi Bourvine ported version 3.91 of the PINE code and the IMAPD server to
VMS. His last release was known as 3.91 Beta 5. However, this port was
incomplete (Mainly the IMAPD daemon). I have progressed the port to a workable
state and upgraded the code since then; This note summarises the changes. My
version starts at 3.91 Beta 6.

Note - the changes here have been tested ONLY with NETLIB and MULTINET. Support
is only partial for direct UCX support although NETLIB support provides an
alternative for UCX users. If anyone wishes to contribute the relevant mods to
make direct UCX support work properly, please let me know. I'll try to
integrate them as and when I can. I only update this in my limited spare time
or as needed for our local users.

The code will compile with VAX C 3.2 and DECC 5.3 and works on both VAX and
ALPHA with Multinet 3.5B.

Note: for those who used a previous port (3.89 beta 10 or 3.89 beta 11) which i
released, all the facilities of those versions have been included into this
release.


Andy Harper, Kings College London, 				September 1996

-----------------------------------------------------------------------------

3.91 Beta 6 - Changes since 3.91 Beta 5
---------------------------------------


1.	IMAPD
        =====

  *  Bug fixes to the code which parses the messages to sort out the headers
     from the text and return the length of each. This was not being done under
     all circumstances and resulted in some short string counts which could
     confuse the clients.
								Sept 3, 1996



  *  Added fuller checks on I/O status checks to/from the network. Should
     prevent the code hanging or looping if the network connection dies.
								Sept 3, 1996


  *  Fixed the NETLIB support code. This let me find some interesting DEC C and
     VAX C header conflict bugs. If compiling with DEC C, it is probably
     inadvisable to point logicals like SYS, ARPA etc. to the SYS$LIBRARY If
     you also have, or previously had, VAXC installed. The logicals cause DEC C
     to pick up certain header files from there, rather than from the standard
     DEC C library. Unfortunately, they conflict in their contents and cause
     various facilities to become unavailable (Someone really should shoot the
     inventor of C header files - they are a facility that is grossly misused
     and abused even by professional programmers! DEC C writers have not helped
     matters with their proliferation of ifdefs and modes of compilation)

     Also had to slightly edit the code to call the right TCP interface
     routine to get the local name.
								Sept 2, 1996


  *  Found a more effective/efficient way of dealing with VMS/RFC822 header
     selection in VMS_MAIL.C. Basically, start by extracting the VMS MAIL
     headers into a buffer. If the first line after this set of headers looks
     like it's an RFC822 style header, copy those over the top of the VMS MAIL
     headers rather than reading them into a separate buffer. It's cleaner and
     uses less memory.
								Sept 2, 1996


*   Added logging to the IMAPD code.  Each activation of IMAPD will create
    a logfile if the logical name IMAPD_LOGFILE is defined with a valid file
    name. The logical is checked each time the IMAPD program starts so it can
    be dynamically assigned/deassigned for selective logging only when there's
    a problem to solve.  The level of logging sent to this file is controlled
    by the logical name IMAPD_LOGLEVEL. If defined with a numeric value greater
    than zero, then logging messages are written to the IMAPD_LOGFILE.

    The level of logging currently recognized are:
      0 or non-numeric: (No logging)
	0 - nothing written to log file

      1-10: progressively higher levels of IMAP tracing 
        1 - Basic trace of IMAP commands and responses

      11-20: internal trace of I/O routines and other technical debugging stuff
	10: Trace of each read/write of an I/O buffer to stdout
	11: Trace of every character read from stdin

    IMAPD Logging consists (currently) of all commands read by the IMAPD daemon
    and their parameters. NOTE that this includes login passwords at present!!
    Command responses are logged too, though not the data generated by the
    command.

  *  The alert facility has been implemented. A logical name of the form
     IMAPD_ALERTFILE can be defined to point to a text file. If this text file
     can be opened, it is copied to the IMAP user at the start of each IMAP
     session. Each line in the file is printed as:
        * OK [ALERT]  text

     Whether or not the IMAP client can detect and print them is, of course,
     client dependent.
								August 30, 1996


*   The idle timeout code was originally written using the ANSI function
    setitimer. As this is not available with VAX C or with DEC C until
    VMS 7, the code was originally commented out for VMS. It's been put back
    and uses alarm() now.

    Previously the idle timeout was fixed via a define in the source. I've
    changed this so that the value can be specified via a system wide logical
    name IMAPD_TIMEOUT.

    For example:
       $ define /system /exec imapd_timeout 1800

    Sets an idle timeout of 1800 seconds (30 minutes).  A value of 0 (the
    default) sets no idle timeout.
								August 30, 1996


*   Added the ability to remap DECNET node names via logicals. With this
    facility,  a name of the form:

	node::username		(or Namespace:.node::username under DECnet/OSI)

    attempts to translate the logical name:

        IMAPD_NODE_node

    And the translation is used to replace 'node'.

    For example:

      Suppose the logical name  IMAPD_NODE_BLACK is defined to "campus.edu"
      then the address:

        BLACK::JOHN

      is mapped into:
        JOHN@campus.edu

      With no logical name, the translation will be:
        JOHN@BLACK
								August 30, 1996


*   The program was originally written for unix, where INETD can fork off a
    process with stdin and stdout automatically connected to the client
    channels. This has the advantage of allowing things like printf to work
    directly to the sockets. With VMS, we can't do this (easily) so I've
    resorted to a rather nasty trick of redefining the standatd i/o calls with
    macros to our own special routines which attempt to detect how to properly
    handle the I/O. Not a pretty sight but it seems to work! Handling of
    network read/write error returns is still a bit flaky though. More work
    needed. It does now work with MULTINET and (shortly) with NETLIB.

    I can't claim credit for the idea of intercepting the I/O code - that goes
    to Yehavi Bourvine who added something similar to the 3.89 port. I've taken
    the idea and refined it to make it cleaner and QIO free. The original code
    had no concept of restrictions on I/O buffer length so would merrily
    overwrite code and data structures. My rewrite is careful not to do this
    and splits reads/writes where necessary.
								August 30, 1996


  *  When a local or DECnet message is found (IE one sent through normal VMS
     mechanisms rather than via SMTP software), the IMAPD daemon returns the
     usual VMS mail header lines. These are, of course, not in rfc822 format
     and confuse various mail header parsers. The code now modifies these
     headers (the FROM:, TO: and CC: fields) into an RFC822-like syntax.

     The following forms are recognized:
         username		   maps to	username	(No DECnet)
         node::username		   maps to	username@node	(DECnet IV)
         namespace:.node::username maps to	username@node	(DECnet V)

     Additionally, a comma separated list of names in each field is allowed
     and each is converted as above. I don't support space separated names!
								August 15, 1996


  *  I've further tidied up all the memory allocation bugs I can find in IMAPD
     and it appears to be fairly stable now. Big messages may still confuse it
     though.
								August 14, 1996


  *  The IMAP daemon reads each message into memory. It allocates space
     for the message using a primitive and inefficient technique and does not
     check whether the allocation succeeded. This leads to random crashes
     later when the invalid pointers are used (well, it was written originally
     for unix where error checking is not necessary ..   :-) )

     The algorithm has been modified to greatly reduce the memory requirements
     for each message. This won't stop the crashes but should make them happen
     less often. I could not find a way to die gracefully if the memory
     allocation failed. At the moment, the check simply prints an error message
     and dies rather than crashing; whether the mail client can print this
     message is client dependent.

     One way to circumvent the problem is to increase the amount of virtual
     memory allocated to the imapd process. If run under MULTINET via the
     superserver, you can use the MU CONF/SERVER command:
        SET PQL-PGFLQUOTA xxxxx

     To a suitably large value. Really though, the code needs to be heavily
     modified to not read each message into memory first.
								August 12 1996


2.	GENERAL
        =======

*   I've added two startup procedures:
      IMAPD_STARTUP.COM can  be called from system startup to initialize the
      logical names IMAPD uses. Note that this should be tailored for local
      use first!

      PINE_STARTUP.COM can be called from system startup to initialize the
      logical names PINE uses. Note that this should be tailored for local
      use first!

      Both files contain examples of the optional logicals. Tailor and comment
      to personal taste.
								August 16, 1996

    
    
    re .-1:
    
    Julie,
    
    Thank you very much, I'm currently copying that kit, just to tell that
    the current version isn't pine_3_91_beta_6.zip anymore but :
    
    ftp://ftp2.kcl.ac.uk/zip/pine_3_91_beta_11.zip
    
    Rgds,
    
           Guy
    

    re .-1:
    
    Karol,
    
    Thank you very much, I'm currently copying that kit, just to tell that
    the current version isn't pine_3_91_beta_6.zip anymore but :
    
        ftp://ftp2.kcl.ac.uk/zip/pine_3_91_beta_11.zip
    
        Rgds,
    
               Guy