Date: 27 Jul 1999 11:33:39 -0600

  Run exmh on the laptop, and modify your .mh_profile to inc using
  APOP. This is how I run MH-E and it works fine. (I did have to
  modify MH-E a wee bit to allow it to prompt for the password. You
  would likely have to do something similar with exmh.)

  As a spare time project I'm adding enough IMAP support to MH (6.8.3)
  to allow you to 'inc -imap [-imapfolder foo]'. If I ever get this
  done I'll stick the diffs up somewhere. (It's not a big priority as
  I can get at my IMAP INBOX using APOP.)

From: Tim Showalter <tjs at andrew.cmu.edu>, John Prevost <visigoth at cs.cmu.edu>
Date: Wed, 25 Sep 1996 21:34:56 -0400

  We are developing fmh and intend to support as much of MH as is
  feasible. However, MH and IMAP don't necessarily agree as to what
  things are going to look like. MH has static message numbers until
  you pack a folder; IMAP keeps two numbers on a message, one which is
  absolutely static and one which is relative to the top of a mailbox.
  Messages in IMAP are essentially immutable. IMAP doesn't (currently)
  allow message annotations. fmh will keep state with a background
  daemon instead of writing it to disk, and will probably try and keep
  as little on disk as possible.

  fmh doesn't understand MH folders at the moment, and probably won't
  for a really long time, if ever. As I said before, we're mostly
  interested in the IMAP aspects as we're using a networked file
  system and saving stuff on the local disk just isn't an option.

  fmh is not MH at a very fundamental level. It is very unlikely that
  it will be merged, as we're not quite as interested in creating
  something that is MH and IMAP as we are in writing a good IMAP
  client. Also, the MH code isn't going to take the introduction of
  IMAP without a near complete rewrite.

  It is not available yet. Inquiries are welcome at <tjs+fmh at
  andrew.cmu.edu>.

From: Rahul Dhesi <dhesi at rahul.net>
Date: 23 Sep 1996 08:39:52 GMT

  What prevents people from doing a telnet to their mail server,
  logging in, and firing up MH directly? Site policy? An operating
  system that does not let MH compile or run? Overloaded machine with
  insufficient processing power for MH? All these are site-specific
  problems and the solution lies in solving them locally, not in
  forcing MH to go over IMAP.

  IMAP was never designed to emulate a filesytem. MH was designed to
  make direct advantage of the filesytem structure. There is no
  compatibility between the two. By the time IMAP is revised enough to
  support MH you will have reinvented NFS.

  There *is* scope for redesign here, though. It would be nice to have
  a single-user filesystem. Create a binary telnet session to the
  filesystem server, log in as yourself, and then over that session
  run a filesystem protocol. Normal filesystem protections at the
  other end will be sufficient for all permissions checking, so the
  filesystem protocol would need to do no other permissions checking.
  The question of whom to export directories to would go away: They
  are exported to whoever completes a successful login, and accessible
  to the user if he would be able to access them on the server as his
  login id. You could even use challenge-response for the initial
  login, coupled with ssh-based encryption, so you automatically have
  a secure filesystem without even trying.

  IMAP is too restricted in its scope to be easily modifiable to
  emulate such a filesystem. It would have to be a redesign from
  scratch.

From: John Romine <jromine at ics.uci.edu>
Date: Sun, 8 Sep 1996 15:45:27 -0700

  No. MH only supports retrieving mail using POP3. POP3 is on the
  "standards track"--it is now an elective Internet Draft Standard
  (see RFC 1939 for more details). At this point, IMAP[23] are
  "experimental, limited use" protocols; it is unlikely that MH will
  support them.

From: Bill Wohler <wohler at newt.com>
Date: Sun, 8 Sep 1996 15:45:32 -0700

  Since John posted the message above, IMAP has progressed from an
  "experiemental, limited use" protocol. While IMAP is not universal,
  many vendors now have implementations.

  I've found several things which might help. First, a definition
  lifted from the Pine FAQ:

  What is IMAP?

  IMAP stands for "Internet Message Access Protocol". An IMAP client
  program on any platform at any location on the Internet can access
  email folders on an IMAP server. While the messages appear to be
  local, they reside on the server until the client explicitly moves
  or deletes them. The IMAP protocol is a superset of POP, containing
  all POP commands plus more. For a comparison of IMAP and POP, see
  the paper Comparing Two Approaches to Remote Mailbox Access: IMAP
  vs. POP (in ftp.cac.washington.edu:/mail/imap.vs.pop). IMAP is what
  allows Pine (or any other IMAP client) to get to email on a central
  campus email server. There are current IETF working groups revising
  IMAP and readying it to become an Internet standard. A copy of the
  latest IMAP draft may be obtained from:
  
    ftp://ftp.cac.washington.edu/mail/latest-imap-draft

  For a list of IMAP clients, see the file imap.software, in the same
  directory.

From: David L Miller <dlm at cac.washington.edu>
Date: Mon, 1 Aug 1994 00:00:00 -0800

  ipop3d from the UW IMAP toolkit can operate in a couple modes. As a
  straight POP3 server, it uses the same C-client library as imapd, so
  it co-exists comfortably with imapd. It can also operate as a
  POP-to-IMAP gateway so that your POP-only clients can access IMAP
  services.

    ftp://ftp.cac.washington.edu/mail/imap.tar.Z			1.0M

From: Mark Crispin <MRC at Panda.COM>
Date: Mon, 1 Aug 1994 00:00:00 -0800

  The only answer I can give for [how MH users can use IMAP] is that
  Pine can read mailboxes in MH format; and that someone might in the
  future develop a version of MH that can use IMAP.