Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06134; 18 May 94 11:07 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06130; 18 May 94 11:07 EDT Received: from mx2.cac.washington.edu by CNRI.Reston.VA.US id aa09357; 18 May 94 11:07 EDT Received: by mx2.cac.washington.edu (5.65+UW94.4/UW-NDC Revision: 2.30 ) id AA14101; Wed, 18 May 94 07:34:19 -0700 Errors-To: owner-imap@cac.washington.edu X-Orig-Sender: owner-imap@cac.washington.edu Return-Path: Received: from ANDREW.CMU.EDU by mx2.cac.washington.edu (5.65+UW94.4/UW-NDC Revision: 2.30 ) id AA14095; Wed, 18 May 94 07:34:17 -0700 Received: (from postman@localhost) by andrew.cmu.edu (8.6.7/8.6.6) id KAA03585; Wed, 18 May 1994 10:34:15 -0400 Received: via switchmail; Wed, 18 May 1994 10:34:15 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Wed, 18 May 1994 10:32:20 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Wed, 18 May 1994 10:32:18 -0400 (EDT) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4c.411 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Wed, 18 May 1994 10:32:16 -0400 (EDT) Message-Id: Date: Wed, 18 May 1994 10:32:16 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John Gardiner Myers To: Everette Gray Allen Subject: Re: kerberized imap client/server... Cc: imap@cac.washington.edu In-Reply-To: <9405181326.AA27714@charon.cc.ncsu.edu> References: <9405181326.AA27714@charon.cc.ncsu.edu> Beak: is Not Everette_Allen@ncsu.edu (Everette Gray Allen) writes: > Steve Lunt tells me that you might be working on kerberizing imap mail > clients and servers. Would you take a minute and tell me how that is going > and if you are willing to let me use the binaries ?? I am interested in > whatever you are working on. Thanks for the time. I have written the specification of the AUTHENTICATE command, which provides a general mechanism for authentication and data stream protection in IMAP4. I have also written the specification for the use of this mechanism by Kerberos V4, GSS API, and S/Key. The release of these specifications is awaiting the completion of the massive restructuring of the IMAP4 document. I have implemented the Kerberos V4 authentication and protection mechanisms for my IMAP server. I have implemented the Kerberos V4 authentication (only) for the c-client IMAP client and server. I am currently working on implementing the Kerberos V4 protection mechanism for the c-client IMAP client. The new Kerberos V4 mechanism is completely different from the old "@KERBEROS:" mechanism. I am not working on having the new servers understand the old mechanism. I am not prepared to start handing out my code at this time. One, the code is not finished and I would rather spend my time doing development than cutting mini-releases. Two, I don't consider it a good idea to put the code in circulation before the underlying protocol has been released and has had some chance to be reviewed by the general community. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10610; 18 May 94 14:56 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10606; 18 May 94 14:56 EDT Received: from mx2.cac.washington.edu by CNRI.Reston.VA.US id aa16645; 18 May 94 14:56 EDT Received: by mx2.cac.washington.edu (5.65+UW94.4/UW-NDC Revision: 2.30 ) id AA19832; Wed, 18 May 94 11:22:57 -0700 Errors-To: owner-imap@cac.washington.edu X-Orig-Sender: owner-imap@cac.washington.edu Return-Path: Received: from alw.nih.gov by mx2.cac.washington.edu (5.65+UW94.4/UW-NDC Revision: 2.30 ) id AA19826; Wed, 18 May 94 11:22:49 -0700 Received: from kirin.dcrt.nih.gov by alw.nih.gov (5.61/1.35(alw-2.4)) id AA04087; Wed, 18 May 94 14:22:44 -0400 Received: by kirin.dcrt.nih.gov (4.1/3.15) id for rdew@web.nih.gov; Wed, 18 May 94 14:22:42 EDT Received: via switchmail; Wed, 18 May 1994 14:22:37 -0400 (EDT) Received: from dude.dcrt.nih.gov via qmail ID ; Wed, 18 May 1994 14:20:46 -0400 (EDT) Received: from dude.dcrt.nih.gov via qmail ID ; Wed, 18 May 1994 14:20:41 -0400 (EDT) Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.dude.dcrt.nih.gov.sun4m.412 via MS.5.6.dude.dcrt.nih.gov.sun4_41; Wed, 18 May 1994 14:20:41 -0400 (EDT) Message-Id: <0hqZlt60ts4j0ElW8B@alw.nih.gov> Date: Wed, 18 May 1994 14:20:41 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bob Dew To: Everette Gray Allen , John Gardiner Myers Subject: Re: kerberized imap client/server... Cc: imap@cac.washington.edu In-Reply-To: References: <9405181326.AA27714@charon.cc.ncsu.edu> Excerpts from mail: 18-May-94 Re: kerberized imap client/.. John Gardiner Myers@CMU. (1632) > I have written the specification of the AUTHENTICATE command, which > provides a general mechanism for authentication and data stream > protection in IMAP4. Great! > I have implemented the Kerberos V4 authentication and protection > mechanisms for my IMAP server. Any thoughts on making it DCE compatible? Thanks, -bob   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20710; 26 May 94 1:01 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20706; 26 May 94 1:01 EDT Received: from mx2.cac.washington.edu by CNRI.Reston.VA.US id aa24157; 26 May 94 1:01 EDT Received: by mx2.cac.washington.edu (5.65+UW94.4/UW-NDC Revision: 2.30 ) id AA20668; Wed, 25 May 94 21:38:06 -0700 Errors-To: owner-imap@cac.washington.edu X-Orig-Sender: owner-imap@cac.washington.edu Return-Path: Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65+UW94.4/UW-NDC Revision: 2.30 ) id AA20662; Wed, 25 May 94 21:38:05 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67e/UW-NDC Revision: 2.27.MRC ) id AA24579; Wed, 25 May 94 21:38:03 -0700 Date: Wed, 25 May 1994 21:31:34 -0700 (PDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Crispin Subject: new command proposal To: IMAP Interest List Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII I propose adding a variation of [+/-] FLAGS that does not cause FETCH responses: FLAGS.SILENT, +FLAGS.SILENT, -FLAGS.SILENT. The motivation is so that ``A234 STORE 1:5000 +FLAGS \DELETED" does not cause 5000 FETCH responses on a low-speed link. Any objections?   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06048; 26 May 94 11:38 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06044; 26 May 94 11:38 EDT Received: from mx2.cac.washington.edu by CNRI.Reston.VA.US id aa08828; 26 May 94 11:38 EDT Received: by mx2.cac.washington.edu (5.65+UW94.4/UW-NDC Revision: 2.30 ) id AA00319; Thu, 26 May 94 08:14:47 -0700 Errors-To: owner-imap@cac.washington.edu X-Orig-Sender: owner-imap@cac.washington.edu Return-Path: Received: from PO6.ANDREW.CMU.EDU by mx2.cac.washington.edu (5.65+UW94.4/UW-NDC Revision: 2.30 ) id AA00313; Thu, 26 May 94 08:14:45 -0700 Received: (from postman@localhost) by po6.andrew.cmu.edu (8.6.7/8.6.6) id LAA11042 for imap@cac.washington.edu; Thu, 26 May 1994 11:14:37 -0400 Received: via switchmail; Thu, 26 May 1994 11:14:36 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Thu, 26 May 1994 11:14:04 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Thu, 26 May 1994 11:14:03 -0400 (EDT) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4c.411 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Thu, 26 May 1994 11:14:02 -0400 (EDT) Message-Id: <4ht=mu600WBwAhRetc@andrew.cmu.edu> Date: Thu, 26 May 1994 11:14:02 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John Gardiner Myers To: imap@cac.washington.edu Subject: Re: new command proposal In-Reply-To: References: Beak: Is Mark Crispin writes: > The motivation is so > that ``A234 STORE 1:5000 +FLAGS \DELETED" does not cause 5000 FETCH responses > on a low-speed link. On my server, if you follow such a command by anything other than FETCH, STORE, SEARCH, or EXPUNGE, you're then going to get FETCH responses for those messages which you have previously done a FETCH FLAGS on. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07169; 26 May 94 12:53 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07165; 26 May 94 12:53 EDT Received: from mx2.cac.washington.edu by CNRI.Reston.VA.US id aa10716; 26 May 94 12:53 EDT Received: by mx2.cac.washington.edu (5.65+UW94.4/UW-NDC Revision: 2.30 ) id AA02250; Thu, 26 May 94 09:32:16 -0700 Errors-To: owner-imap@cac.washington.edu X-Orig-Sender: owner-imap@cac.washington.edu Return-Path: Received: from CAMIS.Stanford.EDU by mx2.cac.washington.edu (5.65+UW94.4/UW-NDC Revision: 2.30 ) id AA02244; Thu, 26 May 94 09:32:14 -0700 Received: from ssrg-ss2-1 (ssrg-ss2-1.Stanford.EDU [36.44.0.84]) by CAMIS.Stanford.EDU (8.6.8.1/8.6.5) with SMTP id JAA29313; Thu, 26 May 1994 09:32:12 -0700 Date: Thu, 26 May 1994 09:28:25 -0700 (PDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bill Yeager Reply-To: Bill_Yeager@camis.stanford.edu Subject: RE: new command proposal To: Mark Crispin Cc: IMAP Interest List In-Reply-To: Mark Crispin's message of Wed, 25 May 1994 21:31:34 -0700 (PDT): Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Mark, I think it is a great idea!! The time saved for a user by having a cooperative server for low bandwitch connections is tremendous. BIll   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07362; 26 May 94 13:06 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07358; 26 May 94 13:06 EDT Received: from mx2.cac.washington.edu by CNRI.Reston.VA.US id aa11034; 26 May 94 13:06 EDT Received: by mx2.cac.washington.edu (5.65+UW94.4/UW-NDC Revision: 2.30 ) id AA02563; Thu, 26 May 94 09:44:41 -0700 Errors-To: owner-imap@cac.washington.edu X-Orig-Sender: owner-imap@cac.washington.edu Return-Path: Received: from CAMIS.Stanford.EDU by mx2.cac.washington.edu (5.65+UW94.4/UW-NDC Revision: 2.30 ) id AA02557; Thu, 26 May 94 09:44:40 -0700 Received: from ssrg-ss2-1 (ssrg-ss2-1.Stanford.EDU [36.44.0.84]) by CAMIS.Stanford.EDU (8.6.8.1/8.6.5) with SMTP id JAA29613; Thu, 26 May 1994 09:44:21 -0700 Date: Thu, 26 May 1994 09:31:29 -0700 (PDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bill Yeager Reply-To: Bill_Yeager@camis.stanford.edu Subject: Re: new command proposal To: John Gardiner Myers Cc: imap@cac.washington.edu In-Reply-To: John Gardiner Myers's message of Thu, 26 May 1994 11:14:02 -0400 (EDT): <4ht=mu600WBwAhRetc@andrew.cmu.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > Mark Crispin writes: > > The motivation is so > > that ``A234 STORE 1:5000 +FLAGS \DELETED" does not cause 5000 FETCH responses > > on a low-speed link. > > On my server, if you follow such a command by anything other than > FETCH, STORE, SEARCH, or EXPUNGE, you're then going to get FETCH > responses for those messages which you have previously done a FETCH > FLAGS on. > > -- > _.John G. Myers Internet: jgm+@CMU.EDU > LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up > I've been working on a low bandwidth project for over a year and these things are very critical if a user is to get reasonable response using PPP for example. The change mark is suggesting will replace N unsolicited replies by 1 in all cases on a cooperative server. This will be great!! Bill Bill   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07672; 26 May 94 13:29 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07668; 26 May 94 13:29 EDT Received: from mx1.cac.washington.edu by CNRI.Reston.VA.US id aa11596; 26 May 94 13:29 EDT Received: by mx1.cac.washington.edu (5.65+UW94.4/UW-NDC Revision: 2.30 ) id AA19887; Thu, 26 May 94 10:03:12 -0700 Errors-To: owner-imap@cac.washington.edu X-Orig-Sender: owner-imap@cac.washington.edu Return-Path: Received: from ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65+UW94.4/UW-NDC Revision: 2.30 ) id AA19881; Thu, 26 May 94 10:03:10 -0700 Received: (from postman@localhost) by andrew.cmu.edu (8.6.7/8.6.6) id NAA07949 for imap@cac.washington.edu; Thu, 26 May 1994 13:03:08 -0400 Received: via switchmail; Thu, 26 May 1994 13:03:07 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Thu, 26 May 1994 13:01:53 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Thu, 26 May 1994 13:01:51 -0400 (EDT) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4c.411 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Thu, 26 May 1994 13:01:49 -0400 (EDT) Message-Id: Date: Thu, 26 May 1994 13:01:49 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John Gardiner Myers To: imap@cac.washington.edu Subject: Re: new command proposal In-Reply-To: References: Beak: Is Bill Yeager writes: > The change mark is suggesting will replace N unsolicited replies by 1 > in all cases on a cooperative server. This will be great!! My point is that the change Mark is suggesting might not save you as many replies as you think. Even if you avoid paying on the STORE, you might end up paying on the NOOP. If you follow that STORE with an EXPUNGE, you're still going to get 5000 "* 1 EXPUNGE" replies. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09441; 26 May 94 14:24 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09437; 26 May 94 14:24 EDT Received: from mx1.cac.washington.edu by CNRI.Reston.VA.US id aa12905; 26 May 94 14:24 EDT Received: by mx1.cac.washington.edu (5.65+UW94.4/UW-NDC Revision: 2.30 ) id AA21509; Thu, 26 May 94 11:06:55 -0700 Errors-To: owner-imap@cac.washington.edu X-Orig-Sender: owner-imap@cac.washington.edu Return-Path: Received: from socrates.ED.ASU.EDU by mx1.cac.washington.edu (5.65+UW94.4/UW-NDC Revision: 2.30 ) id AA21503; Thu, 26 May 94 11:06:53 -0700 Received: by socrates.ed.asu.edu (4.1/socrates-MX-1.4) id AA01883; Thu, 26 May 94 11:05:50 MST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "C. R. Oldham" Message-Id: <9405261805.AA01883@socrates.ed.asu.edu> Subject: More information about installing/using imap. To: imap@cac.washington.edu Date: Thu, 26 May 94 11:05:49 MST X-Mailer: ELM [version 2.3 PL11] I've recently become interested in imap especially since it supports accessing Usenet news. However, I can't seem to find any information about installing and using the utilities. The manpage is, ahem, a little too concise for me, and the RFCs don't provide me with what I need to know as far as things like Do all users receiving mail via imap need an account on my machine? If not, how do I set up the relevant configuration? etc. Is there a FAQ for imap? Thanks, -- | Charles R. (C. R.) Oldham | North Central Association | | cro@socrates.ed.asu.edu or| Commission on Schools | | aocro@acvax.inre.asu.edu | Arizona State University, Box 873011, _ | | Voice: 602/965-8700 | Tempe, AZ 85287-3011 X_>| | Fax: 602/965-9423 | #include "disclaimer.h" <> |   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11374; 26 May 94 15:48 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11370; 26 May 94 15:48 EDT Received: from mx1.cac.washington.edu by CNRI.Reston.VA.US id aa16236; 26 May 94 15:48 EDT Received: by mx1.cac.washington.edu (5.65+UW94.4/UW-NDC Revision: 2.30 ) id AA23470; Thu, 26 May 94 12:24:20 -0700 Errors-To: owner-imap@cac.washington.edu X-Orig-Sender: owner-imap@cac.washington.edu Return-Path: Received: from CAMIS.Stanford.EDU by mx1.cac.washington.edu (5.65+UW94.4/UW-NDC Revision: 2.30 ) id AA23462; Thu, 26 May 94 12:24:18 -0700 Received: from ssrg-ss2-1 (ssrg-ss2-1.Stanford.EDU [36.44.0.84]) by CAMIS.Stanford.EDU (8.6.8.1/8.6.5) with SMTP id MAA05718; Thu, 26 May 1994 12:24:10 -0700 Date: Thu, 26 May 1994 12:04:10 -0700 (PDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bill Yeager Reply-To: Bill_Yeager@camis.stanford.edu Subject: Re: new command proposal To: John Gardiner Myers Cc: imap@cac.washington.edu In-Reply-To: John Gardiner Myers's message of Thu, 26 May 1994 13:01:49 -0400 (EDT): Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > My point is that the change Mark is suggesting might not save you as > many replies as you think. Even if you avoid paying on the STORE, you > might end up paying on the NOOP. > > If you follow that STORE with an EXPUNGE, you're still going to get > 5000 "* 1 EXPUNGE" replies. > Yes, this is correct. But, one can disable expunge on low bandwidth connectins as part of the client interface. Or, user's do all of their usual mail management, and when done with this session, expunge. All in all, I think Mark's idea is a good one. And really needed. Bill   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13185; 26 May 94 17:46 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13181; 26 May 94 17:46 EDT Received: from mx2.cac.washington.edu by CNRI.Reston.VA.US id aa22103; 26 May 94 17:46 EDT Received: by mx2.cac.washington.edu (5.65+UW94.4/UW-NDC Revision: 2.30 ) id AA10457; Thu, 26 May 94 14:26:10 -0700 Errors-To: owner-imap@cac.washington.edu X-Orig-Sender: owner-imap@cac.washington.edu Return-Path: Received: from PO6.ANDREW.CMU.EDU by mx2.cac.washington.edu (5.65+UW94.4/UW-NDC Revision: 2.30 ) id AA10451; Thu, 26 May 94 14:26:07 -0700 Received: (from postman@localhost) by po6.andrew.cmu.edu (8.6.7/8.6.6) id RAA25229 for IMAP@CAC.Washington.EDU; Thu, 26 May 1994 17:25:58 -0400 Received: via switchmail; Thu, 26 May 1994 17:25:56 -0400 (EDT) Received: from nifty.andrew.cmu.edu via qmail ID ; Thu, 26 May 1994 17:24:18 -0400 (EDT) Received: via niftymail; Thu, 26 May 1994 17:24:06 -0400 (EDT) Date: Thu, 26 May 1994 17:24:05 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Chris Newman Subject: Re: new command proposal To: IMAP Interest List In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: <769987445.29215.0@nifty.andrew.cmu.edu> Mark Crispin writes: > I propose adding a variation of [+/-] FLAGS that does not cause FETCH > responses: FLAGS.SILENT, +FLAGS.SILENT, -FLAGS.SILENT. The motivation is so > that ``A234 STORE 1:5000 +FLAGS \DELETED" does not cause 5000 FETCH > responses > on a low-speed link. > > Any objections? I don't have a strong objection because this is a small change, but it doesn't seem like it's worth the additional verbage. For this particular case, changing bunches of flags at once is not a common operation. Performance optimization rules say we should optimize the common operations first. In addition, I believe the "low-speed link" argument is not a valid argument for adding complexity to the base protocol. My reasons for this belief are: 1) The suggestions I've seen based on the "low-speed link" argument have been piecemeal suggestions. I believe a solution to the "low-speed link" problem should address all places where the protocol can be too-verbose. 2) It is quite possible that applying compression to the low-speed link will solve the problem anyway. I believe link-compression would do a good job at making the 5000 FETCH responses reasonable. 3) In the event that #2 turns out to be insufficient, I think "low-speed link" issues can and should be deferred to a document separate from the base-protocol. It's simply not an issue in many environments. Besides, we're getting to a point where we should get the protocol out _NOW_. I think it is reasonable to stop the flow of suggested additions at this point just so we can move forward. - Chris   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13729; 26 May 94 18:52 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13725; 26 May 94 18:52 EDT Received: from mx2.cac.washington.edu by CNRI.Reston.VA.US id aa23747; 26 May 94 18:52 EDT Received: by mx2.cac.washington.edu (5.65+UW94.4/UW-NDC Revision: 2.30 ) id AA12452; Thu, 26 May 94 15:33:08 -0700 Errors-To: owner-imap@cac.washington.edu X-Orig-Sender: owner-imap@cac.washington.edu Return-Path: Received: from nkosi.well.com by mx2.cac.washington.edu (5.65+UW94.4/UW-NDC Revision: 2.30 ) id AA12445; Thu, 26 May 94 15:33:05 -0700 Received: from z-code.UUCP (uucp@localhost) by nkosi.well.com (8.6.9/8.6.9) with UUCP id PAA22050 for IMAP@cac.washington.edu; Thu, 26 May 1994 15:33:31 -0700 Received: from zander by z-code.com (4.1/NBN-16/ZC-13) id AA23993; Thu, 26 May 94 15:26:41 PDT Received: by zander (920330.SGI/920502.SGI) for @z-code.z-code.com:cac.washington.edu!IMAP id AA27163; Thu, 26 May 94 15:32:37 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dan Heller Message-Id: <9405261532.ZM27161@zander.z-code.com> Date: Thu, 26 May 1994 15:32:36 -0700 In-Reply-To: Chris Newman's message on May 26 References: <769987445.29215.0@nifty.andrew.cmu.edu> Phones: (415) 898-8649 Fax: 898-8299 Reply-To: argv@z-code.z-code.com X-Mailer: Z-Mail (3.2a.428 28apr94) To: IMAP Interest List Subject: Re: new command proposal Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii On May 26, 5:24pm, Chris Newman wrote: > For this particular case, changing bunches of flags at once is not > a common operation. Performance optimization rules say we should > optimize the common operations first. In zmail, pick -f imap@cac.washington.edu | save +imap-folder | delete That's a very common type of operation, whether you're using zmail or not. And it's quite popular with filters as well as interactive com- mands. And when you can encapsulate "complex" these kinds of operations in simple GUI buttons, more and more everyday users will be doing stuff like this. > In addition, I believe the "low-speed link" argument is not a valid > argument for adding complexity to the base protocol. A very high % of Eudora users are using it over slow links, and almost all the off-line interest of zmail users are for the same thing. Low- speed links is a major reality here... what you want to do to optimize the "protocol" is another discussion. --dan   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15682; 26 May 94 21:55 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15678; 26 May 94 21:55 EDT Received: from mx2.cac.washington.edu by CNRI.Reston.VA.US id aa26663; 26 May 94 21:55 EDT Received: by mx2.cac.washington.edu (5.65+UW94.4/UW-NDC Revision: 2.30 ) id AA17423; Thu, 26 May 94 18:38:00 -0700 Errors-To: owner-imap@cac.washington.edu X-Orig-Sender: owner-imap@cac.washington.edu Return-Path: Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65+UW94.4/UW-NDC Revision: 2.30 ) id AA17417; Thu, 26 May 94 18:37:58 -0700 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67e/UW-NDC Revision: 2.27.MRC ) id AA25464; Thu, 26 May 94 18:37:50 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67e/UW-NDC/Panda Revision: 2.27.MRC ) id AA08154; Thu, 26 May 94 18:37:44 -0700 Date: Thu, 26 May 1994 18:28:18 -0700 (PDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Crispin Subject: re: More information about installing/using imap. To: "C. R. Oldham" Cc: IMAP Interest List , c-client Interest List In-Reply-To: <9405261805.AA01883@socrates.ed.asu.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Thu, 26 May 94 11:05:49 MST, C. R. Oldham wrote: > I've recently become interested in imap especially since it > supports accessing Usenet news. However, I can't seem to find > any information about installing and using the utilities. This is really a question about the c-client implementation of IMAP as opposed to an IMAP protocol question, and should probably be continued on the c-client list instead of the IMAP list. The technical notes that come along with Pine describe installation, as does the README file. > Do all users receiving mail via imap need an account on my machine? This is normally the case in the c-client implmentation; however, you can change this with some modification. The file imap/c-client/log_???.c (there are different files for different systems) has a routine called server_login() which determines the authentication policy; as written it uses the information from the /etc/passwd file. Similarly, the file imap/c-client/env_unix.c has code which defines what the interpretation of the ``system mailbox'' and the ``home directory'' is. Although ``giving every IMAP user an account'' seems to be an unreasonable burden, you have to consider what you want out of an IMAP user ID: 1) unique user identifiers, and authentication of that user identifier. 2) access control between user identifiers, so that a user cannot access another user's data without authorization. 3) a place for the storage of the user's INBOX. 4) a place for the storage of the user's secondary mailboxes. When you add up all these needs, you quickly find that an alternative mechanism requires at least as much work as an entry in /etc/passwd -- you have to store the (userid/password/mailbox location) data somewhere, and you have to have some mechanism for access control (which UNIX UIDs and file protections generally accomplish). We have dedicated servers which are imap-only and that users cannot log in to. We enforce this by having their shells set so they can not log in, or set so that only an exec of /etc/rimapd is permitted. > Is there a FAQ for imap? Not yet, but hopefully there will be once the dust settles on the specification.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15780; 26 May 94 22:04 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15776; 26 May 94 22:04 EDT Received: from mx1.cac.washington.edu by CNRI.Reston.VA.US id aa26862; 26 May 94 22:04 EDT Received: by mx1.cac.washington.edu (5.65+UW94.4/UW-NDC Revision: 2.30 ) id AA02176; Thu, 26 May 94 18:48:05 -0700 Errors-To: owner-imap@cac.washington.edu X-Orig-Sender: owner-imap@cac.washington.edu Return-Path: Received: from ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65+UW94.4/UW-NDC Revision: 2.30 ) id AA02170; Thu, 26 May 94 18:48:03 -0700 Received: (from postman@localhost) by andrew.cmu.edu (8.6.7/8.6.6) id VAA17996 for imap@cac.washington.edu; Thu, 26 May 1994 21:47:58 -0400 Received: via switchmail; Thu, 26 May 1994 21:47:57 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Thu, 26 May 1994 21:46:07 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Thu, 26 May 1994 21:46:06 -0400 (EDT) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4c.411 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Thu, 26 May 1994 21:46:03 -0400 (EDT) Message-Id: Date: Thu, 26 May 1994 21:46:03 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John Gardiner Myers To: imap@cac.washington.edu Subject: Re: new command proposal In-Reply-To: References: Beak: Is What I'd like to see is some back-of-the-envelope estimates of how much this is really going to help you. How many times do you expect to store flags on 5000 messages and how much does this change win, in percentage of total bandwith, response time, or whatever. We need to measure the benefits of this against the costs. Repeated assersions that "this is a really great idea" don't give much information. My server is going to have to do some not-trival foot-shuffling in order to keep from sending some of those state changes on a subsequent command. There's also the fact that we have to get this spec out by the Seattle IETF. Any addition at this point needs to be met with some amount of scrutiny. I'm not saying the costs are really large, but they do exist and the gains could turn out to be negligible. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23402; 27 May 94 0:07 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa23398; 27 May 94 0:07 EDT Received: from mx1.cac.washington.edu by CNRI.Reston.VA.US id aa28891; 27 May 94 0:07 EDT Received: by mx1.cac.washington.edu (5.65+UW94.4/UW-NDC Revision: 2.30 ) id AA04034; Thu, 26 May 94 20:51:55 -0700 Errors-To: owner-imap@cac.washington.edu X-Orig-Sender: owner-imap@cac.washington.edu Return-Path: Received: from CAMIS.Stanford.EDU by mx1.cac.washington.edu (5.65+UW94.4/UW-NDC Revision: 2.30 ) id AA04028; Thu, 26 May 94 20:51:53 -0700 Received: (yeager@localhost) by CAMIS.Stanford.EDU (8.6.8.1/8.6.5) id UAA20747; Thu, 26 May 1994 20:51:49 -0700 Date: Thu, 26 May 94 20:51:47 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bill Yeager To: John Gardiner Myers Cc: imap@cac.washington.edu Subject: Re: new command proposal In-Reply-To: Your message of Thu, 26 May 1994 21:46:03 -0400 (EDT) Message-Id: John, The command I created is a little different than what Mark created, and it wasn't created in a vacuum, like wow, neat idea. Rather, I have been working on low bandwidth aspects of the protocol for a year, and about two months ago I was cleaning up a mailbox at 30 to 50 messages at a hit and it was taking a rather long time to delete messages. Sometimes 10 seconds, sometimes 30. My line can be noisy. I run PPP with all of the usual goodies - people elsewhere get 2.2kbytes per second - I often end up with .5k bytes per second. This is using ftp which is much more bandwidth efficient that imap beause the latter is bursty in nature. I look at the imap trace, and thought what a waste of bandwidth. 1 hour of hacking on the c-client/imapd, an have made what was a real pain, an instanteous improvement. Deleting 10, 50 or 5000 messages went unnoticed. My command was tag STORE +1FLAG * +1FLAG tag OK Similarly for -1FLAG. Simple, elegant, and suddenly everyone in my lab said what happened. Why is deleting so fast now. Bill   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04904; 27 May 94 12:13 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04900; 27 May 94 12:13 EDT Received: from mx1.cac.washington.edu by CNRI.Reston.VA.US id aa09970; 27 May 94 12:13 EDT Received: by mx1.cac.washington.edu (5.65+UW94.4/UW-NDC Revision: 2.30 ) id AA16825; Fri, 27 May 94 08:42:53 -0700 Errors-To: owner-imap@cac.washington.edu X-Orig-Sender: owner-imap@cac.washington.edu Return-Path: Received: from PO6.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65+UW94.4/UW-NDC Revision: 2.30 ) id AA16817; Fri, 27 May 94 08:42:51 -0700 Received: (from postman@localhost) by po6.andrew.cmu.edu (8.6.7/8.6.6) id LAA14077 for imap@cac.washington.edu; Fri, 27 May 1994 11:42:25 -0400 Received: via switchmail; Fri, 27 May 1994 11:42:19 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Fri, 27 May 1994 11:42:09 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Fri, 27 May 1994 11:42:01 -0400 (EDT) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4c.411 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Fri, 27 May 1994 11:42:00 -0400 (EDT) Message-Id: <4htVH8C00WBwIiqcd2@andrew.cmu.edu> Date: Fri, 27 May 1994 11:42:00 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John Gardiner Myers To: imap@cac.washington.edu Subject: Re: new command proposal In-Reply-To: References: Beak: Is Bill Yeager writes: > suddenly everyone in my lab said what happened. Why is deleting so > fast now. Ok, I find a report of operational experience from a prototype much more convincing. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07159; 27 May 94 15:20 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07155; 27 May 94 15:20 EDT Received: from mx2.cac.washington.edu by CNRI.Reston.VA.US id aa14471; 27 May 94 15:20 EDT Received: by mx2.cac.washington.edu (5.65+UW94.4/UW-NDC Revision: 2.30 ) id AA11713; Fri, 27 May 94 11:52:37 -0700 Errors-To: owner-imap@cac.washington.edu X-Orig-Sender: owner-imap@cac.washington.edu Return-Path: Received: from CAMIS.Stanford.EDU by mx2.cac.washington.edu (5.65+UW94.4/UW-NDC Revision: 2.30 ) id AA11707; Fri, 27 May 94 11:52:35 -0700 Received: from ssrg-ss2-1 (ssrg-ss2-1.Stanford.EDU [36.44.0.84]) by CAMIS.Stanford.EDU (8.6.8.1/8.6.5) with SMTP id LAA05520; Fri, 27 May 1994 11:52:32 -0700 Date: Fri, 27 May 1994 11:39:23 -0700 (PDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bill Yeager Reply-To: Bill_Yeager@camis.stanford.edu Subject: Re: new command proposal To: argv@z-code.z-code.com Cc: IMAP Interest List In-Reply-To: Dan Heller's message of Thu, 26 May 1994 15:32:36 -0700: <9405261532.ZM27161@zander.z-code.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > > In addition, I believe the "low-speed link" argument is not a valid > > argument for adding complexity to the base protocol. > > A very high % of Eudora users are using it over slow links, and almost > all the off-line interest of zmail users are for the same thing. Low- > speed links is a major reality here... what you want to do to optimize > the "protocol" is another discussion. > In a lab at SUN in Palo Alto, the majority of users having been using a modified IMAP server for both disconnected use, and low bandwidth access daily. I've made many, many changes to the protocol as well as to the c-client/imapd to make the user's life as easy as possible under these conditions. And we like the results. A simple example is if a user accidently reads a very large body part, then we have a stop button that causes an exchange of TCP URGENT bytes to halt this operation. Very nice and protocol independent, and necessary. The protocol changes have for the most part been to send abbreviated envelopes or what I've simply called shortinfo and the like. I don't recall them all off of the top of my head, and don't have the time to discuss them right now. So, yes, there is an interest here, and yes, it is for another discussion. Bill   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08868; 27 May 94 17:31 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08864; 27 May 94 17:31 EDT Received: from mx1.cac.washington.edu by CNRI.Reston.VA.US id aa26186; 27 May 94 17:31 EDT Received: by mx1.cac.washington.edu (5.65+UW94.4/UW-NDC Revision: 2.30 ) id AA25127; Fri, 27 May 94 14:10:56 -0700 Errors-To: owner-imap@cac.washington.edu X-Orig-Sender: owner-imap@cac.washington.edu Return-Path: Received: from nkosi.well.com by mx1.cac.washington.edu (5.65+UW94.4/UW-NDC Revision: 2.30 ) id AA25121; Fri, 27 May 94 14:10:55 -0700 Received: from z-code.UUCP (uucp@localhost) by nkosi.well.com (8.6.9/8.6.9) with UUCP id OAA16645 for IMAP@cac.washington.edu; Fri, 27 May 1994 14:11:21 -0700 Received: from zander by z-code.com (4.1/NBN-16/ZC-13) id AA09792; Fri, 27 May 94 13:52:02 PDT Received: by zander (920330.SGI/920502.SGI) for @z-code.z-code.com:cac.washington.edu!IMAP id AA29162; Fri, 27 May 94 13:57:59 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dan Heller Message-Id: <9405271357.ZM29160@zander.z-code.com> Date: Fri, 27 May 1994 13:57:57 -0700 In-Reply-To: Bill Yeager's message on May 27 References: Phones: (415) 898-8649 Fax: 898-8299 Reply-To: argv@z-code.z-code.com X-Mailer: Z-Mail (3.2a.428 28apr94) Subject: Slow links, pilot errors and IMAP To: IMAP Interest List Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii On May 27, 11:39am, Bill Yeager wrote: > A simple example is if a user accidently reads a very large body part, > So, yes, there is an interest here, and yes, it is for another discussion. Agreed. Pilot error is common, and UAs are judged by ease of use, as well as robustness. Having the protocol handle this is necessary. What's the current status for this thread of discussion? Anything at all? --dan   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15086; 31 May 94 2:15 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15082; 31 May 94 2:15 EDT Received: from mx2.cac.washington.edu by CNRI.Reston.VA.US id aa25953; 31 May 94 2:15 EDT Received: by mx2.cac.washington.edu (5.65+UW94.4/UW-NDC Revision: 2.30 ) id AA29274; Mon, 30 May 94 23:00:27 -0700 Errors-To: owner-imap@cac.washington.edu X-Orig-Sender: owner-imap@cac.washington.edu Return-Path: Received: from uucp0.iij.ad.jp by mx2.cac.washington.edu (5.65+UW94.4/UW-NDC Revision: 2.30 ) id AA29268; Mon, 30 May 94 23:00:24 -0700 Received: from wincgw1.winc.ad.jp (wincgw1.winc.ad.jp [202.15.200.1]) by uucp0.iij.ad.jp (8.6.9+2.4Wb/3.3Wb-UUCP) with SMTP id PAA02351 for ; Tue, 31 May 1994 15:00:22 +0900 Received: by wincgw1.winc.ad.jp (5.67+1.6W/4.18:3.7:winc:931216) id AA15925; Tue, 31 May 94 15:00:34 JST Received: by synapse.senri-i.or.jp (5.67+1.6W/4.18:3.7:synapse:931220) id AA08622; Tue, 31 May 94 15:00:04 JST Received: from ford.airco.co.jp by airco.co.jp (4.1/SMI-4.1) id AA15234; Tue, 31 May 94 14:37:27 JST Received: by ford.airco.co.jp (4.1/6.4J.6) id AA06053; Tue, 31 May 94 14:36:41 JST Date: Tue, 31 May 94 14:36:41 JST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Keasling Message-Id: <9405310536.AA06053@ford.airco.co.jp> To: IMAP@cac.washington.edu Subject: Question about license Hello, I am a developer of a IMAP client and have been directed to design a license server. I don't know the first thing about a license server. So, while realizing this is not the forum for such discussion am posing my questions here anyway. I know of no other place to turn. My apologies. If you have any experience with license servers either design/implementation or usage and wish to admit it in public, could you contact me? Also, if you know of a mailing list for such a discussion, please inform me. The design goal is to provide our users with a tool that will allow effective administration of our product and at the same time restrict usage to that which the customer has licensed. Thanks in advance... Mark Keasling makr@airco.co.jp   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10526; 31 May 94 14:17 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10517; 31 May 94 14:17 EDT Received: from mx2.cac.washington.edu by CNRI.Reston.VA.US id aa00253; 31 May 94 14:17 EDT Received: by mx2.cac.washington.edu (5.65+UW94.4/UW-NDC Revision: 2.30 ) id AA12649; Tue, 31 May 94 10:55:35 -0700 Errors-To: owner-imap@cac.washington.edu X-Orig-Sender: owner-imap@cac.washington.edu Return-Path: Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65+UW94.4/UW-NDC Revision: 2.30 ) id AA12635; Tue, 31 May 94 10:55:33 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67e/UW-NDC Revision: 2.27.MRC ) id AA04473; Tue, 31 May 94 10:55:32 -0700 Date: Tue, 31 May 1994 10:47:11 -0700 (PDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Crispin Subject: flush ? in wildcard matches? To: IMAP Interest List Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII It has been observed (by CMU) that there is an unfavorable interaction between % and ? that makes a correct implementation wildcard matching much more complicated than it needs to be. An example is the pattern ``%axxx?xxx%''. I fear (with plenty of historical examples) that anything that is complicated is bound to be implemented wrong. Two solutions come to mind: 1) Require that ? not match the hierarchy delimiter. This solve the unfavorable interaction problem, but may make matters more complex for the flatlander crowd. 2) Remove ? from the specification. It has been claimed that ? is not very useful. Furthermore, ? interferes with any potential use of RFC-1522 in file names (more on that later). As far as we can tell, ? as a wildcard is not used at UW or at CMU. Is there any constituency for preserving ? as a wildcard, and if so, why is it needed? If there are no objections, it'll be flushed. Also, here is a status report of the new IMAP4 draft specification. The rewrite is in the final round of pre-release wordsmithing. I expect that it will be posted as an Internet Draft sometime this week.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10597; 31 May 94 14:19 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10591; 31 May 94 14:19 EDT Received: from mx1.cac.washington.edu by CNRI.Reston.VA.US id aa01054; 31 May 94 14:19 EDT Received: by mx1.cac.washington.edu (5.65+UW94.4/UW-NDC Revision: 2.30 ) id AA23248; Tue, 31 May 94 10:54:47 -0700 Errors-To: owner-imap@cac.washington.edu X-Orig-Sender: owner-imap@cac.washington.edu Return-Path: Received: from CAMIS.Stanford.EDU by mx1.cac.washington.edu (5.65+UW94.4/UW-NDC Revision: 2.30 ) id AA23242; Tue, 31 May 94 10:54:45 -0700 Received: from ssrg-ss2-1 (ssrg-ss2-1.Stanford.EDU [36.44.0.84]) by CAMIS.Stanford.EDU (8.6.8.1/8.6.5) with SMTP id KAA27364; Tue, 31 May 1994 10:54:42 -0700 Date: Tue, 31 May 1994 10:49:07 -0700 (PDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bill Yeager Reply-To: Bill_Yeager@camis.stanford.edu Subject: RE: Slow links, pilot errors and IMAP To: argv@z-code.z-code.com Cc: IMAP Interest List In-Reply-To: Dan Heller's message of Fri, 27 May 1994 13:57:57 -0700: <9405271357.ZM29160@zander.z-code.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > What's the current status for this thread of discussion? Anything > at all? > dan, I think this thread has been snipped for now. The low-bandwidth stuff deserves a separate list I guess, and everyone is very busy getting the imap document out the door. I'm happy to put off the discussion until July sometime. Too much going on right now. Bill